Ken Schwaber is often quoted as saying, “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.” While that is true – it is the minimum – most organizations want to know something about timeline and, even more importantly, Product Managers need to know if the product is achieving the desired results and resonating properly with the intended customers. This is where the three-legged stool of Product Management comes in:
The legs of the stool:
- Product Vision
o High level vision of who the customers are and what their needs are
o A list of attributes that we think the product must have to meet the customer needs (not features)
o A prioritization of customer types and needs
o Some thoughts about how we’re going to make money from this product
o Truly, a set of Observations, Hypotheses and Predictions about the market and customers the product is designed to serve
- Product Roadmap
o A more tactical view of the strategy laid out in the vision document
o Should start to break Product Attributes (from the vision) down into Features and Epics
o Based on the prioritized Customer Needs from the vision, an order of execution is laid out – identify what the scope-boxed releases will be.
o Essentially, a description of the tests and the order or execution to prove or disprove our Hypotheses in the Product Vision
- Agile Execution – The product backlog
o This is where the majority of time is spent by the most people
o This is where the product development takes place
o Features and Epics are decomposed into bite-sized Stories in the Product Backlog
o Scope-boxed Releases are broken up into time-boxes Sprints that contain Stories
o This is the execution of the experiments whose results will further influence our vision – the feedback loop.
Of course, as the metaphor suggests, if any one of these is missing the stool is unstable and mostly unusable: your product fails. It’s shocking to see the frequency at which Product Managers jump right into Agile Execution and forego the Produt Vision and Roadmap. In fact, most product organizations that I’ve seen do this and while that may work initially, it makes it very difficult to change a product’s momentum (or even a company’s momentum) and react to dynamic market conditions. A great example is Microsoft and their newfound irrelevancy. More on this later…
For organizations that do succeed in creating a Product Vision, without a Product Roadmap it becomes very difficult to create a coherent feature-set that aligns back to the Vision and iterate on that feature set. It also becomes nearly impossible to provide realistic timelines to investors, management and other stakeholders. There is often the perception that “Agile” means dates aren’t provided but that’s simply not true, it’s a symptom of a poor Product Roadmap.
When the stars (or stool legs) align and a Product Manager spends time creating a Product Vision, creating the Product Roadmap and then executing on that plan using Agile this creates a truly iterative process where hypotheses about the market can be tested and quickly reacted to. The most important Customer Needs from the Product Vision are targeted first in the Product Roadmap where features are identified to meet those needs and the MVP (Minimum Viable Product) is developed through the Agile Execution to test the markets reaction to those features. If it’s a success, execution against the Vision via the Roadmap continues unchanged. If it’s less than successful, changes are made to the Vision and the Roadmap and we execute on our new hypothesis.
By iterating, measuring and mutating we can systematically deliver successful products to the market with minimal risk and cost.
