How to Lead Your Product (Part 1)

I once attended a Hackathon with my engineering team to build out an MVP for our client. As a Product Manager, I thought I knew my role in the event: to keep the team focused on the right features to execute this idea. 

Instead, I spent the 24-hour event learning from my client: I came in ready to manage the product; he came in ready to lead it. He talked less about what we were trying to build, and more about why it was valuable. He talked less about features and requirements, and more about the pain that the user goes through without this product. He was less authoritative with prioritization, and more inviting to new ideas (no matter how far-fetched). The outcome of leading the product, rather than managing it, was a motivated team that stayed up all night to complete the MVP, which ultimately became its own business. 

You might be asking yourself: but what really is the difference between managing and leading your product (don’t worry, we’ll cover that). Or don’t Product Managers need to be able to both manage and lead? (The annoying answer is: yes)

But in my career, I’ve found myself falling into a predominantly management mindset because it is more comfortable, more convenient and more controlled. I often need to often take a step back and ask myself where I can find more opportunities to lead my product, because I know it will result in better outcomes if I both manage and lead. I will be sharing tools and tips to do this across 5 articles in this series, each with a specific focus: user research, stakeholder requests, the product roadmap, communication, and feature prioritization. 

One way to explain the difference is in how work gets done. Management is getting work done by telling others what to do. Leadership, on the other hand, is getting work done by guiding others in what to do. So leading means bringing people along rather than controlling them. 

Put another way, Abraham Zaleznik from the Harvard Business Review, writes, 

In addition to bringing others along, leadership, therefore, means relinquishing control sometimes in favor of the unknown. Taking these definitions together and applying them to a product context, leading your product can be defined as bringing others along in identifying and driving product outcomes, rather than telling them exactly how to achieve the outcomes you have identified as important.

If you’re bought into the idea that leading your product is important, then let’s talk about some ways to do that. 

The first area where there is an opportunity to lead versus manage your product is in how you approach user research. User research is a core pillar of any good product team’s process, but what you then do with that research is just as — if not more — important. One way I've socialized user research in the past is to create a user research report, where I report on what I’ve learned. I include the transcripts and videos and competitive analysis and data and present a summary of insights and themes. This is managing your product — it is controlling what you want other stakeholders to take away from your research. I have found that it’s much more likely in this case that your research be met with skepticism and mistrust when you only focus on sharing your interpretation of what was learned.

I’ve learned it’s much more effective to collaborate with your team on user research, and bring others along on the journey of understanding users’ needs. In this way, you are relinquishing some control over the outcome, but the result is that others on your team are that much more invested in your user’s needs because they’ve reached their own conclusions from the data. This is leading your product. While it may feel less efficient than just doing this work on behalf of the team, it gives them the opportunity to connect with your users and motivates them to solve their pains. 

But how do you invite your team to participate in the journey to understand your user’s needs in a meaningful way? One way to lead your product is to collaborate with your team on an affinity mapping exercise. In this activity, everyone writes down quotes from user interviews or insights from data or competitive analysis and then collectively works together to group insights by category. Another way is to make the role of interviewer and note taker a rotating responsibility, where everyone on the team has a chance to interact with users. 

This is an example of an affinity map for a product called Chefs on Demand, a mobile app that enables users to find a professional chef in their area to come to their home to cook a meal. From writing down quotes from user interviews, we can create common themes. You and your team start to collectively learn that users want a new culinary experience, to create a special event but also feel safer than in a restaurant, and good food while not cooking. 

You could do this independently and present that data to your team. You could say, “Hey, I’ve talked to users and they say that they want this app for a new culinary experience.” But leading an exercise like this, instead, can help you and your team collectively identify your user’s needs and have a shared conversation around the themes that emerge. 

Coming full circle, this ties nicely back to our leadership definition of tolerating some unknown of how the exercise will work out, and relinquishing some control of the outcome, in favor of a bought-in team and ultimately better outcome. 

Do you have any questions about how to lead your product effectively? Sign up for a free Product Consult, which is an hour-long session where our Product Manager will help you with any product, team, or process-related challenges you’re facing!