Maintaining a User Focus

If you’re the Chief Product Officer, a VP of Product, or a CTO, it’s a huge risk for you to make the user experience, product management, and technology decisions solely by yourself. Who’s to say that you alone know what’s best for the product and how your decisions are going to affect tens of thousands—or even millions—of users? For instance, we recently observed product leaders in an emerging healthcare-related organization reviewing design comps just before shipping. In this scenario, the design decisions are being made in isolation, without any feedback from the end users. That’s a huge risk for an organization to take. They are assuming that they have total understanding of what millions of healthcare professionals or patients would prefer to see on the screens of their digital product.

If you have disagreement within the team, you have a bottleneck to shipping. “As a product manager you have to prove the case for why the company should make a certain decision or not,” says Jacquelle Amankonah, YouTube’s Global Program Manager. “If you don’t back up your idea with facts and data, or only rely on intuition, a lot of people won’t take your argument seriously.” Our product leaders’ experience suggests putting the user at the center of this decision and have the user break the tie for you. Of course it’s never that simple. The challenge is balancing inside knowledge of what the business needs with customer feedback and data.

“How do we continue to have high-quality service and continue to push the roadmap forward quickly? I would say that is the biggest challenge,” says Bryan Dunn of Localytics. So how do product leaders with a fast-growing or large user base solve this problem? The solution appears to be rooted in two areas. First, the foundation of every successful product business is that it is a human-centered organization. Secondly, as the disciplines of the organization grow, the pillars of human-centered design and product development are consistently held up as sacred. This requires leaders to evangelize and lobby for the interests of the customer.

Founders are exposed to this early on and can get beaten down by it pretty quickly. It’s easy for early-stage leaders to believe they have all the answers. When customer feedback comes in that contradicts the leader’s assumptions of how the product is supposed to work, it can be distressing. Healthy leaders undergo a transition, and learn to be a servant leader—that is, they learn to serve the customer’s needs and not just their own ideas. The opposite, and unhealthy behavior, is to ignore customer feedback or research. This latter approach has been more popular in the last decade, and leaders that adopt it are often heard paraphrasing Steve Jobs, who said, “People don’t know what they want until you show it to them.” This idea, from a 1997 Jobs interview with Business Week, has become a convenient excuse for product leaders to eschew market research and customer feedback. What’s overlooked when they repeat this story is the fact that by then, Jobs was already several decades into building consumer products and had amassed years of feedback from which he could make product predictions. Apple was also a billion-dollar global brand by then, giving Jobs an almost unique ability to launch products with unequalled marketing strength. Almost no other company in the modern era, and certainly no other consumer product leader, has achieved this type of effectiveness. Apple wasn’t exempt from product failure either, and it took decades to achieve its success. Trying to use Jobs’s words to describe any other emerging product development is naive.

Checking the Ego

Listening to your user is a far better approach for modern product leaders. It immediately reduces risk. When they start to interact with your product, users show you things that you might never have imagined or protected against. Some leaders may feel that exposing their new creation to users too early will reduce the purity of their manifestation. This is the ego talking. Being open to this feedback isn’t a blow to your original ideas; it’s the best short- and long-term decision you can make. The product might be a manifestation of your creative process, but if you and the team have done your qualitative homework, there’s nothing to fear—you’ve set your product up for success. If you hide from the truth that user research reveals, you’re setting yourself up for an uphill battle. Homework, when executed correctly, means going beyond talking to users to include research into the competitive and market landscapes and the technical feasibility of the solution.

As Reid Hoffman, the founder of LinkedIn, puts it: “If you are not embarrassed by the first version of your product, you’ve launched too late.”

As the company moves through each stage of its growth, the founders’ egos may undergo some friction. Once a startup prepares to ship its first product, things become more important to a founder or to the business. At this and other transitions, it can be easy to lose sight of the product vision and the desired experience. Egos tend to make even the smartest people retreat to familiar ideas and shut down external inputs. Doing this means running the risk of losing perspective and sight of what the users really want.

During these transitions some leaders might ignore the big picture and distract themselves with details. It’s not uncommon to see product leaders focus their attention exclusively on the numbers. They start looking at coin operation, revenue, LTV (lifetime value) to CAC (customer acquisition costs), and length of stay. It’s all unit economics at that point, but again, the danger is that they can lose sight of what the user wants and values. Stay centered on the user—their actual likelihood to buy, and all the factors around retaining really great customers—and this problem solves itself. Companies that are motivated to grow in size and scale generally don’t have founders that are user-centered or empathetic at their core. “I think it’s important to care about what you’re building and who it’s for—taking more than just a shallow approach to understanding the user’s perspective,” says Marco Marandiz, who has worked at CapitalOne, has built products like HoverCards and Instant Logo Search, and is currently Product Manager at HomeAway. Marandiz thinks that having an understanding of behavior is not enough; he believes that it’s the foundation, but that looking more closely at how people interact with the product solves the problem more effectively. “I think this whole idea of empathy needs to be present from the top—in designing the experience, through product management, and down to the developers,” says Marandiz. “Product management should always be asking: What is this product we’re making? How is it actually valuable?” Marandiz says the feedback needs to come from the people in the trenches of product creation and that the organization benefits from these voices. If an engineer doesn’t believe that what they’re building is actually good for the user, then that opinion should matter. Investigate that opinion. Understand why you’re creating a feature or optimizing one. “If you know the goal is to make somebody spend 10 or 15 more minutes on your product—even though it won’t actually add value to their life—that needs to be considered all the way through [the organization].”

The Journey from Technical Master to People Leader

Product company founders and leaders come from a wide array of backgrounds. There are sales and marketing CEOs, engineering-focused CEOs, operationally driven CEOs, and design-minded founders, to name just a few. Right now, product leadership in the digital space is relatively new, and there are not too many founders or CEOs that come from a purely product background. This might seem unusual, but it’s merely a function of time: not enough has passed for senior leaders to have amassed exclusively product-based experience.

Sometimes the transition from technical leadership to product leadership can be bumpy, and dramatic role changes are not uncommon. “They talked to one of the senior developers, plucked him out, made him a senior product manager, and plucked me out of customer support and made me junior product manager,” remembers Janna Bastow, cofounder of ProdPad and cofounder of Mind the Product. “[They] put the two of us together, and that was the first product team this company had seen. This was a 10-year-old, IPO’d tech company with more than 300 people who had never had an actual product person.” Bastow’s experience might sound familiar. It’s not uncommon for product leaders to be in technical positions one day and leadership positions the next. “It was quite the task to take over. We started off by googling stuff like, ‘what is a product manager?’ and ‘how do I do a product spec or a roadmap?’ or things like that.”

These sudden transitions still happen in high-growth companies today. But this is changing. Our perspectives are almost entirely informed by the pace of technology and innovation. We are still in the honeymoon phase of technological evolution, and things will probably remain this way for some time. Our prediction is, if you are a product leader, then your technical strategy is also likely to be your corporate strategy. Whether you like it or not, it is the way of the world. That will slowly change and shift toward a more human-centric set of strategies, but for now the challenge is overcoming the desire to frame all things by the technical conversation.

Connecting the Dots

The  common threads that tie an organization together through each stage, whether it’s an emerging startup or an enterprise, are the following:

• The technology stack

• The experience being built

• The affordances that are put on the page to accentuate that experience

• How the user interacts with those things

At each of these points, you need to consider where you’re meeting the user. Knowing what happens when each element of your business crosses paths with the user is your job as product leader. No value can be created in a commercial product venture without a customer. Connecting the dots between tech, experience, affordances, and interaction through the lens of the user or customer is a challenge a product leader must embrace. The work on these tasks is too often divided across groups or teams. That’s a mistake. Understanding how the tech, experience, affordances, and interactions work together should be the objective, and building teams and communication flow to connect those dots goes a long way toward reaching it.

Technology trends—not only the stack of technology, but the devices that deliver the experiences—are evolving faster than the product leader can accommodate. Whether it’s a wearable device, an IoT device, a native iOS, Android, or a desktop or web app, there will always be more vectors than a single company can address effectively. Just think about all the things that you have to keep track of, depending on your corporate strategy and where you’re going to market. To avoid having the technology conversation completely overwhelm every decision, the product leader needs to seriously consider centering the company on a foundation product. When the company has a core foundation, it becomes the single source of truth. A core product or platform provides a lens through which other business and operational decisions can be filtered. It becomes infinitely easier to project out from the core and inform marketing and sales, customer service and support, and customer success.

Supporting Transitioning Leaders

For many high-growth companies, one of the greater challenges will be providing for product leadership transition paths. Early-stage companies might still have one or more founders involved in the day-to-day running of the product, but emerging or fast-growth businesses will want to outgrow this setup. They will need to hire product managers to lift the operational burdens off the senior product leaders. Naturally this causes a new set of problems. The first challenge is to balance the pace of growth and the interplay with a leader trying to break through to the next growth phase. In many cases, product managers who want to become product leaders find this a really tough phase. Up until then the product leader has been a practitioner. The practitioner is primarily a role characterized by hard skills. By contrast, a leadership role has a much higher degree of interdependent soft skills. It’s not uncommon to see a product manager in the middle of this transition going back to place their hands on the practitioner’s wheel. It’s their comfort zone. It’s what they know. Hard skills mattered for so long that they understandably started convincing themselves they didn’t need to focus on soft skills. “We’ve been around for close to eight years now,” says Bryan Dunn of Localytics. “We have a lot of product. When you’re an early-stage startup, you need to just keep shipping product in order to hook a big customer so you can continue to pay everybody’s paycheck and you’re not running out of runway. We’re at the point now where we have great product/market fit and need to be way more thoughtful about what we ship, and more importantly what we don’t ship.” This last point is the aha! moment for companies in transition. At first you can’t ship enough, but at some point you’ve got the reverse problem. “Everything you ship requires a certain amount of maintenance, service, and support, which causes you to get slower over time,” says Dunn of this challenge of product debt.

As the leader of the product organization, it is essential that you don’t ignore this or assume the transitioning leader can manage on their own. You must take notice and work through the transition for the team’s and individual’s sake. We have seen time and time again that when a product manager tries to make the leap, one of two scenarios occurs. In the first scenario, they make the leap, and the soft skills can’t make the shift. In the second scenario, they make the leap to leadership, but the team leader above them doesn’t create space for the individual to calibrate into the role. Both these scenarios have the same outcome: a failure to add value on the part of the transitioning leader and disappointment for all sides.

Preventing Communication Breakdown

As we’ve said before, the way teams communicate is a major make-it-or-break-it point. All really great products live or die by communication. This goes for communication within the team and inside the product, and only becomes more important as the team and organization grow. Here are four simple tips that might help product leaders improve their communication skills:

• Acknowledge personal bias. As Automattic’s John Maeda reminds us: “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.” In the user experience world, we are used to considering the needs of the user (or at least we should be) and must apply this concept to how we communicate with others. When product leaders are trying to communicate something, they need to think about how people experience them as a leader. It’s not just about what they say, but also about how it will be perceived or understood. Leaders can often fall into the trap of assuming that whatever they say will be understood exactly as they intended. To demonstrate this, we’d like you to think back to yesterday, and any interactions you may have had with your peers, family, and friends. Take a moment and consider how they might have experienced you as a person and your communication. Then go ask them how they actually experienced you in that moment. Don’t explain, don’t defend; just sit there and listen. We bet your intent and their experience don’t line up.

• Practice active listening skills. In order for really effective communication to take place in any situation, people need to have a desire to listen to you and what you have to say. A good exercise in being present is to listen intently to the person communicating with you, and then play back to them what you think you heard. This conveys that you have actually been listening and opens up a magical place where people want to co-create something with you and are prepared to listen.

• Take the information from whence it comes. Now combine the two previous points—bias and listening—and consider the other side. Because communication is two-sided, where delivery is one side of this equation and receiving the other, some people have a listening problem. Delivering communication to these people is inherently problematic for leaders. From high-level concept strategies to daily task delegation, whatever you are trying to get across is going to be filtered by the receiving party. When people listen to you they subconsciously place you into what we call a “listening bucket.” For example, let’s say you are trying to communicate a new experience release to the sales team responsible for selling it. When the sales people listen to you speak, in their mind they think of you as the product leader. This is their confirmation bias. They place the conversation in the “product leader” listening bucket. This means when the leader is speaking in the context of sales or something sales related, people diminish the emphasis of what you are trying to say because you are not the sales leader. This can be an opportunity for the smart leader. If you spend time trying to relate to or seeking to understand their context before you start communicating what you want them to learn, they will feel something different, something more resonant with their interests and ultimately more impactful. You are no longer in the “product leader” bucket because they feel like you understand their world. We first need to listen, then use language backed up by action in a way that connects with them, not to them.

• Remove distractions. Finally, there are also more distractions in the workplace and at home than ever before (notifications from devices seem to be deliberately designed to interrupt conversations), and this can contribute to communication breaking down or people having trouble transferring ideas. We encourage you to ban nonessential devices in meetings.

Here is the challenge we pose to you. In order for you to listen to the user and be the best leader possible, you need to master relating, co-creating, and delivering with your team. It’s essential that the product leader develops these skills. If you can’t do this well with your own team, then you are unlikely to be able to do it with customers and potential customers. Fine-tuning your listening and co-creative skills doesn’t just make you a good product leader; it makes you a good product manager.

Execution Informs Vision

The difference between vision and strategy is in how the value of ideas flows inside the organization. In healthy organizations, leaders, including product leaders, come up with the high-level vision for the organization. Then the execution of that vision happens at the individual practitioner level. Here’s the rub: just because the leaders are developing the vision doesn’t mean the value begins and ends with them. In order for the organization to remain focused and aligned, the value of ideas needs to flow up from the execution level back to the vision level. In practical terms, this means that practitioners need to be connecting their work to the vision, and leaders need to be willing to adjust the vision to accommodate the incoming insights from practitioners and customers. Once real customer data is available, the leaders have to be open to that vision being adjusted and accept that the strategy might change completely because of it.

Let’s look at an actual example of how feedback from the trenches affects the vision and strategy. At Pluralsight the teams were working on a concept called learning paths. Company founder Aaron Skonnard had a vision that their customers, which they call learners, would benefit from a new way of using the web application. His vision was that from inside the web app they could elevate the learner’s experience from just learning specific skills to participating in a learning path. These learning paths were like career paths. This insight came from observing how learners’ journeys correlated with topics popular on the company’s blog. There were over a hundred learning paths that had consistently been bubbling up from Pluralsight’s work during the previous five years, all highly trafficked areas on the company blog, so the team at Pluralsight knew they were popular and established. Skonnard felt strongly that because these learning paths were so popular, it pointed the way to a new vision—they needed to have learning paths inside the web app. To test this vision, the product team designed a wireframe of the new version of the app as envisioned by Skonnard.

But when the team went out and began talking to customers, they quickly discovered that learning paths were not resonating with them. Despite the fact that there was a lot of traffic from the website on those paths, the actual time that people lived inside these activities was very short. What Pluralsight’s product team discovered in this research was that the new vision didn’t mesh with the reality. They discovered that their primary customer, very seasoned developers with 7–15 years of experience, wanted to scale up their skills but not on a predetermined career path. Instead they wanted to scale up skills in a specific technology. They didn’t want to become a frontend engineer; they wanted to learn specific technology skills like Angular, and then they wanted to scale up in Angular 2. That’s the moment where a vision was informed by the execution of a prototype and customer feedback about that prototype. All of a sudden, the vision needed to adapt.

This example isn’t simply about a vision that didn’t work, but rather about what you can discover by allowing real-world testing to inform your vision. When the product people went out to test the execution of that idea, they discovered that instead of launching learning paths, they should be launching skill paths. So that’s exactly what they did. They learned in the marketplace, and it reshaped the vision. That insight changed the company’s product strategy and the product team was able to launch something that users were surprised and delighted by.

At the same time, you have to keep your product vision in mind and not let yourself get sidetracked by all these new inputs. “People are always going to ask you to do more. If you follow them blindly, you can end up being in a different market. Your product can have more features and a bigger footprint and more complexity than it originally had—and lose the focus that made it so valuable in the first place,” says Basecamp product manager Ryan Singer.

Getting the Right People on the Team

Beyond location, how do you identify the people on the team? Once you’ve established your company’s preference for location, or the lack thereof, and the structure, then you’ve got to find the human beings for that environment. How do you do that? “We’ve worked with a couple of recruiters that I had worked with over the years to help me find great people,” explains Katz. Having decided on a recruitment strategy, Katz was able to implement his plan in stages. The first stage was to create the core of the team. “We started building a nucleus of two or three people and radiated out from there,” explains Katz. “We’ve deliberately built the team slowly to maintain quality. I’ve been very conscious to not lower the bar.” Like other successful product leaders, Katz holds the quality of his people above all else. For fast-growing companies, this is extraordinarily difficult. There is always pressure on the product team to provide resources as they are needed. “That’s often a little bit of a challenge because we have an 18,000-person organization,” Katz continues. “As you can imagine, there are a lot of projects that have had latent needs for UX and product capabilities, so there’s this continual pressure to add additional people to meet some of that demand.” The product leader needs to balance the needs of the organization with the need to maintain high standards in new hires.

“I think there are a couple of things that we do as part of our recruiting and interview process,” says Katz. “One of the things that I find challenging is evaluating portfolios. Everybody has a portfolio, and lots of people’s portfolios have great stuff in them, but one of the things that’s really tough is to identify what that person actually did, and how did they contribute to the items they’re displaying in their portfolio?” Katz is describing the familiar challenge of evaluating work during one-on-ones with potential employees. As much as product leaders might be tempted to do what the rest of the organization is doing and go through some kind of standardized onboarding process, there is the threat that the bar might be lowered. The key is to try to separate the work that person has done from the overall output of the team they were part of. “Typically, people work on teams, so it’s often hard to isolate what contributions a given person made. One of the things that we’ve done to get around that challenge is to create a design exercise that we have everybody in the practice complete as part of the interview process.”

Katz asks prospective employees to do these design exercises after their first-round discussion and once mutual interest has been established. “It’s a pretty straightforward exercise in that it’s really an ecommerce checkout experience—a mobile ecommerce checkout experience, I should say.” Katz’s team provides the candidate with a user story and then asks the candidate to create a design that satisfies the story. “We leave it, really, pretty open-ended, and we found that it’s really effective. For one, it’s a story that people can wrap their heads around pretty easily and doesn’t require a lot of domain knowledge. Everyone has experience dealing with mobile checkouts these days. But there’s a bunch of subtleties to the exercise that either people pick up on or they don’t.”

Because there’s no right or wrong way to answer these requests, Katz says these types of thinking exercises enable the team to see where their skills and interests lie, “whether it’s in interaction design or visual design or information architecture. And the overall presentation of things: How did they do it? Do they use a prototyping tool? Do they do static wireframes? Do they do really high-fidelity comps? Or do they do things that are more structural and skeletal, but show the flow?” The insights gained through this exercise provide answers that Katz would simply never get from just looking at a portfolio or speaking to a candidate. “I’ve seen some examples that are just amazing and really out of the box, and there have been other times where I had really high expectations and I was disappointed,” Katz says. “It’s a great way of cutting through to what people can and can’t do, how they think, and where they choose to spend their time.”