Starting the Product Roadmap with Why
For a product engineering team, building software is fun! It is even more fun to solve problems. When the two combine, it creates a state of flow and brings joy to everyday work.
If this resonates with you, does it often match with what you see in practice? Let’s explore.
Conventionally, product development has been driven by feature roadmaps drawn out on a timeline to go with product releases, planned at a regular cadence. For the more agile product delivery process, the release timeline is more of a factor of product readiness than a fixed release date. In both scenarios, however, the view from engineering is feature focussed. A feature set, aka a set of solutions, that product team envisions would benefit the customers or help the business bring revenue or possibly both. The engineering team takes that as a marching order and starts building.
The process above is familiar to many of us and surely also the associated pitfalls. The decision dilemma is commonly around features versus releases timelines. Is the delivery date more important or the feature set on the roadmap? The decision-making process gets clouded with assumptions and leads to confusion.
Products may get built and delivered. The outcome may or may not hit the target. The joy of problem-solving is missing in this journey. And also one key element — the Why.
Why are we building the product? Why do we need the features? Why do we think a set of features are needed by a fixed time?
Without any answers to these questions, there is a lack of clarity and purpose. With no clear vision, there is disengagement. The product team focuses on the deadline and the release outputs and takes eyes off of the release outcomes. The engineering team builds features without knowing what problems these are solving if any. Ultimately, there might be a release celebration, but not a celebration of problem-solving.
What if we start with the Why and What?
What if we start with a roadmap of user problems that we want to solve, in an order of priority.
This will be the guiding force to help envision the product outcomes.
The thinkers and the builders can now engage and participate in a process to identify the path to connect these two.
This leads to a list of product features with a clear purpose and goal and a line connecting the output(feature) to the outcome(goal) and back to the problem.
Let the folks who can build the best software take it from here — owning the problem as well as the solution.
With the Why, What and How well defined — this will bring clarity and connection.
A different starting point will alter the product development and delivery trajectory, and will hopefully bring back the joy in building a product.
