“When is the product done?” A frequently asked question to any Product Owner. The very short answer to this question; it never is. There will always be something to do. But here’s the thing; when I ask questions like “what does the Product Vision look like” to the Product Owners I’ve worked with, they can immediately shout it out. Like it’s at the tip of their tongue, waiting for someone to ask that question. And that’s awesome!
It becomes eerily quiet though when I ask how stakeholders can understand what our progress is toward the Vision and what still needs to be done to get there. My experience is that Product Owners are dealing with organizational forces “bigger” than them that inhibit the ability to drive the product. For instance, the Product Owner has to deal with prerequisite metrics or other factors that are dragging their focus away. Away from the customer and user needs. Here are three of the most common ones in my experience;
1. Pointless metrics weaken the ability to pivot
Measurements and metrics have always been a hot topic, ever since the “Agile movement” started. I’ve been working with quite a number of teams now, and I’ve rarely seen any of them checking the relative progress toward the achievement of the Product Vision. Sometimes nothing was measured when I started, sometimes the organization required hollow metrics like:
- Actual versus forecasted velocity
- Velocity increase over the year
- Utilization rate
- Senior team member turnover
Neither of these say anything about the product or the value delivered to customers and/or users. The whole point of embracing an agile mindset is so that we can capitalize on new opportunities and limit risk. If we are to focus on metrics like the ones mentioned above, the focus on value is diluted. Pointless metrics lead to pointless results.
Imagine a Scrum Team having to make sure that these types of metrics are in the “right” area, or above baseline, we don’t talk about what matters anymore. I like to call these metrics Fragile Metrics (can’t spell fragile without agile); they have the power to create a breakable situation. And all too often either the Scrum Team or the Scrum framework gets the blame for it.
2. Money is being wasted on a continuous basis
I’ve worked with the startup type of organizations as well as the big, monolithic incumbents. Something that I really value about smaller types of organizations is the desire (and necessity) to prove their next step is valuable in order to grow.
Investors want to see bang for buck, and rightfully so. Sprints are funded based on outcomes. This provides startup Scrum Teams with a necessity to think about what the most useful, valuable next step is going to be and why. Waste is limited. People’s jobs are literally on the line. Understanding and reciting the Product Vision and how their work relates to it becomes even more important.
Large incumbents, on the other hand, seem to have what I like to call “the rich company disease” where budget is made on a yearly basis for entire departments, rather than funding products and Sprints. And then there’s this:
“There’s always another Sprint”
Survival is pretty much guaranteed unless you perform poorly on a personal level (unless top-level decide to go in a different direction of course. Still, the budget is there). This in turn leads to the product dragging on forever, missing out on its potential.
3. Other opportunities may be missed due to keeping teams intact
My previous concern has another downside to it. If teams are kept in a state for too long, the point where the initial Vision is achieved and have team members available for another challenge is being delayed. Just delivering features doesn’t mean value is being added. Delay affects the ability to seize new opportunities and potential new revenue or even entire markets.
Picture this scenario:
Product A: Major cash cow, has already made a load of profit and provided a stream of revenue for years. The margin for innovation is low.
Product B: Relative newcomer or even total innovation. Yields a higher level of risk, but with vastly bigger margins.
In every single large organization that I have worked with concern #2 is being combined with Product A. Dragging stuff on for years, resulting in low ROI.
Don’t be Kodak and the digital camera.
The hardest thing that I have experienced for a Product Owner is to really own the product. Having the courage and stepping up to say no. Creating a roadmap based on features that are being pushed in. Be bold! Think back about what the Product Vision is and define a roadmap on outcomes, for instance. Think about what the product needs in order to meet the Vision. Make it as lean as possible. I’m curious, tell me your leanest product you’ve ever created.