This article is part of a series aiming at demystifying the Product Operating Model.
We’ve seen earlier that the Product Model is all about setting up organizations to consistently innovate at speed. Fantastique! But, how does it deliver on this promise? What’s the key thing that makes it possible? What’s really different from other models? In this article, we’ll delve into the key insight and the core idea that underpin the whole Product Model.
Focus on Outcomes
It’s all about Outcomes! That’s the key insight that powers the whole product movement. Outcomes are magical because they lead to customer and business value. Really? Let’s quickly cover how it works.
Here is a visualization of that insight, inspired by Jeff Patton. For more details, check this article.
As knowledge workers, we spend most of our time working on things—call them epics, features, stories, or any other term—that we believe bring value, directly or indirectly, to our customers. These things generate customer outcomes when they address genuine problems, open new opportunities, or help customers embrace beneficial behaviors. They create value when enhancing customers’ lives by making things safer, simpler, more efficient, or cost-effective (probably in this order of priority).
Customer outcomes are generated when we make things
easier, safer, better, faster, cheaper
If you get it right, it becomes a win-win: your solutions make your customers awesome and in return they stay with you, buy more or even recommend your offerings to others. This ripple effect eventually leads to positive business outcomes – or impact – for your company, in the form of increased revenue, access to valuable data, more knowledge capital, or any other valuable thing for you.
Clearly, true success is then about generating more outcomes, and eventually more impacts, faster than your competitors. Interestingly, it also means that, in the long term, you do not improve organization revenues by focusing on revenues, but by improving customer outcomes. The key insight here is that success isn’t a game of outputs maximation: it’s all about maximizing outcomes while minimizing outputs.
The Problem: Help we’re stuck in Outputs!
The big problem is that traditional organizations structures are geared towards output maximation. Budgeting mechanisms, projects, roles and competencies, processes, leadership styles and more, are designed for action. Leaders tend to love actions as they are binary (done or not), easy to communicate, measure and report (how many X have we done?). In contrast, the result of these actions – the outcomes – are notably fuzzier and prone to interpretation. It’s about the experience of the customers and users, where feelings may be involved. It’s so hard that, in the best of cases, actions only a have partial positive impacts on an outcome, and most of the time even have a negative one. That’s really hard, so let’s keep it simple! Let’s measure that which we can control: actions, not impact! As a result, you end up maximizing outputs. Eventually, this game makes organizations blind to creating meaningful impact or addressing real customer problems. As Melissa Perri describes it, it’s the ‘build trap’: companies miss opportunities to create products that resonate with users.
There is another key structural mechanism at play that keep organization stuck in outputs: Proxies. There are always many proxies, layers and handovers. These appear often in large organization as a mean to scale. The problem is that proxies are mandate thiefs. Proxies naturally retain and delay information, usually obfuscating the context and the ‘why’, thereby removing the responsibility for the customers’ outcomes from the development teams. It becomes someone else’s job, somewhere else ‘higher up’ in the org, to come up with the value narrative: which customer segment to focus on, what problems to solve for them, and what solution to propose. So, the team is simply remote controlled, implementing someone else’s ideas. Even worse, when trickling down to the team, these ideas tend to mutate into rigid “requirements”, stripping away their original value as hypotheses and stifling open dialogue. This has several effects:
- As the team is left to “implement” outputs, the discussion with the rest of the organization becomes naturally centered around output optimization: “when is it ready?” (time), “can we cut down this part?” (scope), “why is it so expensive?” (budget). It becomes the type of discussion you’d have with a contractor when renovating your bathroom or kitchen. Jeff Patton refers to this as the Customer-Vendor anti-pattern.
- Interestingly, the problem is self-reinforcing as these hand-over layers make for poor feedback loops. As the information is filtered by each layer on its way back, it loses its actionability. Feedback and becomes an unusable cold shadow of itself. Little insights can be generated, and therefore outcomes – if any managed to be generated – are hardly improved.
Obviously, this is not how it is done in the “best”, product-led, organizations! Why? It’s because these orgs believe in one defining core idea that makes all the difference!
The Core Idea: the Empowered Engineer
The defining core idea that differentiates the “best” from the “rest” is the idea of the Empowered Engineer. As Marty Cagan puts it “If you’re just using your engineers to code, you’re only getting about half their value”. The Product Model is built on, and requires, this idea.
What does this idea mean? Marty’s quote suggests that engineers often have a wealth of potential that the “best” organizations can tap into. By their position in teams at the edge of the organization, engineers have key insights on the customers’ and users’ pains, needs and wants. When you pair that with the engineers understanding of tech and its possibilities, it makes them ideal candidates to propose feasible and usable solutions. Marty also suggests that a well-rounded team will consistently outperform a few specialists, regardless of their ability. This core idea also contains the seed of a different work culture, one that promotes engagement and motivation by distributing mandate and power to the edge of the org.
Why only Engineers? Why not marketeers, or “business people”? Engineers are meant here in a broad sense: everyone contributing to the creation of customer value. Perhaps, a better formulation for you would be “the idea of the Empowered knowledge worker” or “contributor”, or why not “people”?
The Product Model
Let’s put it all together! Armed with our key insights (focus on outcomes), and with our core idea (the empowered engineer) when can now re-invent our team to become an Empowered Team, a team of empowered people! Empowered to do what? Empowered to manage customer and business outcomes!
For a team to manage outcomes, it needs to be given a small number of significant problems or opportunities to solve, and to be able to decide the best way to solve those. This means that the team members are taking the responsibility for customers or business outcomes, not only tasks. Of course, the team measures success by the outcomes created, not by the (many) outputs they generate. As a result, an empowered team is autonomous and not remote controlled anymore.
Going back to our definition of the Product Model from the first article: The Product Model helps you consistently deliver innovative products that customers love, in a way that keeps them aligned with your business ambitions and needs. This is how it does it: using an Empowered Team.
In the next article in this series, we will double-click on the Empowered Team. How does it even work? What components and competencies are needed for it to work?
