You might have read my lengthy articles on the Product Operating Model. Here is a consolidated recap as an interactive guide.
For your convenience, here are some examples of my earlier articles on POM:
The 3 Dimensions of the Product Operating Model
The product operating model represents a fundamental shift from a reactive, project-based mindset to a proactive, value-driven approach. It is about organizing to consistently innovate and deliver high-tech products (software, hardware, or multidisciplinary) at pace.
Essentially, the product operating model is about consistently creating technology-powered solutions that your customers love, yet work for your business.
The Evolution Challenge
Take the example of Integrated Energy (IE), a high-tech organization transitioning from a B2C startup to a global B2B enterprise. The core challenge during growth is maintaining the startup mentality: deep customer focus, high-paced innovation, and high quality, without drowning in bureaucracy and process prescriptions.
The Three Dimensions
At the center of this model are three tightly intertwined dimensions:
- The right problems to solve (Product Strategy & Vision)
- The right solutions to the problems (Product Discovery)
- Solutions delivered the right way (Product Delivery)
Core Principles vs. Antipatterns
Understanding the model is easiest by contrasting its principles with the traditional IT or project-led antipatterns it aims to replace.
Our product continues to focus on solution discovery and delivery, guided by our product vision and strategy.
Our "product" is a reactive patchwork of projects pushed from sales.
We empower product teams to discover valuable, usable, feasible, and viable solutions to problems and measure success on outcomes.
We ask teams to implement specific, predefined solutions and measure success on output.
We ensure that product teams have regular and unrestricted access to both our customers and the business.
Having layers of customer-proxy roles and processes between the teams and the customers.
We provide product teams with the strategic context necessary to discover solutions.
Teams are given detailed instructions on what to build.
Product innovation through disciplined experimentation is an integral part of the daily work in product teams.
Innovation happens in separate "innovation labs" or within a dedicated time slot.
We keep process prescriptions and frameworks at a minimum viable level, perceiving our employees as intelligent, motivated, and responsible.
Process prescriptions and frameworks are substitutes for thinking, perceiving our employees as mercenaries and cogs.
We scale problems to fit product teams and have strong management to support team coordination.
Scaling agile processes and frameworks.
We're placing many small bets when funding the product teams (an internal VC-funding model).
Big bets with big up-front business cases.
Dimension 1: Deciding What Problems to Solve
Project vs. Product
Customer (or internal) solution project: Serves a specific customer asking for and sponsoring the project. 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.
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.
This encapsulates why you should not be "sales-led," reacting to the market and risking a Frankenstein patchwork of customer projects. Similarly, avoid being "engineering-led," which risks over-engineering.
Driven by the Chief Product Officer (CPO), the vision acts as a North Star. It provides meaning and keeps us focused on the customer.
- Provides the overarching, common goal across the organization.
- Helps teams understand how their work contributes to the larger whole.
- Provides clarity to guide architecture (creating a Minimum Viable Architecture).
- Has a 3–10 year scope and leverages industry and technology trends.
What it explicitly is NOT: a roadmap of features and projects.
Strategy guides which problems should be solved. It requires making tough choices on focus (as Christina Wodtke notes: "focus is the difference between excelling and flailing about in mediocrity").
- Quantitative insights: Product data analysis, hypothesis tests on data.
- Qualitative insight: Deep user research.
- Generative insight: Uncovering new opportunities.
- Technology & Industry insights: Spotting new enablers (led by engineers).
Objectives and Key Results (OKRs) are an effective framework for framing problems for empowered teams. "Successful outcomes over efficient delivery" - Jeff Patton.
Objective (The Problem)
- Qualitative and easy to understand.
- Describes what needs to be achieved and why.
- Inspiring, motivating, and aspirational.
Key Results (The Measurement)
- Quantitative (preferably "from-to").
- Specific, time-bound, measurable, and verifiable.
- Aggressive yet realistic outcome metrics.
Pitfalls to Avoid: Cascading OKRs strictly top-down (it should be a negotiation), ignoring "business as usual" work, using OKRs for performance evaluation, or treating them as a to-do list.
Dimension 2: Discovering the Right Solutions
Once the problem is identified (e.g., via an OKR), the empowered product team must discover a solution. One hallmark of the product operating model is that product teams interact frequently and directly with customers, bypassing layers of customer proxies.
Innovation is only expensive if you use traditional business planning to make investment decisions. Innovation, when done right, is about making small bets, testing ideas cheaply and quickly...
The Anatomy of a Discovered Solution
A true solution must satisfy four distinct constraints. The core product team is specifically structured to address these:
Valuable & Viable
Driven by: Product Manager
Is it perceived as valuable to the customer? Will they choose to buy or use it? Is it viable for our business (fits constraints)?
Usable
Driven by: Product Designer
Can the customer easily figure out how to use it? Focuses on holistic user experience, prototyping, and continuous user testing.
Feasible
Driven by: Engineers (Tech Lead)
Can we actually build this with the time, skills, and technology we have? Engineers must be involved in discovery.
We systematically map our assumptions about the customer and our proposed solution:
- Customer Profile: Are we addressing jobs/needs that matter? Are we focused on their top pains and desires?
- Value Map: Do our products actually solve those high-value jobs? Do they relieve those top pains and create important gains?
We cannot test all assumptions. We prioritize structured assumption tests on the most important assumptions where evidence is lacking. To interact with customers, we build prototypes (visual, clickable, "smoke & mirrors").
Prioritizing Assumptions
Prototyping
To ensure discipline and avoid bias during customer interactions, we use:
- Test Cards: Defining the hypothesis, the specific test to run, the metric to track, and the strict criteria for success.
- Learning Cards: Forcing the team to capture and reflect upon the insights gained in a structured way.
This direct, disciplined communication with short feedback loops expedites the process of validating solutions before requesting funding to build them.
Dimension 3: Solutions Delivered the Right Way
Product delivery is not a waterfall phase following discovery; they overlap and interweave. However, the work required is fundamentally different. While discovery answers "did we build the right stuff?", delivery ensures we build it right. We do not deliver half-baked MVPs to customers; we deliver production-grade solutions.
You can't inspect quality into a product; it must be built into it.
The Duality of Speed and Quality
It is a common misconception that quality requires a long time. Based on DORA metrics (from the book Accelerate) and Dave Farley's principles, we know that quality needs speed (small steps with short feedback loops), and speed needs quality.
Scenario 1: Long Feedback Loops (Water-scrum-fall)
Feature development is separated from system integration and testing. Teams implement solutions, not solve problems. A developer committing code waits 180+ days for system-level feedback.
Result: A frantic rush to release, poor software quality, slow delivery, and unhappy customers.
Scenario 2: Short Feedback Loops (Continuous Delivery)
Running the product operating model, this organization uses a Deployment Pipeline that quickly answers: Is my code technically correct? and Is the system releasable?
Result: Potentially deployable release candidates daily. Great software, fast, happy customers.
Building in Quality: Key Drivers
Continuous Delivery (CD) is the foundation of modern product delivery, enabling organizations to safely and quickly get changes into the hands of users. According to Dave Farley, Continuous Delivery stands firmly on three core legs:
The Deployment Pipeline is the automated manifestation of getting software from version control to users. Key practices include:
- Version Control: For all production artifacts (code, configuration, infrastructure).
- Continuous Integration (CI): The foundation. Developers merge to the trunk at least daily. (No real CI = No CD).
- Trunk-Based Development: Avoiding long-lived feature branches, requiring a strong culture of collaboration.
- Test Automation & Data Management: Massive batteries of automated acceptance and regression tests.
- Shift Left on Security: Designed and built-in from the start.
- Small Batches: Shortening the feedback loop dramatically.
- Loosely Coupled Architecture: Helps teams work and deploy independently.
DevOps is a generative culture where people from various disciplines design, develop, deploy, and operate a system together. The core principle is end-to-end ownership.
The stream-aligned product team that builds software remains responsible for its maintenance throughout its lifecycle. There is no throwing code "over the fence" to operations.
As organizations grow, tools and the "you build it, you run it" mandate can create overwhelming cognitive load on stream-aligned product teams, impeding their focus on the customer.
Following Team Topologies, we mitigate this by introducing Platform Teams. They provide "X-as-a-Service" (like Deployment Pipeline infrastructure) to internal customers.
Optimizing for Developer Experience (DevEx)
DevEx applies to all teams (stream-aligned and platform). Platform teams treat internal tooling as a product to ensure stellar DevEx across three dimensions for everyone:
- Feedback Loops: Reducing delays in software delivery for faster learning and course correction.
- Cognitive Load: Providing abstractions and self-service tools so developers don't have to understand every underlying complexity.
- Flow State: Enabling developers to work fully immersed, without interruptions, leading to higher productivity and innovation.