
The 3 Dimensions of the Product Operating Model.
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.
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.

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.