Feature design process

Every time I start work on a new feature, these are the steps I follow to increase the likelihood it will either be a success or never get released.

Understand Why

This is always the first step I take because it determines all the follow-up steps. You can't understand how until you understand why. It's often valuable to follow the five whys method. Make sure you really understand the root cause, not just the symptom. If it was raining and you had a leak in the roof of your house, would your first step be to mop up the water, or would it be to stop the leak? The answer depends on the size of the leak. Too many solutions fix one symptom without fixing the real problem. On the other end of the spectrum, it's easy to get bogged down in fixing root causes that aren't worth the effort. You don't always have to solve the root cause, you just need to know what it is.

Come up with at least two solutions

Engineers are often handed a solution instead of a problem. I believe this is a serious misuse of engineering talent. Engineers are usually the ones most aware of similar problems, most familiar with potential solutions, and most capable of estimating the work required for each. So, if you're an engineer that's been handed a solution to a problem, make sure you understand the problem and come up with multiple solutions. When you know each of the five whys, see if you can find a solution to each one.

Weigh your options

This is the hardest part since each option's apparent value and work required is often hard to measure. A few questions I like to ask myself:
  • Does this require an engineering solution?
  • Do I have a solution to each of the five whys, or do I need to revisit some of them?
  • Can we leverage something off-the-shelf to solve this?
  • Can we solve 80% of the problem with 20% of the work?
  • How difficult is each solution?
  • How much impact will each have?
  • Is a solution that is twice the effort worth it if it's four times the impact?
  • Do I need to put a temporary solution in place then come back with a root cause fix?

Prototype the riskiest part

Engineers often think prototype means a technical prototype: something that proves a technology or a method. But business value is often the riskiest part. No-code prototypes such as power points, wireframes, and prototyping tools are great ways to get signal on the business value before you even start coding. It's a good idea to create 2 or 3 prototypes of different solutions. Show these prototypes to end users if possible, business stakeholders if not, and try to gauge the business value. Have the courage to propose not doing a task that is not worth the time.

Get input

Now that you have your bases covered, is there anyone that needs to see the results of the previous exercises and have input on this feature? Ideally you are in an empowered team model where these would be people you regularly work with. This is the best time to get any input that you need, e.g. from PMs/design/compliance/legal/security.

Small roll out

If the feature has made it this far without getting scrapped, you may have a great new feature coming! The next step is to do a roll out to a small portion of users with the simplest version of the feature possible. Don't worry about making the code great at this point or covering every edge case - the goal is to get feedback from real live users in a controlled setting. The code should be easy to release, toggle on/off, monitor, and delete. Don't be afraid to write throw-away code for this - even if it's going to be on the main code branch. Consider labeling any new classes or components with "Experiment" in the name.

Measure business value

Does this code solve the problem it set out to for real users? Is this feature generating enough business value to be worth long-term maintenance? Do you need any additional metrics in place to make sure you're getting the most value out of this feature? Scrap the feature here if it is not clearly worth keeping - don't fall for the sunk cost fallacy.

Refine it

If you've decided that this feature is worth the effort to maintain, refine it until you are happy with the code quality and coverage of edge cases. Don't be afraid to scrap previous work or use it as a reference in a full rewrite. While the code is still under a feature flag is a great time to make sure the code is top quality, the business value is measurable, and any alerts/monitoring have been added.

Release it to everyone, and celebrate

Congrats! You have a fancy new feature which is delivering measurable business value for the organization. Now is a great time to announce it and celebrate the accomplishment.


Be cautious about iterations that add complexity to the code but don't add business value. Consider running them behind an experiment and removing them when they are not delivering business value. You may even want to follow this full feature process for each iteration - but don't be too overzealous with simple requests that don't add complexity. Code complexity has a carrying cost, the more you can avoid adding low-value code, the happier everyone will be.

This is a lot of work, won't this slow us down?

I often hear some form of this argument against spending time on prioritization. Engineers hate prioritization because it doesn't feel like progress, and sometimes prioritization takes longer than actually doing the easy solution. But the purpose of this exercise is not just to avoid writing low-value features. Writing a feature is only a small portion of the job - maintaining them is often much more work! Say no to low-value features: they are not worth the cost.


Popular posts from this blog

Crossing the Rubycon

The many benefits of working in small increments