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 axioms lead to our 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.