The product operating model: What problems to solve

This is the fourth in the series of articles on the product operating model. To recap, it has three dimensions.

- The right problems to solve
- The right solutions to the problems
- Solutions delivered the right way

This article will examine how to decide on the right problems to solve. Before moving on, let’s ensure we’re on the same page.

Product vs solution project

There is a reason it’s called a product operating model: The scope is products, in sharp contrast to one-off (B2B) customer solution projects.

Customer (or internal) solution project

- Serves a specific customer (externally or internally), asking for and sponsoring the project.
- Typically confined within the classic project triangle.

Product

- Serves a multitude of customers and users.
- Follows a product lifecycle from cradle to grave with continuous discovery and delivery.

In all fairness, if you’re a start-up seeking the initial product-market fit, your coming product typically starts with a project.

Not just purely digital products

Also, the product operating model is not restricted to purely digital products. Multidisciplinary products with advanced (physical) production are included. High-quality (physical) production is a big deal!

Think Tesla

The factory is the product

Elon Musk on X, Jan 11, 2021

Think Apple

Be a yardstick of quality. Some people are not used to an environment where excellence is expected.

Steve Jobs

Assumptions

I’ll assume that the business mission and strategic business objectives are known.

I’ll also assume a proper leadership structure is in place with, e.g.,

- A Chief Product Officer (CPO)
- A Chief Technology Officer (CTO)

And I’ll assume a team topology optimized for problems to be solved.

What I'll cover in this article

This article will focus on the product vision and strategy. Combined, they’ll guide us on what problems to solve and, equally important, what problems not to solve.

You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new.

Steve Jobs

This quote from Steve Jobs encapsulates why you should not have product management integrated with sales, aka being “sales-led.” Not “only” will you be reacting to the market and thus constantly being in a catch-up game, but you risk degenerating your “product” into a Frankenstein patchwork of customer projects (in a B2B setting).

Also, you should not integrate product management with “engineering,” aka being “engineering-led,” with the high risk of over-engineering and having your product driven by what is technologically interesting.

Product vision and strategy

The CPO’s primary responsibility is to drive the product vision and strategy.

Product vision

Its purpose:

- - provides meaning
  - keeps us focused on the customer
  - acts as a North Star, providing the overarching, common goal / larger purpose across the organization
  - helps teams understand how their work contribute to the large whole
  - provides enough clarity enabling the product organization to have an architecture in place—but do not build a full architecture in one massive effort (start with a Minimum Viable Architecture)
  - acts as a primary driver for deciding the team topology; especially the platform teams are heavily impacted by the vision & architecture
  - acts as an evangelism tool

If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.

Antoine de Saint-Exupéry

Elements:
- - leverages industry & technology trends
  - if done well, it’ll be compelling, inspiring and empowering
  - needs not to be too detailed / prescriptive, which can be a challenging balance
  - has a 3–10 years scope
  - is owned by the [CPO]
  - includes a description of the future situation, sometimes including conceptual high-fidelity prototypes (realistically looking but only smoke & mirrors), video, storyboarding, prototypes used in product discovery, etc.

What it explicitly is not:

- - a roadmap of features & projects

Product strategy

It’s purpose:

- - guiding which problems should be solved, ensuring the right focus

I believe the one thing that makes the difference between excelling and flailing about in mediocrity is focus.

Christina Wodtke, RADICAL FOCUS second edition p. 134

Elements:
- - tough choices on what is really important (ref. the quote from Christina Wodtke)
  - generation of insights
    - quantitative insights: Product data, hypothesis test on data
    - qualitative insight: User research
    - evaluative insight: Result from tests
    - generative insight: Did we uncover new opportunities?
    - technology insights: The empowered engineers are often the best to spot new enabling technologies
    - industry insights: E.g., follow the best industry analysts
  - active management (not to be confused with micromanagement): The product leaders must connect the dots/insights in various ways resulting in action; that is, which team should solve which problem, impediment removal, coaching, and follow-up on progress towards targeted outcome

Problems to solve

Objectives and Key Results [OKR] has (among other frameworks) become a widespread and popular heartbeat-driven agile goal-setting and management framework, creating alignment in organizations, vertically and horizontally.

The Objective, where we want to go, equals the problem to be solved by a cross-functional product team empowered to discover a solution to the problem.

The Key Results, are how we measure the outcome progress toward the Objective.

The biggest missing value statement in the Agile Manifesto is:

Successful outcomes over efficient deliveryJeff Patton

Output is important to deliver the outcome, but we do not measure output.

There are no one-size-fits-all rules, but these guidelines should paint the picture:

Objective

- Is qualitative
- Must be easy to understand
- Short and to the point
- Describe what needs to be achieved and, importantly, why, the rationale
- Be inspiring and motivating
- Aspirational & challenging
- 1-4 objectives per team

Key Results

- Is an outcome
- Specific and time-bound
- Measurable and verifiable
- Aggressive yet realistic
- Is quantitative, preferable as “from-to”
- 1-5 KR per Objective

Watch out for the OKR pitfalls

Reading the graphics under assumptions can indicate a “waterfall,” a cascade of problems to be solved from the top to the product teams. That is not the case. This and other potential pitfalls are the topic here.

Pitfall #1, OKRs only cascaded from top to bottom: No, it is a negotiation. The product team must own the OKR and thus be able to challenge it first. Also, the product teams can and will suggest OKRs, knowing the strategic context.

Pitfall #2, teams are only expected to work on OKRs: No, most teams will also have to do some “keeping-the-lights-on” activity, including handling technical debt.

Pitfall #3, OKRs used for performance evaluation: This will quickly lead to teams under-promising, thus rendering the notion of aggressive yet realistic OKRs void

Pitfall #4, OKRs used for “business-as-usual” goals: This would undermine the point of OKRs having a growth-oriented purpose

Pitfall #5, OKRs used as a to-do list: Remember that OKRs are about providing outcomes and not output, as would be the result of to-do lists

Pitfall #6, OKRs at the level of individuals when the primary modus operandi is for people working in teams: Use team OKRs and only

Wrap-up

The first prerequisite for success is to decide what problems you ask your product teams to discover solutions to. For that to happen, you’ll need a strong product vision and insights-driven product strategy.

More Inspiration - moving to the product operating model

Marty Cagan provides a general overview and addresses common transformation pitfalls moving the product operating model.

What transformation (ed.: to the product operating model) really means in practice for most companies is moving from feature teams to empowered product teams Marty Cagan