Product teams create value
Product teams create business value by solving user needs. When we solve user needs, we can extract some of the value we create for the business – this is how we make money (and pay everyone’s salary).
When we create value for our users, we can extract some for ourselves For a business to have longevity, then the value product teams generate for users should be defensible in some way. This prevents competitors offering a similar product or service to our users, and eroding the value we can create.
“How will your product delight customers, in hard to copy, margin-enhancing ways?”
Gibson Biddle, ex VP Product Netflix
Gibson Biddle articulates the purpose of product teams very succinctly. We need to:
- Delight our customers by creating lots of value for them. Far more than they can get elsewhere
- Do this in a way that is hard to copy, so that the value persists, and is not quickly eroded by competition
- Extract some of the value we create as margin for the business, to fund operations and future investment
We want to provide something of value, unique to us 
Examples of companies delivering against a user need in a unique way Creating value requires investment
Building software is expensive. Typical cross-functional product teams have 6-10 people in, spread between product managers, designers and engineers (and likely other specialists too!). Whilst compensation and team size will vary wildly by company, as an order-of-magnitude estimate, think of each product team costing $1m per year to run. The team needs to create that much value each year to pay for itself, and several times that to deliver a reasonable rate of return. Whilst product teams like to concern themselves with solving user needs, from a purely financial point of view, the money going into product development could be spent elsewhere if it’s not delivering a return.
Business invest in development, and need a return on that investment One way to think about this is that as the team goes through discovery, it’s investing time understanding the problem and potential solution. This time is mainly the PM and designer, and discovery is usually fairly light on headcount, and therefore much cheaper than delivery. When delivery starts, then the costs mount up quickly, as the engineers get involved, and a team might have 4-6 engineers for each designer and PM. The longer discovery and delivery take, the more costs are accrued by the business, and the more value a feature will need to create to be worthwhile.
Worked example of time to value for e-commerce marketplace Outcomes are more important than outputs
Outcomes are much more important than outputs When we think about product teams in this way, it is clear that the measure of success for a team is the impact it has (i.e. the outcome). What the output of the team is – shipping lots of features – is important, but only as a necessary step to creating an outcome. Shipping things is not the goal itself. You need to ship the right features in the right way to generate impact.
Outputs vs. outcomes for different businesses Risks that prevent outcomes
When we look at how you could ship features without generating impact, there are four categories of risk:
- Value risk – Do customers really want this? Do they value it?
- Business risk – Can the business deliver this? Does it create operational complexity? Is this legal?
- Usability risk – Can users understand this? Do they know how it works?
- Technical risk – Can we build this? Is it scalable, secure and reliable?
If the goal of the product team is to reliably create value for users and the business, then managing these risks is the main business of the team. Furthermore, it’s important that we address the biggest risks up front, and reduce risk as far as possible before starting development to maximise the impact the team can have – otherwise we’ll be wasting time on features that aren’t going to have the impact we’re looking for.
Product operating model helps manage risk
Product teams have an operating model to manage all these risks in a systematic way. This is the way that we build products, and at its core is the idea of reducing as much risk as quickly as possible.
Operating model helps reduce risk in a systematic way Conceptually, the operating model looks like a double diamond with four phases:
- Discover – Understand which problems we could solve to create value for user
- Define – Define a specific problem to solve
- Design – Generate different solutions which could solve the problem
- Deliver – Build and release one specific solution
In practice, this is rhythm of meetings and set of documentation that map to these phases. Product reviews between the phases allow the team’s thinking to be challenged and strengthened by external stakeholders – typically product leadership and representatives from other departments. Product Requirements Documents record the progress the team has made defining the problem, the solution and the readiness of the feature for launch.
The process here should help accelerate and magnify the impact of teams, by helping them manage risk, and avoid wasting efforts on features that will not deliver impact. At the same time, the leadership ultimately accountable for the performance of the team can get reassurance that the team is working effectively, and can provide more support if things aren’t heading in the right direction.
Just as shipping features themselves does not necessarily lead to impact, neither does strictly following a given process. The process only has value in helping the teams deliver outcomes, and should be kept as lightweight as possible to ensure the teams are getting more out of it than they are putting into it.
Tackling biggest risks first
As features move through the double diamond, risk should be reduced, and the team should focus on removing the biggest risks first. This minimises the time wasted working on features that aren’t going to deliver impact, which is a frustrating experience for everyone. Managing risk is difficult though. It’s hard to put a firm number on how much risk is associated with a feature, and people often become emotionally attached to ideas as they begin to take shape.
One way to keep everyone honest and as objective as possible about the potential of a particular feature is to use a confidence scale. Confidence is the inverse of risk. As we reduce risks, our confidence increases. Measuring risk in a standardised way like this, helps teams and stakeholders make informed comparisons and trade offs.
Confidence Scale Dual track development
Whilst the diamond lays out development as a linear process, this can be misleading. It is linear in the sense that we shouldn’t build things that haven’t been through this process – e.g. going into delivery before defining the problem can lead people to question where we are even solving the right problem. But at the same time, it is iterative, with later steps informing previous ones. When we user test one feature, we gain insights for both the feature we are building and future features we might build. This is a continuous process that is never complete or “done”.
Development is both linear and iterative, with features in different stages simultaneously FAQs
How confident should we be about a feature before shipping it?
This depends on the amount of effort required to build the feature. The overall goal here is to maximise the impact of the team, and minimise wasted effort. Something that will take several weeks or months to build should have substantial effort put into building confidence before development starts. But for a feature that can be built in a day, the maximum wasted effort is a day, so we should only spend a fraction of this building confidence before getting on with it.
How do we deal with senior stakeholder’s pet projects?
This will depend on your internal company culture, but rarely can these be completely ignored. The trick is generally to draw the project through the same steps as everything else, rather than stonewall it or rush it through. Senior stakeholders are usually quite smart, and have good reasons for believing in certain features. And they often get impatient, and jump straight to advocating solutions over winning the team round to their point of view. Get them to explain how their idea contributes to the problems you are trying to solve, what proof points they’ve seen, and how they prioritising it against other initiatives in their own mind. This won’t solve all your problems, but should help everyone think around it more objectively, with a more aligned view on where it sits in the priorities.
Does the team own the entire double diamond process? What about leadership?
Teams generally own more of the process the further right you go on the diagram, and leadership own more towards the left. Exactly how this works in practice will depend on the size of the organisation and culture of your organisation. It’s common for leadership to give significant context into where teams should focus, so that there is a coherent vision amongst a number of teams. At the same time, it’s poor generally a bad idea for them to get too involved in the details, as they won’t understand them to the same level as the team who owns the problem space.
Further reading
