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.

Iterate

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.

Comments

Post a Comment

Popular posts from this blog

Crossing the Rubycon

I first learned Ruby about a year ago and it quickly became my scripting language of choice; a position I doubt it will ever lose, hence the name of this blog post. Here are some of the reasons that I prefer Ruby over Python, NodeJS, and PHP, for most use cases. Testing The primary reason I prefer Ruby is how great writing tests is. Tests in ruby can be incredibly concise and natural. The built in mocking, stubbing, and monkey-patching functionality is very powerful. I particularly love the way contexts can be built up with let(:...) to have very descriptive and concise tests. The philosophy If you look at a language like PHP, it has basically no philosophy behind it, at least not a consistent one. Hence you end up with all sorts of weird behaviors. For example, consider preg_match , which finds matches of a Regex in a string: preg_match() returns 1 if the pattern matches given subject, 0 if it does not, or false on failure. Gross .  Wait, where are the results of the regex match? // 
Read more

The many benefits of working in small increments

If you're a software engineer, you've likely heard of the Single Responsibility Principle  (SRP). I believe it's the single most important principle in software engineering. The simple explanation is that one object should do only one thing and do it well. Having a well defined single responsibility makes code easier to understand, change, delete, and test. The complexity of code grows exponentially with size. Two 100 line classes, with proper segregation of responsibility, are significantly easier to understand than a single 200 line one. SRP is the "work in small increments" principle for code, and the same exponential growth in complexity applies to much more than just code. Working in small increments shortens the feedback cycle, which is the best thing any organization can do to increase its velocity. Small Tasks Every task should be small - small enough to complete in less than two weeks, ideally less than two days. Small tasks are easier to write, understan
Read more

The two qualities of great software architecture

Great software architecture solves a present business need and is easy to change when business needs change. Software architects have developed a number of heuristics: patterns and principles that help to achieve these goals. A software engineer that applies but does not fully understand these heuristics may implement them in situations that run counter to the goal. To write great software, it's important to understand how each pattern and principle contributes to the goal. Entire books have been written on most of these subjects. This is intended to be a brief overview, not an exhaustive list or explanation.  Solving a present business need Most users could look at an application and tell you whether it solves a present business need, aside from some of the more subtle nuances. For example, an application may solve one need but is not secure, which is usually one of the business requirements. Some of the criteria that may roll up to this metric, depending on your business: User ex
Read more