How do we come from our vision to delivery and Outcome? And why talk Outcome and not only Output?
Melissa Perri has written a whole worthy-to-read book Escaping the Build Trap explaining exactly, why we need to focus on Outcome and not only on Output:
A lot has been (see e.g., my list of inspirational sources) and is being written about the inner working of a truly product-led organization. It is easy to get information overload and lose the bigger picture on how the various entities fit together from the high-flying Vision to the day-to-day execution in the product teams. The ambition with this post is to provide such an overview.
Understanding the big picture end-to-end in the product-led organization
If you’re not familiar with the OKR framework, you might want first to visit the previous post on Finding the rhythm with OKRs and Product.
If you’re new to the concept of a product-led and agile organization, you might also want first to read the post, We need business agility in our high-tech Product company.
Finally – if you want some thoughts on the delicate balance process prescription and flexibility, you might want to read this post and this post.
Now having the basics in place, let’s try to understand the links from the top-level strategies to the day-to-day activity execution. Done right, the organization will achieve highly aligned yet (fairly) autonomous teams focused on producing Outcome and have integrated learning as a core element in its culture.
How it all links together
Below I’ve illustrated three levels of focus / abstraction. In practical terms (unless we’re talking a very small organization) we’ll have additional levels covering e.g., Team OKRs.
- Product Vision
The Product Vision is a subset of the full Company Vision
It serves as a common North Star for the organization
Main responsible: Head of Product
- Product Vision
- Product Strategy
The Product Strategy guides which OKRs to work on
Main responsible: Head of Product
- Product Strategy
- Product Goal
Mid-term (1-5 years) high-level objectives leading us to achieve our vision
The Goals are the Objectives in the OKR framework
- Product Goal
- Product Outcome
The Outcomes are the Key Results in the OKR framework
Outcome can be seen as a measurable change in customer behavior
- Product Outcome
Note: In this simplified illustration, we’re going directly from the strategic OKRs to Product Discovery (in the Product Teams). In practice you’ll often have a further break-down of OKRs to the Product Team level with a quarterly cycle.
We’re now at the Product Team level, assuming that relevant Team OKR’s have been agreed with the Product Teams.
Remember that the Product Teams are empowered to Discover the best Solutions to the Problems (aka Objectives). The Product Teams are thus not presented with a given solution / set of features to implement (which would make the Team a Feature Team and not a Product team).
A lot of different techniques exist doing Product Discovery (read e.g., Continuous Discovery Habits, Product Discovery, DARE or INSPIRED) , all sharing the same core principle: generate ideas (called “ideation”) / hypothesis and test these in a disciplined way. Some hypothesis test valid, others fail (read: we’ve learned new insights).
Another core principle is not to start Development activities before the given hypothesis has tested valid.
Some product teams prefer to have “clean” sprints with either Discovery or Delivery. Others (more mature) product teams are able to shift context during the same sprint. This is also known as Dual-track Agile.
Wrap-up
The essence here can be boiled-down to one of the essential take-aways from Henrik Kniberg’s classic video on the Spotify Engineering Culture: Teams / squads being
- loosely coupled (we’re highly focused on what problems are being worked on in which teams thus actively minimizing hard dependencies between teams)
- tightly aligned (the teams share the same North Star)
Ready for more reading? You might want to (re-) read the article on how to achieve high-paced innovation.