What Product Strategy and Inner Peace have in common — and demystifying (at least) one of them

Product Strategy is like inner peace; it’s universally known that you need it, and yet you’re not quite sure how you’re going to find it. Equally fuzzy is how product strategy should drive your roadmap. Most roadmaps are riddled with an overwhelming number of features, and it’s left as an exercise to the reader to figure out how each is relevant to the company’s vision. High-level “thematic” roadmaps fare better in this regard, but even then, how do those themes tie to the vision? Are those themes your product strategy? What is your product strategy, and how do you describe it?

On that philosophical note, in this post we provide a framework to demystify Product Strategy.

You have already created a North Star to guide you and your team.Now, you’re ready to develop your Product Strategy and create a roadmap that ties execution to your North Star. With this tool, you’ll be able to communicate not just the features in your roadmap, but also a more holistic picture of how (and why) they fit in with your end goal.

The rows of this framework break out Product Strategy into four core elements: Real Pain Points, Design, Capabilities and Logistics — RDCL (pronounced simply as as Radical 😀 ). From left to right, you can outline the evolution of each of these components over time — we recommend simply “Now”, “Next”, and “Later” — to help you outline the interim steps to your end goal.

The elements of product strategy

Let’s start with the four core elements: RDCL.

  1. Real Pain Points — Pain Points, Jobs to be done: Describe in as much detail as possible the pain points of your target customer persona(s) for your solution. The customer persona isn’t always the person writing the check but the person whose pain point is being solved or who will benefit from the job being done better because of your solution. For each persona, what is their job/ task and what are they trying to achieve? What’s their real pain point? What will make them successful? Beware of creating generic pain points and personas — when you don’t create a product for a specific and real pain point you risk creating something that works for no one!
  2. Design — Features, appearances, voice/tone, brand/messaging: List the specific features of your product that enable the Customer pain points to be solved. An important but often overlooked aspect of design is the voice/tone and brand/messaging of your product. This is where the PM needs to be in sync with the marketing plan for the product. Together you would answer questions like: Who makes the purchasing decision? How is the decision made? What makes the buyer successful? What will drive adoption? If the decision-maker for purchasing the product is different from the end user of the product, how does the product appeal to the decision-maker?
  3. Capabilities — Data, patents, trade secrets, hard to build competencies: Capture the specific capability in your product that differentiates you from status quo and creates a barrier to entry for competition. Often, this will be the innovation in your solution. Having clarity on what specific capabilities are hard to replicate in your solution will also help identify differentiation from competition and sustaining that differentiation.
  4. Logistics— Medium, pricing/subscription, distribution, delivery: Customer experience starts with logistics and not when the customer starts using the product. This is often overlooked in “enterprise” products which are clunky to install and pricing is overly complex. As you research your customer persona(s) and pain points, identify the specific medium, pricing and distribution of your product that will eliminate their pain points. This is where the PM needs to be in sync with the sales strategy for the product.

Road mapping product strategy

Each of these four RDCL components above will evolve over time as you hit milestones and deliver on customer pain points. Unless you plan on achieving your vision on your first release (in which case, maybe aim higher!), your Product Strategy needs to be executed over time. Use the Now, Next, and Later columns to describe how you plan for each element of your product strategy to change over time until your vision is achieved.

For example, in the “Now” space in the Pain Point row, you may decide to address only one pain point for your initial release Under Next, you might plan on expanding your solution to other pain points. The last column, Later, should represent the end state you describe in your North Star, and therefore capture all the pain points you expect to address in your end state.

Similarly, describe how your Design, Capabilities and Logistics evolve over time to bring you to the desired end state.

How to use this framework

1: Capture

Start with capturing all the different strategy ideas in the framework. These should be current or immediately-proposed strategy options. Then rank them from good vision fit to a poor vision fit. By decoupling RC and DL you can thoroughly explore your options, e.g. you could have the same product strategy that only differs in pricing and assess a subscription model versus a one time purchase in the delivery column. Be honest in identifying the vision fit, rather than force fitting vision based on “desired” business features. For example, while monthly usage-based pricing may be attractive, it may not be an appropriate model for you if there is no good way to measure usage. (The Oracle strategy of using a legal team to measure usage and defend pricing is not a great idea if you want to delight your customer 😀)

2: Evaluate

Once you have listed strategy options, start crossing off ideas that are either a poor fit with your North Star or do fit together with all the other RDCL elements — your strategy must be true to your vision, but also internally consistent. Trim down the strategy to the one you actually plan to pursue.

3: Iterate

If you realize that your vision isn’t supported by the components of the strategy you are already locked into, you might reconsider the framing of the North Star itself (although it should still be something that you truly believe in). The process of syncing the North Star and Product Strategy is typically iterative. This is to be expected, because you are not only creating the blueprint for your product vision and strategy, but also using these tools to create alignment within your team.

Communicating your vision

As you see from the components of the framework, Product Strategy is cross-functional. It requires alignment with the Engineering team on features and technical differentiators.It requires working with your marketing and sales teams to sync up design, branding, positioning, and even pricing. The organizational structure to enable this cross-functional execution is a topic worthy of another blog post.

There! Now with this framework filled out, you can communicate not just your vision, but a product strategy roadmap that your team can point to and use for their decision making. With product strategy demystified, you can save your philosophical explorations for your next mission: inner peace.

Share your experiences as you put together your Product Strategy Framework! We look forward to hearing your comments and questions. Keep an eye on this publication for our next piece, Scaling your vision: how to evolve your North Star over time