Product leadership is not so much about progress on features, but whether changes have the desired effect on achieving business objectives.
In practice you rarely see the relationship with the strategic goals and, more importantly, the right conversations about what each epic or feature will contribute to the overall strategy. This makes it very difficult for everyone to understand what is really desired and what goals should be pursued.
This article explains how to set up a value driven product thinking flow that will result in continuously contributing to strategic goals. Not as an answer to scaled agile frameworks but as a value focussed addition to it. Something that will enrich the whole scope of what is agile product development.
Driven by objectives, validated by outcomes
Below is something I would call a typical product flow. In this flow you start with strategic goals and transform them in a controlled way to working software that your users can use:
When we remove all execution related subjects the, very simplified, backbone of this flow looks like this:
More on this flow and how to set it up can be found here: A practical guide for getting ideas to production.
How to close the feedback cycle
The success of the flow and elements described lies in the fact that they should be measurable/validatable anyway possible. We continuously need to be able to validate whether our ideas were good ideas or not. What measurable values will determine if we are successful?
Are we seeing the changes in behaviour, increase or decrease of usage, conversions we want to achieve with this idea?
Hypothesis driven
The way to guarantee we also follow the carefully created objective driven approach in the execution is by making assumptions and making sure we validate whether they are right. A way to do this is by using the following format for epic, features and user stories:
We think that by implementing <capability/feature/option>
We will solve/Will give the opportunity <problem>/<new possibility>
For <persona>
We know we have succeeded when <measurement>
Validation after: <duration>
Current situation: <baseline>
This way we make sure we don’t skip the success/failure criteria when designing the functionality. In reality we just have to abandon seemingly great ideas from time to time since we are not able to prove their use or benefits they bring.
By clearly stating the success/failure criteria and making these measurable over time we can track the progress quite easy:
All elements of the flow
How about scaling?
Now we’ll bring it all together. The representation used above is a simplified and single product case but scaling doesn’t necessarily mean more complexity. When using the flow as described we now can create the whole picture of agile portfolio management from a value perspective instead of the planning of individual products. We can only make sure we make the right decisions when we regard the whole context any product is part of:
All business cases and products are built around the strategy and so all gathered feedback has a direct link to the objectives from this strategy. Whenever something is not helping towards achieving strategic goals then action is needed. And nine times out of ten the solution is not writing more code. It is often things like marketing, training or stakeholder management.
When looking at the way this way of managing the portfolio in structured we can also clearly distinct the different levels of validation that are linked in this flow:
A matter of controlled successes and failures
In the example below we can see that one of the products derived from a business case has a positive impact while the other doesn’t. Since the business case is created to support the strategic goals, we can conclude that we are not maximising impact on the strategy at the moment. We need to either inspect and adapt the not so successful experiment or choose to abandon it and remove the functionality. The only thing we can’t do now is to ignore it.
Goal validation above all
Instead of mostly having the focus on quarterly planning it’s preferable that CPO’s , PM’s and PO’s also have a focus on continuous goal validation. Measurable strategic, business and epic goals we track over time.
This way the conversation within product leadership isn’t so much about the progress on features but whether new functionality or changes have the desired effect regarding the reaching of business goals. And if not, it forces us to inspect and adapt.
If you would like to learn more please check out the Value driven product thinking course.