The product roadmap is a work of fiction

As a Product Manager I always struggled with; maintaining the product roadmap and, in order to feed the roadmap, requirements gathering. I was constantly expected to present the roadmap to different groups within the organization like it was supposed to mean something. I could tell people what was going to be in the next release but why did they care so much about what came after that? Did it make them feel good that some request they’d put in was still on there?

I made it clear that this was a moving feast and that we had to respond to the day-to-day demands of running the business. And yet we went on with this fallacy, week in week out. I wasted time updating it and we all wasted time talking about it.

I guess it’s all part of the human desire for certainty yet we all know there’s no such thing as certainty. Requirements gathering was the same, for it to appear on the roadmap it had to be identified. Once identified there was an expectation that my team would spend time creating documentation, describing the requirement in some detail, so that the development team had something work with.

Assumptions

The problem with all this is that requirements are assumptions. There are aspects of requirements that are enforced, for example when software must function according to a legal requirement, but how it does it and whether it will indeed work are assumptions. Assumptions that can only be proved, or disproved, through implementation. When a product is wholly defined upfront one of two things can happen. Either you realize early on that many assumptions are in fact wrong and huge swathes of documentation needs to be rewritten. Or, more worryingly, and perhaps more commonly, you continue regardless and build a complete product based on incorrect assumptions.

Telling stories

Fortunately software developers realized this a long time ago. In Agile Development a construct called the User Story is used to capture requirements. User Stories are user focused and goal driven. Who are the users of the product and what business value are they trying to produce? They are lightweight and promise further discussion only when the team are ready to implement them, not a moment sooner. Agile Development advocates frequent delivery of working software, typically in one or two week iterations. This allows assumptions to be tested early and often using real product.

Proving, or disproving, an assumption informs the remaining requirements. As the details of each requirement are only fleshed out immediately before they are built the team are working with the most up-to-date information regarding that requirement. They can apply knowledge based on the correctness of the previous assumptions and adjust the remainder of the requirements as necessary. These frequent re-assessments of the requirement pool also allow you to rationalize what’s in there. When I left my previous company we had a customer specific requirement on the roadmap for a customer that was, sadly, no longer a customer!

Being agile

Agile development practices are starting to take hold across many disciplines, not just software development. There are many unanswered questions around how it scales and exactly where it works but it’s certainly a more pragmatic way to approach projects based on assumptions. Isn’t it time we let the Product Managers into the secret and let them use their time more efficiently?