What Makes an Organization Product-Centric — And Why the Label Is Easy to Fake
A comparative evidence review of GSK, John Deere, and SAP, with a practical AO Method diagnostic and redesign sequence.
Pierre Neis · Menschgeist · September 2026
Get the AO Method’s research and diagnostics delivered to your inbox — no spam, unsubscribe anytime.
Executive Summary
“Product-centric” is claimed far more often than it is demonstrated. This article proposes three evidence-bound pillars for testing the claim rather than taking it at face value: persistent product or value-stream ownership, funding and incentive logic that follows the product rather than a project charter, and a traceable line from customer or business demand through to delivered outcomes.
Tested against public evidence, GSK and John Deere each show genuine, well-documented shifts — GSK strongest on team ownership and outcome-first prioritization, Deere strongest on Board-approved, continuous product-based funding. Between the two, all three pillars are solidly evidenced. SAP’s July 2026 leadership reorganization, by contrast, produces the visible signal of product-centricity — new, named product-line structures — without public evidence of funding or outcome-traceability change, and with reporting that frames it as a CEO and COO consolidating direct oversight after a board-level departure rather than authority devolving to product teams. That combination makes SAP a cautionary contrast rather than a peer case, though the absence of public evidence should not be mistaken for proof that no such internal mechanisms exist.
The closing chapter turns from testing the claim to building it: it shows how the AO (Adaptive Organization) Method’s diagnostic apparatus — the framework-versus-system distinction, the five-dimension baseline (Deliver, Demand, Capacity, Capability, Organisation), the internal-start-up test, autonomy-risk calibration, and a continuity test against sponsor departure — gives an organization a practical, sequenced way to diagnose and redesign its own operating model against these same three pillars, rather than merely relabeling it.
Introduction
“Product-centric” has become one of the most claimed and least verified labels in organizational design. A company renames its project managers as product owners, groups its roadmap into “products,” and announces a shift from project to product thinking — and the label sticks, regardless of whether anything underneath the org chart actually changed.
The concept itself is not proprietary to any single consultancy or framework. It comes out of a fairly well-established body of practice: Mik Kersten’s Flow Framework and Project to Product (projecttoproduct.org; Kersten, Project to Product, IT Revolution Press), the Team Topologies model of stream-aligned teams (teamtopologies.com), and the broader SAFe and DevOps literature on value streams. Stripped of any single framework’s branding, the definition converges on three testable pillars:
1. Persistent product or value-stream ownership — a stable team owns a product or value stream indefinitely, rather than a project team assembled for a scope and disbanded at delivery.
2. Funding and incentive logic that follows the product — budget, investment decisions, and incentives attach to the ongoing product or value stream, not to a fixed-scope, fixed-duration project charter.
3. Demand-to-outcome traceability — a visible, evidenced line from customer or business demand through prioritization to delivered, measured outcomes, rather than a phase-gated project plan disconnected from usage signals.
This article tests three companies against these three pillars using only public evidence: GSK and John Deere, both of which have published detailed accounts of their own transformations, and SAP, whose July 2026 leadership reorganization is often described in the press as a product-centric move but has not been documented against these pillars at all. The purpose is not to declare a winner, but to show what separates a structural relabeling from an evidenced operating-model shift — and to make that distinction sharp enough to be useful before turning, in the final chapter, to how a systemic diagnostic method like AO can help an organization tell the difference in its own case.
Pillar 1: Persistent Product or Value-Stream Ownership
GSK provides the most granular public evidence of this pillar. GSK Tech describes a shift from temporal project teams to stable, cross-functional product teams built around long-term missions intended to remain valid over time — a “north star” for continuous change rather than a fixed deliverable (GSK Tech, “Transforming from a Project to Product Centric Organization”). In its Consumer Tech unit, GSK segmented its customer base, mapped customer journeys, and assigned each product team ownership of improving the experience for one customer segment — with team success measured by customer outcomes rather than delivery output. In R&D, the company runs 88 DevOps product teams, and rather than have every team rebuild common capability, it created a self-service internal product — the Scientific Data Store — that other teams can provision against, explicitly treating internal platforms as products in their own right.
John Deere shows the same pillar from a different angle: role and taxonomy redesign rather than customer-segment design. Deere’s Agile transformation, running from 2019 through 2022 and covering more than 500 teams, replaced a taxonomy “organized more around project type than value delivered” with one organized around Agile value streams (Scrum Inc., “Agile Unleashed at Scale”). Under the old model, “employees were moved to projects rather than being allowed to own a product end-to-end.” Under the new model, Product Owners and teams hold responsibility for “a real product rather than simply completing project deliverables,” with value-stream maps built from a customer-journey perspective determining how products and portfolios are grouped.
SAP’s July 2026 reorganization is the weakest and most ambiguous case on this pillar. The company split its former single Product & Engineering board area into two new lines: a Business AI Platform and CTO organization (combining Data and Analytics, Business Transformation Management, Platform, AI, and remnants of the former Business Technology Platform team) and a new SAP Autonomous Suite organization (combining Finance and Spend Management, Supply Chain Management, Human Capital Management, Customer Experience Management, and Cloud ERP Private) (SAPinsider). This is a real structural change with named, persistent-sounding product lines. But multiple outlets frame the change not as ownership devolving to product teams, but as CEO Christian Klein and the COO consolidating direct oversight of product development, prompted by Chief Product Officer Muhammad Alam’s departure and a Chief Product Officer for BTP, Michael Ameling, also leaving the company (Bloomberg; ad-hoc-news). A name change at the top of an org chart is not the same evidence as GSK’s or Deere’s demonstrated team-level ownership — it may just as easily indicate the opposite motion.
Pillar 2: Funding and Incentive Logic
John Deere is by far the most rigorously documented case on this pillar in the public literature. A Board of Directors-approved investment in 2019 shifted Deere’s model from annual portfolio planning and annual spend roll-ups to continuous portfolio governance and monthly total-product-cost visibility, using Technology Business Management (TBM) tooling as the standard platform to accelerate its Agile operating model (TBM Council). The transformation explicitly moved the company from “investing in IT initiatives” to “investing in digital products,” and from January 2021 the TBM team began publishing total product cost reports monthly, replacing a prior state where senior leadership had only annual product investment visibility. Deere describes this as embracing “Agile funding” — a more flexible way of funding product teams and monitoring investments continuously rather than annually.
GSK’s public account, by contrast, is silent on this pillar. The GSK Tech article describes team structure, customer-outcome measurement, and platform-as-product design in detail, but never once mentions budget reallocation, cost-center restructuring, or funding mechanisms. This is a gap in the published evidence, not proof that GSK failed to change its funding model — but it means GSK cannot be cited as a demonstrated funding-logic case the way Deere can.
SAP has no public evidence on this pillar at all. Coverage of the 2026 reorganization focuses entirely on reporting lines, board composition, and executive departures — none of it addresses whether IT or product budgets shifted from project-based to product-based allocation.
Pillar 3: Demand-to-Outcome Traceability
GSK offers the strongest evidence here. For its paperless manufacturing product, the organization first defined the business outcomes needed, then deliberately moved away from project-tracking metrics like time and cost, prioritizing work based only on what the business and end users needed. For its US e-commerce platform, the technology team and stakeholders jointly defined a product vision and success measures, then built a customer journey map that “exposed gaps in the roadmap from a user-facing perspective rather than an implementation perspective” and surfaced previously unknown customer problems — leading to testable hypotheses rather than a fixed backlog (GSK Tech).
John Deere shows the same pillar through value-stream mapping: Deere built value-stream maps across products, including from a customer-journey perspective, and deliberately grouped products and product families “according to the value delivered to customer personas” rather than technical convenience, accounting for dependencies, handoffs, and bottlenecks in the process (Scrum Inc.).
SAP, again, has no public evidence either way on this pillar.
Summary Table
| Pillar | GSK | John Deere | SAP |
| Persistent product / value-stream ownership | Strong — stable customer-segment teams, platforms run as products | Strong — Product Owners with end-to-end responsibility, value-stream taxonomy | Weak/ambiguous — new product-line names, framed as CEO/COO centralizing control |
| Funding and incentive logic | Not publicly documented | Strong — Board-approved 2019 shift to continuous, product-based TBM funding | No public evidence |
| Demand-to-outcome traceability | Strong — outcome-first prioritization, customer journey mapping | Strong — value-stream maps built around customer personas | No public evidence |
A Necessary Caveat on SAP
It would be unfair to read SAP’s silence on funding and traceability as proof that no such mechanisms exist. SAP is a private enterprise-software vendor under no obligation to publish its internal funding mechanics or product-outcome metrics — unlike GSK’s and Deere’s own technology teams, which chose to publish detailed transformation retrospectives specifically to describe how their funding and prioritization logic changed. It is entirely possible that SAP runs disciplined product-level funding and outcome tracking internally and has simply not written it up for external audiences.
Reading the evidence carefully
The claim this article makes is narrower and more defensible: unlike GSK and Deere, there is no public evidence that SAP has made this shift, and the visible evidence that does exist — a CEO and COO consolidating direct oversight of product development following a board-level departure — points toward centralization of decision authority rather than devolved product ownership. Absence of evidence is not evidence of absence, but it does mean SAP cannot yet be cited as a demonstrated case the way GSK and Deere can be. A structure that names products is not the same as a structure that funds and governs them as products, and on current public evidence, SAP’s 2026 reorganization shows only the first.
Conclusion
Product-centricity is often claimed through structure alone — a renamed org chart, a “Product Owner” title, a new suite name on a slide. But the label only means something when it is backed by three things moving together: persistent ownership of a product or value stream over time, funding and incentives that follow the product rather than a fixed-scope project, and a visible line from customer or business demand through to delivered outcomes. Where all three are present and evidenced, as at GSK and John Deere, the shift is structural. Where only the label changes, it is not — and on the public record, SAP’s 2026 reorganization illustrates exactly that risk: a product-shaped org chart produced by the opposite motion, a re-centralization of authority at the top, with no visible funding or outcome-traceability change alongside it.
GSK and Deere arrived at the same underlying shift from different entry points — GSK through customer-segment team design and outcome-first prioritization, Deere through Board-approved funding-model change and value-stream taxonomy — and between them, all three pillars are solidly evidenced in the public literature. That is what makes them usable as comparison cases and what makes SAP, at least for now, a cautionary contrast rather than a peer.
Chapter: How the AO Method Can Help Build a Product-Centric Organization
The three-pillar test used above — persistent ownership, funding logic, demand-to-outcome traceability — is useful precisely because it is falsifiable: an organization either has public, structural evidence for each pillar or it doesn’t. But the test has a limitation by design: it tells you whether a shift happened, not why it stalls when it is attempted, or what to actually redesign when it does. This is where a systemic diagnostic method like AO (Adaptive Organization), developed by Pierre Neis, is built to operate — not as a competing definition of product-centricity, but as the diagnostic and redesign layer underneath an organization’s attempt to become one.
Distinguishing framework adoption from operating-model change. AO’s central methodological move is separating the adoption of a process or label from the redesign of the underlying system. A team, or an entire company, can adopt Scrum, SAFe, or a “product operating model” vocabulary while decision rights, funding structures, HR systems, and organizational interfaces remain exactly as they were. This is precisely the gap the SAP case exposes: naming a Business AI Platform organization and an Autonomous Suite organization is a framework/label change; whether it is also a system change depends on whether decision rights, funding, and incentive structures moved with it.
A five-dimension lens that maps directly onto the three pillars. AO’s rapid diagnostic frame — Deliver, Demand, Capacity, Capability, and Organisation — gives each of the three pillars used above a home inside a more complete systemic read. “Demand” and “Deliver” map onto demand-to-outcome traceability; “Capacity” and “Organisation” map onto persistent ownership; funding and incentive logic cuts across all five, because AO treats decision-flow analysis as applying to authority and money, not only to delivery.
The “internal start-up” test as an operational check on ownership. AO uses a specific structural test for whether a product team’s ownership is real rather than nominal: it must have decision rights, a value case, bounded autonomy, tolerance for cheap, reversible failure, and founder-like accountability for outcomes. This is the level of diagnostic specificity that separates “the org chart says product team” from “the team can act like one.”
Autonomy-risk calibration for funding and platform decisions. AO’s autonomy-risk boundary treats delegation as a design variable: decisions are safe for local, team-level ownership when they are reversible and contained; decisions with high blast radius, irreversibility, or cross-team correlation require guardrails or escalation upward — giving an organization a concrete design question to answer up front rather than discovering the boundary through failure.
Continuity as the real test of whether the shift survives. AO treats adaptive capacity — and by extension, a genuine product operating model — as organizational only if it survives the departure of its original sponsors. This is the sharpest lens available on the SAP situation specifically: a reorganization launched around named product lines, but visibly triggered and directed by a change in executive personnel, is structurally fragile by AO’s own continuity test until it is shown to persist independent of the individuals currently holding it together.
Where this leaves the three-pillar test. The pillars used earlier in this article are a good first-pass, evidence-bound filter. AO does not replace that filter; it is the next layer down, for an organization that wants to know not just whether it looks product-centric from the outside, but whether its decision flow, funding authority, and continuity actually support the label from the inside — and, if not, where specifically to redesign.
A Practical Diagnostic and Redesign Sequence
The distinctions above are only useful if they translate into something an organization can actually run. What follows is a practical sequence — not a generic maturity model, but a direct operationalization of the AO concepts just described, applied to the specific problem of moving from project to product. It assumes internal access to data that public reporting on GSK, Deere, or SAP does not provide, which is precisely the point: this is the work an external observer cannot do from press releases, but an internal AO diagnostic can.
Step 1 — Name the object of change before touching structure.
Separate what is being asked as a label change (new team names, new titles, a “product operating model” slide) from what is being asked as a system change (who holds budget, who can say no, how work gets prioritized). AO’s framework-versus-system distinction exists precisely to stop this step from being skipped. In practice: interview the sponsors of the shift and ask them, separately, “what should look different in the org chart” and “what decision should be made by a different person, on a different cadence, than it is today.” If the second question produces no answer, the initiative is a relabeling, not a redesign — the SAP pattern this article describes is what it looks like when this step is skipped.
Step 2 — Run the five-dimension baseline read.
Score the organization’s current state, before any redesign, across AO’s five diagnostic dimensions — Deliver, Demand, Capacity, Capability, Organisation — using named, sourceable evidence rather than self-assessment. This step exists so that “we became product-centric” is a testable before/after claim rather than a narrative: where does prioritized work actually originate; is there a traceable line from demand to shipped outcome; are people assigned to a stable team or reassigned by project; does the team hold the skills to own its product end-to-end; and does formal structure match where decisions are actually made?
Step 3 — Apply the internal-start-up test to every proposed product team.
For each team being asked to “own a product,” check it against five conditions: decision rights, a value case, bounded autonomy, tolerance for cheap and reversible failure, and founder-like accountability for outcomes. A team that fails two or more of these is a project team wearing a product label, regardless of its name — and it is the step most transformations skip because it requires naming which teams are not yet real product teams.
Step 4 — Calibrate autonomy by consequence, not by title.
For each decision a product team will make — reallocating its own budget, changing its roadmap, shipping without a separate release gate — classify it by reversibility, blast radius, and correlation with other teams’ work. Decisions that are reversible and locally contained can be delegated outright; decisions with high blast radius, irreversibility, or cross-team correlation need an explicit escalation path or a standing review, stated in advance as a boundary rather than discovered later as a postmortem.
Step 5 — Redesign funding cadence to match decision cadence.
Where Step 4 delegates a decision, funding access for that decision must move on the same cadence — the AO translation of Deere’s shift from annual spend roll-ups to monthly visibility. A team with delegated roadmap authority but annual, centrally gated funding has decision rights without the resource authority to use them, which is a common way a “product team” quietly reverts to project behavior within two quarters.
Step 6 — Build the demand-to-outcome trace as a standing artifact, not a one-time map.
GSK’s and Deere’s strongest evidence — customer journey maps that exposed roadmap gaps, value-stream maps organized around customer personas — has to be maintained, not produced once for a transformation announcement. AO treats this as a Sense–Pattern–Adapt–Reflect–Structure–Sustain cycle: sense demand signals, find the pattern across them, adapt the backlog, reflect on what shipped against what was expected, adjust the structure if the pattern recurs, and sustain the loop as a standing practice.
Step 7 — Test continuity before declaring success.
Run the shift, then deliberately test whether it survives removing its original sponsor: what happens to the product team’s funding authority, decision rights, and roadmap ownership if the executive who championed the change leaves, is reassigned, or loses interest? If the answer is “it reverts,” the organization has changed its language, not its operating model — the exact fragility this article flags in SAP’s case. A shift that depends on one sponsor’s continued attention is not yet a redesign; it is a temporary configuration wearing the vocabulary of one.
Run end to end, this sequence produces the same kind of falsifiable evidence this article demanded of GSK, Deere, and SAP — but generated from the inside, before the claim of product-centricity is made publicly, rather than reconstructed afterward from press coverage and retrospectives.
Diagnostic Checklist: Is This Team Actually Product-Centric?
This table condenses the seven-step sequence into a checklist an internal diagnostic can run directly, mapped back to the pillar it tests and the evidence-based question it answers.
| # | AO Diagnostic Step | Pillar Tested | Key Question | Evidence That Would Satisfy It |
| 1 | Name the object of change | All three | Is the sponsor asking for new titles, or new decision rights? | A named decision that will move to a different owner or cadence — not just a new org chart |
| 2 | Five-dimension baseline (Deliver, Demand, Capacity, Capability, Organisation) | All three | Where does prioritized work originate, and does structure match real decision flow? | Sourceable evidence per dimension, dated and attributable — not self-assessment scores |
| 3 | Internal-start-up test per team | Persistent ownership | Does the team hold decision rights, a value case, bounded autonomy, cheap-failure tolerance, and outcome accountability? | Team passes at least four of five conditions with named evidence, not aspiration |
| 4 | Autonomy calibration by consequence | Funding & incentive logic | Which decisions can the team make alone, and which require escalation? | A written envelope stating reversibility/blast-radius thresholds, agreed before the first exception arises |
| 5 | Funding cadence matched to decision cadence | Funding & incentive logic | Can the team access budget on the same cadence it can make decisions? | Funding review cadence documented alongside decision cadence — not annual budget vs. continuous roadmap authority |
| 6 | Standing demand-to-outcome trace | Demand-to-outcome traceability | Is the customer/business-outcome trace a maintained loop or a one-time transformation artifact? | A running Sense–Pattern–Adapt–Reflect–Structure–Sustain cycle with a visible last-updated date |
| 7 | Continuity test against sponsor departure | Persistent ownership | Would the model survive the departure of the executive who championed it? | Decision rights and funding authority assigned to a role, not a person, and tested by at least one real handover |
A “yes, with named evidence” on all seven rows is the internal equivalent of what this article could only test from the outside for GSK and Deere using public sources. A “no” or “unclear” on rows 4 through 7 in particular is the specific pattern this article identifies in SAP’s public record — a structure that has changed its names before its decision rights.
Want the full report, or the next one?
Download this article as a formatted PDF, or subscribe to get future AO Method research directly in your inbox.
↓ Download the PDF Subscribe to the newsletterReferences
- Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press. flowframework.org/ffc-project-to-product-book; projecttoproduct.org
- Skelton, Matthew, and Manuel Pais. Team Topologies: Organizing Business and Technology Teams for Fast Flow. teamtopologies.com/book
- GSK Tech. “Transforming from a Project to Product-Centric Organization.” Medium. medium.com/gsktech/transforming-from-a-project-to-product-centric-organization-b9af4b58148e
- Scrum Inc. “Agile Unleashed at Scale” (John Deere case study). scruminc.com/agile-unleashed-at-scale
- TBM Council. “How TBM & Product Costing Helped John Deere Accelerate Their Agile Transformation.” tbmcouncil.org/case-studies/how-tbm-product-costing-helped-john-deere-accelerate-their-agile-transformation
- SAPinsider. “SAP Makes Significant Management Changes and Splits Product Engineering Organization.” June 30, 2026. sapinsider.org/sap-makes-significant-management-changes-and-splits-product-engineering-organization
- Bloomberg. “SAP Gives AI Product Oversight to CEO and COO in Reshuffle.” June 30, 2026. bloomberg.com/news/articles/2026-06-30/sap-distributes-ai-product-oversight-to-ceo-coo-in-reshuffle
- ad-hoc-news. “SAP Chief Executive Christian Klein Steps In to Direct Product Overhaul.” June 30, 2026. ad-hoc-news.de/…/sap-chief-executive-christian-klein-steps-in-to-direct-product-overhaul-as/69661624
- Hagiu, Andrei. “Multi-Sided Platforms: From Microfoundations to Design and Expansion.” Harvard Business School Working Paper 07-094. hbs.edu/ris/Publication Files/07-094.pdf — background reference on platform logic, cited for context distinguishing platform strategy from internal product operating model.
© 2026 Menschgeist — Pierre Neis. Evidence-bound analysis prepared using publicly available sources. Not a client-commissioned assessment.
Discover more from Menschgeist
Subscribe to get the latest posts sent to your email.