The Product Engine
The Product Engine, product operating model consulting that stays for the build
Product operating model consulting is the work that moves an organization from funding projects to running products: cross-functional teams that own customer problems and the outcome, a funding model that pays for teams and the results they own, product discovery before anything is built, and a product roadmap written in outcomes over output. The Product Engine is our program for it. We've run the product function ourselves, at IKEA and since, and we install the model with your teams and stay until it runs without us.
The result shows up in two places a board already looks: what gets used, and how fast the next change ships.
What a product team does that a project can't
Take a live-video support tool we ran inside a six-product portfolio at IKEA: a store co-worker points a camera at a part, a specialist on the other end identifies it. Recognition time went from 15 minutes to 2 minutes, the people using it rated it 4.8 stars, and customer satisfaction on those cases rose 25% (IKEA Sweden, 2018 to 2021). The team kept the problem after launch, watched recognition time every week, and rolled the tool to every store in Sweden. That is what a product operating model pays for: the team that stays with the problem after the launch date.
The other side of the ledger is well measured. Pendo found that 80% of features in the average software product are rarely or never used (Pendo Feature Adoption Report, 2019). The Standish Group's CHAOS data puts the share of software projects that finish on time, on budget and on scope at 31% (2020). Both figures describe the same organization: one that funds scope, ships it and moves on, so nobody is left to notice what got used.
What The Product Engine includes
| Step | What we do | What you keep |
|---|---|---|
| Operating model diagnosis | We map how work is funded, prioritized, staffed and measured today, product by product, against the outcomes the board wants | A one-page picture of where projects still hide, and the two or three gates to change first |
| Funding and portfolio | We move funding from scoped projects to teams with outcome targets, and set up the product portfolio review the leadership runs each quarter | A funding model finance signs, with the portfolio review on the calendar |
| Practices installed | Product discovery, outcome-based product roadmaps, release cadence and measurement, set up inside each cross-functional team with its product owner | Teams that can say what they learned this month and what they stopped building |
| Coaching until it holds | We sit with product leadership and the teams through the first two quarters, then step back as the model runs on its own | A product function that survives the next budget round without us |
The scope depends on how many teams switch and how long the coaching runs. We set it with you in one working session, and the operators who set it are the ones who show up on day one.
The proof we bring
One of us introduced iterative product delivery across IKEA's digital product teams from the group headquarters in Älmhult (2017 to 2018), then ran a product portfolio of six products with 21 people for three years (2018 to 2021). That portfolio included a city-format store that paid back its investment in two months, a visual search app launched on two continents with engagement up 30% (2018 to 2021), and the live-video support tool above.
In 2018, selected from 1,112 applications across 62 countries to lead a startup in the IKEA bootcamp as head of product, the same operator took the app to 10,000 users in the Netherlands in 8 weeks.
As product lead and then chief product officer for a global outdoor brand, we took a stalled re-platforming onto a headless stack to stable in under three months: 60 UI components in five months, 700+ brand pages migrated by a task force of four stood up in 48 hours, 600+ post-release bugs cleared, and 95% of the accessibility audit's recommendations applied (from 2024). The case is on the outdoor brand page.
At a leading French online credit broker with 24M visits a year, we ran acquisition, the group's first priority, with four cross-functional squads and nine people, and rebuilt the funnel's measurement from scratch (2026). Another of us is the sole product owner of three live products at IKEA, the shelf-label platform among them. Most of that record was built inside IKEA, which has never been a client of ours. The rest is on the proof page.
The position we hold
A product operating model that is announced from the top and not funded from the top will fail within a year. The ceremonies change, the budget gate does not, and by the second budget round the teams are back to projects with new vocabulary. Process rollouts get one thing right: habits matter, and a good coach makes product discovery and outcome reviews routine. Where they stop is the funding model, because that is where the board sits and a coach has no seat there. That is the part we take on first (most people would rather leave it for year two, which is exactly why it fails). Funding and portfolio come before ceremonies in our program, and we count the model installed when a team has been refunded on an outcome and kept its money.
The engine and the map
The Product Engine changes how the organization funds and runs products. The Hub Map is how we find which problems deserve a team in the first place, and FOCAL is the method that runs both. The rest of what we do sits on what we do. The Hub Map's mechanics are ours alone and stay off the site.
Questions, answered straight
What is product operating model consulting?
It is the practice of switching an organization from funding and running projects to funding and running products: cross-functional teams that own customer problems, product discovery before build, product roadmaps written as outcomes, and a funding model and product portfolio review that keep it that way. Good product operating model consulting is measured in feature adoption, release cadence and the share of budget moved from projects to teams. The model is installed when it survives a budget round.
Why do agile transformations stall?
They change the ceremonies and leave the operating model alone: work is still funded as scoped projects, teams are still measured on delivered features, and the product owner has no say over money. An agile transformation run that way changes the standups and leaves the behaviour where it was. We change the funding and the measures first, then the product management practices land, and they hold because the money now follows them.
What changes for a team in the first quarter?
The team gets a customer problem and an outcome target, a product owner with a real say on priorities, a discovery routine before anything is built, and a product roadmap written in outcomes it reports on monthly. The funding line moves to the team. The feature list stops being the contract, and the switch from project to product becomes visible in that team's release cadence within the quarter.
Do we need to reorganize before we start?
Usually you start with two or three teams and the funding gate, and leave the org chart alone for a quarter. The model proves itself in those teams, then the product portfolio review extends it to the next ones. Reorganizing first is how a project organization buys itself another year of projects with new titles.
How do you measure that the model holds?
Three numbers, tracked from the diagnosis on: the share of budget funded to teams with outcome targets, the release cadence per team, and feature adoption in the products that ship. A model that holds shows all three moving by the second quarter. And the second budget round is the real test, because that is when a team either keeps its money on an outcome or gets handed a scope again.
What should we have ready before the diagnosis?
The list of what is in flight and how each item is funded, the last two budget rounds, an hour with the finance lead who signs the budget, and product leadership in the room for the diagnosis. The rest is ours to bring. Start a conversation and we pick the first teams with you. If finance wants the numbers before it commits a team, the FOCAL Diagnostic is the scoped first step.
Bring the budget round
A working session on your product portfolio with the operators who would run the switch. Bring the list of what is funded and how, and we will show you where the projects still hide before anyone signs anything.