INSPIRED

by Marty Cagan

  The problem is that the individual members of each of these functional departments are the actual members of a cross‐functional product team. The product team has business‐related objectives (for example, to reduce the customer acquisition cost, to increase the number of daily active users, or to reduce the time to onboard a new customer), but each person on the team may have their own set of objectives that cascade down through their functional manager.

  Imagine if the engineers were told to spend their time on re‐platforming, the designers on moving to a responsive design, and QA on retooling. While each of these may be worthy activities, the chances of solving the business problems that the cross‐functional teams were created to solve are not high.

  If you deploy OKRs for your product organization, the key is to focus your OKRs at the product team level.

  What all too often happens in this case is that the people on the product teams are conflicted as to where they should be spending their time. This results in confusion, frustration, and disappointing results from leadership and individual contributors alike.

  But this is easily avoided.

  If you deploy OKRs for your product organization, the key is to focus your OKRs at the product team level.

  This means don't let functional team or individual person OKRs confuse the issue.

  Focus the attention of the individuals on their product team objectives. If different functional organizations (such as design, engineering, or quality assurance) have larger objectives (such as responsive design, technical debt, and test automation), they should be discussed and prioritized at the leadership team level along with the other business objectives, and then incorporated into the relevant product team's objectives.

  Note that it's not a problem for managers of the functional areas to have individual objectives relating to their organization. This is because these people aren't conflicted, as they're not normally serving on a product team.

  For example, the head of UX design might be responsible for a strategy for migrating to a responsive design; the head of engineering might be responsible for delivering a strategy around managing technical debt; the head of product management might be responsible for delivering a product vision; or the head of QA might be responsible for selecting a test automation tool.

  It's also not normally a big problem if individual contributors (such as a particular engineer, designer, or product manager) has a small number of personal growth‐related objectives (such as improving their knowledge of a particular technology). This assumes the individual isn't committing to a burden that will interfere with their ability to contribute their part to their product team, which of course is their primary responsibility.

  The key is that the cascading of OKRs in a product organization needs to be up from the cross‐functional product teams to the company or business‐unit level.

  Product @ Scale

  Overview

  We have thus far discussed product vision, strategy, and business objectives. In truth, as an early stage startup, you can survive without any of these for a while. It's amazing how far you can get by focusing on meeting the needs of some early customers.

  However, the need for this vision and business‐objective context becomes truly serious at scale.

  Keeping a small number of teams and their engineers doing useful stuff is not very hard, but getting good results out of a medium—or, especially, large—organization can be truly challenging.

  Realize also that by the time the company has scaled, the original co‐founders may have moved on, so there may very well be a void. Teams need this context. It is nearly impossible for them to make good decisions and do good work without it.

  The main ways these issues show up is diminished morale, lack of innovation, and reduced velocity.

  CHAPTER 30

  Product Objectives @ Scale

  The OKR system is very scalable. I would argue some sort of tool for managing and aligning work is critical to scaling effectively, but it's also true that many companies do struggle with scaling their use of OKRs.

  In this chapter, I shine a light on what needs to change as you use the OKR system at scale. Remember that I'm just talking about the product and technology organization here (product management, user experience design, and engineering), and while you can use the techniques I'm about to describe at any scale, I am focused here on growth stage or enterprise organizations.

  With startups or small organizations, when everyone essentially knows what everyone else is doing and why, it's normal for each product team to propose their objectives and key results. There's some amount of give and take, and then people get to work. With larger organizations, product teams need more help. The first help they need is a very clear understanding of the organization‐level objectives. Let's say that the top two objectives for the company are to improve customer lifetime value and expand globally. Let's also say you have on the order of 25 product teams. All the product teams likely have thoughts on both of these organizational objectives, but, clearly, the company will need to be smart about which teams pursue each objective. Some teams might focus on only one, others might contribute to both, and yet other teams may be tackling critical work beyond those two objectives.

  Leadership (especially the head of product, head of technology, and head of design) will need to discuss the company objectives and which teams are best suited to pursue each objective.

  Moreover, at scale, it is very common to have some significant number of product teams that are there in support of the other product teams. These are often called platform product teams, or shared services product teams. They are very high leverage, but they are a little different in that they generally don't directly serve customers. They serve customers indirectly, usually through the higher‐level, solution‐focused product teams. These platform teams will get requests from most or even all the higher‐level product teams, and they are there to help them succeed. But, again, leadership will need to help coordinate the objectives for these teams and make sure we coordinate the dependencies and align the interests.

  Once you have your objectives, there is a very critical reconciliation process in which the leadership team looks at the proposed key results from the product teams and identifies gaps and then looks to what might be adjusted to cover those gaps (for example, enlisting the help of additional teams or reviewing the priority of the work).

  At scale, it's much harder to know what product teams are working on which objectives and the progress they are making. There are now a variety of online tools that help organizations make the objectives transparent to the organization. But even with these tools, we lean on management to help connect the dots between teams.

  The larger the organization, the longer the list of high‐integrity commitments that are needed, and the more actively they need to be managed and tracked. Delivery managers play a key role in tracking and managing these dependencies and our commitments. When using OKRs at scale, there's a larger burden on leadership and management to ensure that the organization is truly aligned, that each and every product team understands how they fit into the mix, and that they are there to contribute.

  In many enterprise scale organizations, there are essentially multiple business units, and in this case, we would expect that there are corporate level OKRs, but there would also be business unitendash level OKRs, and the product teams would roll up into those.

  In summary, when using OKRs at scale, there's a larger burden on leadership and management to ensure that the organization is truly aligned, that each and every product team understands how they fit into the mix, and what they are there to contribute.

  CHAPTER 31

  Product Evangelism

  Product evangelism is, as Guy Kawasaki put it years ago, “selling the dream.” It's helping people imagine the future and inspiring them to help create that future.

  If you're a startup founder, a CEO, or a head of product, this is a very big part of your job, and you'll hav
e a hard time assembling a strong team if you don't get good at it.

  If you're a product manager—especially at a large company—and you're not good at evangelism, there's a very strong chance that your product efforts will get derailed before they see the light of day. And even if product does manage to ship, it will likely go the way of thousands of other large company efforts and wither on the vine.

  We've talked about how important it is to have a team of missionaries, not mercenaries, and evangelism is a key responsibility to make this happen. The responsibility for this falls primarily on the product manager.

  There are several techniques to help communicate the value of what you're proposing to your team, colleagues, stakeholders, executives, and investors. Here are my top‐10 pieces of advice for product managers to sell the dream:

  Use a prototype. For many people, it's way too hard to see the forest through the trees. When all you have is a bunch of user stories, it can be difficult to see the big picture and how things hang together (or even if they hang together). A prototype lets them clearly see the forest and the trees.

  Share the pain. Show the team the customer pain you are addressing. This is why I love to bring engineers along for customer visits and meetings. For many people, they have to see (or experience) the pain themselves to get it.

  Share the vision. Make sure you have a very clear understanding of your product vision, product strategy, and product principles. Show how your work contributes to this vision and is true to the principles.

  Share learnings generously. After every user test or customer visit, share your learnings—not just the things that went well, but share the problems, too. Give your team the information they need to help come up with the solution.

  Share credit generously. Make sure the team views it as their product, not just your product. However, when things don't go well, step forward and take responsibility for the miss and show the team you're learning from the mistakes as well. They'll respect you for it.

  Learn how to give a great demo. This is an especially important skill to use with customers and key execs. We're not trying to teach them how to operate the product, and we're not trying to do a user test on them. We're trying to show them the value of what we're building. A demo is not training, and it's not a test. It's a persuasive tool. Get really, really good at it.

  Do your homework. Your team and your stakeholders will all be much more likely to follow you if they believe you know what you're talking about. Be the undisputed expert on your users and customers. And be the undisputed expert on your market, including your competitors and the relevant trends.

  Be genuinely excited. If you're not excited about your product, you should probably fix that—either by changing what you work on or by changing your role. Absolutely be sincere, but let people see you're genuinely excited. Enthusiasm really is contagious.

  Learn to show some enthusiasm. Assuming you're genuinely excited, it's amazing to me how many product managers are so bad or so uncomfortable at showing enthusiasm. This matters—a lot. Absolutely be sincere, but let people see you're genuinely excited. Enthusiasm really is contagious.

  Spend time with your team. If you're not spending significant face time with your designer and every engineer on your team, then they can't see the enthusiasm in your eyes. If your team is not co‐located, you'll need to make a special effort to travel there and do this at least every couple months. Spending some personal time with every last person on the team pays off big in their level of motivation and, as a result, in the velocity of the team. It's worth your time.

  If your company is midsize to large, then it's normal to have product marketing play the role of evangelist with your customers and your sales force. You still may be called on to help out on the big deals and partnerships, but you'll need to focus your evangelism on your team because the best thing you can do for your customers is to provide them with a great product.

  CHAPTER 32

  Profile: Alex Pressland of the BBC

  I have to admit I have a soft spot for the BBC. They've been around for nearly 100 years, but they embraced technology and the Internet relatively early. I've seen so many amazing product people come out of the BBC, and many are now spread across Europe and beyond.

  Back in 2003—a full four years before the debut of the iPhone—a young product manager at the BBC, Alex Pressland, had just finished leading a product effort that enabled the BBC to be one of the first media companies in the world to syndicate content. Most people at the BBC had no idea why this was important or even desirable, but Alex understood that this enabling technology could be used in new and unanticipated ways to increase the BBC's reach, a major part of the institution's mission.

  Because Alex understood the potential for IP‐based syndicated content technology, she started searching for new and useful ways to put this technology to use. She began by looking at people in the United Kingdom who were not being reached by the BBC's conventional broadcast media (TVs and radios in homes and cars).

  One early use she identified was large electronic billboard screens in many city center venues that were capable of displaying video. But she observed that these venues were just playing the same thing you could watch on your television at home, even though the context and audience was very different.

  So, Alex proposed a series of experiments in which she would have editorial teams assemble specific tailored content suitable for specific venues and audiences, and then she would measure the audience reach and engagement.

  While this might sound obvious today, at the time this was a very foreign concept to the BBC's broadcast journalism culture. There was a long list of obstacles in trying to push the BBC in this direction, not the least of which was editorial and legal.

  Editorial wasn't used to the model in which content would be created and then delivered in different contexts. This gets to the heart of the BBC editorial culture and required considerable persuasion to show why this was a very good thing for both the BBC and for the audience.

  Legal wasn't used to distribution via IP‐enabled devices. Imagine the stack of content‐licensing agreements that would need to be updated or renegotiated.

  The results of Alex's experiments and early successes, however, gave her the confidence to propose to BBC leadership a new product vision and strategy which she called “BBC Out of Home.”

  It's important to note that she did this as an individual contributor product manager.

  This work ended up fueling a dramatic shift at the BBC—from broadcast content to content distribution—and this work dramatically affected reach and soon became the basis for BBC's mobile efforts. Today, more than 50 million people around the world depend on BBC's mobile offerings every week.

  With large enterprise companies, it's never easy to drive substantial change, but this is exactly what strong product managers figure out how to do.

  This is not just a story about applying technology to solve problems; it's also a story about the power of force of will. With large enterprise companies, it's never easy to drive substantial change, but this is exactly what strong product managers figure out how to do.

  Alex went on from the BBC to have a terrific career at several tech and media companies and now is a product leader in New York.

  PART IV

  The Right Process

  We've explored product teams in Part Two, and we described how to decide what each team needs to focus on in Part Three. In Part Four, I explain how product teams do their job. We'll work through the techniques, activities, and best practices used to repeatedly discover and deliver successful products.

  Even though this part is titled “The Right Process,” I hope you'll soon realize that the right process is not any single process. Rather, it's more accurately described as a combination of techniques, mindset, and culture.

  I mostly emphasize discovery techniques, as our focus is on product managers, and that is their primary responsibility.

  The bulk of the p
roduct manager's time needs to be focused on working with her product team, with her key stakeholders, and with her customers to discover solutions that her customers love and that work for the business.

  Keep in mind, however, that the product manager and product designer do need to ensure that they're available to answer questions from the engineers that arise during delivery activities. Normally, answering these delivery questions is on the order of half an hour to an hour of time per day.

  Product Discovery

  Overview

  Most of us are working on solving some pretty hard problems, and it usually ends up taking some fairly complex systems to power these solutions. For most teams, there are two very significant challenges to tackle.

  First, discovering in detail what the customer solution needs to be. That includes everything from making sure there are enough customers that even need this solution (the demand) and then coming up with a solution that works for our customers and for our business.

  Even harder, we need to make sure we come up with a single solution that works for many customers, and not a series of specials. To do this, we need to be able to test out many ideas, and we need to do this quickly and inexpensively.