Category: POM

Posted on

The Product Operating Model – RECAP

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. Marty Cagan, TRANSFORMED

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:

  1. The right problems to solve (Product Strategy & Vision)
  2. The right solutions to the problems (Product Discovery)
  3. 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.

Principle

Our product continues to focus on solution discovery and delivery, guided by our product vision and strategy.

Antipattern

Our "product" is a reactive patchwork of projects pushed from sales.

Principle

We empower product teams to discover valuable, usable, feasible, and viable solutions to problems and measure success on outcomes.

Antipattern

We ask teams to implement specific, predefined solutions and measure success on output.

Principle

We ensure that product teams have regular and unrestricted access to both our customers and the business.

Antipattern

Having layers of customer-proxy roles and processes between the teams and the customers.

Principle

We provide product teams with the strategic context necessary to discover solutions.

Antipattern

Teams are given detailed instructions on what to build.

Principle

Product innovation through disciplined experimentation is an integral part of the daily work in product teams.

Antipattern

Innovation happens in separate "innovation labs" or within a dedicated time slot.

Principle

We keep process prescriptions and frameworks at a minimum viable level, perceiving our employees as intelligent, motivated, and responsible.

Antipattern

Process prescriptions and frameworks are substitutes for thinking, perceiving our employees as mercenaries and cogs.

Principle

We scale problems to fit product teams and have strong management to support team coordination.

Antipattern

Scaling agile processes and frameworks.

Principle

We're placing many small bets when funding the product teams (an internal VC-funding model).

Antipattern

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. Steve Jobs

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.

Product Vision (The North Star)

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.

Product Strategy (Tough Choices)

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).
Framing Problems as OKRs

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... Tendayi Viki

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.

1. Value Proposition Canvas

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?
Value mapCustomer ProfileProducts& ServicesGain CreatorsPain RelieversCustomerJob(s)GainsPainsProduct/Marketfit
2. Prioritizing & Prototyping

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
ImportantUnimportantNo EvidenceHave EvidenceThis is wherewe're primarilyfocusing ondesigning testsfor ourassumptions.
Prototyping
InteractivityFidelityHandsketchesStaticwireframesStaticmockupsClickablewireframesClickablemockupsInteractiveprototype
3. Structured Testing (Test & Learning Cards)

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.

Test CardStrategyzerTest NameDeadlineAssigned toDurationSTEP 1: HYPOTHESISWe believe thatCritical:STEP 2: TESTTo verify that, we willTest Cost:Data Reliability:STEP 3: METRICAnd measureTime Required:STEP 4: CRITERIAWe are right ifCopyright Strategyzer AGThe makers of Business Model Generation and Strategyzer
Learning CardStrategyzerInsight NameDate of LearningPerson ResponsibleSTEP 1: HYPOTHESISWe believed thatSTEP 2: OBSERVATIONWe observedData Reliability:STEP 3: LEARNINGS AND INSIGHTSFrom that we learned thatAction Required:STEP 4: DECISIONS AND ACTIONSTherefore, we willCopyright Strategyzer AGThe makers of Business Model Generation and Strategyzer

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. W. Edwards Deming

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:

Continuous DeliveryCultureDeployment PipelineSystem Architecture
Continuous Delivery & The Deployment Pipeline

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 Culture: "You build it, you run it"

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.

Scaling, Team Topologies, and DevEx

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.

Stream-aligned teamInternal services/productsPlatform team
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:

DevExFlow StateFeedbackLoopsCognitiveLoad
  • 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.

© 2026 ProjektDK. All rights reserved.

This interactive guide summarizes the comprehensive articles on the Product Operating Model available on the Projekt.dk Blog.

Let’s Turn Strategy Into Delivered Value

Whether you are navigating CRA and NIS2 conformity, transitioning toward an empowered Product Operating Model, or de-risking a mission-critical technology project, let’s explore how we can work together.

Send an Email Connect on LinkedIn
Posted on

A few core ingredients for a successful product organization

Product Organization ingredients 1200x745

Each of the core ingredients for a successful product organization is a deep rabbit hole in its own right. This article intentionally keeps it short and does not explore the rabbit holes in detail. 

For more ingredients, visit, e.g., my article series on The product operating model. 

Ingredient #1: Running a product organization, think product!

Some “product organizations” think and act in chains of discrete projects and not with a continuously evolving cradle-to-grave lifecycle mindset. It matters:

Project vs Product

When to release to market is a business decision. Multiple daily releases are, for some products, optimal for serving your customers. Other products are best released with a lower frequency, maybe following some chosen go-to-market rhythm.

BtB organizations must separate the evolving general product from customer-specific configurations (encapsulated in customer-specific projects). Do not mix the two. Maintain a strong separation of concerns:

The product organization interacts with selected customers during product discovery,  testing the solution hypotheses on the general product to be valuable and usable. This interaction is not about implementing specific customers’ needs in the general product!  

Recommendation: Evolve the product continuously, not in discrete projects, and release when it best serves the customers and the business.  

Ingredient #2: Drive your product by vision and strategy, not by sales!

Some organizations drive their products by what is being sold, aka “sales-led”. This is a reactive approach, letting your product strategy be driven by your customers.  

If I’d asked customers what they wanted, they would have asked for a faster horse, not a car.

Henry Ford

You must have, maintain, and communicate a strong product vision and strategy. If not, you’re betting on faster horses!

To avoid any misunderstandings, this does not imply not listening to your customers!  Your product teams are in direct and frequent dialogue with your customers and testing solution hypotheses.

We’re not asking the customers what to build. We’re validating solution hypotheses for problems concluded via our product strategy.

Driven by strategy

Recommendation: Organize around having your product driven by a product vision and strategy. Keep your product clean and free from customer-specific elements, but maintain close interaction with sales, providing valuable market insights.

Ingredient #3: Know the VPC!

From your position in the organization, always know the Value Proposition Canvas(es) you’re contributing to.

Value Proposition Canvas

You might belong to a team serving your organization’s external customers. Or you might belong to a platform team serving the teams, serving the external customers. It is the same. Know your customers, and know how to serve them.

Recommendation: Try the litmus test in your product organization. Can people describe the VPC from their perspective?  Are these perspectives making a consistent whole?

Test failed? You have a job to do, focusing your product organization on customers, products, and services. This focus is a prerequisite for working effectively and efficiently.

Test passed? Congratulations!

Ingredient #4: Aim for a nimble and lean way of working!

It seems to be a law of nature, at least in the northern parts of Europe, that the answer to growth and complexity is (more) process prescription with process offices, more complex organizational structures, lengthy decision processes with countless decision and coordination bodies (that often fail to make decisions or coordinate), and the elephant in the room: even more politics and internal fighting.

These organizations, especially when the above is seen in poor market performance, could decide to clean up the mess for better efficiency, less bureaucracy, and with right-sizing initiatives. That is good and needed, and will most likely have a positive short-term effect. But when returning to normal, the above “law of nature” kicks in. If you do not appreciate the root cause of your problems and only treat the symptoms, you’ll see the same problem sneak in again.

An organization like Amazon’s success cannot be disputed. Despite being a big organization, Amazon has managed to maintain and is determined to keep a start-up mindset. Amazon has coined this a “Day 1 mentality” in contrast to the “Day 2 mentality”.

Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations.

Jeff Bezos

Amazon Day 1

Image source: Daniel Slater Worldwide Lead, Culture of Innovation, AWS

With a few great exceptions, I find many of the “Day 2 mentality” characteristics in Danish product organizations.

Recommendation: Be tough, very tough, on your portfolio of prescriptive processes. And, when you’re at it, let most of your “process people” go. Only the processes that must be prescribed and followed to the letter are in the prescriptive process toolbox. Before throwing out the rest, consider whether some process fragments should be included in a pick & use toolbox.

As substitutes for excessive prescriptive processes, empower teams and have these supported by strong management. The more we free intelligent people from the prescriptive process rulebook, the more we free the innovation potential in the organization. And, guess what, the pace of innovation in your product organization is exactly what you should optimize for, and you’ll be rewarded in the market.

Wrap-up

I see a growing, but IMO too slow,  trend among Danish high-tech organizations towards adapting the principles from the Product Operating Model. Many organizations still place their bets on big process prescriptions. You might want to visit the article The European Process Disease.

Posted on

Solutions delivered the right way: Deployment Pipeline

My earlier article on product delivery recommended the core strategy of implementing Continuous Delivery as described by Dave Farley. To recap, Continuous Delivery rests on three legs, all equally important for success. This article will take a closer look at the Deployment Pipeline.

To illustrate the power of the Deployment Pipeline, we start "simple"

By “simple,” I here mean purely digital products (though these need to be executed in some physical environment). In a future article, I’ll add the physical (mechanics, electronics, procurement, production, etc.) dimension to the product equation. 

From my article on product delivery, the purpose of the Deployment Pipeline is as fast as possible, to provide answers to the questions

    1. Is my code technically correct?
    2. Is the system releasable?
Deployment Pipeline
This is for illustrational purposes, not a full pipeline design, inspired by Dave Farley's Continuous Delivery Pipelines.

See also Dave Farley’s book Continuous Delivery Pipelines, and his video below.

The keyword here is “fast”. We want feedback loops to be as short as possible and have a potentially deployable release candidate as frequently as possible because

quality needs speed, and speed needs quality.

When to release to customers is a business decision.

Some key Deployment Pipeline characteristics

Inspired by e.g., Continuous Delivery and Continuous Delivery Pipelines, here are some of the characteristics.

The Deployment Pipeline defines the releaseability, and is the only route to production. Normal feature releases, patch releases, Long Term Support releases. The only route, no exception!When the work of the Deployment Pipeline is complete, we will know that the software is sufficiently fast, scalable, secure, resilient and does what our customers want it to do.
The Deployment Pipeline is a falsification mechanism.It is not a tool to prove that our software is good. Rather, it is a mechanism based on the scientific principle of challenging our hypotheses. Even if just one test fails, we know our code is not good enough and is therefore not fit for production.
We include in the Deployment Pipeline all tests that are necessary to determine releaseability of our software. This includes


  • Fast, technical commit stage tests

  • Deployment tests

  • Integration tests

  • In-depth acceptance tests

  • Other tests: Performance, scalability, resilience, security, etc


When all automatic tests (plus potentially some manual explorative tests) are passed, we know that the release candidate is good, and safe to release to our customers.
We automate everything we can in the Deployment Pipeline so that development activities are repeatable, reliable and carried out efficiently, often in parallel, with consistent results.
Automation is not just for the code and the tests. Automation should extend to


  • The build, test and deployment infrastructure

  • Monitoring and measurement of the software and how it is developed

  • Data and data structures


We do not rely on people manually following a (maybe valid) recipe, configuring a piece of environment. It is error-prone and slow. We want to use, e.g., “golden images” and infrastructure as code. Only when presented with indisputable arguments will we accept manual intervention. Otherwise, no manual processes.
We take version control very seriously and apply it to everything: code, dependencies, test cases, test data, test results, configurations, infrastructure … everything.
Our aim is to ensure that every bit and byte that we deploy into production is the one that we intend.		For every release candidate, we know exactly what version of code, test cases, test data, configuration, infrastructure etc. constitute that consistent release candidate – exactly!

Version control and configuration management

Recap the points above on version control and configuration management: If you are not stringent about it, forget about harvesting the benefits from the Deployment Pipeline.

Thought experiment: We need to establish, exactly, the versions of code, 3. party libraries, configurations, build systems, test cases, test data, infrastructure, etc. used in the past to produce a specific release candidate. Can we do that, fast?

YES: Great, we’re doing configuration management as we should!

NO: Huston, we have a problem!

Test stategy

One of the characteristics above is the Deployment Pipeline, having automatic tests. Getting a test strategy right is a big topic. What is test-driven development? What is behavioral-driven development? How do you avoid flaky tests? How do you manage test data, etc.?

I could include it in a future article. This will be a quick overflight. The tradition is to use the test quadrant combined with the classic test pyramid.

Test quadrant
From continuousdelivery.com
Test pyramid
Medium.com

In October 2024, Dave Farley released this video with an updated view on software testing, challenging the classic test quadrant and test pyramid. It is great stuff and worth investing 18 minutes!

Dave Farley provides us with a treasure chest of insights in his channel. I highly recommend it.

Cybersecurity (CS)

You may have heard the notion of “shift security left” or the more general term “shift quality left”. We must ensure that quality (including cybersecurity) is natural and integral in developing software solutions. CS must not come as an afterthought. Also, it must not be a parallel development track with late integration. I’ve experienced both, and it leads to poor software quality. 

No doubt that, e.g., IEC 62443 for OT (Operational Technology) is complicated, but that is not an argument for separating CS development from the other solution development. We must (shift left) ensure the CS aspects are fully integrated with the ongoing solution development. A future article might dive into IEC 62443.

isa.org

Wrap-up

The world’s best Deployment Pipeline does not place your organization among the best, but it helps – a lot – moving in that direction! The two other legs in Continuous Delivery must also be strong.

Remember, product delivery is “only” one of the three dimensions of the product operating model.

Posted on

The product operating model: What problems to solve

Problems_to_solve_1200x745

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

Posted on

The product operating model: The right solutions to the problems

Product operating model - product discovery_1200x745

This is the third 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

The previous article was on product delivery. Here is how to discover the right solution to a problem.

Assumptions

The right problem to solve has been identified. A good practice is to formulate the problem as an OKR (Objective and Key Results).

    • Objective is the qualitative problem description of what needs to be achieved and, importantly, why—the rationale
    • KR is an outcome and how we measure the progress towards the Objective

The empowered product team has been asked, within the strategic context, to discover and deliver a solution that is valuable & usable for the customers, feasible for us to build and maintain, and viable for our business.

Product descovery

As noted in the previous article,

    • the team will iterate between product discovery and product delivery
    • the two intertwined disciplines are fundamentally different
Effective and efficient

Many companies … have eagerly adapted Agile, thinking it was a silver bullet for creating more value in software, only to be disappointed. Why? Agile does indeed promote a better way of collaboration and a faster method of building software, but it largely ignores how to do effective product management.

Agile assumed that someone was doing that front-of-funnel part, generating and validating ideas, and instead optimized the production of software. Yet, that piece has been lost along the way, as companies believe that Agile is all you need to do successful software development. So, many product managers in Agile organizations still operate with this Waterfall mindset.

Melissa Perri, Escaping the BUILD TRAP p. 26

Melissa Perri here stresses the importance of a structured and disciplined product discovery. 

Product discovery

The discipline of product discovery is a deep and branched rabbit hole in its own right. In 2022, I wrote this article on the subject, pointing to some of the many discovery techniques.

At least these four books should be on your shelves.

INSPIRED
Testing Business Ideas
Build Trap

One hallmark of the product operating model is that product teams interact frequently and directly with customers, not via layers of customer proxies.

During customer interactions, the product team will use experiments to test hypotheses on value (is it perceived as valuable to the customer?) and usability (is it easy for the customer to use?). The solution hypotheses must also be feasible to implement, support, and be viable for our business.

Customer interaction

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 to identify the winners in which you then invest more resources

Tendayi Viki, Pirates In The Navy: How Innovators Lead Transformation

There is no one-size-fits-all product team structure, but for the sake of argument, let’s use this one from Marty Cagan to illustrate the focus areas:

Product manager

The product manager is responsible for the solution to be valuable for the customer and viable for the business.

    1. Deep knowledge of the Customer – meaning the need to become an acknowledged expert on the customer: their issues, pains, desires, how they think, how they work, and how they decide to buy. Of course the PM must also be an undisputed expert on your actual product.
    2. Deep knowledge of the Data – being comfortable with data and analytics.
    3. Deep knowledge of your Business– understanding how it works and the role your product plays in your business. This includes knowing who the various stakeholders are and especially learning the constraints they operate under.
    4. Deep knowledge of your Market and Industry – covering not only your competitors but also key trends in technology, customer behaviors and expectations and following the relevant industry analysts. The PM may be supplemented with what are called domain experts or subject matter experts.

To be successful, a product manager must be the very best version of smart, creative, and persistent. 

Marty Cagan, INSPIRED p. 41

Product designer

The product designer is responsible for making the solution usable to the customer.

    1. Product Discovery – meaning product designers continuously collaborate with product managers and engineers, from discovery to delivery. The product designer sits side by side with his or her product manager, a full partner with the product manager on product discovery. The product designer is deeply oriented around actual customers and the value their product brings to those customers.
    2. Holistic User Experience Design – meaning any way customers and end users realize the value provided by your product. It includes all the touchpoints and interactions a customer has with your company and product over time. Good product designers think about the customer’s journey over time as they interact with the product and with the company as a whole.
    3. Prototyping– meaning the use of prototypes as their primary canvas for communicating ideas, both internally and externally. They are generally comfortable with many different prototyping tools and are able to apply the correct one for the task at hand.
    4. User Testing – meaning that product designers are constantly testing their ideas with real users and customers. User testing is broader than usability testing. Product designers and their product teams utilize the opportunity to assess the value of their ideas. Will customers use or buy the product and, if not, why not?
    5. Interaction and Visual Design – where interaction design generally includes the underlying conceptual models and visual design includes composition, typography, and how the visual brand is expressed. If building devices such as consumer electronics, there’s another critical dimension to design – industrial design – which looks at materials and design for manufacturing.

Apple is one of the most valuable and design-conscious companies on the planet; yet few tech companies understand the importance of design talent.

If you’re doing products for businesses, then this is one of your best competitive differentiators.

Marty Cagan, INSPIRED p. 53

The Engineers and the Tech lead role

The engineers are responsible for the solution as feasible to build and maintain.

    1. Strong relationship—meaning there’s probably no more important relationship for a successful product manager than the one with your engineers.
    2. As much latitude as possible – meaning that you let the engineers come up with the best solution.
    3. The Tech Lead Role among the engineers is important – meaning that the Tech Lead also has an explicit responsibility to help the product manager and the product designer discover a strong solution.

Marty Cagan, INSPIRED p. 59

Additional roles, often across product teams

A future article might address some of these roles.

    1. Product Marketing Manager
    2. User Researcher
    3. Data Analyst
    4. Domain/subject-matter experts
    5. Delivery Manager
    6. And ..?

Example from Grundfos

As an external consultant in 2022, I worked with Grundfos on validating an ambitious business model (that I coined “Future Reach”) based on an advanced digital self-service offering, providing customers with a full and seamless end-to-end customer journey, selecting, configuring, purchasing, commissioning, and servicing full Water Solutions. The full case is found here. Specific details cannot, of course, be disclosed.

My approach was to utilize (some of) the principles from the product operating model. I’ll return to this case in an upcoming article on what problems to solve. I’m here assuming that we have decided on a problem to solve.

Background

Before initiating the business model validation initiative, the Grundfos division had done the initial homework, running customer exploration experiments, such as customer interviews, to provide insights on customer opportunities (jobs/needs, pains, gains/desires).

These customer insights, combined with the strategic context, form the basis for the Future Reach business model hypothesis.

At a point in time, we came to a business model hypothesis that needed validation:

“We believe that we have a valid Future Reach business model that is desirable for our customers, feasible for us to implement and operate, and viable for our business.” 

What was more natural than using the Business Model Canvas to model and validate a business model?

The Business Model Canvas can logically be grouped into three hypothesis areas: desirable, feasible, and viable.

 

Three segments in BMC

I’ll here only focus on the desirability hypothesis.

Testing the desirability hypothesis

Desirable means that what we provide to the customers

    • is valuable
    • is usable

In other words, we need a strong product/market fit.

Our next step was, based on the earlier collected customer opportunities, to decide on

    • the customer segments/profiles that we want to serve
    • our value proposition to these customers
Product-market fit

Inspired by Dan Olsen’s The Lean Product Playbook

The Value Proposition Canvas helps us structure exactly that.

Value Proposition Canvas

Customer profile: we believe that we

    • are addressing jobs/needs that matter to customers
    • are focused on pains that matter to customers
    • are focused on gains/desires that matter to customers

Value map: we believe

    • our products and services solve high-value customer jobs and needs
    • our products and services relieve top customer pains
    • our products and services create important customer gains

We’re not done yet, having populated the Value Proposition Canvas. It still represents our assumptions. We need to go back to our customers and test the validity of these assumptions.

Realistically, we cannot and should not spend the customers’ and our own time testing all assumptions.

We’ll prioritize planning and doing structured assumption tests on important assumptions for which we do not yet have sufficient evidence to support them.

For the important assumptions with seemingly a high level of evidence, we’ll challenge ourselves on the validity of the evidence.

Now having decided on a few highly prioritized assumptions, the next step is to design and run the assumption tests with the customers.

Inspired by Testing Business Ideas

Because Future Reach is a digital offering, we prioritize mostly using visual means to test our assumptions with customers.

The product team prepared a clickable mockup to be used during the interaction with the customers.

Visual prototypes

Inspired by The Lean Product Playbook

As you’ll recall, the product team needs direct access to customers. Grundfos arranged exactly for that. A group of customers were provided to the product team. Before moving on, I’ll share with you the energy and excitement such a direct interaction sparked. 

The customer: “So great that we can have this kind of interaction with a highly knowledgeable team seeking to discover solutions to problems that matter to us. We’re also a bit humble, being asked to voice our opinion in this early stage of the product development.”

Team: “This kind of direct communication with a brief feedback loop expedites the process of validating the solution hypothesis before requesting funding to put it into action.”

Customers are happy, the team is happy—what’s not to like?

Discipline

For us to gain the most insights, we needed to act structured and disciplined. To support this, we chose to use the test- and learning cards from Testing Business Ideas.

In this way, we forced ourselves to come prepared for a focused dialogue with the customers, and we forced ourselves to capture and reflect upon learning in a structured way.

Test Card
Learning Card

Wrap-up

Done right and disciplined, product discovery helps us ensure that we choose to implement the best solution to the given problem, meaning that the solution 

    • is valuable to the customer
    • is usable for the customer (and users)
    • is feasible for us to implement and maintain
    • is viable for our business
Posted on

The product operating model: Solutions delivered the right way

Product operating model - product delivery 1200x745

This is the second in a 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 and the next articles will examine the three dimensions in more depth, starting with solutions delivered the right way. They will combine my practical experience with insights I’ve collected from various sources.

In an attempt to focus, I’ll here and in the next articles assume the product “only” to be software-based, a radical simplification compared to IE (see previous article).

Assumptions

The right problem to be solved has been identified, and the discovered solution has been verified to be valuable, usable, feasible, and viable through hypothesis testing.

At this point, the empowered product team is confident that the solution discovered is worth implementing. 

Waterfall?

The above illustration suggests a waterfall process, with product delivery after product discovery. It is not. In practice, the team will iterate between solution discovery and product delivery, as illustrated in my article on Product Discovery. 

Effective and Efficient

All product teams do a set of activities to decide what to build and then do a different set of activities to build and deliver it. While you’ll learn that these activities can and should overlap and interweave with each other, the work that is required to do each is fundamentally different.

… many companies put a heavy emphasis on delivery – they focus on whether you shipped what you said you would on time and on budget – while under-investing in discovery, forgetting to asses if you built the right stuff.

Teresa Torres, Continuous Discovery Habits p. 13-14

What we deliver must adhere to our quality brand

We do not present our customers with some half-baked “MVP.” What we deliver to our customers are production-grade solutions. MVPs and other types of prototypes are great tools for supporting product discovery.

To avoid any misunderstanding, it’ll be evident below that we strive for continuous delivery, delivering production-grade solutions in small batches, and optimizing for short feedback loops. We go to great lengths to ensure the built-in production-grade quality.

You can’t inspect quality into a product; it must be built into it.W. Edwards Deming

Right, so how do we build in quality?

Accelerate Appendix A provides 24 key capabilities that statistically significantly drive improvements in software delivery performance.

Note on page 86 on team experimentation: “We’re not proposing that you set your developers free to work on whatever ideas they like. “

Reflecting on the product operating model, I would rephrase this: “We’re not proposing that you set your product team free to work on whatever problem they like. Through our product strategy, we decide what problems to solve. We empower our product teams to discover solutions to problems. Setting hypotheses and testing through experimentation is a core aspect of our teams.“

Despite not being explicit about product teams empowered to discover solutions to customer/business problems, Accelerate is still a treasure trove of valuable insights. Among the 24 capabilities, many are highly relevant to the product operating model. 

Accelerate

Continuous delivery

    1. Use version control for all production artifacts: Control the version of nearly everything. This is the foundation of a solid configuration management practice in the Deployment Pipeline.
    2. Automate your deployment process: Deploying automatically to production is the best thing to do in some scenarios, and in other scenarios, it must be a business decision. 
    3. Implement continuous integration (CI):  CI is foundational for CD. No real CI, no CD.  Martin Fowler on CI: “Continuous Integration is a software development practice where each team member merges their changes into a codebase together with their colleague’s changes at least daily.”
    4. Use trunk-based development methods: “Trunk” is another name for the main line. CI expects to merge to the trunk at least daily. We’ll have no, or at least very short-lived, feature branches. A strong culture of collaboration and shared ownership is needed for CI and trunk-based development. 
    5. Implement test automation: This is one of the key characteristics of the Deployment Pipeline. A massive battery of automatic acceptance/regression tests is needed.
    6. Support test data management: Managed test data under configuration management control is also a key characteristic of the Deployment Pipeline. 
    7. Shift left on security: Ensuring cybersecurity is not an afterthought. It is designed and built in from the start. 
    8. Implement continuous delivery (CD): A logical extension of CI.

Dave Farley is the undisputed king of continuous delivery, with Continuous Delivery and Continuous Delivery Pipelines, among other books. Dave Farley recommends we become proficient in these practices (yes, resonating with Accelerate):

    • Reduce the Cycle Time
    • Automate Nearly Everything
    • Control the Variables
    • Work in Small Steps
    • Make Evidence-based Decisions
    • Work in small, Empowered Teams
    • Apply Lean & Agile Principles
Continous Delivery

I highly recommend reading all of Dave Farley’s books, Continuous Delivery, Continuous Delivery Pipelines, and Modern Software Engineering.

Architecture

    1. Use a loosely coupled architecture: This helps teams work and deploy independently and maintain a high release cadence.
    2. Architect for empowered teams: Accelarate’s definition is not as far-reaching as the empowered product team in the product operating model. Accelerate, page 204: “Our research shows that teams that can choose which tools to use do better at continuous delivery and, in turn, drive better software development and delivery performance.” In the product operating model, the product teams are empowered to discover (valuable, usable, feasible, & viable) solutions to problems. The choice of tools is only a small fragment of the larger empowerment.

Product and process

    1. Gather and implement customer feedback: This is at the core of empowered product teams, with direct and high-frequency customer interaction.
    2. Make the flow of work visible through the value stream
    3. Work in small batches: This helps shorten the feedback loops.
    4. Foster and enable team experimentation: This is at the core of product discovery and testing hypotheses on the solution’s value to the customer, usability for the customer, feasibility for us to build, and viability for our business.

Lean management and monitoring

    1. Have a lightweight change approval process: The product team is empowered to discover solutions to problems and is held accountable for the outcome. It does not rely on some external change approval board. Highly efficient product teams avoid lengthy PR (pull requests) blocking flow using, e.g., pair programming.
    2. Monitor across application and infrastructure to inform business decisions
    3. Check system health proactively
    4. Improve processes and manage work with work-in-progress (WIP) limits: How the product team stays focused is at the team’s discretion. 
    5. Visualize work to monitor quality and communicate throughout the team: Transparency of status is one of the characteristics of the Deployment Pipeline.

Cultural

    1. Support a generative culture (as outlined by Ron Westrum):  A culture of product teams empowered to discover solutions to problems and strong management facilitating cross-team collaboration.
    2. Encourage and support learning. Is learning, in your culture, considered essential for continued progress? Innovation and learning through disciplined experimentation in the product teams and Communities of Practices across teams.
    3. Support and facilitate collaboration among teams: The product teams are cross-functional, and management facilitates cross-team collaboration.
    4. Provide resources and tools that make work meaningful: If not, why hire smart people in the first place?
    5. Support or embody transformational leadership: Product teams are provided with the strategic context (business mission and strategic objectives, product vision, and product strategy) to discover solutions to problems. Management lives and inspires the values and principles of DevOps.

Yes, that is a mouthful. One important takeaway is the duality that

quality needs speed (small steps with short feedback loops), and speed needs quality,

they go hand in hand. 

This may, at first glance, sound counterintuitive. Do you not need a lot of time to provide quality?

To illustrate the point, let’s look at two distinctly different scenarios.

Scenario #1:

(Very) long feedback loops

This organization has chosen to separate feature development from system integration and testing. The self-understanding is being “agile,” though I would describe the way of working as “water-scrum-fall.”

In this scenario, the teams are given features (solutions) to implement, not problems to solve.

Water-scrum-fall

A developer committing some code can experience 180+ days of feedback length on system level. The feedback from customers is even longer.

Not surprisingly, organizations having this way of working are experiencing poor quality and returning panic getting the quarterly release out the door. Having a long time does not resonate with providing great software.

Poor software, slowly, unhappy customers!

Yes, some organizations will work this way in 2025.

Scenario #2:

(Very) short feedback loops

Running the product operating model, this organization appreciates the duality that quality needs speed (short feedback loops) and speed needs quality.

It has implemented Continuous Delivery by Dave Farley. It stands on three legs:

Dave Farley consistently uses the term “Deployment Pipeline.” It covers what is traditionally known as “CI/CD pipelines.” Cut to the bone, the Deployment Pipeline must, as fast as possible, provide answers to the questions

    1. Is my code technically correct?
    2. Is the system releasable?

The organization has potentially deployable release candidates at a daily cadence. When to release to customers is a balanced business decision. 

Great software, fast, happy customers!

Continuous Delivery is today the norm in many of the world’s most successful software organizations.

DevOps culture and scaling

Thinking “DevOps” in the culture leg above, you’re close. You’ll find a lot of definitions on DevOps. This one from ThoughtWorks seems to catch the essence:

A culture where people, from a range of disciplines, work together to design, develop, deploy and operate a system.

DevOps is a way of working that stresses the need for cross-functional teams — from a huge variety of backgrounds — who have ownership of the systems they’re working on. It’s a cultural approach, not something that you buy.

Thoughtworks

“You build it, you run it” is a software development and management approach where the team that builds a piece of software also remains responsible for its maintenance and management throughout its lifecycle.

It’s an important aspect of DevOps cultures, where people from a range of disciplines work together to design, develop, deploy and operate systems, services, and applications.

Thoughtworks

Scaling

It looks very fine and dandy; what’s not to like?

In a relatively small organization with only a few product teams and a not too complicated product, this is great. No throwing stuff over the fence. Teams own it end-to-end.

As your organization grows with additional product teams and as the complexity of your product and enabling technologies grows, the cognitive load on your product teams grows to an unmanageable extent. Such a loss of bandwidth to focus on the customers is business-critical.

The mitigation is to keep the cognitive load on the teams at a balanced level. You might remember the strategic context described in my first article on the product operating model, including the product team topology.

In Team Topologies, Matthew Skelton & Manuel Pais provide a framework for exactly that; managing the cognitive load in a balanced way. I recommend reading the book.

Team Topologies suggest a range of team types and a set of interaction modes. For the sake of illustration, I’ll here only use the two team types 

    • Stream-aligned team (product team), serving the customers
    • Platform team, serving the internal customers, the stream-aligned teams

and the “X-as-a-Service” interaction mode.

Platform team

Internal product management

The rationale is to have a platform team provide a range of internal products and services to the stream-aligned teams (aka the product teams) to offload the otherwise excessive cognitive load impeding focus on the customers.

We want the platform teams to apply the same product management principles used by the product teams, with product vision and insights-driven product strategy, deciding what problems to solve. This is a delicate balance, finding the level of abstraction that benefits the product teams most. The platform team must understand the jobs to be done, the pains, and the desires of the product teams.

Developer Experience - DX

An obvious product for the platform team to provide is the Deployment Pipeline infrastructure, tooling, and plumbing with a range of (self-)services. We improve developers’ experience in delivering solutions to customers. It has been coined DX, and it is a big deal. 

You’ll find many definitions of DX. The one to the right is from acmqueue with, e.g., Nicole Forsgren, one of the authors of Accelerate.

With inspiration from acmquque

These are the definitions from acmqueue on the three dimensions:

Feedback Loops

Also, scenario #2 above.

“Software organizations commonly look for ways to optimize their value stream by reducing or eliminating delays in software delivery. This allows faster feedback and learning about what is being built, which in turn allows for more rapid course correction. Studies have consistently shown that organizations deploying more frequently and maintaining shorter lead times are twice as likely to exceed performance goals as their competitors.”

Cognitive Load

Also, DevOps scaling above.

“Software development is inherently complex, and the ever-growing number of tools and technologies is further adding to the cognitive load faced by developers. Cognitive load encompasses the amount of mental processing required for a developer to perform a task. For example, cognitive load typically increases for a developer working on an inherently difficult or complex task, or learning to understand an unfamiliar development framework. Cognitive load also varies according to how external information is presented and increases when mental processing is required for translating information into longer-term domain knowledge and models.”

Flow State

“Developers often speak of “getting into the flow” or “being in the zone.” Such statements colloquially describe the concept of flow state, a mental state in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment.

Frequent experiences of flow state at work lead to higher productivity, innovation, and employee development. Similarly, studies have shown that developers who enjoy their work perform better and produce higher-quality products. Interruptions and delays—which relate to the feedback loops dimension—are important factors that hinder a developer’s ability to experience flow state.”

Wrap-up

The main suggested takeaway would be to optimize for DevEx. In its wake, you’ll naturally come to address Continuous Delivery (remember its three legs) and DevOps scaling. 

I could also in this article have addressed Domain-Driven Design (DDD), Test-Driven Development (TDD), Behavior-Driven Development (BDD), test strategies, the team sport called Continuous Integration, the automated Deployment Pipeline, Infrastructure as Code (IaC), version control, configuration management, cybersecurity like IEC 62443, cloud computing, microservices, etc.

I did not. Some of these themes may be in future articles. 

More inspiration

Dave Farley on Continuous Delivery, Software Engineering, Deployment Pipeline, and “dual-track agile” (though he does not explicitly use that term) at the 2024 GOTO Conference.

Posted on

The product operating model

Product_operating_model 1200x745_v2

This is the first in a series of articles on the product operating model. It’ll be a mix of my practical experience and various inspirational sources.

In one of my earlier articles, I outlined what it takes to achieve fast-paced innovation of multidisciplinary high-tech products. This article will further address the product operating model using Integrated Energy (IE) to illustrate key points supporting fast-paced innovation.

Essentially, the product operating model is about consistently creating technology-powered solutions that your customers love, yet work for your businessMarty Cagan, TRANSFORMED, page 7

Integrated Energy (IE)

IE is a high-tech product organization that develops a business-to-business (B2B) multidisciplinary product to drive the reduction of CO2 emissions. The product is based on massive data collection from various sensors in production, office buildings, logistics, local solar/wind power production, energy storage, and other data sources. With IE’s product, customers will have near real-time transparency on its CO2 emissions. IE’s product is configurable from running a report-only mode to active mode, minimizing CO2 emissions. Lately, the hub has become cloud-based and enhanced with AI.

IE was initially a startup focused on smart B2C products for residential homes. The founders achieved a strong product-market fit, enabling them to grow the business to its current strong global B2B position. 

From the beginning, the founders have wanted to keep the start-up mentality during growth. IE has transitioned from a small start-up to an enterprise without drowning in its bureaucracy and process prescriptions. Being focused on the customer, maintaining a high pace of innovation, and having a high-quality brand is fundamental for the founders.

IE and the product operating model

IE uses visualization to convey the essence of complex topics in an easy-to-grasp way. To give an overview, let’s start with their operating model, centered around the three dimensions of the product operating model.

IE product operating model

As a conceptual model rather than a process framework, I’ll outline IE’s core principles inspired by the “product operating model” and supply antipatterns for what IE aims to avoid, enforcing the message.

Principle: Our product continues to focus on solution discovery and delivery, guided by our product vision and strategy.

Antipattern: Our “product” is a reactive patchwork of projects pushed from sales.

Principle: We empower product teams to discover valuable, usable, feasible, and viable solutions to problems and measure success on outcomes.

Antipattern: We ask teams to implement specific solutions and measure success on output.

Principle: We ensure that product teams have regular and unrestricted access to both our customers and the business.

Antipattern: Having layers of customer-proxy roles and processes between the teams and the customers.

Principle: We provide product teams with the strategic context necessary to discover solutions.

Antipattern: Teams are given detailed instructions on what to build.

Principle: Product innovation through disciplined experimentation is an integral part of the daily work in product teams.

Antipattern: Innovation happens in separate “innovation labs” or within a dedicated time slot.

Principle: We keep process prescriptions and frameworks at a minimum viable level, perceiving our employees as intelligent, motivated, and responsible. 

Antipattern: Process prescriptions and frameworks are substitutes for thinking, perceiving our employees as mercenaries and cogs in the big machine.

Principle: We scale problems to fit product teams and have strong management to support team coordination.

Antipattern: Scaling agile processes and frameworks.

Principle: To us, leadership is not a job; it’s a mindset and a way to act. Management is a job (VP, functional manager, product manager, project manager, etc.). All our employees are expected to have and show leadership skills, some more than others.

Antipattern: The ability to lead is reserved for and only expected from managers.

Principle: We’re placing many small bets when funding the product teams. We’ve adapted the VC-style funding model from the early start-up times; now it’s an internal VC-funding model.

Antipattern: Big bets with big up-front business cases. 

Principle: We firmly believe in having our product teams live the core values of DevOps. But, at scale, we need to balance the cognitive load on the teams, ensuring that we focus on the customer. We achieve this through a well-thought-out topology of teams. 

Antipattern: A pure DevOps approach only works for a relatively small organization and does not scale. If not attended to, teams will lose focus on the customer in the quest to keep up with enabling technologies, tools, standards, and good practices. 

Wrap-up

Through disciplined focus, IE has managed to grow into a league of successful high-tech product organizations with a product operating model. In IE, you’ll not hear people talk much about, e.g., Agile, Scrum, Kanban, SAFe, PRINCE2©, or Project Management Offices with huge project process models.

Sure, IE has grown a substantial pick-and-use toolbox over the years and has several CoPs (Communities of Practice) across the product teams to share insights and good practices. You will find prescriptive processes in IE as a basic glue, but only at a minimum viable level.

It is fundamental for the founders to keep a nimble and lean organization with a focus on the customers and enabling technologies, not on internal bureaucracy.

Next

This initial article will be followed by articles for each of the three dimensions of the product operating model, the next being The product operating model: Solutions delivered the right way.

More inspiration

Marty Cagan has written three groundbreaking books: INSPIRED, EMPOWERED, and TRANSFORMED, helping us to understand what distances the best high-tech product organizations from the rest. If you have the time and energy, read all three, starting with INSPIRED. If not, at least read TRANSFORMED.

Melissa Perri’s Escaping the Build Trap and Teresa Torres’ Continuous Discovery Habits are also worthy reads.

Want more? Check out my full list of inspirations.

Proudly powered by WordPress