How to lead your product — Part 3: Communication

I recently covered three parts of how to lead your product, with a focus on how to bring others along in uncovering insights from your User Research, how to not jump to solutions, but instead Keep Calm in the Problem Space, and how to lead others to be engaged in The Product Roadmap.

The next part of the series discusses how to lead your product in the context of communication.

Communication

As product managers, we often communicate very logically—we write out detailed user flows, capturing every path and every use case. We think through potential user actions and the associated consequences. We think through edge cases and document the logical path. But leading your product means communicating effectively with all stakeholders. A product leader needs to sell ideas to others—such as a client, a marketing team, the CEO—on a product or idea as well. Lengthy user flow diagrams aren’t always going to help you do this. Tapping into emotional responses, however, can often be more convincing in bringing a broad audience along in the product vision.

One tip here is to trade in your polished presentations in favour of whiteboarding when convincing stakeholders of an idea. Taking a collaborative approach where those in the room are embarking on a journey together to make a decision will lead to more buy-in than offering a presentation of the decision you proposed. Let’s return back to our Chefs on Demand product that we covered in earlier parts of this series. This is a mobile app that enables users to find a professional chef in their area to come to their home to cook a meal. For this product, we could present this diagram of how the user logs into the app, all of the paths around resetting a password or creating an account, and then how the user searches for a chef, what happens when a chef isn’t available, and then ultimately what happens when they select and contact a chef.

Whiteboarding—or picking up a marker on a whiteboard and drawing out your ideas in real-time and telling a story—can be more convincing and keep your team focused on the big picture. In the world that we live in today, where most workforces are now remote, using tools like Miro and Whimsical can help you have the same impact in a virtual world. For our Chefs on Demand product, the diagram might end up looking more like this.

By keeping it high level and focusing on the emotive impact, you can focus on user needs and outcomes. You avoid being bogged down by distractions about the details with those that don’t need to get in the weeds (not to mention, probably providing one of the more engaging meetings on your colleagues’ calendars).

Prioritization

A good product person always has a framework in place to prioritize features. But what separates managing your product from leading your product is how you socialize and implement that framework when it comes to feature requests.

When a request comes in that does not land in a high priority bucket, do you tell the requester, “That’s low priority,” or “Sorry, that’s not on the roadmap”? Or, do you bring them along in your prioritization decisions and talk about tradeoffs? The former is telling people why the request can’t fit in; the latter is helping to draw a line between the feature request and desired user and business outcomes. You can help the person requesting the feature arrive at the same conclusion you would about the priority of the feature—a good framework leads them to the right conclusion. This is leading your product.

This is not easy, but being transparent about your prioritization framework, and socializing that with your team and company, can help you say no, while maintaining good relationships with others and showing them that you still value their ideas.

In this diagram, we can take an internal stakeholder through the different components of the prioritization framework, from whether or not it aligns with any strategic objectives, to evaluating its impact and reach, to understanding the confidence level in that assessment, to a conversation about trade-offs within the existing roadmap. Instead of evaluating the request independently, coming to the conclusion that it is a low priority, and telling the stakeholder “no,” you can review the scoring process with the stakeholder, see the score in the context of other product objectives, and help them understand how their request may not fit in with the bigger picture.

It’s possible that some friction might arise around different goals and strategic objectives across departments in larger organizations. This can be challenging, but can also lead to another leadership skill: encouraging and taking part in processes that align all departmental goals with business objectives and while allowing space to discuss interdepartmental dependencies.

I hope you’ve enjoyed this series around how to lead, and not just manage, your product. Putting these tips into practise is not always easy. Putting in the effort, however, is rewarding and ultimately leads to better outcomes for your product, team and organization. As I reflect on all of these tips, I’m reminded of interacting with my two-year-old daughter. If I tell her what to do, provide only one option on how to do it, and ignore her input (after all, I know best, right?), it is a struggle to get anything done. If I, instead, explain to her why we are doing something, give her two options to choose from, and welcome her input, it is far less of a struggle to move forward. Products and product organizations are a lot like two-year-olds: they like being led in the right direction, not managed or forced. 

Good luck leading your product!

Feel free to reach out to me at [email protected] if you have any thoughts, comments, or questions on how to lead your product.

Catch up on previous articles in the How to Lead your Product series: