At the heart of every great tech company is a world-class product. But the interesting thing is the gulf that exists between the very best tech companies and the rest. This article is based on a discussion with Marty Cagan, one of the world's foremost thinkers on this topic, who talks eloquently about the difference between the world's top tech companies and the rest. Marty has held executive positions at eBay, Netscape and HP, and a number of fortune 500 companies. He's the author of the often quoted and much recommended, Inspired, how to create tech products customers love. Marty is a partner at Silicon Valley Product Group.

You can listen to the discussion in full here:

Why do so few companies have product strategies?

It’s pretty clear to me that tech companies don’t have a product strategy. They have goals of course. They have goals around growing revenue, reducing churn rate, reducing acquisition costs, increasing their lifetime values and so forth. These are all normal. Then they have roadmaps which, of course, are tactics, not strategies. They’re basically features and projects that they think will help deliver on those goals. So the vast majority of companies have some big company goals, usually set by the board once a year or so, and then they have roadmaps that they give to teams, which the teams plug away at.

This strikes me as ridiculous because in good companies, it's very different. The good companies have a strategy, which enables a plan to make sense of how they will deliver on those goals. The actual features and projects that the company ends up building emerge from that strategy. More on that later. Inbetween is product strategy.

So why don’t companies have product strategies? Partly it's ignorance. I would argue a lot of the leaders are not product leaders, so they really don't understand. Partly it's politics, especially as companies grow, in particular when they are larger enterprise class companies. They often have all these different business units and of course very limited resources with which to build. They have to find some way of divvying up the capacity among the business units. So they end up saying “all right you've got this many features you can have and this team has or this business unit has this many features” and they each get their own roadmaps basically. But again, there’s no strategy in place and I find this in stark contrast with how good companies work.

The difference between feature teams and product teams.

There are three kinds of product teams out there. Also known as squads, especially in Europe.

The most common team is really something we, at SVPG, don't see much at all and they're called delivery teams. And basically they are just there to code. That's where they have a product owner and they have a bunch of engineers and they are just there to execute a roadmap. But that's not really done in product companies, that's done in insurance companies and banks. And you know, in those giant enterprises they're not even trying to innovate. They are just trying to crank out code. Personally, I'm not interested in that. I think it's short sighted.  My concern is the other two kinds of teams that I see: feature teams; and what I call empowered product teams. What's tricky is that, from the CEO’s point of view, they look pretty similar.

In each team there's somebody that's usually called a product manager. There's somebody that's usually called a designer. And then they have somewhere between two and about ten engineers. So, at a high level, they look pretty similar. But in a feature team, they're given a roadmap and they're told to build that roadmap. In which case, the designer does a little bit of design, they might do a little usability testing, and then they give the design over to the engineers to build it sprint planning, and they build it. The product manager, in truth, is much more of a project manager, they're just herding the cats to get it from design into code and out the door. And so, they are good at delivering features. They're all about output.

On the other hand, an empowered product team isn’t given a roadmap or a list of features to build, rather the leaders give them problems to solve like churn rate or retention or acquisition cost. So they're given problems to solve, and the team’s job is to figure out the right tactics to solve that problem. And because they're empowered, they can be held accountable to the results. So those teams are measured by business result, not by output or shipping features.

Now, it's a lot harder to be an empowered product team than a feature team. Because in an empowered product team, you don't just design and code you also have to make sure the solution is valuable and viable. That customers will actually buy it, or choose to use it, that it is viable (i.e. works for your business, sales, marketing, finance, legal, privacy, etc) and that you can afford it to build it. So it's a much harder problem, a much harder assignment. When we talk about a good product company, what we see are empowered product teams.

Product strategy helps you to identify the problems to solve

The product strategy tells us which problems are the most important and is itself a major topic. One of the problems with product strategy is that people think it's like step by step, ABC, and you're done. But it’s much, much harder than that. This gets again to the distinction between those good product companies and the rest, because more than anything else, great product strategies require strong product leaders.

So what do those Product Leaders do? They focus on what's important. And, for most companies, the problem starts right there as they don't like doing that. When I say focus I don’t mean prioritize, I mean picking the one or two things that really have the chance to move the needle for your organization. And that's very difficult for most companies to do, to make those kinds of hard choices. But good organizations do that; they know how to focus. The key to product is what you don't do. It's so that you can focus in and really do a good job on what you need to do.  

I was at a company recently, and on their wall, they had a list of their top priority things and they had over 50 items. And they were all prioritized. That's meaningless, and they needed an intervention. And I tried to explain to them that, “that is not focus!” And their answer was, “you should have seen how many things we're not doing.” Prioritization is very overrated. We can do much better if we just choose the most important problems and then let the teams try out lots of ideas.

So the first part is focus.

The second part of developing a product strategy is that you need insights for the truly important things that you want to focus on, the levers that can guide your strategy. There are three major sources of insights:

1. First up is our data. That's where most of our product insights come from today, but certainly not all of them, but they're a great source of insights.
2. The second is qualitative research from talking to customers and really understanding why they do or don't use our products and what the issues are. So qualitative insights come from user research.
3. The third source of insights are from new enabling technologies. That's one thing that I love about our industry is that what's just now possible is always changing. And so you're looking at those enabling technologies and you're also looking at the industry as a whole and the learnings you can see from the industry? What are the trends? What is the competitive landscape doing?

Then the Product Leaders have to identify insights that can be leveraged to action.  

That's really the third step in strategy; to turn that into action. And that's where we decide which product teams are going to be working on which problems.

And then finally, the fourth thing is, the leaders actually have to actively manage that work because as soon as teams get going, they find dependencies on other teams, they find technologies that they have to use and license and there's 100 things that come up that have to be dealt with very actively. So we want them to be engaged and eliminate those obstacles without resorting to command and control management, which would defeat the purpose of an empowered team.

But those are the four big things for creating a product strategy: 1) focusing, 2) generating insights, 3) converting insights into action and then 4) managing the teams through success. Admittedly those are four things that most companies don't like to do, I would say, but those are the four things that good product companies consistently do. And that's really what powers their product strategy.

When organising Product Teams, it's important to distinguish between discovery and delivery.

To start with, teams in lots of locations is a non-issue. That's been the case for 20 years now, having offices all around the world and having teams in those offices. You have to go where the talent is, of course, and there is no one place in the world, starting with San Francisco, that has enough talent. That's why so many companies have offices all over the world. But where it gets tricky is when you break up a single specific product team. When that team is not in the same location things get trickier.

The whole world is getting a crash course on working from home right now which can be very disruptive to teams that are used to sitting together and solving hard problems collaboratively. And, as we now know, that's a lot harder to do over video calls. So, the main thing I'd say about remote teams where individuals are spread apart is, it really depends on whether the team is trying to optimize themselves for discovery or delivery.

When we say discovery, we mean real innovation and coming up with a solution to a hard problem.

Delivery is to actually code and ship that code. Both are critical. You don't have a product without both. But it's normal to optimize them for one or the other and sometimes at different times. And the truth is, for delivery, I don’t think there's any real disadvantage when people can work from home.  

For discovery though it's mostly a disadvantage when key people are not sitting right next to each other because the nature of the work is so real-time collaborative. It's not impossible. I know teams that do a good job at it, but it's harder. And all this is about just increasing your likelihood of success. There is a lot of confusion out there between remote and distributed teams, but be very clear. There's nothing wrong with having one or more product teams in different offices scattered around the world. That's pretty much the common practice now for larger organizations. It only becomes a real difficulty when those product teams are not together in one of those locations.

I'm a big believer that the original product leader should be one of the co-founders.

I wouldn't personally invest in a company without a product leader as a co-founder and most of the VCs I know won't invest unless one of the co-founders is a proven product leader. I like that person to be the only product leader for a while, typically through to product market fit. There's a lot of leverage to that. And at the startup stage, the product is the company.

Then you get past product market fit and the organization is really trying to scale and especially when there is a second product or a third product, creating a whole portfolio of offerings.

At a certain point the first hires are typically for the new efforts, a real Product Manager. And once you get large enough, a Head of Product. Before those positions, every company I know already has engineers, so I'm assuming that was a given. Most startups I meet have a founder, who is the product person and a set of engineers. And that's pretty much what we've got. But I'm a big fan of adding a designer as the next product hire, assuming it's a user-facing product; the product designer can get a whole lot more leverage and can be a good complement to the CEO.

When we scale by product teams there's typically one product manager, one designer and a minimum of two engineers per product team. So we can grow in units of that once we're really scaling the organization. But you know, the main thing I see go wrong on scaling is a tendency to want to lean on process.

What I mean by that is when people use, in Jeff Bezos words, “process as a proxy for doing good work”, it can very easily become all about the process. I don't think it's about the process at all. I think it's much more about the people. And so to me, the way you scale is with the right leaders and you make sure those leaders know how to develop their people. And that's really the only successful recipe I know to scale and not degrade your organization. And I think all too many companies lean on process. I don't know if you've ever heard of a process called SAFe which stands for scaled agile framework, but it's truly toxic to everything we've been talking about. And I have never seen it actually used in a technology product organization, but it is very big in those companies that love process. The old bureaucracy of the old days. And so that's exactly what I mean about what you don't want to have happen.

So I discourage that tendency to lean on process and to focus instead on the people.

What role does the product roadmap play?

Most roadmaps are just tactics.  They are features and projects and the problem with features and projects is that most of them, empirically, will end up not working and delivering on whatever the goal was. And so when we lock ourselves in to tactics for a quarter for a year, we're locking ourselves into wasted effort.

You do of course need to put your focus into action. When you convert it into action, there's really two ways to do that. First, even though I don't advocate this, if you use that product strategy to drive your roadmap, I would argue that at least as an intelligent roadmap it might be okay, but you're still going to end up wasting a lot of time. But at least it'll be things focused on what's most important.

Rather than a roadmap, I’d rather see a set of OKRs for the product teams. It's really the alternative to a roadmap. So instead of giving a team a list of features to build, you're giving them a set of problems to solve and business results to be measured against, and the irony is here, you're actually giving team business results to be held accountable to, which as you know, that's what the board cares about. That's what investors care about. That's what the company cares about, not shipping features. It’s not hard to ship features. It's hard to solve problems.

There are two things the very best product companies do incredibly well.

The first thing they do is truly empower their teams. They hire people, not to tell them what to do, but for them, these are Steve Jobs words of course, “to show leaders what's possible.”

And number two? They have serious leaders.  They invest in real leaders of product, of design and engineering. And they are active leaders. They're not just in the background, they're not passive. They're active leaders. They're not micromanaging. But it turns out there's a lot of coaching and development that's necessary if you're trying to build and scale an organization.

When shipping products, especially in B2B, customer references are the foundation of success.

There's creating the product, and then there's launching it. We talk about products for businesses and products for consumers. More specifically, if a product has a direct sales organization, like a lot of Notion’s portfolio does - enterprise, B2B, direct sales  we have to be really smart about how we launch products in that world. Because as you know, that is an extremely expensive sales channel and the worst thing we can do is waste them; it's often the biggest line item for the company. And so the short answer is if we've got a direct sales organization, the main thing we need to do to launch products well, is make sure that nothing launches until and unless we have developed reference customers. So there's a big focus in a b2b context, to make sure that we have reference customers. Before we train the sales force and have them go out, we have got us an early set of customers that we have worked with, one on one, to make sure that they are running the product for real in production and that they paid for it for real. And they love it enough that they'll tell others how much they love it. That is absolutely the best thing we can do to help salespeople sell. And so if you don't do that, there's all kinds of bad consequences that happen. The number one thing we really push hard on for direct sales products is the development of those reference customers. And then we launch the product.

Now, it's very different in the consumer world, we don't have that whole dimension. Every user is the buyer. So in the consumer world, we have to sort of debut and roll things out differently. And of course, our numbers are orders of magnitude or more. So we can have hundreds of thousands to very quickly millions of users, in some cases, billions of users. And so the way we do that is through continuous deployment. We will have a constant stream of small changes rolled out progressively. And we'll look at the data to make sure those changes are well accepted and working properly before we spread those out. So there's a whole set of techniques that are known as gentle deployment techniques.

So in conclusion, the difference between the best product teams and the rest is built upon three things: 1) having real leaders in product, engineering, 2) empowering your product teams, and 3) giving those teams problems to solve, not features to build.

If people want to learn more about Marty’s work, please visit SVPG.com. For Notion companies we are launching a SVPG Product Leaders Academy on the 5th June so please approach us for more information.