Chapter 4. Being a Great Product Leader

Management is about doing things right; leadership is about doing the right things.

Peter Drucker

Setting Product Principles

In order to set your team up for success as it scales, it’s important to consider what the core product and design principles for your organization are—and articulate them clearly so everyone in the team understands them and can apply them in their work.

Says Paul Adams, VP of Product at Intercom, “We have three principles that are the foundation on which everything else that we do is built. The first principle is that we think big but start small. This means thinking about a big vision and then ruthlessly cutting the scope so we can ship. Because our next principle is ship to learn, which means shipping as fast as possible so we can learn as fast as possible. The third principle is to design from first principles—to start with a blank sheet of paper instead of copying a competitor or assuming the best solution exists in the world already.”

These principles set the groundwork for all future product work, and give the team a common set of guardrails that can guide all the minute decisions that make up each iteration of the product.

Setting a Product Vision

Jeff Bezos, CEO and founder of Amazon, said, “Be stubborn on vision, flexible on details.” The vision should continue over a very long period of time, potentially years. The best product visions are timeless and disconnected from the technology they are built on. In a startup, the vision is usually championed by a founder or an early-stage CEO. Their responsibility is to remind the organization’s people—throughout all the product decisions and product roadmap discussions—of that vision. “When I joined the company in 1992, we used to talk about our mission as putting a PC in every home, and by the end of the decade we had done that, at least in the developed world,” says Microsoft CEO Satya Nadella. “It always bothered me that we confused an enduring mission with a temporal goal.” Disconnecting from time and trends is essential to creating a long-term vision—because, ultimately, achieving the objectives determined by a clear view of the future makes for a better product.

The company vision is unlikely to change much. Pivoting a company or product doesn’t necessarily mean changing the vision. If described correctly, a vision will be timeless and not connected to technology or trends. Disney’s vision to “Make People Happy” doesn’t need to explain how that gets done. A vision should be able to stand the test of time while also being translated into near-term goals, Objectives and Key Results (OKRs), or roadmaps. The OKRs and roadmaps can change; in fact, they should change as new information is received from the market and from customers. This adaptation of the near-term goals shouldn’t have any effect on a well-constructed and timeless vision.

“One thing I’ve seen for myself and for others in the past, is having a tough time showing the roadmap knowing it’s going to change,” says Rose Grabowski, previously Director of Product Management at Invaluable and now Senior Product Manager at GrubHub. “It’s always going to change ‘tomorrow.’ Even when you get to tomorrow, it’s going to change the next day too. Maybe not literally tomorrow, but you know you’re always learning and thinking about course correction.” Grabowski describes a familiar environment for all product people: working in an ambiguous world of shifting deadlines and fresh problems to solve: “It’s tough to say, ‘We’re going to show something and we’re going to couch it with all sorts of notes on this being a living document. Things always change. These aren’t committed dates.’ That kind of thing.” Grabowski has homed in on the counterintuitive nature of the product leader’s job—having a clear long-term vision while simultaneously living in a shifting short-term world of tasks and deliverables.

An additional challenge is that once a team sees the vision and the roadmap, they get attached to the outcomes. “[People] hope that nothing will change, or at least the thing that they don’t want to change, doesn’t change,” says Grabowski. Aligning a vision and managing the daily activities to get there means regularly sharing that vision while at the same time reminding your team that the details of how you get there will change. That change is guaranteed, so it’s important to have the conversation and just accept that nothing is perfect. Overcommunicate if necessary, because, as Grabowski reminds us, “undercommunicating the roadmap is a big mistake that can easily be made.”

The product leader assumes the same responsibility and champions the vision at each step of the product creation process. The product leader always needs to be asking, how does the big problem we’re solving relate to the ultimate vision? Will the product live up to the vision? How is the vision being communicated? How often will this vision be communicated or presented? Who is responsible for the vision communications?

Regardless of what the vision is, it is essential to have an advocate constantly reminding people about it; in some of the companies we interviewed, company vision is woven into weekly meetings and into almost all all-hands meetings. This advocate can and should be the executive team and the product team, but in some cases can also include an external advocacy group. Titleist, the manufacturer of premium golfing products, has a group of customers that are part of the company’s inner circle. They are included in conversations about new products and innovative ideas. During a recent web and mobile project, these customers got to see early-stage designs so they could provide constructive feedback and direction. The customers are explicitly asked if these new digital products will be consistent with Titleist’s stated vision “to serve the needs of the serious and recreational golfer with value added products and services that have a competitive advantage worldwide.”

Ultimately, where the vision comes from is less important than ensuring that it is the correct one. As product management guru Rich Mironov says, “It’s not important to me who has the good idea, but it is my job to make sure it’s the best one, that it’s still validated, and that we have people who are going to pay for it. The process has to continually validate the vision. If we do that, I don’t care whose vision it is.”

Moving from Vision to Strategy

The most common question from tactical leaders about the organizational vision is, how does it translate into a product roadmap? How do you take the vision and ensure that the steps along the road reach that horizon that holds so much promise for the organization? These are important questions, because one of the challenges product teams face is that roadmap-related decisions are often made that are disconnected from the strategic goals of the organization. In any size organization, it’s important for product managers to work with and educate stakeholders about the company’s priorities and goals. Getting buy-in from the stakeholders for the four or five or six things that are going to be accomplished during the year is the first step. Once that is achieved, the product manager must work with the stakeholders to define the initiatives that will fit those strategic goals. This early collaboration will be far more productive than having a product manager operating in a vacuum and unilaterally creating a product roadmap of where they’re going to be, and it becoming set in stone.

The vision gives rise to specific product goals. These product goals could be things that must be accomplished over the next year—for example, growing revenue, reducing churn, and improving customer satisfaction—or they might be more strategic product goals. Whatever they are, the goals, like the vision, should be championed by product leadership; whether the founder of the company, the VP of Product, or the Director of Product, it’s important that the product leader constantly revisits those individual goals in order to support the overall vision.

“We’re very goal focused,” says Paul Adams, VP of Product at Intercom. “Pretty much everything we do is oriented at a goal. We have company goals. Specific teams have their team goals. And we do this at pretty much every level of granularity, so we’ll have quarterly goals that we’ll break down into weekly goals that will break down into daily goals—and they all cascade. You could take an engineer’s daily goals and map that to a weekly goal they have, map that to a six-week goal our team has, which would map to a quarterly goal that the product and engineering team has, which would map to a company goal, etc.”

Out of the goals will come the specific features for development. Like a ripple effect with the vision at the center, the objectives or goals are generated and they in turn generate the features that support those goals. Never start with features. Even if your business or product is based on a “feature concept,” ask yourself what the bigger problem is and why it needs solving. Any feature shouldn’t be considered, prioritized, or delivered in a vacuum. Without a vision to guide the product creation, a project can quickly become a collection of cool solutions lacking a core problem to guide them. Features need to be directly tied to the product or organization’s strategic goals.

“The product vision is really what our products are going to deliver and for whom, but it’s a bigger view,” says Tim Buntel, VP of Products at XebiaLabs. Buntel, who has served product roles at Atlassian, Microsoft, Adobe, Codiscope, and now the DevOps company XebiaLabs, sees a smooth transition between vision and strategy. “Product strategy is about how you attain that vision. It could be your value proposition, it could include key feature areas, and [it] could also include business goals. That strategy might extend a year or so out into the distance.” Buntel knows that key feature areas tend to change once you get past that one-year horizon. He believes that a vision is long term, but the strategy is probably no more than a year or so. “The roadmap is even shorter, maybe six months out. It tells how the key features will come in actual releases.”

Buntel has observed that product leaders are always seeking order in an inherently chaotic environment. This influences their thinking and forces them to become attached to structures and tools. “The world that we’re in right now is very fast-moving. I think a challenge as a product manager is to allow yourself to be flexible with your vision and understand that these things can evolve really quickly. You need to be able to go along with some of those natural evolutions.” The qualities that allow for adaptation are just as important to product managers as any of the other skills identified here. Product management might not be the right career path for a person that is averse to change.

Finding ways to adapt will also serve the broader team as they encounter inevitable outside pressures. Market disruptions and environmental changes can all but destroy a company. Product leaders need to assume change will happen, and sometimes that change will be out of their control. We’ve witnessed new companies like Airbnb, Uber, Tesla, and Slack shake up established industries and provide a new landscape for operators. Product leaders that are affected by this forced adaptation need to jump into action. Having a vision that can accommodate unexpected externalities means being able to adapt faster to change. Because the product strategy hangs off the product vision, it’s important to have a flexible, timeless vision.

Moving from Strategy to Roadmap

When you’re looking at the finished work of a well-executed product, it seems perfect. All you can see is the beautiful presentation and anticipate the potentially enjoyable experience ahead of you. Of course what you don’t see is all the hard work that went into the creation of this sensory masterpiece. You don’t see the people and processes that go into making that amazing thing. The same is true of almost all beautiful products. Behind every great product is a great team doing work in a way that guarantees results. They are following a roadmap from the starting point to the end product.1

Here is just a sampling of the people and elements involved in any great product: product leader and/or manager, product team (designers, engineers, QA, etc.), components, roadmap, tools, UIKit, marketing team, and a marketing website, and of course, customers. Remove any one of these elements, and the outcome will be different. As with baking a cake, changing any of the ingredients (team members) could result in a completely different cake. Sometimes this will be good, but many times it will be an outcome you didn’t plan for and your customers won’t want. If you’re selling chocolate cakes and suddenly they start coming out strawberry flavored, you’ll have some unhappy customers.

It’s also true that if you stick to the recipe and process too closely, you’ll never experience any opportunities for improvements or moments of delight. This is why the best chefs run a rigorous and disciplined kitchen but also make space for experimentation and improvement. The trick is in getting the guiding framework right and allowing for flexibility inside that framework. In product creation circles, this is what’s often referred to as the roadmap. It’s not a replacement for a rigorous process or a smart team. It focuses the people and process on the best outcome for the customer. So how does a roadmap help you deliver on the product work?

Focus
First it puts a lens over the work and focuses in on the core value. Humans not only want focus, they require it to do their best work. The roadmap also helps us understand what we won’t be giving our attention to. If we stick to our cake baking metaphor we would say, “We’re making the best cake. Not cookies, not brownies, just cake.”
Alignment
The roadmap also helps create alignment. It gets the entire team working toward the same goals. Once the roadmap has been discussed, the team will have clarity on what their roles are and what their efforts will create. In our kitchen we’d hear, “We’re all on board with the cake flavor, styling, and time it’ll take to get it from start to finish.”
Priority
Knowing what to do is half the story; knowing when to do it is the other half. Prioritization is a core part of having a roadmap that works. Another way to look at it is to substitute the statement, “We won’t have time for that” with the clarification “That isn’t a priority for us to be successful.”
Visibility
Seeing the way the team works and what they will be doing makes everything easier. Roadmaps help us visualize potential pitfalls and opportunities by organizing the work in terms of priority and importance. If it’s 3 p.m. and our cake needs to be on the shelves by 10 a.m. the next morning, then working backward, what do we need to be doing between now and then?
Coordination
Overlapping efforts or misaligned work that cancels out our progress causes stress and waste. Getting our team working in a rhythm is a big part of creating and maintaining momentum. Everybody should know their contribution and how it dovetails with the others on the team. The old saying “too many cooks in the kitchen” is too perfect not to add here.
Vision
The best companies and products have a clear vision of where they are going. A great vision should paint a picture of a brighter future for your customers. It’s not about you. It’s about them. As mentioned earlier, the most famous, and possibly one of the best, customer-centric visions was Disney’s original “Make People Happy.” It’s simple and easy to use as a lens for what needs to be done each day. You’ve just delivered a tasty and beautiful cake to your hungry customer. What is next for your relationship with them? A roadmap should paint a picture of what comes next to achieve a long-lasting relationship with your customers.

Now you know what’s in your roadmap. But before we go any further and discuss how to create a roadmap, it’s important to clarify what a roadmap is not.

  • It is not a release plan—leave out specific dates and timelines.

  • It is not a list of features and/or components, nor should it include job stories, user stories, or “jobs to be done”; these are too granular for a roadmap.

  • It is not a commitment. It is a living guide that reacts to new information.

  • It is not one monolithic document. Given that we argue for small, autonomous, cross-functional teams focused on specific areas of the product, there should be a roadmap per team.

  • A successful roadmap is not a Gantt chart. Dependencies and waterfall connections won’t work for this level of planning.

ProdPad’s Janna Bastow underscores these points: “The place where I see roadmaps falling down is when people start putting concrete dates on them. There’s a big misconception about what a roadmap is and what it isn’t. I see it as an artifact that communicates the direction you’re going to meet the product vision. It is a completely separate document—or it should be a completely separate document—from the release plan, which outlines what’s being launched and when and who’s working on what. They’re both valid documents, but when people try to combine them, you essentially end up with a Gantt chart with dates stretching out—not just from the first one or two quarters that you can plan for, but beyond that. I always point out to people that you don’t know how big your company’s going to be by December, let alone how fast you’re going to be able to deliver.”

Matt Walton, Chief Product Officer at FutureLearn, adds: “Each of our teams is responsible for their own roadmap. It’s down to them how they achieve the mission they’ve been set and move the metric that we have made them accountable for. The key thing to remember with a roadmap is that the document itself is uninteresting—it’s the process of understanding and negotiating that the team goes through, to own the problems and commit to solving them, that is its real purpose. Where as once our roadmap was a single beautiful published document made in Keynote, they are now organic, living, and collaborative Trello boards owned by each team and so much more useful because of it.”

The best roadmap, therefore, is a strategic communication artifact that is focused on the big picture and conveys the path you’ll take to fulfill your product vision. “More often than not, the lack of a roadmap encourages you to do too many things not as well,” says Anthony Accardi, CTO of Rue La La. Who will use the roadmap once it’s complete? Well, everybody: product, design, development, sales and marketing, executives, customers, partners, and customer support.

Focusing Themes on Customer Problems

Because it’s a strategic document, what you want to convey in your roadmap is not a series of features or solutions but themes around the customer problems you intend to focus on and work on.

Shifting a roadmap to themes can be incredibly powerful. As User Interface Engineering’s Jared Spool says, “Themes are a promise to solve problems, not build features,” which in one stroke makes learning about the customer the most important thing the product team can do. If you only prioritize customer problems, then you need to understand those problems first.

This also simplifies your roadmap, as one customer problem can encapsulate multiple features, as well as the prioritization process, because only those features or ideas that focus on solving that customer problem make the cut.

“Product managers usually have hundreds of features on their roadmap that they try their best to prioritize,” says product consultant Bruce McCarthy, “but they haven’t usually gone and dug underneath the request to understand the real underlying need, to understand the problem that the customer wants solved.” Each of those features adds up to a lot of little fixes and effort, but with a little digging the true underlying issue comes out—a theme that lets you tackle a larger customer problem more comprehensively than merely a series of small fixes.

Prioritizing Goals and Strategic Activities

“Too often we think we have a good idea, but we’re starting on the supply side. We’re looking for excuses to build the thing that we want to build, and the real trick to going deeper with product is to learn to move backward and get into the demand side and ask: Why is this the right time? Why is this important? What matters right now?” says Ryan Singer, Product Manager at Basecamp.

We’ll talk in detail about prioritization in other sections of this book, but as it’s essential to the roadmap creation process, we need to address it here too. Let’s start with how not to prioritize your strategic goals and activities. Knowing what filters not to use is as important as knowing what filters you should use.

Your CEO’s gut reaction to a feature is not a good place to start. It’s not that your CEO isn’t smart or doesn’t have great insights, but all subjective opinions are frequently influenced by personal bias. Similarly, requests from sales teams or support teams reacting to one or two customer requests need to be checked for consistency and relevancy to the broader customer base. Prioritizing a feature because one customer says they need it will set a precedent for this kind of interruption to the workflow. We also recommend not relying too heavily on analyst opinions either. These industry pundits are basing their suggestions on historical and aggregate sector data, so beware of using them to forecast the future of your narrow market. Of course, all of these sources are valid, just not in isolation and never at face value.

So if these sources of information should be either distrusted or double-checked, what sources should you trust? Prioritization is best done through the lens of the core product management principles:

  • Valuable

  • Usable

  • Feasible

Valuable and usable are the core customer-focused parts of the prioritization process. Is this new idea, product, or feature valuable to the customer? Is it valuable enough to be valuable to the business? Is it delightful for the customer to use? This of course has to be contrasted with the technical (and business) feasibility of the idea. Can it be built in a cost-effective manner? What is the cost to service and support it? Only by looking at the full picture like this can you prioritize one idea against another.

Managing the Unknown

Often when prioritizing new ideas, features, or products, you simply don’t have all this information to hand. So inevitably most teams start guessing what the impact might be, what the dev effort might be, and so on—leading to personal biases and assumptions that tend to overestimate impact while underestimating effort.

The key to solving this is to embrace ambiguity and focus just as much on learning about your customers as on features. Most product leaders we spoke to talk about this in the form of hypotheses, and spend a lot of time and effort on quickly validating these hypotheses through testing. Using the language around hypotheses removes the ego from the results.

“I like my teams to think in terms of bets. By proposing ideas in the form of ‘I bet that by doing X we’ll see Y,’ sharing your thoughts becomes less risky than stating a more formal hypothesis. If your bet is wrong, you might feel bad, but it was a bet—nothing more. Using bets lightens the mood of creating and sharing ideas. Plus, bets work into people’s vocabulary much easier than hypotheses—it’s a great step toward actually building a culture that encourages experimentation,” says product management consultant Kate Leto.

Small bets

If you’re optimizing an existing, mature product, the best way to get data to back up your assumptions is simply to start testing your bets using a/b or multivariate testing. This data-based approach short-circuits any arguments or biases by showing what actual users or customers do when confronted with new affordances. With the testing frameworks and tools available today, there’s no excuse not to be doing this either. Beyond installing a testing library, your engineering team doesn’t even need to be involved!

Bear in mind, though, that focusing solely on optimization can blind you and your team to the bigger opportunities that might be out there. In striving to constantly optimize the details on a current product, you will inevitably achieve a local maximum, but you might be missing the global maximum potential if you don’t take bigger bets.

Large bets

When it comes to making larger bets on new product lines or completely new features, multivariate testing just doesn’t work. This is where most product leaders fall back to the MVP (minimum viable product) approach. This concept came out of Eric Ries’s 2011 book The Lean Startup (Crown), but the term has become so overused it’s lost its original meaning.

“MVP is often mistakenly applied to the first release of a rudimentary product and as a result, the ‘MVP’ ends up much more complex than the quick test it was supposed to be and far too shoddy for a released product,” argues Rik Higham, Senior Product Manager at Skyscanner.

Instead we should focus on learning and put the emphasis on testing our riskiest assumptions. “A RAT, or riskiest assumption test,2 is explicit. There is no need to build more than what’s required to test your largest unknown. No expectation of perfect code or design. No danger it will prematurely become a product,” Higham continues.

Mapping Ambiguity to Time

While the product leaders we interviewed uniformly eschew timelines on roadmaps, it is of course a document showing what you intend to focus on over time, so some dates are important to convey meaning. The best roadmaps simply divide time, and your themes, into what the team is working on currently, what is queued up to come next, and big-picture ideas for the future, with varying degrees of definition and flexibility (see Figure 4-1 for an example).

Roadmap concept courtesy of Janna Bastow, CEO and cofounder of ProdPad (http://bit.ly/2n4Ipan).
Figure 4-1. Roadmap concept courtesy of Janna Bastow, CEO and cofounder of ProdPad (http://bit.ly/2n4Ipan).

Putting your roadmap together is ultimately an exercise in planning your activities into ever-increasing time periods. As DJ Patil, recently US Chief Data Scientist, has said, “Dream in years; plan in months; evaluate in weeks; ship daily.” Start thinking broadly and then narrow down your efforts to the shortest time frames. Implicit in this idea is that the roadmap is dynamic and requires continual updating. Like all tools and artifacts at the product leader’s disposal, these roadmaps are only as good as the information that goes into them and the attention they receive. Failing to communicate this roadmap clearly and frequently will make it less effective.

Product Is a Team Sport

As we’ve noted, many define product leaders as the CEO of their product, but this fundamentally misunderstands the role and, worse, sets up for failure any product leader buying into it.

A better analogy would be the product leader as the captain of a sports team, a conductor of an orchestra, or a university professor guiding their class. Like the professor, conductor, or team captain, the product leader is an individual who succeeds only by bringing the whole team along with them, working toward a common goal.

As we’ve outlined, in almost every organization product managers have no direct authority over engineers, designers, marketers, or any other members of the product team. This oversight of organizational theory may seem like a bad thing, but it forces product leaders to exercise true leadership, and not to manage by authority and dictate alone.

The product leader’s job is not to constantly manage or direct, but to lead their team by clearly articulating the common goal. They should provide the context the team is working in, from the problems and frustrations the customers have to the competitive environment the company operates within. If nothing else, this is what you will get out of this book.

True leadership recognizes that the whole is greater than the sum of the parts. Being dictatorial and enforcing your own product ideas is never going to be as productive or successful as bringing the whole team, from design and engineering to sales and marketing, together. The product leader’s job is to curate the right team, provide an environment for success, bring the user problems to them, and then facilitate conversations and help connect the dots so the whole team can design the solutions together.

When you’re designing solutions it’s so valuable to involve the whole team, with their diverse mindsets and experience, that it would be foolish not to. Every job in a tech company is an inherently creative role, whether it’s obvious (designers) or not (engineers). Some of the best product solutions we have worked on have come from engineers who have such a good understanding of the problem space (thanks to a great product leader), and an inherent grasp of the opportunity afforded by the technology stack, that finding quick, elegant solutions to customer needs is second nature to them.

The bottom line is that everyone in the company owns the product, and its success or failure lies in the hands of each person who touches it. It bears repeating that a product leader’s job is to create the best team possible, to lead them to tackle the product challenges together, get the best out of everyone when building the product, and provide a gentle hand to keep it heading in the right direction.

Designing a Product Team

“Product is people. Every single person in your organization influences the customer experience in some way, so the experience your customers have is a direct outcome of the people you hire and the decisions they make,” says Nilan Peiris at TransferWise. “There’s a myth in the corporate world that people do what you tell them to do, but in reality they only do what they want to do, so you have to build a culture that influences those decisions in the right direction.”

In traditional product management, decisions get made in line with the accountability structure, from shareholders through the CEO down to the product teams. Because the accountability and the decision making sit at the top tier of this org chart, the feedback loop to the actual customer is far too long. This creates top-down plans, little or no accountability at the team level, and ultimately, unhappy customers.

A new organizational model is emerging, from extremes like Holacracy to the scaled, Agile approach of Spotify, that realigns the accountability structure around small, independent, cross-functional teams. This offers them full autonomy to discover what their customers need and execute the delivery of that product in whatever way they see fit.

TransferWise has built fully autonomous product teams with clear KPIs (key performance indicators)3 but otherwise total freedom to set their roadmap, decide their organization, and build the team and resources they need to execute their plan. Any team can change any part of the product. So, for example, marketing doesn’t have to wait for product to build what they need; they have full access to build pages, change user flows, or do anything else necessary in pursuit of their goals.

At Pluralsight, teams have complete autonomy and are cross-functional and collocated. They do not stand up a team unless this team composition is possible to achieve. Each team discovers, builds, and delivers on their own to a production environment. These teams control their experience and the experience of their customers in its entirety (see Figure 4-2).

David Platt (left) leading a customer preference test for the Pluralsight learner experience.
Figure 4-2. David Platt (left) leading a customer preference test for the Pluralsight learner experience.

Spotify developed one of the better-known models around this autonomous approach. They start with squads, independent teams that sit together and have all the skills and tools needed to design, develop, test, and release their part of the product to production. Each squad self-organizes and decides its own way of working. Some use Scrum sprints, some use Kanban, and others use a mix of these approaches. Squads are grouped into tribes that work on related areas of the product, and are never allowed to exceed the Dunbar number.4 In order to coordinate functional best practices (for example, design) across these teams, they introduced chapters and guilds to share knowledge and experience across squads and tribes.

However it’s described, this idea of small, autonomous, cross-functional teams that can get close to the customer is an increasingly important factor in great product leadership. It is not perfect: too much autonomy risks losing economies of scale5 and introduces both dependencies and alignment challenges between teams. However, almost everyone we spoke with aspired to this ideal. That tradeoff decision is key, as it emphasizes the customer’s central role in the development of great products, and makes the coordination challenge internal instead of external. Autonomy motivates teams better than the old carrot-and-stick model, and as a team structure, it scales better and moves faster than any top-down model. In today’s fast-moving world, your team has more information, experience, and knowledge about the customer problem and the specific product area they’re working on than you ever will, so why try to drive their priorities when they have more information?

“Traditional management is great if you want compliance, but if you want engagement, which is what we want in the workforce today as people are doing more complicated and sophisticated work, autonomy and self-direction just works better,” shares Dan Pink, author of Drive: The Surprising Truth About What Motivates Us (Riverhead).

If you are not evolving your organizational design, it might be an indicator that your product strategy is getting stale. In our experience, most rigid organizational structures are built to create processes for predictability, not successful outcomes. The problem with this is that not only does it support a command-and-control philosophy, but it also must exist in a static state in order to provide data. We prefer a process that has the ability to evolve, however marginally, every quarter or year and to set the expectation that we should restructure as needed. The same goes for the discovery and delivery teams. The organizational model we just shared will continue to evolve in order to better support our teams over time, knowing that this is not how we may operate a year from now. The scaffolding of supporting teams should remain, but we may reconfigure it depending on what we are working on, making leadership changes and team moves as required. The decision to do so comes from our teams, who have their finger on the pulse of our customers and understand what needs to be done to execute on a solution. In an ideal situation, the product team isn’t making decisions based on a burndown chart or efficiency flow metrics; rather, the team is making decisions based on customer outcomes.

Diversity

Diversity in a team should be the imperative. From the beginning of an organization’s journey, diversity will serve the overall best interests of the entire team and the product itself. The tech world suffers from a lack of diversity, and this is often reflected in our products and the challenges they face in the market—from every major social network’s inability to manage online harassment to an overabundance of startups aiming to solve white, upper- or middle-class problems.

A good product team needs a mix of design, tech, and business; a mix of genders, creeds, and backgrounds; a mix of industry experience and product management experience; and a mix of skills, from the visionary to the detail-oriented, from the data-hungry to the user-research fanatics. This level of diversity not only is the best chance you have of representing your audience, but also ensures the best experience is brought to any product challenge the team will face, and is the best defense against any one individual’s confirmation bias.

James Keller, who leads strategy at Uncorked Studios in Portland, has a great name for diversity in product creation. “Building great things requires diversity of age, skills, and experience. We call that ‘people soup.’ Organizations need structure and hierarchy to get validated ideas built into products, but the initial ideation and concept development needs less structure and more chaos. Product creation needs the chaos of people soup. Once the early phases are done, more structure is needed.”

There is a wealth of research that underlies the value of diverse teams and shows that being around people who are different from us makes us more creative, more diligent, and harder-working,6 and has also been proven to make companies more innovative and successful.7

Mina Radhakrishnan shares how she approached diversity in building the product team at Uber: “For me, it was really important to make sure that we had diversity in our group, because I think it’s really important to have women, people of color, and minorities in leadership roles in order to encourage diverse thinking. One of the ways we did this was to really look for people who didn’t necessarily have exactly the same background as us, rather than rely on the kind of pattern matching that I think is so prevalent when it comes to recruiting.

“The second product manager at Uber, for example, was an ex-McKinsey consultant, and is probably one of the best PMs I have ever had the privilege of working with. She had a completely nontraditional background. She did go to Stanford, but in terms of the work that she had done and the way that she thought about things, she just presented herself very differently. In just looking at her résumé you would not have thought she was a product person, but she was a complete natural.

“What we did was create exercises for people to do as part of applying to the product management area. In the process of looking at those exercises, we found people who really showed the right user-centric product thinking we were looking for.”

Cross-Functionality

When we say cross-functionality we don’t just mean product, design, and engineering (although that’s a good start). The best teams go further, and contain everything needed to execute their area of the product, from legal to marketing.

For example, at TransferWise, the currencies team contains lawyers and bankers in addition to the product manager, designer, and developers, so that they can manage the local bank accounts and regulatory requirements required to launch new currency exchange paths. Imagine how much more efficient this is than having to coordinate with a separate legal or banking department within the company in order to get this more basic part of their work done.

Each of these internal interfaces between teams or departments creates unnecessary additional friction, and requires processes for queueing and prioritization. True cross-functional teams can skip all of that and execute much faster because of it.

Eternal optimism

The teams we are describing are eternally optimistic, are full of energy, and have an unquenchable appetite to understand. They deconstruct problems, build the best idea for the customer, and have an unbridled passion that needs to be reined in at times. They start with a learner’s mindset. This might sound a little like unicorns and rainbows, but the reality is that great teams deliver from a positive attitude.

The best part of having diverse, cross-functional, and optimistic product teams is that much of the personal bias is reduced because the user breaks the tie. It’s unlikely that all bias will be removed, but gone are individual contributors fighting over who has the better idea. It’s purity at its core. These teams can be implicitly trusted with any vision, strategy, or idea because they know how sacred it is to respect and deliver something truly meaningful to the user. Their individual roles cross over and intersect naturally. It is not uncommon to see a user experience designer sitting next to a developer learning how to pair and code, or a developer interviewing, leading, and guiding a customer discussion.

Currently, best practices look more like this: they encapsulate both product discovery and engineering delivery. When discovery is applied the correct way, an entire product experience team can see the origin story all the way to the first, big idea stage. This involves the team creating the vision, strategy, and idea implementation. These teams actually shape it. The delivery phase brings user experience and product management to the engineering table. We have seen a lot of success using several different pieces of, or entire practices like, Lean slanted toward Kanban, Agile, and Scrum (see Figure 4-3 through Figure 4-8). This way, user experience and product management have the opportunity to witness how engineers size stories, how the single-piece workflow of a practice like Kanban breaks down into deliverables, and how much time it takes to deliver those story’s steps and details. The real goal here is for companies to make the journey from inflexible products, processes, and platforms and grow into a constant state of assiduous iteration.

Mitch Dumke (center) and team from Pluralsight leading a narrative session. Team members each jot down their simple narrative and then take turns to learn how each individual (development, product management, and user experience) sees the story coming together for the customer. Themes are collected and a simple narrative is created.
Figure 4-3. Mitch Dumke (center) and team from Pluralsight leading a narrative session. Team members each jot down their simple narrative and then take turns to learn how each individual (development, product management, and user experience) sees the story coming together for the customer. Themes are collected and a simple narrative is created.
David Platt from Pluralsight (right) leading a sizing session with the team. On the far left are three separate taped artifacts resembling the customers they are creating outcomes for. The simple narratives are grouped into themes, then steps, and then details below. The team then sizes and creates cards for their Kanban boards.
Figure 4-4. David Platt from Pluralsight (right) leading a sizing session with the team. On the far left are three separate taped artifacts resembling the customers they are creating outcomes for. The simple narratives are grouped into themes, then steps, and then details below. The team then sizes and creates cards for their Kanban boards.
Directed Discovery includes both stages of continuous discovery and continuous delivery. Column 1, VOC, stands for the “voice of the customer.” Column 2, CPT, stands for “customer preference testing,” or prototype observation. OE refers to cards dedicated to operational excellence. (Source: http://bit.ly/2nzOXB6.)
Figure 4-5. Directed Discovery includes both stages of continuous discovery and continuous delivery. Column 1, VOC, stands for the “voice of the customer.” Column 2, CPT, stands for “customer preference testing,” or prototype observation. OE refers to cards dedicated to operational excellence. (Source: http://bit.ly/2nzOXB6.)
One month’s worth of deploys at Pluralsight. Each box represents a story.
Figure 4-6. One month’s worth of deploys at Pluralsight. Each box represents a story.
One team’s worth of releases from October 2016.
Figure 4-7. One team’s worth of releases from October 2016.
A juxtaposition to a sprint cycle style of deployment. In most cases continuous discovery and continuous delivery are completely absent, potentially resulting in a higher frequency of rollbacks, bugs, and experience that don’t meet outcomes expected by the customer.
Figure 4-8. A juxtaposition to a sprint cycle style of deployment. In most cases continuous discovery and continuous delivery are completely absent, potentially resulting in a higher frequency of rollbacks, bugs, and experience that don’t meet outcomes expected by the customer.

Power comes from the team seeing this entire process and learning its nuances. Nuances are by nature the small, easily overlooked ways of working together to create better outcomes. The team learns one another’s strengths and weaknesses. This approach also provides them with the opportunity to break apart and solve problems as a group, so that everyone is part of the solution and they all see soft and hard skills working together. Teams that can relate to one another will also move more quickly and deliver at a blistering pace without even realizing it. To them, it is just a way of working.

Better still, this approach embraces the idea of a fulfilled work/life balance, as the team is not operating at an artificial pace sometimes called “scrum theater,” which gives the illusion of productivity without the material impact. This situation emerges when there’s a lot of activity but no clear metric is being created for measuring anything of value. If the team is merely following the process theory but not making true connections between each other, then they’re probably going to fail. They will be going through the motions, but to any observer the team will look and feel soulless. Velocity isn’t a label for ticking boxes on a spreadsheet, it’s what happens when there is authenticity and understanding in a team. In other words, velocity is not a measure of activity, it’s an outcome of good work. The team’s pace expresses their love for the craft of developing an amazing experience.

Developing Product Team Talent and Designing Careers

Anyone in a leadership position at a product company would agree that people are their greatest asset. “Don’t forget that people make the stuff. Relations make the bigger stuff. Get the relations and people part right first. The rest will follow,” says design guru John Maeda. In the world of software creation, nothing comes close to the potential of great talent as a predictor of success. Unlike in traditional engineering industries, there are very few hard assets like machinery and inventory to evaluate. Almost all value in the creation of modern digital products is the result of human capital. Time spent planning, discussing, designing, coding, selling, and marketing brings these products to life. Sure, there are the computers, cloud services, and physical offices needed to enable these activities, but they are all commodities and very rarely strategically critical to the success of a product.

The challenge for product leaders is to be able to guide their people in a way that is both valuable for the company and for the individuals involved. We dislike the idea of humans as “resources.” They are not inventory. They are a company’s greatest asset and should be treated accordingly. Taking responsibility for your team’s growth is a requirement for a product leader’s success. It cannot be outsourced. Throughout this book you’ll find suggestions and the recommendations of top product leaders for how to actively help your team members grow and develop. These suggestions are often stage-specific and contextual. What follows here are general recommendations that can be applied to most product organizations and teams.

Much like the processes of designing and developing product, the process of nurturing product team talent is in flux. There is no generic solution to all organizational challenges in this regard, but there are some best practices. One of them is Directed Discovery, which embodies human-centered product and design principles where the user breaks the tie. Product leaders that have developed within a process like waterfall or even Agile will have to shift their mindset from a process to more of a work style with Directed Discovery. The distinct difference from those other approaches is that the team is completely autonomous with accountability built into the work style. Directed Discovery allows the team to see themselves in a very objective way—that is, to clearly see their confirmation bias—by writing discussion guides, interviewing, building prototypes, iterating, writing code, and shipping a product with built-in analytics to measure whether the team’s qualitative research meets the desired outcome. The best implementations are not overly structured but rather frameworks that provide guiderails and allow flexibility—a set of principles, not rules, that give leaders the foundation to implement their own growth models for their teams. The ideal framework provides structure for daily decision making while still allowing for spontaneous or opportunistic adjustments. Even when you have a clear vision and a strategy to get there, it’s good to know you can course-correct when the right opportunity comes along. We call this work in developing the careers of team members “designing careers.”

The first thing to recognize is that very few leaders are having the growth and development conversation with their team members. It’s surprisingly rare to see product leaders take the initiative in designing their team’s careers. Simply having these conversations will set a good product leader apart from the rest, and although the conversation alone won’t maximize the team’s performance, at the very least it will get them thinking about what it means to take control of their own futures. Applying design-thinking principles to one’s own life is both fun and satisfying.

Creating a career path to the vision

If it’s not already obvious to those in leadership positions, your team will grow and develop with or without your input, but not in the way that helps satisfy any of the organization or product goals. If you have left a vacuum of opportunity, then other things will start to fill that vacuum. The problem you face as a leader is that any team member that cares about personal and professional development will seek growth opportunities in a way that’s not aligned with the organization, or even leave the organization to find support for their goals and dreams. Great talent won’t tolerate an unsupportive or silent leader. If you’re not having the career design conversation, then the vacuum left by that oversight will be filled by someone else’s plans or ambitions. The outcome of ignoring this type of conversation is almost always negative, and losing good talent is often the worst-case scenario for any leader.

It’s worth noting that designing people’s careers is frequently the best way to ensure that teams retain talent. You may have been led to believe that free lunches, ping-pong tables, and beanbag chairs were the way to do that, but that’ll only get average talent in the door—and it won’t keep them. More than anything else, people want to be challenged, recognized, and respected. Sitting down to help your people design their careers is all about those things. Keep in mind that you’re not doing the career designing work for them, but you are providing guidance, support, and mentorship where needed. We’ll dig into the type of questions product leaders should ask of their teams.

As the product leader, your role in helping to design your team’s career is very similar to how your design your product. The starting point of designing careers is to discuss the person’s understanding of their value, their dreams, and their vision for the future. Just like a great product, a clear, well-articulated persona and vision is a requirement for success. Clarifying your team member’s understanding of themselves—the persona—follows a similar path as the one you’d use for a product user. As we’ve said, having your team members “eat their own dog food” (or the more palatable “drink their own champagne”) and do this persona work on themselves is a great exercise in self-awareness. Again, the tools common in product development can be used just as effectively on career development—the team becomes the indispensable product.

Starting career conversations with the big picture

In his book Drive, and based on studies at MIT, Dan Pink suggests that to motivate employees who work on anything above and beyond basic tasks, we need to focus on three factors:

Autonomy
Our desire to be self-directed. As we’ve shown, this increases engagement over compliance.
Mastery
The urge to develop better skills. We’ll cover this in coming chapters.
Purpose
The desire to do something that has meaning and is important.

The purpose provides a rock to which the activities that follow can be tethered. Don’t start career conversations with incremental improvements. As product leaders, we don’t start new product conversations by listing our feature requirements. To get started, you need to know what problem the person is solving with their career. Understanding this is key to knowing how someone builds the path to a solution—that is, their career. Start with the why questions. Finding the purpose of someone’s career is the same as finding the purpose of a product. Here are some suggestions:8

  1. What dreams and plans do you have for your life?

  2. Why these particular dreams and plans?

  3. What is the problem you are working to solve?

  4. Why is this a problem worth solving?

  5. What does it look like several years into your career?

  6. When you were an eight-year-old, what did you spend your time doing?

  7. Why do you think those activities were attractive to you?

  8. Can you describe those activities in detail?

  9. How are they connected to your current work or career path?

The last few questions are especially useful, because the activities that engage our young minds are often those that we have the greatest natural affinity for. Our favorite childhood games and activities are a great indicator of the things we’re attracted to throughout our lives, even when we’re all grown up. Designing, making, building, and improving are just some of the qualities of play that might translate into a product team skill set. For example, a child attracted to creating, planning, and building things from scratch using whatever they have at their disposal—Legos or other components—might find similar satisfaction in building products as an adult. Reminding the team of the things that excited them in their childhood might help them identify what they want to do with their lives.

Building a vision of your individual team member’s future isn’t always easy. It might take several conversations to reveal where their passions and skills intersect and for them to get clarity. Experience has taught us that it’s better to help them focus on what they love working on than on the specific output of that work. What hard work are they willing to do each day that gets them closer to the outcomes you both seek? What hard work are they prepared to struggle through to get to the other end?

Developing hard skills

Mastering product management and design requires mastering a multitude of skills, and as we’ve outlined before there is no single degree or path that will teach your team all the skills they need in their role. This means the best product leaders focus on continuously developing their teams’ skills, especially in response to the new ideas, requirements, or trends that will inevitably arise as your product and business develop.

When it comes to hard skills, the first step is considering whether your team needs these new skills in response to a tactical need or a strategic focus.

“If it’s tactical,” says Ellen Chisa, VP of Product at Lola, “such as figuring out the best way to instrument something you’re shipping next week, then you’re just googling, calling someone, figuring it out; it’s pretty simple. But if it’s strategic—say you’re at an early stage, you haven’t been thinking about revenue, and you don’t know how to do that—then that’s a very different problem. It’s really a spectrum for hard skills where you have to consider what are we trying to do here, what are we trying to learn, and what’s the most effective way to learn that going to be?” Also recognize that everyone in your team learns differently, whether it’s just googling things or needing the structure of a formal course or class.

Developing soft skills

Soft skills, such as managing people, communicating clearly, and empathizing with other stakeholders or customers, are by their very nature much, much harder to teach. The best way to handle these skills is to use a coaching approach where you focus on one skill at a time and coach the team member whenever that situation comes up. Ellen Chisa underscores this point: “The most impact I’ve ever seen on coaching soft skills is being able to come up with an example right after it happens and pull someone aside and say, ‘I noticed in the meeting you did this. What were you trying to do with that?’ Sort of coaching it in the moment.”

Balancing Discovery and Delivery

There is nothing quite so useless as doing with great efficiency something that should not be done at all.

—Peter Drucker

Optimizing teams and processes for delivery is a practice that is deeply rooted in software engineering. Some of the most widely known delivery practices are Agile, Scrum (which lives inside Agile but has been more of the focus in recent years), waterfall (better known as the grandfather of early software practices), and finally, Lean. These broad buckets have their own subcategories. For example, within Lean is Kanban, a widely practiced byproduct of the Toyota Production System (TPS). All of these well-respected frameworks, processes, and workflows have been the guardrails within which we have all worked in the modern era of software development. A multitude of documents, products, tools, and the like have all been created to articulate what they mean to different companies and humans.

Process aside, as we’ve outlined earlier, the biggest delivery challenge is deciding where to spend the resources you have. We’ve discussed prioritization in depth, but how do you know what should even make it to the table for consideration? It’s extremely hard to know whether to add new features or improve existing features. This gets to the heart of product leadership. How does a leader juggle the available resources to align with the customer’s needs? Especially those needs not yet met. Simply because customers are using a product does not imply that they are enjoying it or even like the product. “That’s probably a pretty common mistake people make when working in product,” says Marco Marandiz, Product Manager at HomeAway. A product manager or leader can be fooled into believing that because people are using their product, it doesn’t need any improvement. Marandiz argues that product leaders will say to themselves, “People are using it, so it must be scratching their itch,” but that this would be a mistake. Instead, they should be asking, “How do I make this more relatable to other people? How do I reposition or frame my product in a way that addresses more people’s issues in a way that is actually valuable?” Discovering new problems or improving on existing problems boils down to the effort you put into understanding your customer. Great product leaders spend the majority of their time focusing on this discovery process.

Pushing Pixels Versus Pushing the Envelope

Product managers might be inclined to focus on the updates to the UX or UI because that’s very often easier to do than understanding the customer. But asking your customers which UI elements need to be changed will get you only a fraction of the information you need to make a product better. Discovering the real reasons behind why customers use your product will leapfrog the basic interaction questions and go straight to the core of why they think it’s valuable. This perceived value is where the attention of the product team needs to be. “I would say, take more time to make sure you’re asking the right questions, and use the data to find the real answer,” says Marandiz, who feels that focusing on data alone is a common distraction for product people. “Data is very valuable, but isn’t helpful without qualitative research. You need to ask the right questions. You need to really understand who’s using it and what you are not fulfilling as much as what you are fulfilling.”

This process of digging deeper into the value of the solution you’re seeking strikes the balance between discovery and delivery. Discover for value and then deliver on that value. Use your product vision as a lens to focus your discovery, but use the qualitative feedback from your customers to refine what you deliver.

Qualitative data is best gathered when you have something to share with your users. Prototypes, and the observations that go along with sharing them with users, are exceptionally powerful ways to gather this data. As John Maeda, Global Head of Computational Design and Inclusion at Automattic and previously Design Partner at Kleiner Perkins Caufield & Byers, says, “If a picture is worth a thousand words, a prototype is worth a thousand meetings.” We recommend reading Design Sprint: A Practical Guidebook for Building Great Digital Products (O’Reilly) by Richard Banfield, C. Todd Lombardo, and Trace Wax,9 for more information on how to create prototypes and develop the interviewing skills related to gathering qualitative feedback.

Making Discovery Part of Your Process

The key to successfully making discovery a core part of your product development process is to make it a regular part of your process, one of the rituals you do alongside stand-ups, retrospectives, and the like. The best teams we’ve spoken to make discovery and customer research a regular commitment—whether it’s a day per week or once per month. Even if they don’t always have something new to show, this schedule ensures an organization’s commitment to constantly learning and discovering what their customers value. Discovery is a muscle, and you’ll only stay strong by using it regularly.

Just Enough Process

On the practical methodology side of product leadership, there is also a lot of confusion, as well as discussion, about what processes to use. Every good product leader understands the need to be customer focused and iterative, but many are not quite sure what that looks like from a day-to-day process point of view. The questions they ask include: Do we use Agile? Scrum? Are we Lean? Are we Lean-UX? Are we a hybrid of Agile and Lean? Do we even need a process to be successful? Are we a combination of those things? Are we just making it up on the fly? These questions often overlook the fact that the specific tactics of these methodologies and frameworks have never been proven to substantially improve a product’s success.

So how does a product leader select the best process? Because these questions can be answered only in the context of the organization’s history and current implementations, it’s ridiculous to suggest a single solution. What the leader needs to do is understand the specifics of their organization and choose a process based on that information. Every company and team has a different culture, and that culture informs the best option. Here’s a list of questions the product leader needs to ask to select the ideal process for their organization:

  1. What is the process problem we’re trying to solve?

  2. Do we really know if this is the right problem to be solving?

  3. What assumptions have we been making that should be tested or validated?

  4. How will we test a new process?

  5. What’s our hypothesis?

  6. What metrics will we measure to prove or disprove our hypothesis?

  7. Who are we building a product management process for?

  8. Will these proposed changes dramatically improve the value of what we are delivering?

  9. Will these proposed changes make the lives of the team better or worse?

  10. Are we considering these changes because of external pressure or because we can truly justify the improvements?

  11. What will be affected if we add, change, or replace the current model?

  12. If we chose to add, change, or replace the current model, what will be the best way to make this happen without losing good talent or disrupting the delivery of value to our customers?

This list is not exhaustive because each organization will have industry- and stage-specific nuances that we can’t know from the outside. What these questions do is help the product leader think through issues facing the organization before changing or disrupting the current process. The goal is to understand what the digestive system of the organization looks like and what it is able to digest on a day-to-day basis, then plan for that.

The big insight is this: process means nothing without a great team. A mediocre process can be reformed into an excellent process by great people, just as a mediocre team can undermine even the best process. Choose the team first, and then decide what process amplifies their best efforts.

There is also the issue that companies of different sizes need different approaches depending on which growth stage they are in. A business can go from being a startup to an enterprise in less than a decade. That growth creates massive friction for both people and processes. We’ve interviewed and worked with a wide array of companies, and it’s not uncommon to see inconsistencies in even the most established ones. Just as small companies aren’t always agile and fast, fast-growth companies don’t always attract great talent, and big companies sometimes can’t plan ahead effectively, despite all the resources at their disposal.

Even in today’s fast-product timelines, some teams don’t have daily iterative cycles. That’s just not part of their cultural fabric. A great product leader needs to be aware of these inconsistencies and be able to plan accordingly. There are other teams that work at such high velocity that they operate on intra-day cycles, frequently prototyping and testing, not in the traditional design sprint five-day period, but in a three-day, or even two-day, period. To get on board with this and make a difference, the best product leaders have to be empathetic to the organization and the teams, and adjust themselves accordingly.

Our advice for product leaders is to spend as much time understanding the team culture, problems you’re trying to solve, and the specific organizational context as you do identifying the best features for your product process. Having smaller, cross-functional, collocated teams that have autonomy to select the best process for their specific needs might be the best solution of all.

Today’s industries and environments shift so fast that it’s hard to know anything for certain, and for product leaders around the world, that means going for a long swim in the sea of ambiguity every morning. They’re searching for the rigor of process, but it can’t always be found. As leaders, we need to understand that the rigor is not going to come from the process, but from an understanding of the context and the team—something that takes a lot of effort. For these reasons, product managers might be feeling a bit out to sea and are looking for help to find some solid ground. They want to be recognized as people who’ve got persuasive power over what happens to the product they are building—even if that recognition comes at the expense of authority.

Communication and Constraints

Connecting how you communicate to how people experience you becomes a bigger issue when you have constraints—for example, if you are under pressure to deliver on a deadline, or have an unrealistic expectation placed on you from another party. External and internal constraints are unavoidable and necessary for growth and improvement.

Understanding product leadership constraints requires first understanding your influence within a team or company. Whether you realize it or not, people hear every word that comes out of your mouth. Some of those people hang on every word you speak or write. What you say determines what your team sees as possible or impossible. Language is the point of creation, whether it be written, verbal, or body language. Your team picks up on those cues. Teams beyond your immediate responsibility will also be influenced by what you communicate. Training yourself to listen, to watch your words, and to consider the way they are received gives you an awareness that will make your communication more effective. Language either breaks down or enforces certain constraints. The specific words you use communicate constraints that, up until the moment they are received, may or may not actually exist.

Let’s consider how this works in product teams around the world. All product teams have to solve problems. Each day those teams discuss the problems. Many product leaders trying to deliver on a certain product experience talk about the options for solving those problems. Leaders might say things like, “These are the resources we have to throw at the problem,” or “We only have so many resources to go around,” or “We can’t hit that date with this much notice!” When a leader starts a problem-solving process by directing their team to certain options, they are shutting down the creative process. Leaders who are describing these constraints are not deliberately restricting creativity, but that’s often the outcome.

Step back for a minute and think about phrases like the examples just given. Those points of view suddenly become really limiting, yet how many times have we uttered them to teams and leaders around us? By using language like this, the leader creates restrictions to potential solutions. And when presented with such limited options, the team may assume the leader wants them to ignore all other options, even those not yet discussed. The team is not at fault here. They are doing what the leader has asked of them. When people hear limits, they don’t experience inspiration, creativity, or leadership.

As fellow product leaders, we know that you can come up with a lot of reasons to justify why these options are a reality for you. For instance, you could be protecting teams because they are already under a lot of pressure. They have too much on their plates or, in some cases, those options are the only known reality. Justifications tend to be based on the illusion that leaders need to have all the answers. If you, or your organization, defines leadership as having all the answers, then you’re misunderstanding leadership. Leadership is empowering people around you to see the vision, strategy, or a mission. The job of the leader is to be connected to the why of the work, not the how. Let teams shape the how. If you are a product leader playing deep in the how of the work, then there’s a very good chance your people are struggling to know what to do. Free yourself from the mental constraints of just giving options to people, and focus on the problem statement. Once you’ve got clarity on that, you can pass the responsibility of solving the problem onto your team.

You are the leader of a team, or possibly several teams. How you organize them around what is currently most important is your job. It follows, then, that giving them the best possible language to empower them is also your job. We’re not talking about motivational speeches. We’re talking about using a common vocabulary that shows your team you trust them to come up with solutions on their own. A common set of terms and descriptions goes a long way to remove assumptions about what you expect from your team. This goes beyond just describing artifacts and processes, but giving them meaning too. A task or artifact without a clearly communicated meaning won’t have the impact you seek. For example, it’s not uncommon for members of a team to disagree on what a term like wireframe means. Is it a high-fidelity or low-fidelity artifact? What format is it delivered in? Does the wireframe need annotating? Why do we need the wireframe in the first place? Who benefits from this activity or artifact?

Communicating this outwardly is necessary to build the trust that makes good teams great. Center your teams on the why as a way to frame the best solutions. Think back to conflicts you may have had over direction with your peers or teams reporting to you. Most of these stem from the language you or others created. It is your job to create language that moves the constraint to a new dimension of possibility. Treat this like a practice. Take time to learn how to do this. It may take months or even years. Commit to making it a daily exercise and teaching it to your team. It will take some time to settle in, but the fruits of this effort will return a tenfold value.

Clarifying the Question of Authority

The scarcity of recognition for their work can be a hard pill for product leaders to swallow. Many of the product leaders we spoke to mentioned that there is far less recognition for their team’s work than they had anticipated. In some cases, they may have come from roles where this was a part of the leadership environment, only to find themselves in a situation where recognition—from their company peers and the market in general—is rare, or even nonexistent. Product leaders are like the Aquaman of the technology world; they’ve been told they’ve got great superpowers, and they get to stand side-by-side with all the other superheroes, but they’re still not getting the respect they feel they deserve.

This may seem like rubbing salt into the wounds of an already difficult job, but it’s unlikely that the product leader will ever get the same personal recognition as other positions. Despite this, they do need some recognition for the hard work they do within the organization, or they might begin to feel undervalued. One of the ways to foster this is to create teams of people who value each other, so that respect and recognition come from within.

As we mentioned earlier, the role of product leader often feels like all the responsibility without all the authority. This should not be interpreted as never having any authority. Creating strong and successful teams is almost always in the power of the product leader. Product managers may not share this authority, but it’s rare that a senior product leader doesn’t have the influence and direct authority to hire their teams. The subtle difference is that product leaders don’t necessarily have authority of the entire company or over tangential teams. The founder-as-product-leader does have authority over the wider team, but that doesn’t mean they should rely on it; they should still lead, not command. Nonfounder product leaders also have the authority to hire their product managers even though they don’t have hiring or general authority over the rest of the product team (design, engineering, etc.).

Managing Politics

Leaders must find a way to depoliticize the normal work process and give their teams the superpowers to be successful. By giving them “superpowers,” we mean help them to amplify their impact. In other words, build tools and habits that highlight their impact beyond the average. Empowering teams can generate the recognition that all human beings crave. When these amplifying habits and behaviors are put into practice, the product leaders and their teams can go back to their stakeholders and say, “Look at what we’re doing. Here is the impact we’ve made.” Whether they’re artifacts, demos, prototypes, or actual finished products, it doesn’t really matter; results have to be shared with the organization. If leaders are looking for ways to bolster their internal influence and authority, they must see this as part of their jobs.

To be clear, this should never be selfishly motivated. Seeking recognition in these practical ways allows product leaders to develop authority and then use it as leverage to develop more influence within their organizations.

1 Several parts of this section on roadmapping gained color and clarity after our conversations with the authors of another O’Reilly book called Product Roadmapping: How to Prioritize Your Opportunities, Align Your Teams, and Deliver the Most Value to Your Customers and Stakeholders (http://oreil.ly/2oQAka2), C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors. We’re very grateful for their insights and for giving us permission to share their wisdom and knowledge here.

2 http://bit.ly/2n32CN0

3 A quantifiable measure used to evaluate the success of an organization, employee, etc., in meeting objectives for performance.

4 This number was first proposed in the 1990s by British anthropologist Robin Dunbar, who found a correlation between primate brain size and average social group size. By using the average human brain size and extrapolating from the results of primates, he proposed that humans can comfortably maintain only 150 stable relationships.

5 Overly autonomous teams risk losing the benefits of interdependent organizations. A lack of information cross-pollination and efficiency from centralized processes is possible, albeit unlikely, in a well-managed company.

6 Katherine W. Phillips, “How Diversity Makes Us Smarter,” Scientific American, October 1, 2014, https://www.scientificamerican.com/article/how-diversity-makes-us-smarter/.

7 Sylvia Ann Hewitt, Melinda Marshall, and Laura Sherbin, “How Diversity Can Drive Innovation,” Harvard Business Review, December 2013, https://hbr.org/2013/12/how-diversity-can-drive-innovation.

8 We recommend you add to and edit these suggestions with your own ideas. Each organization and product culture will demand a slightly different approach.

9 http://oreil.ly/2nOzgnN

Get Organizational Design for Teams, 1st Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial