Product Success
Exactly a year ago I was invited to give a keynote at the Craft Conference in Budapest and I discussed the 10 biggest reasons why product teams fail. You can read the narrative article here.
As I mainly shined a light on why so many teams are operating so ineffectively, and despite claims to the contrary, most product organizations are hardly “agile” in any meaningful sense of the term, as the organization overall is still operating in a very waterfall fashion, the conference organizers invited me back again this year to give the sequel, to discuss more about how the best teams I know work.
Last week I delivered that talk, and this article is a narrative version.
After the first talk quite a large number of people contacted me and asked for more information about the alternative. Other than recommend to people that they read my book or attend a 2 day workshop, I didn’t feel like I was able to give a very satisfying answer. So it inspired me to think hard about the most important characteristics of very strong product teams, and I forced myself to pick what I consider the ten most important.
CONTINUOUS DISCOVERY AND DELIVERY
Just as I described the ten biggest problems in the context of the Waterfall model, I described the ten attributes of successful teams in the context of the Continuous Discovery and Delivery model (also known as Dual Track Agile, or Discovery Sprints and Delivery Sprints).
KEYS TO SUCCESS
1. Empowered Product Teams
The most important characteristic of all is the absolutely fundamental concept of a strong product team. But what does that really mean?
First, it’s essential that the team is durable; the members are not meant to be moved around like chess pieces. If they want to actually innovate, they need the time to get to know each other, their technology, their customers, and the business context.
Second, the chemistry of the members of the team is key. This means that the know and respect each other enough that every member of the team feels comfortable contributing and raising suggestions, and challenging themselves and each other to do better.
Third, this means that teams have the necessary skill-set diversity, which is typically product management, user experience design, and engineering. In many cases we would add to this list data analysis and user research.
Finally, despite being a sensitive topic for many companies, it is hard to argue with the advantages of a co-located team. Co-location means that the product manager, product designer, and the engineers (or at least the tech lead) all sit right next to each other. We can’t always achieve co-location for all of our teams, but we try. And just to be clear, having teams in multiple locations is not the issue, it’s when a single team is split up that causes the negative impact to both velocity and especially innovation.
2. Product Vision and Strategy
In order for a product team to actually be empowered and act with a meaningful degree of autonomy, the team must have a deep understanding of the broader business context. This starts with a clear and compelling product vision, and a path to achieving that vision, which is referred to as the product strategy.
The product vision describes the world we are trying to create, typically somewhere between 2 and 5 years out (longer for hardware efforts).
The product vision must be inspiring. When done well, it is one of our most effective recruiting tools, and motivates people to come to work every day. Strong technology people are drawn to an inspiring vision. They want to work on something meaningful.
The product strategy is our sequence of products we plan to deliver on the path to realizing the vision. It would be a very poor strategy to try to please everyone with a single product release. Instead, we have a prioritized list of markets, geographies, or personas and we focus on achieving product/market fit for each of these markets.
The more product teams you have, the more essential is to have this unifying vision and strategy in order for each team to be able to make good choices.
Most importantly, the product vision should be inspiring, and the product strategy should be very intentional.
3. Focus on Business Outcomes
The second part of the business context that an empowered, autonomous team needs in order to be able to make good decisions is the set of prioritized business objectives. The OKR (Objectives and Key Results) system is intended to facilitate precisely this.
The OKR’s reflect the list of specific business problems that the team is being asked to solve. These are not features. Features are only potential solutions to problems. Launching a feature is not success for a team; solving the actual business problem is.
The two principles that are behind these performance management techniques are: first, teams will perform better if you give them the problems you need them to solve, rather than give them the solutions; and second, the team is measured by results, not output. Shipping features on a roadmap is output, solving business problems are results.
4. Competent Product Manager
Sadly many engineers have never had the opportunity to work with a capable product manager. The ones that have are the ones insisting that they always have such a person on their team. Even worse, many engineers don’t even know what the product manager is supposed to be contributing to the team.
Think of it this way. In order for a product team to solve hard business problems, it’s not enough that the solution just work technically, and it’s also not enough that the customer loves it, but also, and often most difficult, the solution must actually work for your business.
Think about what this means. Imagine you are working for Uber or AirBnB and you have to navigate complex laws and unions and trade groups. Or eBay which had to navigate significant constraints to be classified as a marketplace rather than an e-commerce site. Or Tesla which had to navigate liability issues with Autopilot. Every company has a list of these types of constraints.
There are legal constraints, financial constraints, sales and pricing constraints, brand and marketing constraints, privacy constraints, security constraints, partnership conditions, and the list goes on.
Unfortunately, in many cases the only person that has done the work to understand all of them is the CEO, and if that’s the case, you can imagine why he or she might not feel comfortable truly empowering the team to make decisions.
There are really three options to how teams work. One is that the CEO or some other exec decides everything. The second is that the weak product manager schedules a big meeting and invites all the executives into a room and they argue it out – this is called design by committee – which consistently produces weak results. The third is that the product manager does her job and learns these constraints, and brings them to the team so that the team can figure out the best way to solve the problem.
Combine this with strong understanding of technology, and deep knowledge of the users and customers, and hopefully you can see why this is a tough job. But also one that’s absolutely key to a strong product team especially if the team wants to have any meaningful degree of autonomy.
5. Collaboration-driven Solutions
I am not saying “collaboration” here as a buzzword. What I mean by this is that rather than a product manager handing down “requirements,” and a designer making things pretty, and engineers just there to code what they are told to, instead, the three skills – product, design and engineering – truly collaborate to solve the problems. This is because with good solutions, the technology drives the functionality as much as the functionality driving technology. The technology enables design options as much as design drives technology selection. And design direction drives functionality as much as the other way around.
The point is that the technology, the user experience design, and the functionality, are all completely intertwined. We come up with good solutions with a constant back and forth, give and take, between the three.
The need for these collaboration-driven solutions is the single biggest reason why co-located teams consistently out-perform distributed teams.
6. Product Discovery: Learn Fast
Much of great product boils down to the ability for the team to try out lots of ideas quickly. We want to quickly separate the good ideas from the bad. Product discovery is a broad set of techniques intended to help us learn quickly which ideas will fly and which are not so great. Some ideas are big and some are small. Some are risky and some are expensive. Sometimes we need proof, and sometimes we just need evidence.
Lots of people describe this is different ways. Some like to describe this as “fake it before you make it” and some like to emphasize the “build things that don’t scale” point. The key is we need to learn fast and minimize waste.
Using the engineering team to build and release actual products in order to try out an idea is considered the slowest, most expensive way to learn.
7. Focus on Key Risks
There’s a couple important points to emphasize about product discovery.
The first is that we need to focus on the four key risks: value risk – would anyone buy this or choose to use it?; usability risk – would they be able to figure out how to use it?; feasibility risk – can our engineers build this with the technology available, the time available, and the skill-sets available on the team?; and stakeholder risk – are the different parts of the company ok with this proposed solution?
In product discovery we are looking for good answers to these four questions. If so, we have the evidence and confidence we need to have the engineering team spend the time to build and deliver a product quality and scale solution.
8. The Role of an MVP
The concept of an MVP is one of the most important concepts in product yet it’s also one of the most abused and misunderstood concepts.
It’s always dangerous to generalize, but I’m going to go out on a limb here and argue that an MVP should never be a product. In every single case I have ever encountered, when the team spent the time and the money to build an actual QA’d product as their MVP, I have always been able to show them afterwards how they could have accomplished the same learning at much less cost and waste.
So an MVP is an experiment; a test. It’s usually one of the forms of prototype. Often that’s a user prototype, sometimes it’s a live-data prototype, sometimes a feasibility prototype. And sometimes they’re hybrids. In every case, it’s a fraction of actually building out a real product.
9. Product Delivery: Release with Confidence
My point here is not to tell developers how to build and release software. Actually quite the contrary. One of the issues that comes from the prior issue where teams use the engineering team to create these MVP’s, is that the engineering team is often pressured to release software that they know is not really something that should be released. It’s not something they feel comfortable standing behind. There might be major reliability issues, or scale issues, or performance problems. But the product manager keeps saying “it’s just an MVP, so relax!”
I’m suggesting here that when it comes to software that your customers are actually depending on to run their business, you should not compromise. We have plenty of good product discovery techniques for testing MVP’s in ways that protect our customers, our revenue, our reputation and our own employees.
So use your best practices, and only release true products to production when you have the necessary confidence in that release.
10. Obsess Over Customers
The final point I’d like to make is a bit different. Nearly every company I meet tells me how much they love their customers. It’s usually somewhere in their company values or mission statement, but I have to tell you that it’s easy to say the words, but much harder to actually follow through.
I can tell pretty quickly when I talk to the team. If a customer production issue comes up, how do they respond? What level of urgency is there? Does the team reach out directly to customers to understand if they need to? Do team members know customers by name? What type of relationship do they have with customers? Do they consider the customers a big pain, or do they consider them more like colleagues?
The best way to instill this true empathy for and commitment to customers is to connect the team, including and especially the developers, directly to customers.
I hope this gives you a better sense of what makes great product teams great.
