From Vision to Delivery and Outcome in the product-led organization

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:

The build trap is when organizations become stuck measuring their success by outputs rather than outcomes. It’s when they focus more on shipping and developing features rather than on the actual value these things produce. When companies stop producing real value for their users, they begin to lose market share, allowing them to be disrupted. Companies can get out of the build trap by setting themselves up to develop intentional and robust product management practices. At that point, product managers can find the opportunities to maximize business and customer value.

Melissa Perri, Escaping the Build Trap p. 1

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 Strategy
    • 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 Strategy
      The Product Strategy guides which OKRs to work on
      Main responsible: Head of Product
    • 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 Outcome
      The Outcomes are the Key Results in the OKR framework
      Outcome can be seen as a measurable change in customer behavior

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 DiscoveryDARE 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.

Dual-track agile


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.