An 80/20 Rule for Product Development

At Numeric, we have learned to make great progress with a small team. For any software startup this is essential. Incumbent players will have an established product, multiple years’ head start, and far more resources and people. And yet, it’s not unheard of to see comparatively tiny companies rapidly catch up in an existing market. How?

The answer, of course, is that many different things must come together to make this possible. For us, one particularly important component has been how we approach discovery and product development, which depends critically on our belief in an “80/20 rule” for new feature development.

Consider a “traditional” approach to product development:

1. Pain point is identified and information is gathered (led by product managers)
2. Design and feedback process (designers are now brought in the process)
3. Documentation and requirements are formalized
4. The project is handed off to engineering, who have their own approach for building

‍

For a lot of reasons, teams tend to operate in this model even if they didn't start this way. In many teams which claim to be "agile", the process will be largely the same but just repeated on smaller pieces. Or, in some cases, the "agile" practice only exists within the execution of step 4.

‍

At Numeric, we hold a few beliefs which reveal problems with the above approach:

1. There is more than one way to solve a problem, and both product and technical insights can introduce new ways of looking at a problem.
2. Identifying which details and requirements are valuable (or essential) requires deep understanding of the audience.
3. It's notoriously difficult for non-engineers to know the relative difficulty of technical tasks, and often small details and non-critical requirements drive disproportionate effort and cost.

‍

Taken together, these lead to a conclusion:

For most product goals or pain points, there exists some solution that achieves 80% of the value with 20% of the effort, but finding it requires combining deep understanding of engineering, product, and users.

‍

The problem with the "traditional" approach then becomes obvious–if engineering is only brought in after requirements are formalized, we've lost the ability to leverage this flexibility in defining the solution.

Once the "define the solution" phase has been solved and documented, the core shape and definition of the solution is largely set. Engineering may push back on aspects at the fringes but it's unlikely the plan will be dramatically reoriented. Not only have we missed the possibility of a more optimal solution, but this pattern creates a frustrating and unsatisfying role for engineering to occupy.

Alternatively, we can work to combine customer insight, product understanding, and technical knowledge at every stage of development. Engineers provide insight into what's difficult, what's easy, what's possible and what's impossible. The product manager (or anyone with insight into the customer) can elucidate the goals: who are we are serving, what's necessary or nice-to-have, what's certain or experimental.  And the designer can synthesize these ideas into a concrete, usable proposal. Together, these constraints encourage the kind of creative problem-solving that yields a great product which can be quite different from the first proposal and delivered in a fraction of the time.

This approach vastly shortens the timeline to learn more from customers after launching. And for early startups, this makes the difference between success and non-existence.

It's not easy to do this. The domain, the customers, the company size, the members of the team and other variables can help or hinder the effort. But when done right, the result is a fast-moving and collaborative process with impressive results to show for it.