by Marty Cagan
Process @ Scale
Overview
It is understandable that, as companies grow, they become more risk averse. When you're small there really isn't much to lose, but as you get to scale, there is quite a lot on the line, and many people from across the company are there to try to protect those assets.
It is all too easy to institute processes that govern how you produce products that can bring innovation to a grinding halt.
One way companies try to protect what they've achieved is to institute process by formalizing and standardizing how things are done in the name of reducing error or risk. This applies from how we get reimbursed for travel expenses, to how we request a change to a report, to how we discover and deliver product.
In many areas, such as expense reporting, it's an irritant but not likely to make the difference between success and failure of the company.
On the other hand, it is all too easy to institute processes that govern how you produce products that can bring innovation to a grinding halt. Nobody does this intentionally, but it happens so frequently, in so many companies, that I find it quite remarkable.
As just one example in the process area, Agile methods are generally very conducive to consistent innovation. Yet there are several process consultancies that specialize in “Agile at Scale,” which introduce methods and structures intended to scale to large numbers of engineers, yet which absolutely destroy any hope of innovation.
It does not have to be this way. Many of the best product companies in the world are very large companies that have successfully scaled their product and technology organizations. The techniques and methods described here are all about maintaining your ability to consistently innovate as you continue to grow and scale.
CHAPTER 61
Managing Stakeholders
For many product managers, managing stakeholders is probably the least favorite part of their job. I don't want to suggest that this will always be easy, but it can usually be substantially improved.
First, let's consider just who is a stakeholder, then what the product manager's responsibilities are with these stakeholders. After that, we'll talk about techniques for success.
Stakeholder Defined
In many product companies, just about anyone and everyone feels like they have a say in the products. They certainly care about the product, and they often have many ideas—either derived from their own use, or from what they hear from customers. But, regardless of what they think, we would not consider most of them to be stakeholders. They are just part of the community at large—another source of input on the product, along with many others.
One practical test of whether a person is considered a stakeholder is whether or not they have veto power, or can otherwise prevent your work from launching.
This group of people typically includes:
The executive team (CEO and leaders of marketing, sales, and technology)
Business partners (to make sure the product and the business are aligned)
Finance (to make sure the product fits within the financial parameters and model of the company)
Legal (to make sure that what you propose is defensible)
Compliance (to make sure what you propose complies with any relevant standards or policies)
Business development (to make sure what you propose does not violate any existing contracts or relationships)
There can be others, but you get the idea.
In a startup, there are few stakeholders because the company is very small, and frankly, there's not a lot to lose. But in large companies, quite a few people are there to protect the substantial assets of the company.
Product Manager Responsibilities
In terms of the stakeholders, the product manager has the responsibility to understand the considerations and constraints of the various stakeholders, and to bring this knowledge into the product team. It doesn't do anyone any good to build things that may work for the customer, but then at some review meeting find out that you're not allowed to deploy what was created. This happens much more than you might realize, and every time it does happen, the company loses a little more confidence in the product team.
The product manager has the responsibility to understand the considerations and constraints of the various stakeholders, and to bring this knowledge into the product team.
However, beyond understanding the constraints and concerns of each stakeholder, if you want the latitude to come up with the most‐effective solutions, then it's critically important that the product manager convince each of these stakeholders that she not only understands the issues, but that she is committed to coming up with solutions that not only work for the customer, but also work for the stakeholder as well. And this must be sincere. I emphasize this because, if the stakeholder does not have this trust that you are going to solve for their concerns as well, then they will either escalate, or they will try to control.
Strategies for Success
Success in terms of stakeholder management means that your stakeholders respect you and your contribution. They trust that you understand their concerns and will ensure solutions work well for them too. They trust that you will keep them informed of important decisions or changes. And, most of all, they give you the room to come up with the best solutions possible, even when those solutions end up being quite different from what they might have originally envisioned.
It's not that difficult to have this kind of relationship with stakeholders, but it does require first and foremost that you are a competent product manager. This especially means having a deep understanding of your customers, the analytics, the technology, your industry, and in particular, your business.
Without this, they won't trust you (and in fairness they shouldn't). The main way we demonstrate this knowledge to the organization is by sharing very openly what we learn.
With this as a foundation, the key technique is to spend one‐on‐one time with the key stakeholders. Sit down with them and listen. Explain that the better you understand their constraints, the better your solutions will be. Ask lots of questions. Be open and transparent.
One of the most common mistakes product managers make with stakeholders is that they show them their solution after they have already built it. And, sometimes, there are issues because the product manager did not have a clear enough understanding of the constraints. Not only will the stakeholder be frustrated, but your engineering team will be frustrated as well with all the rework. So, commit to previewing your solutions during discovery with the key stakeholders before you put this work on the product backlog.
This is one of the keys of product discovery. In discovery, you are not only making sure that your solutions are valuable and usable (with customers), and feasible (with engineers), but you are also making sure your stakeholders will support the proposed solution.
The other big mistake I often see being made is when situations boil down to the product manager's opinion versus the stakeholder's opinion. In this case, the stakeholder usually wins because he or she is usually more senior. However, as we've already discussed many times before, the key is to change the game by quickly running a test and collecting some evidence. Move the discussion from opinions to data. Share what you're learning very openly. It may be that neither of your opinions were right. Again, the discovery work is designed specifically as a place for these tests.
Mostly this is about creating a collaborative, mutually respectful personal relationship. For most companies, it takes about two to three hours a week—meeting for half an hour or so with each key stakeholder—to keep them apprised, and to get their feedback on new ideas. My favorite way to do this is a weekly lunch or coffee with your most‐involved stakeholders.
Many product managers tell me that the way they deal with testing business viability with all their different stakeholders is by scheduling a large, group meeting and inviting all the stakeholders. The product manager then presents to them what they want to build, usually with a Pow
erPoint presentation.
There are two very serious (potentially career limiting) problems with this.
First, presentations are notoriously terrible for testing business viability. The reason is that they are far too ambiguous. A lawyer needs to see the actual proposed screens, pages, and wording. A marketing leader wants to see the actual product design. A security leader needs to see exactly what the product is trying to do. Presentations are terrible for this.
In contrast, high‐fidelity user prototypes are ideal for this. I plead with product managers in larger companies to not trust a sign‐off on anything other than a high‐fidelity prototype. I have seen far too many times where the execs agree to something based on a presentation, but when they see the actual product, they are completely shocked, frustrated, and often visibly angry.
The second problem is that a group setting is not the forum for designing strong products. It results in design by committee, which yields mediocre results at best. Instead, meet privately with each stakeholder, show them the high‐fidelity prototype, and give them the chance to raise any concerns.
This may sound like more work to you, but please believe me that, in the long run, it will turn out to be far less work, time, and grief.
One final note: in many companies, some of the stakeholders may not even understand what product does, and some may even feel threatened by the role. Be sensitive to this. You may need to spend some time explaining the role and how technology‐enabled product companies operate and why.
Devolving from Good to Bad
Lots of people have written about the challenges of managing growth, and especially about the importance of working hard to maintain staff quality as you scale the organization.
There is little question that most organizations become worse in their ability to rapidly deliver consistent innovation as they grow, yet most people attribute this to staff quality, process, and communication issues of scale. Some believe that this is unavoidable.
There's an anti‐pattern I see in many companies that are doing very well, growing aggressively, yet they will sometimes—over time and unintentionally—replace their good behaviors with bad ones.
I have never seen this anti‐pattern written about before, and I suspect it's going to make more than a few people uncomfortable. But it's a serious issue that I think needs to be out in the open, as it's not hard to prevent if you're aware.
The scenario is that you are probably a later‐stage startup or growth‐stage company. You've probably achieved product/market fit, at least for an initial product, and to have accomplished that, you've probably done some important things right. But then you get some substantial funding, or a board member strongly suggests that you need to bring on some “adult supervision” or some experienced people from brand‐name companies.
Here's the thing. The new people you hire are often from those large, brand‐name companies that have stopped growing, have long since lost their ability to innovate, and have been living off their brand for many years. Because of this, they're not on the trajectory they once were, and people leave.
Would you rather hire all your staff and leaders from Google, Facebook, Amazon, and Netflix? Sure you would, but these people are in very short supply and there is lots of strong talent at other companies.
There is little question that most organizations become worse in their ability to rapidly deliver consistent innovation as they grow, yet most people attribute this to staff quality, process, and communication issues of scale.
But, let's say you are at a young, growth‐stage company, and you decide to hire a senior leader—maybe the head of product, or the head of engineering, or the head of marketing—from a brand name like Oracle. Your board will probably like that. The issue is that, unless you make this clear at the outset, that new leader may assume you're hiring them for their knowledge of process and how to define and deliver products. And, so they bring with them their views on how things should work. Even worse, they often then proceed to hire people that want to work in those ways.
Note that I'm picking on Oracle here as an example, but they are certainly not the only one. There are a great many very strong people to hire from Oracle as they love to acquire companies, often very good companies, but those strong product, design, and technology people they also acquired rarely like Oracle's culture or ways of creating product.
I have seen this anti‐pattern play out at every level of a company—from individual engineers all the way to CEO. It doesn't happen overnight; it happens over years. But I've seen it enough to be convinced it's an anti‐pattern. Many people intuitively sense this problem but they usually just attribute it to a “big company person,” but this is less about being from a big company and more about being from a company that's not strong at product.
I know of two ways to prevent this problem from infecting your company:
The first is to have a very strong and very intentional product culture, and to have that culture very well established so that new hires know they're joining a different type of company that takes pride in how they work and in using best practices. When you join Netflix, or Airbnb, or Facebook, it's something you figure out in your first days, and that's their intention.
The second way of preventing this is to make this explicit in the interview and onboarding process. As part of my advisory work, I'm often on the interview team for senior positions, and when the person is coming from one of these types of companies, I'm up front with the prospective hire. We'll talk about the reasons why their former company has not produced successful new products in many years, and I'll emphasize to them that the new company is interested in them because of their mind and their talents, and of course they wouldn't want to bring with them the bad practices of their former company.
In my experience, people are really good about this when you talk openly and honestly about it. In fact, people often tell me it's a major reason why they want to leave their former company. It's more about getting this to be something you and they are very aware of.
CHAPTER 62
Communicating Product Learnings
Sharing what we learn in a startup happens naturally because the product team and the company are pretty much the same thing. However, as companies scale, this becomes substantially more difficult; yet, it also becomes increasingly important to do.
A technique I love for helping with this is for the head of product, at a company all‐hands or similar meeting every week or two, to take 15 to 30 minutes to highlight what has been learned in product discovery across the various product teams.
Note that this is meant to cover the bigger learnings and not the minor things—what worked, what didn't work, and what the teams are planning to try the following week.
This update needs to move fast and kept at the big learnings level, which is why I prefer the VP product to do this. This is not where every product manager parades in front of everyone for a detailed update, taking one to two hours of time and at more detail than most people want to see. It's not meant to be a repeat of sprint reviews either.
Instead, the update is meant to address several purposes, some tactical and some cultural:
The big learnings are important to share broadly, especially when things don't go as hoped. As a side benefit, sometimes someone in the audience has an insight about what might explain the results.
This is a useful and easy way for the various product teams to keep apprised of what other teams are learning, as well as ensuring that useful learnings make it to the leaders.
This technique encourages the product teams to keep their focus on big learnings and not on minor experimentation that doesn't have a real customer or business impact one way or the other.
Culturally, it's critical that the organization understand that discovery and innovation is about continuously running these rapid experiments and learning from the results.
It is also important culturally that the product organization be transparent and generous in wha
t they learn and how they work. It helps the broader organization to understand that the product organization is not there “to serve the business” but, rather, to solve problems for our customers in ways that work for our business.
CHAPTER 63
Profile: Camille Hearst of Apple
I'd love to introduce you to another very strong product manager, Camille Hearst.
Camille was a product manager on the iTunes team at Apple, and as you might imagine with such a disruptive and groundbreaking product, she experienced and learned a great deal during her formative product years at Apple. This was especially the case because she was there during the years moving from iTunes's original DRM‐based music to DRM‐free, which was critical in helping iTunes become truly mass market.
Moving beyond early adopters into mass market involved many different efforts, some product, some marketing, and some a blend of the two. A good example of this blend was the relationship the iTunes team engaged with the American Idol television program.
This turned out to be one of the most dramatic and visible—yet challenging—product efforts for the iTunes team.
This is a great example of how great product managers work to find creative solutions to very difficult problems.
During 2008, American Idol was a cultural icon—watched by more than 25 million people twice a week, with a level of repeat engagement that was largely unrivaled.
Apple saw in this an opportunity to expose an ideal target market to the power of iTunes and digital music. Not just by selling the music from the contestants featured on the show but by making iTunes an integral part of consumers' lives.