Product planning is a difficult term to define because it’s so broad and involves so many different aspects of a product manager’s job. In fact, it’s probably a much larger portion of your role as a PM than you realize.

What is Product Planning?

Product planning involves all of the internally focused decisions, steps, and tasks necessary to develop a successful product. In other words, it involves everything you’ll need to do that will affect the product itself. By contrast, go-to-market planning involves all of the external-facing steps. These are the things you’ll do to introduce and market your product to the public.

Here are a few examples of both a product plan and go-to-market plan to better understand how we see both functions.

Product Plan:

• What features should we prioritize for the product’s development?
• How will we determine the price points for our product?
• Which vendors will we work with for manufacturing?
• What will be our revenue targets, our goals for new-customer adoption and other metrics that we can track to determine the product’s level of success?

Go-to-Market Plan:

• What email campaigns will we develop to inform prospects about our new product?
• Which pieces of marketing collateral should we create for this product launch?
• How and when will we train our sales force on selling the new product?
• Should we create limited-time promotions to boost early purchases?
• What PR campaigns will we roll out to increase industry awareness prior to launch?

Product Planning is Not One Meeting or a One-Time Activity

A common misconception among product owners is to think of “product planning” as just an activity, something they do once in the early stage of a product’s development. They might hold a single meeting with their stakeholders. The meeting will help to decide, for example, what major themes to prioritize, who their target customers will be, and the basic pricing structure for the product. From there, they jump straight into execution mode—never to revisit any of these big-picture strategic decisions again.

Of course, after you’ve gotten underway developing your product at any stage, the realities on the ground might change. This is why it is important to not view product planning as a one-time step in the process and as a major strategic component of the process itself.

One great thing about understanding product planning as an ongoing part of your role, as opposed to a one-time task, is that it can give you a new framework that allows you to make changes to your initial planning when those changes are strategically called for.

Let’s say at various stages of your product’s development you gain new demographic data about your primary user persona, or your customer surveys reveal new and counterintuitive information about which features to prioritize in your next release, or you bring in a new stakeholder who has insights your team hasn’t considered before. All of these scenarios might demand that you revisit the decisions you and your team made in your early-stage product planning sessions.

However, changing some of these agreed-upon priorities and decisions midway through your development can feel uncomfortable. That is why it is essential to adjust your organization’s thinking to understand that product planning is never actually finished.

So, here’s the bottom line around your product plan:

When you approach product planning as a one-time event, the decisions made dictate the entirety of your product’s development. It is more strategically advantageous to make decisions throughout the product development process, so that you can constantly weigh new information and new realities.

A Good Product Planning Strategy

Okay, so if product planning is a never-ending part of product management. If it should be woven into everything we do as product managers to help us successfully develop our products, then what should the product planning portion of our role actually look like? How should we schedule product planning? Whom should we involve, and when?

Here are a few steps to help you craft your own product planning culture.

1. Create an organizational culture that views product planning as an ongoing process.

For most companies, this will require a major shift in thinking, but it will be worth the effort.

You don’t want to change your core mission every other week, of course. But you also shouldn’t feel beholden to a set of strategic plans that came out of a single meeting months earlier — merely because you called that your “product planning meeting” and everyone agreed on those decisions back then.

Tweet This:
“Create an organizational culture that views product planning as an ongoing process.”

When you can persuade your core team, your stakeholders and your organization in general that product planning must be ongoing and must leave open the ability to change direction or priorities when the facts demand it, you will ultimately be in a much better position to deliver more successful products.

2. Establish a culture of frequent communication throughout the product development process — not merely in the few meetings you’ve scheduled.

If you encourage your organization to adjust its thinking and to understand that product planning might require a shift in priority when the strategic realities call for it, you will want to communicate more often with your team — and to encourage more communication from them as well.

Because your early-stage decisions are not set in stone, you might be making changes to your plan at various stages throughout the process. And because your team now knows they can suggest changes as well if they have the data or insights to support them, they might also want to propose updates to your strategic plan. For these reasons, you will want to communicate more frequently across your organization to make sure everyone knows about any updates or additions to your plans.

This new frequent-communication culture might take the form of additional, short update meetings. You may also benefit from using a product roadmap tool that can automatically alert the relevant teams and individuals when you’ve made updates to the roadmap.

3. Summarize your research with conclusions and key takeaways — don’t data dump.

Pollsters and other political researchers often use the term “top sheet” to mean the front page of a technical and usually equation- or graph-heavy report. This top sheet is a handy summary to what’s inside that report, usually just a few bullets that any layperson can understand, such as “42% of respondents said they are concerned or highly concerned about….”

As a product manager, when you want to suggest strategic plans or goals for your product or propose strategic changes as part of the ongoing product planning we’re discussing, you’ll want to back up those changes with data. But that does not mean merely dumping volumes of research onto your team and expecting them to find your conclusions for themselves.

A good product manager will summarize the data — and present what amounts to a top sheet that clearly and quickly shows the support for your ideas. This top sheet might be the data points you are pulling from a relevant industry report. It might be a few key quotes from customers, taken from surveys or interviews you’ve conducted. The point is, you want to pull out the relevant information from your research that helps you make your point — without making your stakeholders and your team sift through the raw data and find it themselves.

At the same time, though, you will still need to provide that raw data. If you are merely dumping information in front of your core team or your stakeholders — and not supplying them with any context or conclusions around that data — you are not doing your job. Likewise, if you’re simply presenting conclusions without the supporting research, you are also falling short of your responsibility. You need to do both.

4. Include product planning ceremonies to make sure everyone on the team is up-to-date and, if needed, has a chance to weigh in.

If you follow the steps outlined so far, then you will avoid one of the most common pitfalls a product manager can fall into. Surprising stakeholders and key players across the company with information about the product’s development that they had no idea was taking place.

In an environment where the PMs do not communicate regularly with their teams, or share all strategic updates, large ceremonial update meetings can be risky. Some participants can feel blindsided because they are hearing items under discussion for the first time.

But when you’re treating product planning as a part of the process, and informing your team along the way of all updates and changes, you can introduce product planning ceremonies — meetings, perhaps quarterly, where you can discuss the product you have made and any big-picture strategic updates to your plan.

These product planning ceremonies can also be a great time for you and your team to discuss any open-loop strategic questions — such as priorities or plans that might need to be changed but which haven’t yet come up for discussion.

The point here is that, because you’ve shifted your company’s way of thinking, discussing a possible tweak to your product plan in a quarterly meeting like this won’t feel like a bombshell that goes against whatever your team decided several months back. It will be treated instead the way it should be — as an item that, based on new information, evidence or insights, might deserve another look because doing so might lead to a better product.

How do you view product planning? Is it a one-time activity or an ongoing process? And how does that affect how you drive your product development?