by Marty Cagan
Those startups skilled and fortunate enough (it usually takes both) to get to product/market fit are ready to tackle another equally difficult challenge: how to effectively grow and scale.
There are many very significant challenges involved in growing and scaling a startup into a large, successful business. While it's an extremely difficult challenge, it is, as we say, a good problem to have.
In addition to hiring lots more people, we need to figure out how to replicate our earlier successes with new, adjacent products and services. At the same time, we need to grow the core business as fast as possible.
In growth stage, we typically have somewhere between about 25 and several hundred engineers, so there are many more people around to help, but the signs of organizational stress are everywhere.
Product teams complain that they don't understand the big picture—they don't see how their work contributes to the larger goals, and they're struggling with what it means to be an empowered, autonomous team.
While it's an extremely difficult challenge, it is, as we say, a good problem to have.
Sales and marketing often complain that the go‐to‐market strategies that worked for the first product are not so appropriate for some of the new products in the portfolio.
The technology infrastructure that was created to meet the needs of the initial product is often bursting at the seams, and you start to hear the term “technical debt” from every engineer you speak with.
This stage is also tough on leaders because the leadership style and mechanisms that worked while the company was a young startup often fail to scale. Leaders are forced to change their roles and, in many cases, their behaviors.
But the motivation to overcome these challenges is very strong. The company is often in pursuit of a public offering or, perhaps, becoming a major business unit of an existing company. As well as the very real possibility of having a significant and positive impact on the world can be very motivating.
CHAPTER 5
Enterprise Companies: Consistent Product Innovation
For those companies that succeed in scaling and that want to create a lasting business, some of the toughest challenges still lie ahead.
Strong tech‐product companies know they need to ensure consistent product innovation. This means constantly creating new value for their customers and for their business. Not just tweaking and optimizing existing products (referred to as value capture) but, rather, developing each product to reach its full potential.
Yet, many large, enterprise companies have already embarked on a slow death spiral. They become all about leveraging the value and the brand that was created many years or even decades earlier. The death of an enterprise company rarely happens overnight, and a large company can stay afloat for many years. But, make no mistake about it, the organization is sinking, and the end state is all but certain.
Strong tech‐product companies know they need to ensure consistent product innovation.
It's not intentional, of course, but once companies reach this size—often becoming a publicly traded company—there are a tremendous number of stakeholders throughout the business working hard to protect what the company has created. Unfortunately, this often means shutting down new initiatives or ventures that could re‐create the business (but potentially put the core business at risk), or putting up so many obstacles to new ideas that few people are willing or able to drive the company in a new direction.
The symptoms of this are hard to miss, starting with diminished morale, the lack of innovation, and how much slower it is for new product work to get into the hands of customers.
When the company was young, it likely had a clear and compelling vision. When it achieves enterprise stage, however, the company has largely achieved that original vision and now people aren't sure what's next. Product teams complain about the lack of vision, lack of empowerment, the fact that it takes forever to get a decision made, and product work is turning into design by committee.
Leadership is likely frustrated, too, with the lack of innovation from the product teams. All too often, they resort to acquisitions or creating separate “innovation centers” to incubate new businesses in a protected environment. Yet this rarely results in the innovation they're so desperate for.
And you'll also hear lots of talk about how it is that large, enterprise companies such as Adobe, Amazon, Apple, Facebook, Google, and Netflix have been able to avoid this fate. The organization's leadership team wonders why they can't do the same. The fact is they could do the same. But they'll need to make some pretty big changes, and that's what this book is about.
CHAPTER 6
The Root Causes of Failed Product Efforts
Let's start by exploring the root causes of why so many product efforts fail.
I see the same basic way of working at the vast majority of companies, of every size, in every corner of the globe, and I can't help but notice that this is not close to how the best companies actually work.
Let me warn you that this discussion can be a little depressing, especially if it hits too close to home, so if that's the case, I'll ask you to hang in there with me.
Figure 6.1 describes the process that most companies still use to create products. I'll try not to editorialize yet—let me first just describe the process:
FIGURE 6.1 Root Causes of Failed Product Efforts
As you can see, everything starts with ideas. In most companies, they're coming from inside (executives or key stakeholders or business owners) or outside (current or prospective customers). Wherever the ideas originate, there are always a whole bunch of things that different parts of the business need us to do.
Now, most companies want to prioritize those ideas into a roadmap, and they do this for two main reasons. First, they want us to work on the most important things first, and second, they want to be able to predict when things will be ready.
To accomplish this, there is usually some form of quarterly or annual planning session in which the leaders consider the ideas and negotiate a product roadmap. But in order to prioritize, they first need some form of a business case for each item.
Some companies do formal business cases, and some are informal, but either way it boils down to the need to know two things about each idea: (1) How much money or value will it make? and (2) How much money or time will it cost? This information is then used to come up with the roadmap, usually for the next quarter, but sometimes as much as a year out.
At this point, the product and technology organization has its marching orders, and they typically work the items from the highest priority on down.
Once an idea makes it to the top of the list, the first thing that's done is for a product manager to talk to the stakeholders to flesh out the idea and to come up with a set of “requirements.”
These requirements might be user stories, or they might be more like some form of a functional specification. Their purpose is to communicate with the designers and engineers what needs to be built.
Once the requirements are gathered up, the user experience design team (assuming the company has such a team), is asked to provide the interaction design, the visual design, and, in cases of physical devices, the industrial design.
Finally, the requirements and design specs make it to engineers. This is usually where Agile finally enters the picture.
Anyway, the engineers will typically break up the work into a set of iterations—called “sprints” in the Scrum process. So maybe it takes one to three sprints to build out the idea.
Hopefully the QA testing is part of those sprints, but if not, the QA team will follow this up with some testing to make sure the new idea works as advertised and doesn't introduce other problems (known as regressions).
Once we get the green light from QA, the new idea is finally deployed to actual customers.
In the majority of companies that I first meet, large and small, this is essentially how they work, and have worked, for many years. Yet these same companies con
sistently complain about the lack of innovation and the very long time it takes to make it from idea to customers' hands.
You might recognize that while I mentioned Agile, and while almost everyone today claims to be Agile, what I've just described is very much a waterfall process. In fairness to the engineers, they're typically doing about as much Agile as they can, given the broader waterfall context.
Okay, so that may be what most teams do, but why is that necessarily the reason for so many problems? Let's connect the dots now, so we can clearly see why this very common way of working is responsible for most failed product efforts.
In the list that follows, I'm going to share what I consider to be the top‐10 biggest problems with this way of working. Keep in mind that all 10 of these problems are very serious issues, any one of which could derail a team. But many companies have more than one or even all of these problems.
Let's start at the top—the source of ideas. This model leads to sales‐driven specials and stakeholder‐driven products. Lots more to come on this key topic, but for now, let me just say that this is not the source of our best product ideas. Another consequence of this approach is the lack of team empowerment. In this model, they're just there to implement—they're mercenaries. While almost everyone today claims to be Agile, what I've just described is very much a waterfall process.
Next, let's talk about the fatal flaw in these business cases. To be clear, I'm personally in favor of doing business cases, at least for ideas that need a larger investment. But the way most companies do them at this stage to come up with a prioritized roadmap is truly ridiculous and here's why. Remember those two key inputs to every business case? How much money you'll make, and how much it will cost? Well, the cold, hard truth is that, at this stage, we have no clue about either of these. In fact, we can't know. We can't know how much money we'll make because that depends entirely on how good the solution turns out to be. If the team does an excellent job, this could be wildly successful and literally change the course of the company. The truth, however, is that many product ideas end up making absolutely nothing. And that's not an exaggeration for effect. Literally nothing (we know this from A/B testing).
In any case, one of the most critical lessons in product is knowing what we can't know, and we just can't know at this stage how much money we'll make.
Likewise, we have no idea what it will cost to build. Without knowing the actual solution, this is extremely hard for engineering to predict. Most experienced engineers will refuse to even give an estimate at this stage, but some are pressured into the old t‐shirt sizing compromise—just let us know if this is “small, medium, large, or extra large.”
But companies really want those prioritized roadmaps, and to get one, they need some kind of system to rate the ideas. So people play the business case game.
An even bigger issue is what comes next, which is when companies get really excited about their product roadmaps. I've seen countless roadmaps over the years, and the vast majority of them are essentially prioritized lists of features and projects. Marketing needs this feature for a campaign. Sales needs this feature for a new customer. Someone wants a PayPal integration. You get the idea. But here's the problem—maybe the biggest problem of all. It's what I call the two inconvenient truths about product.
The first truth is that at least half of our ideas are just not going to work.
The first truth is that at least half of our ideas are just not going to work. There are many reasons for an idea to not work out. The most common is that customers just aren't as excited about this idea as we are. So, they choose not to use it. Sometimes they want to use it and they try it out, but the product is so complicated that it's simply more trouble than it's worth, so users again choose not to use it. Sometimes the issue is that customers would love it, but it turns out to be much more involved to build than we thought, and we decide we simply can't afford the time and money required to deliver it.
So, I promise you that at least half the ideas on your roadmap are not going to deliver what you hope. (By the way, the really good teams assume that at least three quarters of the ideas won't perform like they hope.)
If that's not bad enough, the second inconvenient truth is that even with the ideas that do prove to have potential, it typically takes several iterations to get the implementation of this idea to the point where it delivers the necessary business value. We call that time to money.
One of the most important things about product that I've learned is that there is simply no escaping these inconvenient truths, no matter how smart you might be. And I've had the good fortune to work with many truly exceptional product teams. The real difference is how you deal with these truths.
Next, let's consider the role of product management in this model. In fact, we wouldn't call this role product management—it's really a form of project management. In this model, it's more about gathering requirements and documenting them for engineers. At this point, let me just say that this is 180 degrees away from the reality of modern tech product management.
It's a similar story with the role of design. It's way too late in the game to get the real value of design, and mostly what's being done is what we call the “lipstick on the pig” model. The damage has already been done, and now we're just trying to put a coat of paint on the mess. The UX designers know this is not good, but they try to make it look as nice and consistent as they can.
Maybe the biggest missed opportunity in this model is the fact that engineering gets brought in way too late. We say if you're just using your engineers to code, you're only getting about half their value. The little secret in product is that engineers are typically the best single source of innovation; yet, they are not even invited to the party in this process.
Not only is engineering brought in way too late, but the principles and key benefits of Agile enter the picture far too late. Teams using Agile in this way are getting maybe 20 percent of the actual value and potential of Agile methods. What you're really seeing is Agile for delivery, but the rest of the organization and context is anything but Agile.
This entire process is very project‐centric. The company usually funds projects, staffs projects, pushes projects through the organization, and finally launches projects. Unfortunately, projects are output and product is all about outcome. This process predictably leads to orphaned projects. Yes, something was finally released, but it doesn't meet its objectives so what really was the point? In any case, it's a serious problem, and not close to how we need to build products.
The biggest flaw of the old waterfall process has always been, and remains, that all the risk is at the end, which means that customer validation happens way too late. The key principle in Lean methods is to reduce waste, and one of the biggest forms of waste is to design, build, test, and deploy a feature or product only to find out it is not what was needed. The irony is that many teams believe they're applying Lean principles; yet, they follow this basic process I've just described. And then I point out to them that they are trying out ideas in one of the most expensive, slowest ways we know.
Finally, while we're busy doing this process and wasting our time and money, the biggest loss of all usually turns out to be the opportunity cost of what the organization could have and should have been doing instead. We can't get that time or money back.
It's no surprise that so many companies spend so much time and money and get so little in return. I warned you this could be depressing. But it's critical that you have a deep understanding of exactly why your company needs to change how it works, if, indeed, your company is working this way.
It's no surprise that so many companies spend so much time and money and get so little in return.
The good news is I promise you that the best teams operate nothing like what I've just described.
CHAPTER 7
Beyond Lean and Agile
People are always searching for a silver bullet to create products, and there is always a willing industry—re
ady and waiting to serve with books, coaching, training, and consulting. But there is no silver bullet, and inevitably people figure this out. That's when the backlash begins. As I write this, it's in vogue to criticize both Lean and Agile.
I have no doubt that many people and teams are in some measure disappointed with the results from their adoption of both Lean and Agile. And I understand the reasons for this. That said, I am convinced that Lean and Agile values and principles are here to stay. Not so much the particular manifestations of these methods that many teams use today, but the core principles behind them. I would argue that they both represent meaningful progress, and I would never want to go backward on those two fronts.
But as I said, they are not silver bullets either, and as with any tool, you have to be smart about how you use it. I meet countless teams that claim to be following Lean principles; yet, they work for months on what they call an MVP, and they really don't know what they have and whether it will sell until they've spent substantial time and money—hardly in the spirit of Lean. Or they go way overboard and think they have to test and validate everything, so they go nowhere fast.
And, as I just pointed out, the way Agile is practiced in most product companies is hardly Agile in any meaningful sense.
The best product teams I know have already moved past how most teams practice these methods—leveraging the core principles of Lean and Agile, but raising the bar on what they're trying to achieve and how they work.
When I see these teams, they may frame the issues a little differently, sometimes using different nomenclature, but at the heart, I see three overarching principles at work: