What would you say is the hardest thing about being a product manager?

It’s communication.

Think about it.

You sit in the middle of infinite competing needs and finite resources.

The sales team needs this feature. The marketing team wants that one. The ops team just wants to know what’s coming out next, by when, and why. The CEO is griping about when they can see the new prototype. The engineering team missed their last sprint goals and wants more resources.

Your job is all about synthesizing and communicating what actually is happening versus what should be happening. You must then try to close any gap by aligning with key stakeholders and communicating those changes.

If the definition of stress is being accountable for something that you have no direct control over, well, then your role as product manager can be very stressful indeed.

So here’s the next question…

If communication is one of the most demanding jobs of a product manager, then what’s the secret to effective communication?

It’s context.

Think about it. If a team has first built shared consciousness together about why, when, and how product decisions are being made, effective communication becomes possible. Without shared context, each individual usually sees things only from their vantage point, leading to noise, ambiguity, and dissatisfaction with the product, the roadmap, and the overall business direction.

And the next question…

If a product manager’s success depends on effective communication, and context is the key to effective communication, then how can you build shared context across your team as quickly as possible?

Use a picture.

You already know the adage about pictures and a thousand words. It’s true!

In this article, I’m going to propose that you add your products, or groups of products, to the Organizational Physics Strategy Map below to show your team where each product or product category sits now in its lifecycle stage:

By doing so, you’ll create the necessary context across the team to explain why you’re treating different products or product categories differently and what the next set of product roadmap decisions should be for each. You’ll also assist in aligning the surrounding business to support the given product or product category.

Products or Business Units?

The Organizational Physics Strategy Map is usually used to put a business or business unit on the map, identify strategic execution risks, and develop the next-stage strategy of the company. Instead of a business or business unit, I am placing your company’s products, or product categories, on the same map. The assets may be different, but the principle is the same: the current position on the map dictates the next steps.

How to Place Your Products onto the Product Strategy Map

To illustrate how to place your company’s products onto this map, let’s use an example of ACME Company, which has three products. Its legacy product is in the Milk It stage; its core product is in the Scale It stage, and it has several prototypes A, B, C in the Pilot It stage. Its Product Strategy Map looks like this:

What does this placement tell the product leaders at ACME?

  • Legacy Product (Milk It Stage): Decisions should be short-range and tactical, focused on reducing operating costs, increasing short-range sales, or directly impacting the bottom line.
  • Core Product (Scale It Stage): Needs the bulk of engineering resources for growth, innovation, new features, and improvements to capture market share. The goal is to stay in the Scale It stage by adding new features and line extensions as long as market demand holds.
  • Prototypes A, B, C (Pilot It Stage): Must be sandboxed and tested through the stage gate process to find the best candidate to drive into the Nail It stage. Decisions here must allow the prototype team(s) autonomy to test, iterate, and innovate without interference from the core or legacy teams.

Conduct the Same Exercise for Your Own Products

Use this checklist below to identify the current product lifecycle stage for your company’s products and then place them on the map:

Pre or Early Pilot It

  • We have the concept of a potential product/solution but it is still only slideware.
  • We have a compelling vision and a very early prototype, mostly still for internal use only.

Mid Pilot It

  • We have an Alpha stage prototype built and we are receiving feedback from early users.
  • We are learning a lot as the product vision meets market realities.

Late Pilot It/Early Nail It

  • We have a Beta version of a live, working prototype deployed with early customers and we are actively getting feedback from them.
  • We are quickly translating early product feedback from a handful of early-stage customers into tangible product features and improvements.

Mid Nail It

  • We have critical usage metrics from paying customers using the complete, or nearly complete full product.
  • We have enough real-world data from actual customers to tell us that we’ve nailed it, or that we need to make a pivot.

Late Nail It/Early Scale It

  • We have unarguable evidence that we indeed have product/market fit because customers are buying/using once and then coming back to buy/use more.
  • We are being pulled forward by market demand. It may also be hard for us to easily add new features or line extensions because we have outgrown our existing product/solution architecture.

Mid Scale It

  • We are continuously adding new features/line extensions to the core product/solution. We can do so relatively easily because our product/solution architecture can handle the growth and the addition of new features/line extensions simultaneously.
  • We are growing and innovating rapidly and it feels like we have the wind at our back.

Late Scale It/Top of Curve

  • Our core product/solution leads its industry in features, functions, and capabilities and the business has a defensible moat.
  • We won this round. We are the de facto choice with dominant market position and pricing power. We are no longer a noun but a verb. “Google it.”

Milk It

  • We are the cash cow that funds the rest of the business.
  • Our product decisions have gotten more reactive to respond to competitor moves rather than proactive to set the industry pace.

Late Milk It

  • We are maintaining a legacy product/solution that is no longer on the cutting edge.
  • This product/solution does not seem to have much life left in it. The industry has shifted.

How to Determine Product-Market-Execution Alignment

What makes the Organizational Physics Strategy Map unique and powerful is that it also reveals if you have alignment between the lifecycle stage of your products, markets, and execution capabilities. Here’s the map again for your reference:

The first step, already completed, is to place your products or product categories onto the map in their current lifecycle stage. Then use the other dimensions of the map, which are the market development stages located at the bottom of the map: Innovators, Early Adopters, Early Majority, and Late Majority/Laggards as well as the execution capabilities located along the strategic execution line, which is the parabola with the four-letter code: psIu, PSiu, PSIu, PSiU, -S–, and —-.

Basically, place your products where they are now – Pilot It, Nail It, Scale It, Milk It, or Kill It (sell it off) – and then use the other indicators to tell if you have alignment between your products, market needs, and execution capabilities.

This is a bigger topic but it should be intuitive why finding and maintaining alignment between products, markets, and execution capabilities is so critical. Everything develops in stages and if you are out of sequence, then you’re going to fail!

If you’d like to learn more about how to create and measure lifecycle stage alignment between products, markets, and execution capabilities, as well as understanding and identifying strategic execution risks to your business, you have several options to explore:

But What’s the Point?

If you’re still unclear about why placing your products onto the product lifecycle map can help you create more context, alignment, and velocity for your product roadmap, let me break it down for you.

What I’m proposing is that you begin your product roadmap meetings by showing where your company’s existing products or product categories are located on the product lifecycle. Then use that picture to create context and educate your stakeholders on three important concepts:

  1. We don’t treat all of our products the same way. We manage each product, or similar-stage products, to what’s necessary and appropriate to that stage. Show them where your current products are in their lifecycle stage.
  2. We make product roadmap decisions based on our overall business strategy and the lifecycle stage of each product. That’s why some products are getting more resources than others. Show them the current strategic imperatives for the company.
  3. We strive to go as quickly as possible through each stage, but we can’t skip a stage. Teach them lifecycle theory using the resources above.

Only after you’ve established overall context with the team using this shared picture should you go through your review of your traditional product roadmap. But notice something important. Now your regular product roadmap review, which shows upcoming product features, release dates, resource allocations, and issues, is much more useful and results in better awareness and decisions. Why? You know why! The team has first built shared context about where each product or group of products currently sits in their lifecycle stage and they have a shared understanding of the needs and implications of each stage.

The best part is that once you personally understand product-lifecycle-execution strategy, and once you’ve placed your products into their correct location on the map, then you don’t have to do a lot of extra work. You would only need to revisit product locations once or twice per year because lifecycle stages don’t usually change faster than that.


As someone who has coached hundreds of product and leadership teams, I can tell you that if you can align the team first on a shared picture of reality and only then engage in decision-making, not only will the team make better and more informed decisions, but they will also tend to better comprehend and support the decisions that have been made.

By establishing context first, you reduce barriers to effective communication, which is the most challenging aspect of being a product manager. Not establishing a shared picture of reality before making product decisions usually leads to entropy, infighting, and misunderstanding. It also makes your job a lot harder. If, on the other hand, you use the product lifecycle curve and the Organizational Physics Strategy Map to create context for product decisions, you will be more effective and your job will be a whole lot easier!