Solving the right problem

Without doubt the biggest challenge for startup businesses is whether or not they are solving the right problem. Will their solution be something people are willing to pay for, and is there long-term value in this solution? Unfortunately, these questions require answers that are not always easy to provide to an early-stage company. That’s the bad news. The good news is that there are several things a product leader can do to avoid driving the business off a cliff.

It’s been our experience that too many product managers and leaders don’t spend enough time understanding the problem before they start trying to solve it. They skip over the discovery work because they are too eager to get started on the solutions. We’ve all been in those early-stage discovery meetings when the team is already suggesting UX, UI, and engineering solutions before the problem has even been defined. Having an awareness of this tendency can help to refocus thinking on the problem.

Mike Brown, Product Manager at PatientsLikeMe, has a cautionary tale about how startups can focus too much on the shiny solution and ignore the glaring problem. Brown and his team were trying to solve the apparent problem of people not spending enough time outdoors: “One of the main takeaways from running a web community of businesses like GearCommons was that we actually had two big problems that we could solve in the outdoor industry. The first reason people don’t get outside more is that they say they don’t have enough time. We felt like that problem was an ephemeral thing—helping people find more time to go outside is not a very straightforward problem to solve. The number two problem was that people lacked access to the right equipment. For example, if you don’t own a kayak, you don’t typically go kayaking. The outdoor industry requires you to have a lot of equipment that’s highly specialized and very expensive, and this is a barrier for involvement. The light bulb moment for us was that the number two problem—access—is one that we could solve using a sharing occurrence model, a Airbnb- or RelayRides-like model. So we really, really focused on driving access to equipment through the roof. We basically amassed over a million dollars in outdoor equipment here in Boston and then a number of cities throughout the country as well. With that being our goal, we succeeded in meeting the access requirement that we had set for ourselves. But in doing so, we had unintentionally caused a problem, which we only became aware of as the business kind of came to a close. Hindsight is 20/20. We found that by focusing on the number two problem, access, we had actually exacerbated the number one problem, which was time. By amassing the equipment in one place, we increased the amount of time that it took to acquire a piece of equipment. We then found that people were actually willing to pay more money to spend less time acquiring equipment, but because we were so focused on increasing access, we didn’t focus at all on time. By creating this sharing economy marketplace, we actually exacerbated the number one problem and we think that’s one of the big reasons that our platform never took off. So, the lesson is to always follow the number one problem, not the number two problem.”

Balancing internal and external drivers

Getting quality feedback from users can be both exciting and overwhelming. Balancing this with internal drivers and ideas is difficult. Not all ideas for improvement need to come from the users. It’s perfectly normal and expected that the product team will have ideas of their own that they will want to implement. So how do you pull this together and determine what your product roadmap is, and what does that problem-solving process look like? How do you process all of that input to determine what goes on your roadmap or priority list?

Jacquelle Amankonah, YouTube’s Global Program Manager, offers this advice: “We cannot do anything or make any decisions without the protection of our creators and our viewers. I’m on the creator team. If I default to creator, that’s why. We use that as not only a data point, but as a starting point for us to determine whether we can balance this priority with our business priorities as well. Maybe there are things that we find are hard for creators or viewers to articulate, but we realize that if we act on this certain technology we can solve this very efficiently for them. We aim to validate that. We may ask, ‘If you could have a magic button that when you press, you end up with this completely automated thing, what would you want that to be?’”

Amankonah knows that posing broad questions to her team and to the user base won’t help identify the right problems. “We definitely don’t just ask, ‘What do we feel like doing, guys?’” she says. “Instead, we start with a prioritized list, a roadmap. We have to make sure that everything we want to do, all of these great ideas, are cadenced in the right way.” Amankonah does this by creating a list of the things they want to design and develop. The team then discusses what the ideal timing would be as those things relate to each other. In other words, will the launch of one thing interfere or add value to another thing? Sometimes features need to launch at the same time to ensure they are adding appropriate value, and sometimes they need to be separated to maintain their integrity. Releasing everything in one batch makes no sense for YouTube because users expect incremental improvements, not sudden and wide-reaching UX changes. “Those are the types of things that we aim to balance so that we have a very clear and cohesive story to the end user,” Amankonah continues. “Even if they’re built on different teams, we all have to work together to make sure we are making one choice as YouTube.”

In developing a roadmap, all of those internal and external nuances have to come into play. What do we have time to do? What can we make time for? How many resources does the team have? What are our users’ most pressing needs? How can we make this happen in a technically interesting and innovative way? Once those questions have been answered, the team can start determining the best path forward. “Then we cross-check them against critical user journeys,” says Amankonah. “We have to make sure that creators want to achieve this very core flow. They want to make sure they can easily and simply upload a video, check how many views they got, or review comments received on a video uploaded last week. From end to end, if we’re able to deliver that smoothly within our product, then we’re good. Then we move to the next user journey to make sure it’s just as smooth. First, we have to get the foundation right, then we can build on nice-to-haves.”

“Focus on the why,” Mina Radhakrishnan stresses. “There’s no point in building a feature if you don’t know why you’re building it. You will always have a thousand ideas for what to build, but where does that lead to? What is the purpose of what we’re trying to do? How does this tie to our company goals?”

Our interviews revealed so many good suggestions that we’ve created this cheat sheet for what product leaders should be thinking about as they balance the needs of the customer and organization:

• Understand why you’re solving this problem for the customer.

• Understand why the solution the company offers to the customer actually does what it’s supposed to do.

• Understand the problem you’re solving for both the customer and the company, and how they connect.

• Focus on the #1 problem, not on the #2 or #3.

• Build time with customers or users into your weekly product cycles.

• Understanding the users’ most pressing needs by talking to them and observing them.

• Develop a roadmap that outlines the core themes and priorities.

• Determine how much time your team will have to implement the work.

• Figure out if the team needs help from outside (freelancers, agencies, etc.).

• Discuss the technical details of how to make the work interesting and innovative.

The time that it takes for each team to gather this information and map it out will differ. Experienced product leaders will use a lens to direct the decision making and avoid scope creep or bottlenecking. That lens is almost always the company’s key set of goals. YouTube’s Amankonah says, “The way we do it is that we have OKRs that we use across Google. Most teams use OKRs quite heavily. We have annual planning, which is the end of the year. We just completed 2017 team planning, which includes taking a step back in our business to understand what went well, and where are we still missing key opportunities? What is the industry looking like? Where do we think it’s going? What big bets do we want to make in the next year? Our leadership teams get together, and using input from across the entire team, we try to land the key things that we want to ensure we hit in the next year. Those can be anything, from small changes or confirmation that we should continue something, to complete revamps of the company.”

Using a lens like OKRs, the product vision, or other key metrics will help the team decide which things on the draft roadmap are worth executing.

Getting to know your customer

Throughout this book you’ll see mentions of Directed Discovery, design sprints, and other discovery and research methods. These methods are extremely valuable, and successful product leaders reference them over and over again. Research, gather data, and prototype until you understand the problem and can articulate a solution clearly and without doubt. In a time when testing is extremely affordable and prototyping tools are practically free, there are no excuses for incorrectly defining the problem statement and associated solution. The 2016 InVision Product Design Report¹ suggests 87% of designers prototype during the design process. This is an encouraging number, but product leaders need to ensure that all members of their teams are doing this type of research and user testing as it relates to this prototyping. At Pluralsight, Fresh Tilled Soil, and Mind the Product, that number is 100%. No problem goes untested, because there’s no excuse not to test.

It benefits you, the product, and the company to spend more time upfront validating with other users and getting feedback before you build something. “The real cost of a feature is not what it cost in design, engineering, product, and all the other functions it requires,” warns Mike Brown. “The real cost is once it’s been built and is in production. That’s where you start to see the real cost, because now you have something that can break. Everything that’s built on top of that feature is something that will have to [be taken] into account. So, in fact, the real cost happens after you ship.” Brown believes, as we do, that it behooves you to spend as much time upfront trying to gather information and data to guide your decision making and your requirements before you build anything.

And industry-wide data backs this up: based on member data, the Institute of Electrical and Electronics Engineers (IEEE) estimated that fixing a software problem after deployment costs 100x as much as fixing it before development starts.²

Brown has learned a tough lesson and now insists on prototyping on all new initiatives. “As an example, this week we’re doing paper-level prototypes that we’re also testing with employees at the company. We’re asking, ‘Does this interaction make sense? Is there anything about this that you find puzzling?’³ Once this is done, we’ll take it to another level of detail where we’ll engage patients, and watch them use a particular interaction. This way, we can observe if there are any patterns, and if we can introduce them to our site to solve any problems.”

Produx Labs CEO Melissa Perri echoes the sentiment that not enough discovery is being done at companies, large or small. “Some companies do this very well, but the majority of companies don’t do this at all,” Perri says. “They’ll build an MVP, and their MVP becomes the first version of the product. They don’t descope it. They don’t experiment. They simply build a first version and launch it. Often, they’re not measuring success on it. What’s missing is a logical step-by-step approach of answering the long list of questions the team has about the product before coding anything.” Perri feels companies are rushing to get something to market, but they aren’t spending enough time understanding why it’s performing like it is. Avoid the expense of failure and product debt by doing as much lightweight testing as is reasonable. This is the best way to ensure that what you’re building is going to be useful and usable.

Closely connected to solving the right problem is talking to the right people. Knowing who to talk to reduces risk, but knowing what to talk about yields the most important value. Regardless of the domain, you need to know what specific problems your user is experiencing. You can only identify these problems by talking to them directly, which requires designing the right interview questions. The right questions identify the problems they are trying to solve as well as whether those problems are worth solving. “That’s another big challenge that startups and new products have,” says Jim Semick. “Internally, they think there’s a problem, but the end user doesn’t perceive it to be a high enough problem on their priority list to solve.”

Making the “fuzzy end” of the process less fuzzy means acknowledging that some of the things the product leader thinks are important may not be important to the end users. In the beginning stages of a product, the right conversations have little to do with product features, pricing, or onboarding. The best conversations focus on thoroughly understanding the problem that you’re trying to solve and whether that is a problem worth solving. In other words, is this a problem important enough that your users or customers will exchange something of value (time, money, energy) to have it solved?

You also have to deliver enough value that you overcome users’ natural inertia. Switching from whatever product or solution they use today has a real cost, so your solution doesn’t just have to be better—it has to be so much better it’s worth the effort to switch.

Talking to the right people doesn’t actually mean you do all the talking. In fact, it should be the reverse. Asking the right questions is the right way to think about it and then listen to the answers without bias. “The best piece of professional advice is actually the same piece of advice that I got from my mother growing up, but I think I was probably 25 before I realized what it actually meant,” says Mike Brown of PatientsLikeMe. “You have two ears and one mouth. Use them proportionally.” Listening seems to be challenging for everyone, not just product people. Consciously making the time to listen is a skill we could all be better at. Here are some easy ways to practice listening skills:

• Start any conversation with stakeholders, users, and customers with the intention to listen, and wherever possible, the commitment to be the last to speak.

• When someone has made an observation, provided feedback, or simply thought out loud, invite them to “tell me more?”

• When you receive feedback that is suggesting a feature update or addition, respond by asking, “And how would you do that?” or “Show me how you would do that?”

• Repeat back phrases to the person talking once they have finished to confirm that you have heard what they’ve said.

“That’s something that I’m still working on,” says Brown. “Being an extrovert product manager who has to corral a lot of people, it’s sometimes hard to step back and listen, and so that’s something that I continue to work on in my own career. It’s easy to keep talking until the right words come out, but to really listen to what people have to say is even more important. You’re there to ask good questions and take the feedback from a number of people. Using my ears and my mouth proportionally is something I think would serve me and other people well.”

To Brown’s point, we might add that you have two eyes as well. Two eyes, two ears, and one mouth—using them in that proportion when doing user research is indeed a good lesson.

Managing your team’s expectations

Setting expectations helps teams to manage the tough times, and product leaders set expectations all the time. Successful product leaders, however, do it differently. They focus on setting positive expectations. They discuss what they want from their teams, but they set expectations as part of a healthy, productive discussion. The discussions are focused on what can be achieved, not on what can’t be. This is subtle but important. Telling your team what you don’t want from them, or that the product might fail if they do a certain thing, is the incorrect way to motivate them. Great leaders do not use negative expectations to motivate their teams, and if you are guilty of doing this, it’s time to stop. Failure is part of the game, and needs to be taken into account, but it should not be used as a threat. Failure that happens because teams are experimenting, learning, and pushing the limits is normal and should be expected. Using the threat of failure discourages people from doing the experimentation necessary to find solutions. We are human, and of course we realize that it hurts to let the company, users, and teams down. However, breaking a few plates along the way is how we learn to spin them. Don’t punish failure or experimentation.

Knowing yourself

From our interviews it seems like some leaders are better suited for the startup challenge than others. Working with a freshly minted product team certainly features as one of the bigger challenges for early-stage companies. “I have done both,” says Jeff Veen, Design Partner at the VC firm True Ventures and formerly VP of Design at Adobe and Google Analytics Team Lead. “I have adopted existing teams as well as built teams from scratch. I have never really been successful with an adopted team. It’s always been creating the team from scratch that works best for me.” Veen, who cofounded TypeKit and Adaptive Path, the ground-breaking user experience firm in San Francisco, admits that he’s drawn to startup teams because he finds it very hard to work with established teams. He prefers to select a certain balance of people to pull together into a team, and adopting an existing team doesn’t allow for this precision—“So stepping in as a leader in an existing team just never worked for me.” Veen’s experience isn’t unique, and possibly not even restricted to startups. Adopting or joining existing teams is often about merging cultures and styles.

This can be challenging for any team, so finding the right leader is critical. It’s essential that the leader knows their strengths and admits where they might lack patience, hard skills, and soft skills. Cait Porte, VP of Product at Zmags, embodies the type of self-reflection and awareness that makes the difference in great leaders: “I would probably say patience is a virtue. I tend to be somebody who is always going, always looking for the next thing. I’m very driven, very motivated, really energetic, and I like things that can happen right away. I want them to happen yesterday. As I’ve grown in my product career, I’ve realized that sometimes patience is really, really valuable because you can get more feedback, you can digest things a little bit better. When I think back to my early product career, I wouldn’t understand why we weren’t getting something done faster. Why is it going to take us so long to do XYZ? As I’ve grown into this new role, and watched myself evolve and watched others evolve, having patience has become increasingly important, particularly as a product manager, to show me that there’s a lot more complexity than ‘build this feature, get it out the door, and then build the next one.’ I would probably tell myself to just be a little bit more patient, both with process and with people.”

For the product leader, it’s important to figure out where they can add the most value. What situations appeal to them? Does an early-stage company suit their character and style? When are they doing something that comes naturally to them, and when are they trying too hard to adapt to a role that doesn’t suit them? We’ve all witnessed this, either in others or in ourselves. An extremely small set of leaders can be both startup gurus and leaders of a mature product  organization.

Mapping the vision

Translating the vision into an experience map, roadmap, or product map is part of the job. How, then, can you take the vision and make sure there are steps along the road to achieve it? The challenge here is to ensure that during the translation, the decisions that go into the work remain connected to the vision. When tactical teams are working on product roadmaps, it’s easy to lose sight of the overall vision. For example, Tesla started its business by positioning itself as an energy company for the future. Unfortunately, that big vision can get easily lost when the product manager on the factory floor is worried about shipping a single component of the car’s software. Decisions that are made about what gets onto the product roadmap are sometimes disconnected from the strategic goals of the organization.

A well-mapped and communicated vision will include the following elements:

• A timeless description of what value the organization aims to deliver (remember Disney’s “Make People Happy”)

• A vision disconnected from specific technology or trends

• Separate documents to describe the user goals and the product goals

• A roadmap of what the big themes or stages of product delivery will be

• Connections between the stages of delivery and the value being delivered

The physical form that your vision and roadmap take is less important than what they include. Thinking through these steps is almost always more important than the specific output  forms.

Communicating continuously

It’s really important for product leaders to work with stakeholders (investors, founders, board members, key employees, core customers, and partners) to understand their priorities and get buy-in from them on the things the team is going to accomplish this period. Once there’s clarity around the vision, product leaders must work with these stakeholders to define the initiatives that will fit those strategic goals. Rather than a product leader or manager operating in a vacuum and unilaterally creating this product roadmap, they engage in a co-creative process that solidifies the vision and aligns the team. Roadmaps are just the output of a conversation and an agreement—and this conversation may need to happen several times during the evolution of a product. Roadmaps are not supposed to be set in stone. As with most things in leadership, they’re an exercise to get people talking to each other.

Good product leaders today work alongside their stakeholders or, at the very least, keep their stakeholders regularly updated. This continuous communication needs to err on the side of overcommunication. They break down silos and open channels. They look for buy-in all along the way. This also means they take the time to educate their stakeholders and executives. Updates and education don’t have to be big things, either—it might simply mean informing the executive team that a feature agreed on six months ago is no longer valid because circumstances have changed. Maybe some new competitive information was uncovered, or maybe the development effort that seemed likely at that stage didn’t materialize. Educating or reminding the stakeholders that things in this Agile world are going to change is key. As Jim Semick says about communicating expectations to executives, “In the next two, three months, I’m fairly certain about what is going to get delivered. Beyond that, we have an idea, but it’s not set in stone.”

It might be clear that product leaders need to do a good job of setting and managing expectations for their stakeholders, but it requires regular communication. Unfortunately, regular communication isn’t the norm, even in small companies and teams. In all our interviews we noticed that the most successful product leaders were also those that were regularly and actively communicating to all parts of their product organization, their users, and their outside partners. The organizations facing the worst problems had a culture of poor or infrequent communication. Unsurprisingly, we also observed that there is no single communication structure that works for all; every organization has their own style. Whether that communication is done through formal meetings with the stakeholders, daily standups and monthly meetings, or informal catch-ups, the key is to open up the channels. Perceptive product leaders will also craft channels for the different personalities within the organization. Here are some suggestions:

• Detailers will get detailed reports.

• Analyzers will get options and reasons for choosing one or the other.

• Producers will get brief but frequent updates and decisions.

Other techniques involve the “show and tell” approach:

• Prototyping demos

• Providing walkthroughs of new product features

• Standing in front of a wall-sized experience map to make sure everyone is seeing the latest thinking and feedback

Whatever the style of communication, one thing is common across successful organizations: communication is constant.

Don’t skip the research

Product startups or early-stage product projects often miss this first key step of understanding the problem. They are in too much of a hurry to build features or screens that haven’t been validated. As we’ve said, not understanding the user experience leaves gaps in knowledge that lead to frustrations around planning for the future. If product leaders invest time and energy into knowing their audience and developing the personas to adequately describe them, they will reduce the ambiguity. Only then can you move on to customer development, the process of really understanding the product and whether or not it solves the needs described by the users. Once both these steps—understanding the problem and understanding the solution—have been achieved, the product leaders can move on to next steps like deciding what the MVP (minimum viable product) will include or how it might be priced.

It bears repeating that overcoming the ambiguity of what to build and when to release features can come only from understanding your users. Knowing what their problems are, and being able to clearly articulate them, leads to better persona clarity. Once you have mapped your personas and validated your core value against actual revenue, usage, and utilization of your product, then you’re able to map one-step, two-step, three-step adjacencies in your strategy about what markets, new or emerging, to go after. What new products should you chase? What new geographies do you go after? It becomes increasingly clear what not to do, and what low-hanging fruit you should go tackle.

Making research accessible

“One of the things that we’ve been working harder to do is to get research into the hands of the rest of the team in digestible bits,” says Josh Brewer, CEO of digital product design firm Abstract, and previously Principal Designer at Twitter. “Getting the team exposed to that data was the first order. They’re starting to see and pick up the tone, if you will, of what we’re seeing in the big aggregate set of data.” Brewer’s deliberate efforts to make research understandable before dropping it into the laps of his team supports the best practices we’ve observed. Simply dumping research or data onto a product team has no value, and may even become an obstacle to product improvements because it takes time to understand and digest. This does not mean that leaders should be filtering the research through their own biases or preferences, but rather that they should identify vectors by which they can deliver the insights to the team. Each team will need to determine which vectors or communication channels they prefer. Data is becoming more accessible, but that doesn’t necessarily solve the problem of quality. Ideally, the importance of the information being shared will determine the delivery vector. For example, qualitative data from customer interviews is best delivered in forums where team members can ask questions and get additional clarity. Broader market research could conceivably be delivered without face-to-face discussion.

To start with, early-stage product leaders need only the most important qualitative data to point them in the right direction. It’s very rare that companies require enormous amounts of research to do basic validation of their product/market fit. “We’re trying to understand what the customer’s main pain is so we’re able to clearly articulate that,” says Brad Weinberg of the earliest stages of product creation. Weinberg is cofounder of Blueprint Health, a New York–based healthcare incubator that has stewarded dozens of product startups through the early phases of their growth. The job of the startup product leader is to explain how their business can potentially solve the user’s problem and whether you have agreement with the client. “In the beginning all you need to create is a high-level plan,” says Weinberg. This is step one for Weinberg and his teams. In this high-level plan there are a handful of questions that need answers before you can move on: “Ask the customer what their pain point is, what their current problems are, how they try to solve those problems now, and how you might solve them differently. Second step: go run that by them.”

Cycling through these steps might require a few iterations. Feedback from potential customers might alter how you present the solutions or identify new personas. Weinberg continues that the point of this simplified back-and-forth is to find out whether you can solve those problems, and whether the customer would buy the solution. The third step, according to Weinberg, is to take the people that expressed interest in buying the proposed solution and refine that solution. He recommends making something the prospective customer can start to see, touch, and experience: “Build some wireframes and some mockups in parallel.” In this initial stage the product leader is focusing on the basic functionality, like how the wireframe solves the user story. The artifact is not the object; rather, the response to the object’s suggested solution is where the product leader needs to focus attention. By building basic design mockups you’re validating the earlier rounds of thinking. This is not intended to convert these testing audiences to paying customers but rather to validate that intention. This interview-build-validate cycle can be repeated as many times as necessary until the team has established a risk level they are comfortable with. In other words, does the team feel they have enough feedback to elevate the conversation to the next version of prototype?

Prototyping is one way to help you define and harmonize internally as you do concept testing. Fighting for prototypes to be used as a core part of the testing strategy is part of the product leader’s responsibility. As you start putting prototypes out into the market and getting them into your product, the challenge becomes, how you do qualitative user testing and research—whether it’s the research before you actually decide to do anything, or once you’ve put it in the product? “We do user research in lots of ways,” says Emily Rawitsch, Senior Manager for Project Design at Spotify. “Sometimes we’re doing early concept testing at a high level, and sometimes we’re testing an early concept before it’s being developed. Other times we’re testing a concept while it’s being developed, and then sometimes we’re getting research after it’s been in the wild. When it’s early concept testing, that’s often when we’re moving fast, kind of like in design sprints. Although in our company we often call it design swats, kind of like a SWAT team or a group of specialists coming in to solve this urgent problem.”

Attacking this early concept testing research SWAT-style gives Rawitsch’s team the speed they need to answer their problem statements. “We’re trying to move fast because we don’t have a lot of time,” she explains. Balancing the need to move quickly while ensuring they are not leaving any of the other product team members behind is a delicate balancing act: “We can’t stay that far ahead of the sprint, and the developers are itching to go. More often than not, we’re doing this in four or five days. To give you an example of what that hyper-speed research looks like, we just did this two weeks ago where on day one we were exploring lots of solutions with divergent thinking. Day two is where we regroup with the engineers and product managers to converge ideas and kind of figure out what we’re really trying to learn. Day three, we’re finalizing our prototype and recruiting actual users and scheduling sessions, and putting together a moderation guide. By day four, we are talking to five to seven users for 30-minute sessions, and before we leave the office that day we’ve had our research debrief and emailed our top findings. At that point we’re ready to keep running with the coded prototype.”

The point of doing this type of research is to avoid having to build out an entire product only to discover that nobody cares for what you’ve created. Writing out product features in excruciating detail before basic testing is avoidable too. There are too many assumptions early on. There are sometimes assumptions about assumptions. Until these assumptions can be identified and resolved, any product creation is just guesswork. Some might argue that best practice and the product team’s previous experience might overcome these gaps in knowledge, but the reality is that they will never be a good substitute for in-depth research. Whatever the situation, the product leader will need to make tradeoffs and decide what research solutions to spend their time, money, and energy on.

Prioritizing goals

Assuming that the product leader and their team have done the necessary work of getting end-user feedback and supporting research, the next challenge is knowing what to prioritize. In other words, which of the unmet needs will get the attention of the team? “There are two answers to that,” says Josh Brewer. “One, there’s always an initial set of things for any product. We identified very early on that there were a couple things that absolutely had to exist. Otherwise, nothing else would matter.” Research or initial market fit testing will always generate a list of core items. “Two, if you don’t do X, all of the things that depend on X in the system don’t exist. So guess what? That one thing becomes one big risk.” Brewer uses this simple two-step model to identify things that need his team’s attention. Either it’s a core item or it’s a critical element that other core items need in order to exist. Finally, Brewer runs through the list and asks how the team can test these things. “Aside from those core pieces, because of the research and the methodology that we’ve used, they’re resulting in a scoring mechanism. We’re able to say, ‘Wow, OK. There’s four unmet needs that are at the top of the scale.’”

There is prioritization around what needs the product is solving, but then there’s the implication for the product development life cycle. After prioritization, it becomes a gating function. The reality is that even after items have been prioritized, there’s often still a suggestion from executives, founders, or possibly HIPPOs (highest paid person’s opinion) to include more items on the list than time might allow for.

In some cases there’s no way around the fact that something has to get done. Brewer describes such a scenario: “We have to do all of them, period. And we have to go heads down, and we have to go work through these. And then we have to figure out how to put them together and how they relate to each other.” While we don’t recommend giving in to every request that comes along, we do like the idea that this triggers new conversations. How you structure those conversations will be dependent on the team structure and processes you use. There is no ideal way to have conversations about priorities, but it is a requirement to have these conversations frequently and without politics. “It’s a mix of longer-term evaluation and working with the team to get feedback on initiatives that are in current sprints,” says Rose Grabowski, former Director of Product Management at Invaluable. “Also, looking at bugs that come in and trying to make connections between issues that are happening. There’s definitely a variety of high-level and very granular type things day to day. That’s the life of a product person,  right?”

Balancing priorities and embracing tensions

There’s   always some tension, healthy or otherwise, between overall company priorities and the specific product priorities. When you’re building the company, you have to be thinking about a wide range of things, like fundraising, so that you have a runway for everything else to happen. Those things might impact or change what you are actually doing on the product side. The most common question product leaders have is, how do you balance that tension? Product leaders should always have a place for prioritizing suggestions resulting from these conversations about features and ideas. Most people just want their idea heard and valued. Of course, there will always be too many ideas. We suggest creating a car park or a backlog for these product ideas. This can be maintained as a whiteboard, as a series of Post-its, or in a company Slack channel or idea management tool. If everyone knows there’s a place where their idea will be stored, considered, and not discarded, then most of the time these conversations are much, much easier.

“I’m right in the middle of it because my goal is for this to be a profitable company,” says Brewer. “We’re building something that we intend to charge for and we believe it will be valuable. We have a lot of stuff to validate on that front, but that’s the work. We also have a runway, and we know where the end is.” Brewer is describing a scenario very familiar to startup and high-growth companies. These constraints and tradeoffs are part of the leader’s job. Instead of avoiding these decisions, great product leaders acknowledge the reality and embrace them. Brewer sees the tradeoffs and implications as an opportunity to drive the advantages of good process. “Given the amount of time, the number of people, and the skill sets that we have, let’s establish a framework to make decisions around what we do and what we don’t do.” The decisions will be constrained and guided by things like the vision of the company, what the team believes this product should be, the skills of the current team, what’s missing from those skills, and some level of prioritization.

From that framework, a product leader will be able to cluster things into the various categories of prioritization and start to scope those out. Brewer’s goal is to have a complete picture of what the team wants to do so he can break it down and say, “OK, we probably can’t do all of this, but how can we build the right system that grows into this? And do we all agree, at least right now given all the data we have, that this is what we want to grow into? Yes? OK, great.  Let’s go.”

Diving deeper on what to prioritize

We’ve heard from the top product leaders that one of their greatest fears is that they find themselves working on the wrong thing. A team might spend weeks, months, or even years trying to fix product problems, and then realize they are either the wrong problems or that things are out of their control. “If they had lifted their heads up a little bit, looked over, and spent time understanding the user’s problem, they might have realized that actually, there isn’t a product problem if we take that away and replace it with whatever,” says Brewer.

“A lot of times, startups in technical spaces—the medical world being one of them—are very engineering-heavy,” says Brad Weinberg of Blueprint Health. “So the mindset is about knowing what the functionality needs to be, but not really knowing what the user experience is going to be.” Weinberg believes product leaders need to be able to think at the level of the user story. To know what to prioritize, a leader must operate at the level of solving problems rather than at the level of functionality. “[Product leaders] are getting people to think,” says Weinberg. “It’s the same thing as engineering, but in a different way. Engineers are doing it because they know code and they know engineering really well, and the product people are doing it because often—as businesspeople that haven’t built products before—they are thinking of features.” Weinberg says it’s about asking the right questions so the team will focus on the right activities. “What’s the way to solve this? What’s the way we can accomplish this from a design and an engineering perspective, in an efficient manner, and at the same time, solve the core question of the problems we have?”

“Part of that process is also socializing that information in lots of different ways,” says Placester’s Fred Townes of the prioritization process. “Our breakout sessions start with saying: ‘This is what we did. This is what we learned. We agreed this is important. This is how we’re doing it.’ There’s lots of straightforward communication.” Many of the leaders we spoke to talked about the importance of good communication. For most of them this seemed so obvious they didn’t make a big deal about it, and it can be overlooked. Junior managers or first-time leaders might assume that good communication happens naturally. However, as we’ve outlined earlier, good communication takes consistent effort.

Researching and reprioritizing

Product leaders can learn some surprising things in research, things that make them reconsider or deprioritize an item that their team was going to work on. This insight results in a reprioritization and in some cases puts the item on the back burner.

Emily Rawitsch from Invaluable tells the story of a reprioritization because of a change in initial assumptions about the product idea: “There’s one that really blew my mind. We wanted to redesign how search results were presented on the website. Today they are presented in a listview.” Invaluable is a premium auction site, so in many ways the business model and user experience is similar to ecommerce experiences. “But there are definite differences because we have a detailed description and a condition report,” Rawitsch continues. “People want to know if there’s a chip in an expensive vase, or they want to know the estimate, so there’s a lot of information. We looked at several mental models or expectations of how search results are presented on most shopping or ecommerce websites, and usually, it’s a beautiful grid view of images.”

Based on user research, Rawitsch’s team knew that customers prefer to see large, high-resolution images. After all, this is an auction site for high-value items. “We figured, since our users love images, let’s test out a gridview.” Initially the team was prototyping, as Rawitsch wanted to make sure they tested the concepts before they started development. “We did it using InVision, trying the idea that we could give them a listview and a gridview. We probably talked to 10 or 12 people in the end.” The team initially thought that the gridview would work best, because of the high value the users had given to images during research. What was surprising was the reaction from the users. They didn’t like the gridview. “They were not wowed by it, and we really thought that they would be. Our hypothesis was that they would want the gridview because they could see more items at once, which is what they expect when browsing the web for shopping.”

The lesson here is that what works elsewhere may not work in your context, and prioritizing based on new user research is key. Prioritizing based on gut reaction or assumed interactions might not end up as expected, as Rawitsch discovered: “Many of the users said it was harder to compare and contrast the information, as they could no longer skim down the page to compare the estimates or the conditions. Instead, their eyes had to zigzag across the screen, and that made it harder. That definitely surprised us; we weren’t expecting it. It doesn’t mean that we won’t ever implement this because, keep in mind, we talked to existing users who also have a bit of bias because maybe they don’t want the site to change. They are used to how it is. We didn’t talk to potential new users, but at the same time, because nobody we talked to was jumping up and down for the feature, we knew that we could deprioritize it and focus on something that might bring more value to our user base, faster.”

Managing team dynamics

“We’re very small, so although I do some one-on-one work, generally speaking we work together as a group,” says Ally Shear of ANSWR. “When we’re doing higher-level design it’s usually done as a group, but when we get down to details, it’s more focused—for example, exploring whether we want to include this drop-down, or this element, or that style, tends to be decided on a one-on-one basis.” Shear is describing the typical startup group dynamic. Teams like this can morph from one-on-ones to very small groups to larger groups on an hour-to-hour basis. That means leaders need to be able to go from manager to mentor and then back to manager in a moment’s notice. This back-and-forth requires strong communication skills. Living in a bubble is not an option for product leaders. Jim Semick believes that product managers need to develop these skills to manage the dynamics of startup life: “They have to have the communication skills and the political skills to know who to talk to, and how often to talk with them.”

Startups employ fewer people, so communication between team members can be as easy as swiveling a chair around. As the teams grow, the luxury of easy communication can turn into a logistical nightmare, especially for distributed teams who may not be in the same location. Being in different locations has obvious challenges. Collocation is preferred, but as teams embrace remote working practices, it is now less common. The upside of an expanding team is that more people are paying attention to the product and taking responsibility for it. The downside is an increased need for communication. This requires pretty crisp decision making to prevent tasks from stagnating and dragging out. Smaller teams don’t have the structured communication channels that larger teams have, so things tend to get done in a style that resembles the inconsistent nature of the environment they work in. One day or one week might be all about communicating issues and finding solutions, while the next might be all about production or testing.

“I spent all day yesterday in issues—all day answering questions and then answering more questions and poking holes in things and whatnot,” says Josh Brewer, who, in addition to cofounding Abstract, is coauthor of the highly popular 52 Weeks of UX. “But we made enormous progress.” Brewer describes the back-and-forth that goes on in startups. One week his team will be heads down trying to get the fundamentals done, and then suddenly all the issues they’ve been working on reach the point where an entire day of discussion is necessary. A week of low-level communication can be leapfrogged when there’s a flurry of solutions created by sudden communication opportunities. The dynamic has a variable cadence, but because of the small team size, a single day of intense communication can turbo-charge solutions and get blockages out of the way. Brewer says, when this happens, “a bunch of the work goes to engineering because it’s done and good to go, while other stuff is going back to the drawing board so we can take another pass at it.”

Being able to facilitate and maintain agility in group structures is an important skill for product leaders. It shouldn’t be assumed that such skills come naturally to them, however. These kinds of people management skills are often taught and learned through experience, and are not innate characteristics. Experience in semistructured or timeboxed design thinking exercises can be very useful for this skill development. Training or exposure to design sprints, Directed Discovery, workshop facilitation, or deep dives gives product leaders the formal training and experience they need to manage ever-changing group dynamics.

Aligning personalities and philosophy

In a startup, it’s essential that you hire people who are respectful of one another and can adapt quickly. These qualities allow them to switch roles and responsibilities whenever there’s uncertainty. Dealing with the discontinuity of team dynamics and potential disagreements requires an open-mindedness and respect for other perspectives. Adaptability often means a product leader must hire people that are well rounded. Simply put, this means that they can take on roles and expand beyond what they are hired to do. An early-startup employee might need to step into a product leadership role one minute and then act like a sales rep the next. Frequently switching roles can be confusing and frustrating for some people, and it’s certainly not for everyone. You can determine whether someone is capable of this type of change by either looking at their track record or discussing how they have dealt with change in other aspects of their lives. “In my experience, not everyone is cut out to work for a startup or at the early stages of a new product where you only know 80% of the answers because you’re never 100% certain,” says ProductPlan’s Semick. We’d go as far as saying that uncertainty is the domain not just of the startup world, but of all product companies. Daily swims in the ocean of ambiguity are a part of the product leader’s life—it’s just the depth that changes.

Hiring this flexible personality type means product managers and leaders get more out of their teams. “I’m usually looking for people who are multidisciplinary in their background, and in the way that they approach stuff,” says Josh Brewer of the teams he’s worked with both at Abstract and in his experiences with startups. “People who really want to work with their counterparts. The designers are engineering-focused, the engineers are design-focused, and everybody’s product-focused.” This cross-functional and sometimes overlapping skill set is what Brewer seeks and what informs his hiring decisions. A word of caution here, however: although multidisciplinary people who can jump between roles might be ideal for startups, these characteristics don’t always gel in larger or mature product organizations. We’ll dig into that subject in the chapters on emerging and enterprise organizations.

It can also be tempting to try to find that perfect person who has deep experience and skill in all the areas you might need them to work on, but so-called unicorns like that are very rare and this risks dragging out your hiring process indefinitely. It is far more important to find someone with deep experience in an area where help is needed, and who brings the right attitude and aptitude to pick up in other areas as required.

Aligning team members

Not all product teams will be constructed from people with product backgrounds, and not all alignment is internal to the product team alone. “We are a super early-stage startup. Only a three-year-old business,” says Mark Coffey, Chief Revenue Officer at Boston-based startup Gameface Media. He describes his experience with startup product teams: “We have a very, very small team. We’ve got a CTO, two developers, and then someone who is playing a product role, but not necessarily a person with a strong background in products.” For Coffey, his priorities for generating revenue have to be aligned with the product team’s work. “I love our current CTO right now because he gets that the reason for the product’s existence is not just to create a customer, but also to create revenue and a profit. Anytime I can sit with a product person who can see all the obvious agendas in the room, I’m happier.” Coffey feels that a good product leader will always understand that at some point the work will have to be monetized and the business made profitable. When Coffey is planning and interviewing for new product hires, he’s looking for product people who “are very, very good at joining the dots.”

Finding the right people to connect the dots is about doing the work within the context of the business and market. That means being contextually aware and sensitive. For example, one of the things that is perennially hard with the design of products is that everybody thinks they have a little bit of design capability—especially the CEO. A designer on a product team needs to allow for this, but should filter the inputs through the lens of the user experience. Coffey describes how these scenarios bring out the best “dot connecting” in product people: “What is critical in a product person is to be able to take all the noise and conversation in a room and turn it into something they can execute on. Then bring it back to the team in a way that everyone feels like their input was heard, while staying focused on the consumer experience.” Managing expectations, creating solutions, and balancing inputs with market needs is just a day in the life of a product creator. It’s no easy task but possible to do with practice.

Here are some suggestions for filtering, collecting, and communicating inputs. Asking these questions in meetings and after meetings will help filter the signal from the noise and allow the product leader to focus their communication and action:

1. It is clear what the real struggle is? In other words, can you see beyond the noise and identify the real problem or pain?

2. Can you discern whether that pain is something aligned with the vision and roadmap of the product or company? Does it need to be solved?

3. Does the company need to solve this problem to achieve its goals? How urgent is this to delivering value to the customer?

4. If urgent, then does the company have the resources to solve this problem right now? Or should we postpone it until later?

5. If the resources are available, does this reinforce the value of the product? Or does this reduce the value?

6. If it reinforces value, is that value easy to describe and communicate to the customer and product team?

7. If not, why is it hard to describe? Is it just complicated or is it not aligned with the vision, brand, or roadmap?

Aligning leadership style with team style

Aligning personality types with organizational personalities can be difficult. As with any successful business, it’s best to connect the personal goals of the team to those of the organization. “I always try to think about teams in terms of what their ambitions are. You have to create an environment where they have something to look forward to,” says Placester’s Fred Townes.

Making sure the team personalities match the organization personalities before you even make the commitment to hire them solves a fundamental problem for Townes: “To put it simply, it creates an opportunity for them to be self-motivated, and for them to stretch and want to grow.” Townes admits that it’s easy to say that, but much harder to implement this strategy. To be successful at this alignment of business and human personalities, you have to be able to demonstrate the steps to achieving their personal goals within the organization.

For the product leader, it often boils down to belief systems. At Placester, concepts like servant leadership,⁷ making data-driven decisions, and wanting to test hypotheses all align strongly with their founder’s philosophy of how good product is created. These ideas are at the core of their hiring conversations.

“I’m looking for people who are willing to learn and discovering what they naturally believe,” says Townes. “When they demonstrate that they do [learn], they tend to be successful, if not wildly successful at it, because they get to take their intuition and use that to form a hypothesis.” Aligning the product leader’s behaviors and philosophies with an environment that allows them to amplify those characteristics is the goal for Townes. The product leader gets provided with a safe place to be their best self. “They get to do experiments, which is a safe way to validate things. The results allow them to develop, and their intuition gets enhanced. At the same time, they’re progressing and moving forward toward creating some value for the business.” The lesson here is that when you hire people that share the same product philosophies as the company, there is less friction and more value creation. Our caution here is that hiring people who are simply agreeing with you, whether you’re right or wrong, is pointless. A mature product leader is committed to the customer-centric way of making product and should always hire for that alignment.

Being user-centric

Creating a product purely because you have a cool new technology is not a solution. We’ve heard this described as an “elegant solution looking for a problem.” Who will be the humans that delight in exchanging time, money, or energy for your solution? Have you really listened to them? Have you immersed yourself in their world to truly understand their pain?

There’s a demonstrable difference between people who have developed that user-centric muscle and those that haven’t. Practically, you can test this during hiring by asking prospects how they would solve problems. Each organization will have a different way to do this based on who is interviewing the candidate. The goal here is for the interviewer to see how the candidate works the problem as a product thinker. Do they start talking about technology solutions before they even consider the user’s experience? Do they reference subjective opinions instead of describing how they would establish objective research? Do they describe how they would be working as a team, or do they consider themselves to be individual contributors? The process and solutions they describe during the interview will indicate their future behaviors. Alignment between their responses and what you’re trying to create in your organization is critical to a successful product organization.

“It’s definitely about finding people who are skilled at what they do but, by default, customer focused,” affirms Joshua Porter, cofounder of the product design firm Rocket Insights and former Director of UX at HubSpot. “I remember talking about this a lot at HubSpot. We would interview candidates and always talked about people in terms of their default being customer focus. We would have them prototype something, or sketch out a flow, and would always be asking: are they talking in the voice of the customer?”

This default position isn’t only in their approach to work. Product leaders will reveal this customer-centric default in their writing too. Leaders like Porter, who coauthored 52 Weeks of UX with Josh Brewer,⁸ says he finds clues for this position in new recruits for his product team in “whether they write in first person or third person. When we recruit that’s definitely a very key trait.” Porter observes that writing in the third person indicates a lack of ego on the part of the candidate. This is essential for team alignment if you’re looking for the people who focus on creating a great product by doing well by the customer and not just servicing their egos or making a name for themselves. “You might say it’s a frame of mind,” Porter says. “It’s also the most important thing about building teams. Obviously, you need the right skill sets and you need a good balance between the skill sets and all that stuff, but I think the frame of mind is really a big part of a successful team.”

According to experienced product leaders like Porter and Townes, it’s important to have the soft skills aligned first. Once the common ground is established, you can find ways for the new team member to have an immediate and positive impact. This requires aligning their hard skills with the job at hand so they can hit the ground running, and begin adding value to the process immediately, but also giving the individual an opportunity to create personal traction and something to reference as they grow. Townes elaborates, “You can start looking at stretch opportunities either because they want to move on to another role or take another step, or because that’s just what the business needs and they’re the person closest to being able to meet that need.” A requirement for this strategy of producing good candidates is having a pipeline of talent to select from. Industry-specific hiring strategies and tactics are not the purview of this book, but product leaders need to hone their skills in this important area. Startup product leaders especially need to be mindful of their company’s growth and who their next hire might be.