Start with Why: A Practical Guide for PMs

When communicating as a product manager, start with why.

Starting with why can help you avoid:

• Building a product when your team doesn’t know why they’re building it.
• Sharing data with execs when they don’t know why this data matters.
• Arguing about a design when no one knows the goal of the product.

Here’s how to put start with why into practice:

If you enjoy reading this post, I’m writing a book for new and aspiring product managers to help them get a head start in their PM career. Sign up at principles.pm to get a free chapter now.

1. Understand why

In product, your why is the customer problem that you’re trying to solve and why it matters to your company. Make sure to include your team and other stakeholders in understanding your why. This encourages everyone to contribute, feel ownership, and stay motivated to solve the customer problem even if the product changes. I cover this step in more detail here.

2. Communicate your why constantly

Once you and your team understand why you’re building the product, you need to communicate it constantly to your team, other teams and executives in docs, e-mails, and meetings.

Communicating your why constantly empowers everyone to make decisions with the same goal in mind.

For example, when we were building Twitch achievements, our goal was to let creators track their progress towards Twitch affiliate and partner status. Some people on the team however, thought that our goal was to build as many achievements as possible. This led to wasted development time that could have been avoided if I got everyone aligned on the same objective early.

3. Align on the why first

Repeating your why also helps you resolve conflicts.

I’ve found that 90% of disagreements happen when individuals or teams start discussing the what before aligning on the why.

For example, earlier this year, I shared the design for a new Twitch creator analytics page with the executive team. But I started to walk through the design without getting alignment on why we were re-designing the page in the first place. Because I didn’t walk through the why first (e.g. creators want all their analytics in one place at a glance), people were not able to easily understand the trade-offs that we made and raised a lot of questions.

As another example, in the early days of Facebook Live, my team wanted to show more live videos in News Feed. We ran an experiment and found that more live videos in feed led to more comments, but fewer likes. We spent a lot of time debating the value of comments vs. likes with little progress. Only after discussing the why (in live video, people want to interact with the creator through comments, not like the post) and aligning on a higher level goal that’s shared by both teams (time spent) were we able to move forward.

Have the discipline to start with why everyday. The PMs that do are rewarded with a team that’s aligned on a single objective and a clear path towards resolving disagreements.

I’m writing a book for new and aspiring product managers. If you enjoyed this post, visit principles.pm to get a free chapter.