Shreyas Doshi is one of the best product leaders in the public sphere to learn from. So when he mentioned that he was launching a course on Maven, I immediately grabbed a spot in the first cohort. Here’s my summary of the course, the structure, key points, and overall opinion of whether it’s worth it.

In Summary (tl;dr)

The course is aimed at senior product managers or leaders. If you are just starting out, this course isn’t for you. It focuses primarily on designing your career. Shreyas has had an incredible career thus far (Google, Stripe, Yahoo, Twitter), and he lays out what he’s learned, the decisions made, how he thinks about choices, and some harsh truths that are probably too nuanced for Twitter.

Thanks for reading TJ's Newsletter! Subscribe for free to receive new posts and support my work.

Bottom line for me: this is a fantastic course to take if you’re in product. I’ve held senior positions for some years now, but always felt like I needed to plan my career and skillsets more intentionally, this course has given me a lot to think about and kickstart that process. I guarantee that for most product managers, you will get a lot of value from these two days with Shreyas.

But, anything new from Shreyas?

I’ve consumed a lot of content from Shreyas already, so I wasn’t sure what would be new here. But there was plenty, and one of the most important aspects of the course is Shreyas’ transparency about how he got to where he is — he shares everything from salary and equity, txt messages with recruiters, email exchanges on offers (all sensitive parts blocked out of course), and he shares his frustrations with himself and his experience. The level of openness throughout the course is refreshing, genuinely valuable, and one of the key aspects of the course.

This is what makes it feel like Shreyas is talking to his fellow peers in a humble but honest way. The kind of conversation you really want to have with somebody like Shreyas.

Course Setup

• Hosted on Maven, led by Shreyas personally, but with a team of four Maven moderators and ‘Sherpas’ assisting.

• It’s over a weekend, which is something I really liked. There’s no need to take time out of work, and on a weekend it’s more relaxed and gives you time to think about the content.

• Four hours on Saturday, and four hours on Sunday. There are 3–5 minute breaks at various points in the agenda.

• There’s a bunch of additional resources and links to consume before and after the sessions — this is rich and valuable in itself.

• About 220 people were on the course, from all over the globe. All were experienced product managers. A lot from top tier companies.

• Sessions are recorded and the videos are available for download — this is a major plus point.

• You are assigned to ‘career circles’, around 8 people, this is where you do some breakout sessions with your peers. There were only a few, but they were fun and useful.

• At the end of each day is a 1 hour AMA with Shreyas, which is optional and recorded. I found that most people stayed for this, and it had a lot of value.

• Shreyas plays snippets of recorded interviews he has done, the full videos are available in the resources. They are high quality.

• The course costs $750.

Course structure

There’s an official agenda, but it’s only a few points and doesn’t really convey the depth to which Shreyas goes. So I’ve made a bullet point list of some of the key talking points in both days — it’s not exhaustive, but it should give you a feeling about the topics.

Day 1

• Overview of Shreyas’ career journey

• Gaining competence faster as a PM, core skills: strategy, communication, editing

• Deb Liu on career planning, and what your future self needs from you today

• The Pygmalion effect: high expectations lead to improved performance

• Set a 3 year lighthouse goal

• Deep dive on lighthouse goals, with real ones from Shreyas’ career

• Shortlisting companies you would like to interview at

• Understanding tech company tiers — 1 to 4, and generational companies

• Why tier 1 companies matter so much

• Breakout exercise: defining your tier 1 and 2 companies

• Crystal Widjaja on her process for getting hired

• Powerful resources for finding great companies to work for that most people don’t use

• Take a 20 year horizon, with 5–7 bets throughout

• Chris Johnson on how top tier recruiters work

• Spend at least 1% of your time each month learning about roles and companies

• Austin Brizendine on keeping your eye on the market

• Exercise: updating your LinkedIn headline

• Sharing of lightbulb moments across the group

• AMA with Shreyas

Day 2

• Tactics for working on your résumé, and examples of Shreyas’ résumé

• Tactics for interviewing

• Kent Beck’s 3X framework

• The top 3 questions to be asking that separate you from most people

• What the types of interviewers care about most

• Take home assignments companies give out, the good and bad

• Diya Jolly on her interview experience at Okta

• Breakout exercise: sharing interview and hiring process tactics

• Getting offers: the many ways we fool ourselves, and how to recognise the traps

• How to pick between offers: tables-stakes, ego, joy framework

• Money, scope, title framework

• How to evaluate the calibre of talent at a company

• Negotiating compensation

• How to get recognition: competence and reputation are the foundations

• Diya Jolly on doing a good job first, be in the top 20%

• Deb Liu on the importance of communication, there is a bias for those that do it well

• Recognition is a function of your scope, outcomes, outputs, and visibility

• Noam Lovinsky on Google vs Meta ways of measuring performance

• Lenny and Shishir Mehrotra interview on the PSHE framework

• Diya Jolly on working on the most important priorities your company has for impact

• The types of managers you encounter, and understanding the spectrum

• Diya Jolly on making your manager an ally in your progress

• Deb Liu on getting your manager on your side, and not putting them on the back foot

• Exercise: fill in the promotion drivers template with your own situation

• What is success for you? Stack ranking the key factors. This was powerful!

• AMA with Shreyas

Course Resources

As well as the two days with Shreyas, there’s a whole bunch of materials you get access to (and more to come I believe), plus the community and discussion from your cohort remains there indefinitely.

Here’s a list of some of the resources you get. It’s high value material, and in combination with the sessions it makes the $750 fee an absolute bargain in my opinion.

• PM career skills map

• Resources for improving strategy, communication, and editing skills

• Examples of 3 year lighthouse goals

• List of sources to locate interesting and early stage companies

• At least 6 private conversations recorded with top tier recruiters, and product leaders

• More interviews are coming, which you also get access to

• Company tiers exercise from all breakout groups: hundreds of companies listed

• Shreyas’ PM career bible

• Recordings of both day 1 and 2 sessions

• List of all other participants in the course

Thanks for reading TJ's Newsletter! Subscribe for free to receive new posts and support my work.

Being data-driven is simplistic. A machine can make decisions based on data. Algorithms can be made to choose the best path forward based on data. If it’s simple for a machine to do it, where’s your added value?

The truth is that to be a great product manager, you need to be driven by strong instincts more than anything else. The best product managers, the founders of companies, are guided by strong instincts for what customers want. Most of the time when going from 0 to 1 there is no reliable data to go on, and you must rely only on instincts.

Data is useful, it can help lead to insights, sometimes really powerful ones. But you want to be data-informed, not data-driven. It’s a subtle but important difference.

The mental model

As a PM, you need to build a mental model of your customers, taking all kinds of inputs, from quantitative and qualitative sources. The best product managers tend to have an extraordinary level of empathy for their customers, they can see things the way the customer sees it. Data alone doesn’t allow you to empathise enough to create this kind of rich model.

Relying on data as your primary source is lazy — we have lots of tools to collect and organise data now, it’s doing the work for you. The hard stuff is qualitative and experience related. You need to talk to customers, see their world, see their needs. Read about the problem space, talk to experts, see what other solutions exist, look at adjacent spaces. It’s total immersion to create that mental model which gives you confidence to make good decisions.

The problem with focusing so much on data is that you tend to focus more on things which are easily measurable. You end up knowing a lot about the numbers, but not a lot about the why.

Some things are hard to measure, but it’s those things which often lead to breakthrough insights about unmet needs.

But why is data driven so popular?

Because the big companies talk about it so much.

And if you work for one of the giant tech companies, then it does make sense that you are strongly led by data, for two reasons:

1. These companies have an insane amount of data about their product usage and users. It’s so far ahead of what most companies have in reach and scale. When looking at the practices of these companies, you need to take their unique context into account. They are not like you. But yet their practices get widely adopted by others who have an utterly different environment.

2. These companies have so many employees, that they need a way to have some control over their PM’s decision making. If they operate on a strong data-driven principle, then it adds a layer of control over what can change. It would be hard to say to 1,000 product managers: go learn about your customers, develop incredible instincts for what they want, then go build it!

It’s also true that if you aren’t a very good product manager, and you haven’t immersed yourself in the field to cultivate that deep understanding, then you definitely better cling to the data, it’s your only hope.

Instinct first, data second

The reality is, most products get created by people with a strong instinct for what to build. Most successful products make it through their initial phases of growth based on this instinct. In later phases when it’s more incremental in nature, then data becomes a useful tool for deciding what to iterate on, what to optimise.

But recognise the difference here: instinct is greater than data. Instinct is what the better builders develop and use, and data is what the lesser builders need.

Google’s initial search product was born from the strong instincts of Larry and Sergey. They had a deep insight about a better way to do a search engine. But since then, the overwhelming majority of Google’s homegrown new products have been failures — probably built by data-driven PMs. Their successes have come from acquisitions — YouTube, AdMob, DoubleClick, XL2Web (became Google Sheets), Writely (became Google Docs), Tonic Systems (became Google Slides). These were all built by founders with a strong instinct for solving a problem.

I’ve spent my career working for founders of product companies. In every case, the founder created something based on gut feel. They were immersed in a field, it provided an insight, they took that and ran hard with it. They trusted their instincts. Only when they hired people who didn’t have that same level of instinct did the question of data suddenly become relevant.

Instinct first, data second.

I heard about the LNO framework from Shreyas Doshi. For a product manager, it’s a powerful way of thinking about your todo list, to ensure you’re delivering valuable output consistently.

It started when Shreyas joined Google. He had a hard time keeping pace with the high performance environment. He had his first child shortly after starting. He was working long hours, tired, feeling overwhelmed and stressed.

Unsatisfied with his output and a never ending todo list, it was really starting to take its toll on his personal life. Searching for solutions, he hit on the LNO framework, it was a game changer.

Your tasks are not created equal. Categorise them into three types (L, N, and O):

L = leverage tasks

• You can get 10x or 100x in return for the effort you put in, they offer significant leverage for you

N = neutral tasks

• You get roughly what you put in, or maybe a little more sometimes, but not by much

O = overhead tasks

• You get back less than you put in, sometimes a lot less

People tend to treat these tasks the same, they all sit on the todo backlog together. This was the epiphany Shreyas had at Google; among the things in the todo list, there were very few L tasks. Yet these are the tasks which propel you forward.

It made sense to focus a lot on those L tasks, and to work on them when feeling most energetic and productive. Allow your inner perfectionist to shine, spend more time on them than you normally would. Indulge yourself.

Then, spend less time on N and O tasks.

N tasks, just get them done quickly with minimal effort. Take chunks of time to blitz through them in one go, don’t worry about perfection.

For O tasks, actively do a bad job on them, cut corners. Your inner PM perfectionism will most likely prevent you doing a really poor job, but try and set the bar as low as you can for O tasks. Don’t wordsmith it perfectly, don’t fuss over every detail, just get these things off the list.

A simple example is writing up notes from a meeting. Is this meeting important? Was the CEO or product leader on the call? Are the topics of high consequence? If so, this could be an L task if you do it well - people will use these notes, they could be the basis of a strategic decision. If the meeting was routine and low consequence, maybe no-one will even read them, so it sounds like an O task, do it the quick and dirty way.

Some days N and O tasks will take over. It’s fine, but recognise it. Set yourself the mission of clearing those N and O tasks in a day or two.

Then block out time for the L tasks, don’t context switch. Change location for them, like at a coffee shop or different room in the house, it will force a change in your focus.

Creating regular time for L tasks will increase the value of the output you create, and create leverage for you.

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.