main(e)learn Reflections: What is a product leader?
A colleague once told me that products leaders are driven above all else to solve user problems simply, elegantly, and ultimately for the overwhelming delight of the user. Nothing can or will stand in the way of that goal. Great product leaders, then, have the knack and the skill to determine the right problems to solve and the best way to solve them. Product leaders are explorers – they identify a destination (the problem to solve) and chart a journey (how to solve the problem) to get there. While the goal sounds simple, in practice the journey requires myriad techniques, methods, processes, systems, and often a little intuition to successfully arrive at the destination.
Like an explorer, the product leader first needs to determine the destination for the journey. Sometimes a journey is necessary to figure out the destination, but the journey is never more important than the destination. In other words, product leaders must first discover what problems matter most to solve before they can choose how best to solve them. That is easier said than done, sometimes, when a shiny technology may dangle before a product leader’s eyes with the promise all things to everyone.
Where does this exploration start? With the user, of course. Some product leaders may have been users in the past, and those product leaders can rely heavily on experience and their own “genius”, or intuition. Most product leaders, however, must deeply immerse themselves in their users’ experiences to feel their problems and empathize with their pain. Simulations, persona building, focus groups, user interviews, and data analytics are important techniques that can help, but when feasible there is no better method than direct, immersive observation. Product leaders usually find this to be the most interesting part of the process.
What next? Product leaders need to assess, analyze, and weigh the user research to articulate the user problems and determine which are most important to solve. Users are a collection of many different experiences and problems, and no two users are the same. Sometimes the data collected is incomplete or difficult to interpret. Regardless, product leaders must synthesize the research, establish simplified user personae, clearly and simply articulate the user problems, and decide which of the problems are most meaningful to solve.
Occasionally the questions and gaps are too significant to make decisions, and the products leaders must go back to the start to conduct more research. But when the research is sufficient and solid, great product leaders rely on diverse groups of stakeholders to help with this process. Many great techniques exist for how to harness groups to transform observations into needs and judge their relative importance. But, in the end, the product leader ultimately must decide the destination and choose the problem to solve.
Once the destination is determined, the product leader creates the path, or roadmap, for the journey. Roadmaps are built from the specific requirements necessary to solve the prioritized user problems. Requirements are built from the detailed, methodical articulation of user needs in the form of stories. Stories articulate the “what” and the “why”. The “how” will come later and should be left to the builders. Product leaders often find this challenging, as other business stakeholders may want to jump directly to the “how” – remember the siren call of shiny dangling technology. But shortcuts followed risk taking the journey off course and ending up somewhere else than the needed destination.
Product leaders also must ensure that the product team stays driven and focused to get to the destination. This sounds simple, but product teams often get distracted with other directions that may seem interesting, trendy, or intuitively better to follow. When these arise, great product leaders continually repeat a simple question as a mantra: “What problems are we trying to solve?” The answer should be simple, since the first step of the process determined the problems to solve. But if the team has strayed off course, the answer can get quite convoluted and confusing. Repeatedly asking “What problems are we trying to solve” can be quite annoying to the product team or business stakeholders, but if the team cannot answer this question properly, then it uncovers a distraction or diversion that needs to be addressed.
It is worth pausing a moment to note that destinations and journeys can and should change if user needs and problems change in type, scope, understanding, and / or priority. “Agile” processes come into favor over “waterfall” processes for this reason – agile processes foster and accommodate changes in direction better. Regardless of process, product leaders need flexibility and foresight to know when to make changes to the direction or the journey. But regardless of change, a product leader and team must, at the end of the day, have a "north star", be able to answer “What problems are we trying to solve?”, and believe the answer leads the journey to the most important destination.
Now comes the journey itself. We will share further reflections later regarding how to different approaches to making these journeys. But at the risk of being tautological, product leaders must lead their teams through the journey. Developers, designers, project managers, marketers, customer support – everyone in the team needs to know and believe the product leader has full responsibility and accountability for the product’s direction and destination. It’s a difficult responsibility, no question, but it’s the price a product leader pays for the opportunity to choose the destination, chart the roadmap, and share the joy of the journey to its successful end -- the overwhelming delight of the customer.