How to ship

How Senior engineers take a feature from start to delivery

Introduction

While interviewing during my job hunt, I was asked how I’d take a feature from start to delivery.

I think it's a great question because it reveals how the candidate thinks through the entire development cycle. The thinking and understanding here differentiate more senior developers from junior ones.

Let’s start with the interview question I got: “You’re given a feature. What’s your general approach from start to delivery?”

General steps

1. Ask why

The first step is to ask the “why”. Why do we need to ship this feature to customers?

From my experience, if enough data hasn’t been gathered, this could delay the feature until more data has been gathered.

By “data”, I mean the information that explains the “why” behind the feature.

If you have enough data, you will be more motivated and also work on the right thing.

2. Identify MAVP

Identify the Minimum Actually Viable Product (MAVP). What is the minimal thing you can ship that still offers real user value?

Instead of shipping the entire feature, you want to break it into milestones. The first milestone would be the MAVP.

To learn about the MAVP, you have to learn about your users and thoroughly understand the “need” for the feature. This is also why you need the first step to do this step successfully.

Here, you will want to break the feature into milestones with the first iteration being the MAVP.

I wouldn’t worry too much about the future milestones. They can be broken down into rough assumptions. Once you reach those milestones, you will have much more clarity about what to work on.

3. Simplest technical solution

When working on something new, we often have to come up with a technical solution. It’s easy to think that whatever is seen as the “common” or “best” solution in our industry for a particular problem may be the right solution.

But, simplicity is key. You want to identify the simplest solution for your situation.

Keep YAGNI (You’re Not Gonna Need It) in mind. Do not implement something you don’t need. Focus on the present moment and find the simplest solution to satisfy the current requirements.

This may sometimes be a solution that would typically look ugly in a different situation.

4. Break into tasks

Once you have the idea for the technical solution, break the MAVP into clear and small tasks.

This is good for several reasons:

• To not get overwhelmed.

• Easier to review the pull requests.

• Transparency on how the work is going.

5. Feature flagging and rollout

You will want to implement feature flags as you work through the tasks. Feature flags enable you to turn on the feature for specific users in different environments, such as development, staging, and production.

For example, in the staging environment, you may not want to show the progress of MAVP to everyone to avoid making it look messy. But you still want to show it to your Product Manager and Designer for feedback.

With feature flags, you can roll out a feature incrementally or to all users.

It’s a good practice to roll out the feature incrementally. You can enable the feature for a subset of users and gather early feedback, e.g. based on location.

This way, you can already improve the feature based on user feedback before rolling it out to all users.

6. Validate assumptions and gather feedback

Once MAVP has been launched, the first milestone, you want to validate the assumptions you had.

The assumptions often come from the initial “why” behind the feature.

• What’s the problem?

• What do customers need?

• How is the feature expected to solve this?

  • What do we aim to achieve?

You want to gather user feedback and validate your assumptions.

If you didn’t achieve what you aimed for, why? What went wrong?

If you did achieve what you aimed for, what did you do right?

7. Improvements and following milestones

In this step, my preferred approach is to first look at user feedback and try to improve the feature based on that. It’s important to stay agile and not work on the “next” milestone because you feel you have to.

What matters most is customer satisfaction.

If you plan on working on the next milestone, you can prioritize which milestone to work on based on user feedback.

Important note

This is a general approach taking a feature from start to delivery.

I said “you” all the“, but I want to emphasize that this is all done with the team.

For example, you might set up a brainstorming session with a few developers to identify the simplest technical solution.

Or you will write an RFC and have it reviewed by team members.

Speaking of RFC, I have a template.

Conclusion

In the real world, developing a feature from start to finish isn’t as easy as working on it and getting it shipped.

The general steps we went through would be a pretty Senior answer.

Someone who is more Junior might start by breaking it into smaller tasks and likely mention Feature Flagging not to break production.