How the best product teams work
The quality distribution of product teams probably resembles something like a bell curve. Most teams are in the middle: average, sometimes doing good things, sometimes not. A smaller portion are plain terrible. Then there’s the small portion at the front of the curve who are consistently excellent, and seemingly doing everything right.
So, what’s the difference between these top product teams and the rest?
TJ's Newsletter is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
I’ve been lucky enough to attend multiple workshops with Marty Cagan, where he describes how the best product teams work. It’s also exactly the fundamental differences I’ve seen in my career, where I’ve worked in teams right across the span of that bell curve.
What I’ve learned is that there is a profound difference between how the very best product companies create technology products and all the rest. And I don’t mean minor differences. — Marty Cagan
So, let’s take a look at what those differences are.
Three Types of Product Teams
Firstly, in summary, these are the characteristics of the three types of product teams you’ll generally find:
Delivery Teams (the unfortunate left side of the bell curve)
Primarily exist to serve the business stakeholders
Given features to go and build by those stakeholders
Measured by their output, rather than outcomes
Engineers are treated liked mercenaries, with little to no ownership of the problems to solve
Sometimes engineering is even outsourced
Often little or no design input
Using fake agile, or even still using some form of waterfall process
Essentially a team of mercenaries that is focused on the stakeholders more than the customers, acting like a software factory
Feature Teams (the middle of the bell curve — where most teams are)
Also primarily there to serve the needs of the stakeholders
Typically have a roadmap full of features that stakeholders have lobbied for
Do some design work and then put those features on the backlog
Celebrate releases, rather than outcomes achieved
Have product managers or product owners, but they act more like project managers
Sometimes organise in squads
Team doesn’t feel any real ownership for the outcomes, it’s all about output
Essentially a good product team, but not fully empowered to deliver results
Empowered Teams (the high performers on the bell curve)
Team exists to solve hard problems for customers
Design solutions that customers love, and that work for the business — both together
Instead of roadmaps with features to build, they’re given problems to solve
Use discovery methods to figure out the best solutions to build
Have capable customer focused product managers
Design and engineering are engaged in the discovery phase
Are responsible for achieving the desired outcomes
Essentially a strong cross-functional team collaborating together to solve difficult problems for customers, which also work for the business, and taking full ownership of the outcomes
Empowered product teams are given ownership of difficult problems to solve. They figure out how to solve them by collaborating intensely between design, product and engineering.
But they are also fully accountable for the outcomes. The team as a whole solves the problem, with back and forth between the roles. Empowered teams must have a competent and skilled product manager to be be successful, as we’ll see further on.
So, let’s focus on the things which empowered product teams do differently.
Tackle Risk Up-Front
The biggest thing to know in software development is that you do not know if something is really going to solve the problem or not. — Marty Cagan
You cannot be sure what you are building is going to solve the problem. Which is why the waterfall process has major limitations for software development; all of the risk is at the end of that lengthly process. The best teams flip this, and put put as much of the risk at the front.
There are four primary risks that teams focus on:
Value risk
Feasibility risk
Usability risk
Business viability risk
Value risk: by far the most important, and the one the product manager is most responsible for. It’s the most important, because it’s the one teams get wrong the most; building things that customers just don’t value enough.
Feasibility risk: is this technically feasible to build, to the level we need it to be, and given all of the other constraints (time, cost, etc.)? This is primarily for engineering, and is not always a straightforward thing. Particularly with something like machine learning, it may not be clear at the start whether there is a sufficiently feasible solution to the problem.
Usability risk: can we ensure the solution is usable enough for the customer to realise the value? This is primarily the responsibility of the designers. Luckily, this is something we can do a lot of upfront testing on to get right, through prototypes, mockups, live data experiments and so on.
Business viability risk: does this solution work for the business as well? It needs to fit within the numerous constraints on the business, including cost, resources, brand image, consistency, business model, privacy, compliance, etc.
There are many techniques for lowering the risk early, including prototypes, smoke tests, a/b tests, and so on. The team should be using whatever technique they can to quickly gather evidence that they are on the right track with the solution.
Discovery and Delivery as a Conceptual Model
Dual-track agile is another name for it. Essentially we have two things going on in parallel:
Discovery: the PM and designer are working together to figure out the right thing to build, iterating quickly, gathering evidence, and getting closer to the point of handing off to engineering to go build.
Delivery: engineers are working on building production-ready code based on the concepts we have developed through the discovery phase.
Some clarifications:
PMs and design are involved in both and will support engineering throughout delivery. But, it is their main job to work on discovery.
Similarly, engineers should be involved in discovery work in some capacity. You’ll want to share your insights on a daily basis to get their input, particularly for the feasibility risks. Engineers often know more about what is possible, so you’ll want to capitalise on their knowledge for discovery purposes. But most of the engineers time is spent on delivery.
Discovery is happening all the time. So is delivery. A PM will be moving back and forth between both aspects on any given day.
PM and design should not spend weeks or months on discovery for one item. It should be done in fast iterations, with the goal of gathering sufficient evidence to feel confident that the solution is valuable.
Not everything requires discovery work. Sometimes there is a clear solution that we are highly confident customers will value. Or often we just have keeping-the-lights-on work that has to be done. But for any new feature or major item of work where we have a high degree of uncertainty, we will want to do some discovery work.
The best teams are iterating around 15–20 times in a single week. This sounds remarkably high to most, but this is why the best teams are so far ahead of everyone else. They are using the array of modern techniques to gain speed in the discovery process.
An iteration can be as small and quick as a whiteboard session between the PM and designer. They share an idea, build on it, and get to a point where they agree to mock it up to show to a customer.
Or, it might be a usability test of a prototype conducted online. Several iterations on this can be done in an afternoon.
Sometimes it will be a fake door test on production with a cohort of users. An example is putting up a button for a feature and seeing how many users click on it. When they click you can mention you are thinking of building this, and let them provide some input on how they think it should work.
Realize that many iterations never make it beyond just you, your designer, and your tech lead. The very act of creating a prototype often exposes problems that cause you to change your mind. As a rule of thumb, an iteration in discovery should be at least an order of magnitude less time and effort than an iteration in delivery. — Marty Cagan
Team Collaboration
A modern product team is small, cross-functional, and collaborative. They are also accountable for a clearly-defined set of business objectives.
Primarily a product team is a product manager, a designer, and between 2–8 engineers. Remember the two-pizza rule from Amazon: if you cannot feed the team on two large pizzas, then the team is too large.
Sometimes the team will have additional roles like a user researcher, data analyst, or a product marketing manager. This depends on the nature of the work the team is conducting.
To be clear, the product manager is not the boss of anybody in the team. Everybody is an individual contributor, with line managers outside of the team. A product manager cannot be an actual manager of people, the job is far too big for that, as we’ll see later.
We need a team of missionaries, not a team of mercenaries. — John Doerr
We want our teams to be durable. They need to work closely together for a good amount of time, so that they can learn together, see the customer’s pain together, see some ideas fail and others work.
This takes time. If the problems they are tackling are challenging, then it will also take time to develop the deep expertise needed to really innovate in that area.
To create a team of missionaries, they need to take full ownership of solving those difficult problems, and be given time to work on them together.
We also want our engineers fully engaged. One of the biggest problems with the waterfall model is that engineers are brought in way too late. Too much has already been decided by the time they start building. You want your engineers engaged at the start.
The little secret in product is that engineers are typically the single best source of innovation; yet, they are not even invited to the party in this process. — Marty Cagan
Outcomes over Output
Feature teams are still celebrating releases. But nothing has been achieved with the release yet, we don’t know if it really helps a customer until it’s actively in use. Empowered teams are focusing on the outcome and measuring their success based on getting closer to a solving a problem.
An outcome could be:
Reduce the onboarding time for a new user from 1 hour to 10 minutes.
Reduce the percent of 0 result searches from 15% to 5%.
Reduce customer churn from 20% to 10%.
Increase conversion from free trial to paid plan from 2% to 6%.
It goes without saying that all product teams should be instrumenting their products. These product metrics are vital for analysing user behaviour and measuring progress. Products should have a north star metric which describes the key measurement that tells us if our product is succeeding and growing. Additionally, other product KPIs will be defined for different aspects in the product. Our outcomes will often be linked to one of these KPIs.
The typical way empowered teams organise for outcomes is with OKRs (objectives and key results). OKRs need a whole article on themselves, but in essence:
Business leaders set the objectives. These are the things we need to see happen. They are assigned to teams to go solve.
Key results are defined by the team, in negotiation with the business leaders. They determine how we can judge the success of the objective.
The team is in charge of the ‘how’, they need to figure out the best way to solve the objective.
Objectives are qualitative and ambitious. They are things that will move the company forward in a meaningful way.
Key results are quantitative.
You should not expect 100% on every key result. If so, then they are too easy. They should be tough to hit, and therefore ambitious and meaningful. 70% is considered a very good result.
Some key results are binary; we either did it or we didn’t.
OKRs are typically set once a quarter. It usually involves quite a bit of time and effort to get agreement on what is most important, and how to measure it. It’s worth the effort, because it helps to focus on what will really move the needle for the company.
Here’s a classic talk on OKRs from Google.
Objectives should be given to teams, not individuals. You want the whole product team to be working together to solve these challenges.
When a team succeeds in hitting outcomes, it’s really something to celebrate. Shipping releases is not.
The Role of the Product Manager
“The honest truth is that the product manager needs to be among the strongest talent in the company. If the product manager doesn’t have the technology sophistication, doesn’t have the business savvy, doesn’t have the credibility with the key executives, doesn’t have the deep customer knowledge, doesn’t have the passion for the product, or doesn’t have the respect of their product team, then it’s a sure recipe for failure.” — Marty Cagan
The product manager is often the weak link in the empowered team model. The designers and engineers are usually well trained in their disciplines and know how to work well in an empowered model. But the product manager has a lot more variance, and if the PM isn’t up to the job, the team can quickly unravel.
The truth is that many delivery and feature teams are the way they are, because the company doesn’t have good enough product managers that the stakeholders trust to deliver in an empowered team model.
Google created their APM program to develop higher quality talent in product management; talent which could work in the empowered way Google expects. Other’s have followed with similar programs.
Top quality product managers are a hot ticket, precisely because you need great ones to be able to run empowered product teams.
But the role of product manager is extremely demanding in this model. We are not talking about a product owner (in the scrum sense), nor a project or delivery manager.
These roles are primarily focused inwards at the business, their job is more about project delivery. This is valuable for sure, but it is only a small part of what needs to get done.
A product manager needs to be externally focused, the advocate of the customer, whilst also managing these internal aspects.
Writing user stories, managing the backlog, organising and running meetings, managing stakeholders, helping engineers with their queries, is all something a product manager must do, but it is only 5–10% of their role. The rest is focused on solving hard problems, iterating through discovery, and driving the team closer to successful outcomes.
Combining technical depth with business savvy, creativity and persistence. — Larry Page
There are four key things a product manager must cover:
Deep knowledge of the customer. They should be the acknowledged expert on the customer, their issues, pains, desires, how they think.
Deep knowledge of the data. They should understand what the customer is doing with the product. Most PMs start their day looking at the analytics tools, understanding what happened in the last 24 hours, checking the results of a/b tests, or reviewing sales analytics.
Deep knowledge of the business. Successful products are not only loved by the customer, but also work for the business. Succeeding in this role means convincing each stakeholder that you understand their constraints, and that you are committed to delivering solutions which are consistent with those constraints.
Deep knowledge the market and industry. Not only competitors, but also key trends in technology, customer behaviours and expectations. If the PM isn’t excited about learning new technologies and exploring with engineers and designers how to use these trends to deliver more value to customers, then it may not be the right career path for them.
The role of product manager is one of the most demanding in the company. Every day the PM will be pulled into discussions and meetings, talking with customers, handling queries from sales and marketing.
But every day the PM must carve out thinking time. This is focused time where the PM is thinking only about the key problems to solve, and thinking about discovery work for those problems.
The suggested benchmark from Marty Cagan is four hours a day. Four hours focused on solving customer problems, working on concepts, evaluating ideas.
To achieve this, a PM is often getting that time from 5pm-9pm, when all the meetings and discussions are done. This isn’t a popular view, but it’s the reality for many who are leading high quality product teams.
Product managers are sometimes called mini-CEOs, or the CEOs of their product. I’m not sure if this is a good label. But it highlights the importance and dedication required for a product manager if they are to work in an empowered product team model.
Team Topologies
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” — Melvin E. Conway
Essentially, how you communicate internally will reflect in the software you make. If you are organised into small modular teams, your software will tend to be modular. If you’re in large teams, with a lot of dependency and communication, software tends to be monolithic.
Conway’s Law is from 1967, but in the last ten years or so it has seen a revival. Companies have adopted a micro-services — or service-orientated — approach.
To better support this effort, start with the shape of the teams, since the structure of the code you create will follow from the design of those teams (and their communication patterns).
We should aim to limit the size of software services/products to the cognitive load that the team can handle. Software that is too big for our heads works against organisational agility.
The team topologies approach optimises for flow of change and feedback from running systems. To achieve that means restricting the cognitive load on teams and explicitly designing the intercommunications between them to help produce the software-system architecture that we need.
Broadly speaking, we have four types of teams:
Stream-aligned teams. A stream is a continuous flow of work aligned to a business domain. This could be a single product if small enough, or a service within a product, a single set of features or user journey. The team is empowered to deliver value as quickly, safely, independently as possible.
Enabling teams. They provide expertise and learning to other teams to up-skill them. For example, they may research a new JS framework, then teach it to other teams to help them move faster or more efficiently.
Complicated sub-system teams. Some products have a particular complexity in one area, which requires a specialist team to manage it. This could be an important authentication aspect like facial recognition, or a banking transaction with fraud checking process. A dedicated team can be used to abstract this complexity away from others.
Platform team. Their purpose is to enable stream-aligned teams to deliver work with substantial autonomy. Provide internal services to reduce the cognitive load that would otherwise be required for those teams. Usually the platform team is providing APIs to other teams, and we are aiming for the thinnest viable platform as possible to simplify the developer’s life.
Stream-aligned teams are the primary type of team in most companies. Marty Cagan calls these ‘experience teams’, because they focus on the experience the customer has. All other team types are there to reduce the burden on these stream-aligned teams.
Amazon is famous for moving to service-oriented teams as far back as 2002. This was a deliberate mandate from CEO Jeff Bezos to ensure that each service or application in the Amazon estate was truly independent — acknowledging Conway’s Law — and ensured that the teams would be independent as well.
You can read more about team topologies in this excellent book. You can also get some great insights into how Amazon dealt with this in the equally excellent book Working Backwards. I can highly recommend reading both.
In Conclusion
The best product teams are working in an empowered way.
They are small, cross-functional, and collaborate intensely to solve problems for the customer, in ways that work for the business. They are outcome driven and take full accountability for those outcomes. They are constantly evolving, learning and testing the best techniques for discovery. They are also far more fun and enjoyable to work in than delivery or feature teams.
I’ve captured just some of the key points of empowered product teams here, but to learn more you cannot do better than reading Marty Cagan’s Inspired and Empowered.
Would you add anything else to the list of how the best product teams work? I’d love to hear your thoughts.
TJ's Newsletter is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.