top of page

Cliff Notes (with best-of diagrams)

Jan 31, 2024

7 min read

5

272


This e-book provides a framework for cohesively integrating product strategy with product development in complex product development environments.


The framework is organized around three stages of integration: ACTIVATE, OPERATIONALIZE, and OPTIMIZE.


While the practices and concepts contained in this e-book are directed towards product managers, they motivated by the ideals of product development team cohesion and empowerment, and the efficacy of distributed decision-making in solving complex problems.


The ultimate goal of this e-book is to maximize the success potential of product development teams by deeply integrating product strategy throughout all roles and processes.


"All minds have to see the whole task to contribute efficiently" - (Oppenheimer movie, 2023)


 

The introduction offers a primer on the essential elements of a robust product strategy. It continues with a discussion on product strategy integration, why it's important, and why it's so difficult.


Product strategy is the collection of product developments AND supporting activities required to reach a desired end state which yields the most positive outcomes against 1) your market’s needs and 2) your own business goals.

Product strategy integration is the process of coordinating strategy across decisions, actions, and time.

The process of strategy integration seeks to accomplish three objectives:




In the ACTIVATE stage, product narratives and storytelling techniques are combined with outcome-oriented roadmapping to empower product development teams to interpret and apply product strategy in their respective disciplines throughout their day-to-day decision-making.


In the OPERATIONALIZE stage, principles and practices for continuous discovery are coupled with decision-making frameworks to enable the iterative and adaptive application of strategy at all levels of product development.


In the OPTIMIZE stage, a six-part framework of tactics is introduced to harness emergent "Product Truth" and harvest strategic insights (building on Agile "inspect and adapt" and Lean Startup's "validated learning").



Part 1: ACTIVATE


Part 1 discusses how to most effectively activate product strategy by articulating through a [narrative + system of stories] model.


A product narrative is an open-ended container for the system of interrelated and synergistic stories that make up your product strategy. It captures several higher-order concepts and unifying themes which provide essential context for strategy storytelling.


A strategic story captures an intended outcome against the needs/problems/desires your target market personas have. The system of synergistic, outcome-oriented stories together make up your product strategy.


The following diagram depicts the “Product Narrative Canvas”. It is inspired by the popular business model and product positioning canvases. It brings together elements of vision, mission, and product positioning to create a narrative container that provides essential context for strategic storytelling.


A product narrative should establish credibility while appealing to emotion and logic:



Part 1 continues with discussion on how to build out the “system of interrelated and synergistic stories” that make up your product strategy. The synergy between strategic stories is the golden thread that ties them together.



Customer outcomes drive product outcomes based on the value proposition of the product. Positive product outcomes are transformed into business outcomes through the business model of the product.






Empowered product development teams own product outcomes and build towards customer outcomes.


Customer and product outcomes can be organized on a roadmap by three universal business objectives: sustainable value, growth, and/or profit. Well established outcome-oriented and objective-organized roadmapping practices are discussed in detail.



Part 1 closes with comments on the overlap with outcome-oriented roadmaps and OKRs as well as thoughts on portraying timing on roadmaps (e.g. relative now>next>future timing). Many more diagrams, examples, anecdotes, and best practices are provided.



Part 2: OPERATIONALIZE


Part 2 discusses how to effectively operationalize product strategy by commencing continuous discovery activities and employing decision-making and prioritization frameworks.


These practices enable the iterative and adaptive application of product strategy through time and across all levels of work and architecture.


My Operating Mantra:

Learn fast
Validate often
Build right

Expanding on the customer > product > business outcome chain introduced in part 1, we can lean on concepts like Minimum Valuable Experience and Minimum Viable Product to inform the ongoing development of product:




Converting product strategy into product development action begins with discovery. Discovery seeks opportunities to address market-level problems, unmet needs, or unfulfilled desires with [valuable + viable + usable + feasible] solutions.


In Continuous Discovery Habits, Teresa Torres provides a working definition of continuous discovery:


At minimum, weekly touchpoints with customers
Performed by the team building the product
Where they conduct small research activities
In pursuit of a desired outcome

Guiding principles for discovery:


  1. Discovery is continuous

  2. Discovery is a cross-functional science

  3. Discovery requires first-hand inputs

  4. Discovery is guided by outcomes, not outputs

  5. Discovery seeks and prioritizes opportunities, not solutions

  6. Discovery tests assumptions, not ideas

  7. Discover with empathy and customer-centricity

  8. Discovery and delivery are not separate responsibilities

  9. "Respectfully, your customers and stakeholders aren’t able to tell you what to build" - Marty Cagan


Opportunity Solution Trees (OSTs), pioneered by Teresa Torres, are the modern standard for continuous discovery frameworks. OSTs are comprised of a product outcome, an opportunity map, collaboratively ideated solutions, and assumption tests. Continuous discovery is supported by exercises like customer interviews, experience mapping, rapid prototyping, and experimentation, all while managing biases and examining assumptions.




Part 2 continues with concepts and practices to support prioritization and decision-making.


Decision-making is empowered by context. Problem statement-based thinking is a powerful tool for establishing the context a product development team needs to shape solutions to deliver desired outcomes. Problems/needs/desires are the plots of your strategic “stories”; they are your market opportunities.


A primer on problem statements:


A good problem statement should articulate:


  1. Your impressions of what’s wrong/needed/desired

  2. Who this problem/need/desire affects

  3. Why addressing this problem/need/desire matters

  4. How much better things could be if you can somehow find a way to solve for the need


…and there are two aspects of how you frame problem statements that are critical to delivering the right outcomes:


  1. The Goldilocks Problem: is the need you are tackling the right size?

  2. The Insight Problem: are you framing the need in a way which is meaningful and potent?


Problem-statement based thinking can be employed in many different product management contexts including discovery, roadmapping, backlog refinement sessions, user stories, feature requests, etc.  Examples and anecdotes are provided.


Popular prioritization frameworks like the RICE framework, the Kano model, and the MoSCoW method have valuable applications in the product management discipline such as ordering a backlog. However, being relatively simplistic and/or quantified models, they also have limitations.


For initiative or product outcome-level decisions, the North Star Metric framework is highly effective as decision-making framework:



The North Star Metric framework contextualizes product initiatives with your business model and product-market fit.


Part 2 closes with comments on the importance of building cross-functional trust and partnership.


Together, the concepts and practices in part 2 empower product development teams to apply product strategy in an iterative and adaptive manner through time, across levels of work, and throughout evolving architecture and market conditions.



Part 3: OPTIMIZE


In the optimize stage, a product manager's objective is to implement continuous learning practices. Continuous learning seeks to answer the question "Pivot or Persevere?" by harnessing emergent "Product Truth" and harvesting strategic insights.


Part 3 opens with a conceptual discussion on the differences between complexity and complication and how an understanding of this distinction (and the reality of pervasive complexity) should shape product strategy for a given product development endeavor.


Complex things are defined by their “unknowables”: unbounded and infinite inputs/outputs and ever-evolving possible states. The natural world is complex. The human brain is complex. Evolving system architecture, customer preferences, market needs, and behavioral dynamics are all common sources of product development complexity. Complexity cannot be simplified upfront; it must be realized over time and through action.
Assembling Ikea furniture, on the other hand, is complicated. Mechanical watches are complicated. There may be lots of parts and steps, but these things are ultimately perfectly knowable. Complication may be simplified upfront or along the way through tactics like research, documentation, and project management.

When organizations fail to grasp the reality of pervasive complexity in their product development environment, they tend to also under-appreciate the importance of continuous discovery.


What then follows is a focus shift away from continuous discoveries of right problem > right solution > done right (product-market fit) to a project execution, feature development, or delivery focus. This, in turn, results in disempowerment of the product development team and the product management role (Marty Cagan's book "Empowered" discusses this phenomenon). Common symptoms of this problem include: feature factory teams, delivery timing obsession, outputs over outcomes, poor quality, unmitigated risk, crippling debt, and missed product-market fit.


Methodologies which are based on Agile principles emphasize responsiveness, which is the optimal mode of operation in complex product environments. 


In part 3 the phrase “Product Truth” is introduced to emphasize the critical distinction between real-world evidence and that of hypothesis, opinions, or general confidence about a product. While inspired by the Agile mantra "inspect and adapt" and Lean Startup's "validated learning", I find this framing to be more effective at driving the critical distinction product development leaders must internalize.


Part 3 continues with a detailed review of six constructs around which product managers can work with their product development teams to harness emergent "Product Truth" and harvest strategic insights:



"No facts exist inside the building, only opinions"  - (Steve Blank, the Godfather of Silicon Valley)


As you continue to develop a product over time, you will (knowingly or not) be faced with many "Pivot or Persevere?" questions.


Emergent Product Truths will inform your answers to those iterative "Pivot or Persevere? questions.


Fine-grain truths such as some small piece of user feedback or a specific measurement will inform fine-grain strategies on features and prioritization. Occasionally, fine-grain truths will create larger "a ha!" moments.


Similarly, external context (e.g. user preferences, competitive threat, new business interests, etc.) will inform both large and fine-grain product strategies.


Closing notes


Notable tie-backs to parts 1 and 2 include:

  1. Dimensions of product growth (breadth/depth/frequency/efficiency) are also dimensions of product measurement

  2. Dimensions of continuous discovery (value/usability/feasibility/viability) are also dimensions of risk and product debt

  3. Top-level product strategy should include affording product development teams the authority to define the "how" of delivering any outcome as well as the autonomy to self-optimize based on signals from emergent Product Truth









Jan 31, 2024

7 min read

5

272

Related Posts

  • LinkedIn
bottom of page