Robotics Is Not About Robots

Co-authored by Oana Olteanu of Motive Force

 

Henry Ford’s Rouge, source

A robot running at 95% accuracy sounds impressive. In a factory running fifty cycles an hour, that means fifty failures every shift. Each one requires a human to intervene, log the incident, reset the system, and decide what happens next. The robot is working. The deployment isn't.

This is the gap that ends most robotics companies. Not the hardware. Not the vision model. Not the manipulation benchmark. The system around the robot.

We have been spending time with founders and engineers working in physical AI, and the same failure mode keeps surfacing. The robotics conversation is almost entirely about the machine: better models, better form factors, better demos. The deployment conversation barely exists. And almost nothing in the stack was built for what comes after the demo.

Physical AI is not a robot problem. It's a skills, workflows, and learning system problem.

The hierarchy nobody draws

At its core, a robot is just an embodiment: joints, sensors, actuators. The real abstraction sits above the machine.

Physical work can be structured as a hierarchy: scenarios decompose into skills, skills into tasks, tasks into trajectories. This defines how complex industrial processes become machine-executable actions. It is also, not coincidentally, how enterprise software has always modeled work. The systems we worked on at SAP were built on exactly this kind of decomposition. What's different now is that AI can learn the levels of this hierarchy, not just execute against a fixed specification.

The primary challenge is therefore not the robot. It's the toolchain that lets robots learn, operate, and improve: simulation environments, workflow models, perception and planning stacks, data pipelines, the software that converts human demonstrations into reusable skills. This is the infrastructure that lets automation move beyond isolated machines toward scalable systems.

Hardware is a data acquisition device

Here is the reframe that matters for thinking about where value accumulates.

Robots increasingly function as data acquisition devices. Each deployment generates operational telemetry and demonstrations that feed back into learning systems. Over time, those feedback loops produce skill libraries, workflow abstractions, and training datasets that let automation capabilities transfer across tasks, sites, and embodiments.

This is why many of the most interesting robotics founders are not primarily designing new machines. They are building learning systems that combine simulation, real-world telemetry, and human motion data to continuously improve performance across fleets. The compounding advantage is in the accumulation of operational data and the ability to convert it into reusable automation capabilities.

One idea we keep coming back to from several conversations: the intelligence doesn't have to live inside the robot. One architecture inverts the assumption entirely: the brains are in the environment, and the robot is just a tool the physical model uses to act on the world. That inversion changes the cost structure, the upgrade path, and the distribution model. It also makes the robot itself much cheaper, which is the actual bottleneck for adoption in most markets.

The deployment gap is real, and it's not about the model

The pattern is consistent: great demos, almost no real deployments. And when companies do deploy, they hit a different set of problems than they expected.

Integration with existing operations. Financing and asset lifecycle. Service networks. Change management. Human workflow alignment. These are not engineering problems. They are adoption problems, and almost nothing in the robotics stack was built to solve them.

The deployment stack is where most robotics companies die: not on the benchmark, but on the installation. Nobody can plug the robot into the existing ticketing system. Nobody has figured out how to triage a failure at 2 am. The operator doesn't know when to trust it and when to override. And the vendor who sold the hardware has no infrastructure to help.

This is the tank problem. Germany built the most complex and complicated tanks in the second world war but lacked scale everywhere. The Soviet Army built the most tanks of all, but they were designed as disposable items. The United States built simpler tanks at scale with a massive supply chain and service network.

Robotics is still in the beautiful tank era. The market winners will build the whole logistics network.

Berlin, summer 2024. Research.

The agent runtime is the missing layer

There is something happening in the software stack that will define which robotics companies matter in the next few years, and it is barely being discussed.

The architecture of a capable physical AI system is, at its core, two things: the model and the agent runtime. The models are getting better and everyone is paying attention to that. The agent runtimes are almost invisible in the conversation, and yet the performance of the whole system is insanely dependent on them.

An agent runtime for physical AI has to do things that software has never had to do before. Operate continuously, not just on demand. Manage asynchronous input from the physical world. Reason about state across long time horizons. Coordinate between multiple agents pursuing different objectives in the same physical space. Log decisions in a way that's legible to humans who need to understand what happened and why.

This is not a solved problem. What most people are building today are either model wrappers or task-specific automation. Neither is infrastructure for continuous physical operation. Neither was designed for a world where the agent is running, the robot is acting, and a human somewhere needs to understand and trust all of it.

The companies building the agent runtime layer for physical AI don't have a clean category name yet. That's usually the right sign.

Where value actually accrues

Selling a robot is a capex transaction. Scaling automation requires owning the workflow layer: the point where robotic skills integrate with customer operations, business processes, and human workflows.

That layer determines adoption. It determines utilization. It determines whether a company accumulates the operational data that makes the next deployment better than the last one. And it determines whether, when a customer's processes change, the automation changes with them or breaks.

The companies that define this market won't necessarily be those that build the most sophisticated machines. They will be those that develop the most effective learning and workflow systems around machines. The robot is the vessel. The system is the product.

What we’re looking for

The category map writes itself. Simulation and training infrastructure. Workflow modeling tools. Agent runtimes for continuous physical operation. Incident management and operational orchestration. Context layers for physical assets. End-to-end deployment platforms that treat automation as a service, not a product.

None of these require building the robot. All of them are more defensible than the robot.

We’re looking for founders who see physical AI as a systems problem, not a hardware problem. Who understand workflows and operations, not just models and sensors. Who think in hierarchies: what is the scenario, what are the skills, what are the tasks, what are the trajectories, and how does learning flow back up through all of them.

If you're building in this layer, or working in physical environments where you've felt the deployment gap firsthand, we’d genuinely like to talk. 

—--

About Motive Force: We back technical founders at the idea stage, before the category has a name. If that's you, reach out.

About Christian Dahlen: angel investor with investments in robotics and industrial software and a Ph. D. in engineering. Select investments include Wandelbots, deltia.ai, and SDA.

What I look for in robotics founders

I have met with dozens if not hundreds of robotics startups who want to build for industrial operations.

This is what I look for in the founding teams:

• Factory native founders who understand real operations.
  People who have lived uptime, OEE, and production pressure, not just built robots in labs.
  
  
  
• Founders who are deployment-obsessed, focused on install time, integration with PLC/MES systems, safety, and reliability.
  Not demos or model benchmarks.
  
  
  
• Founders think in workflows, not robots.
  They define the manual process, redesign it for automation, and treat the robot as just one component in a broader system.
  
  
  
• Founders who can clearly articulate ROI.
  Cost per hour, payback period, uptime assumptions, and why this beats human labor or existing automation.
  
  
  
• Founders with a strong bias for simplicity.
  Deliberately reducing complexity, constraining environments, and standardizing tasks to make systems reliable and scalable.
  
  
  
• Hybrid teams combining software/data capability, industrial experience, and hands-on deployment experience.
  Not just pure roboticists.
  
  
  
• Founders who think in fleets and learning loops, understanding that value compounds through data, iteration, and scaling across many deployments.
  
  

👉 Bottom line: 

• Founders building industrial-grade systems that deploy, work, and scale.
  Not impressive robots.

Factory to robotics startup: Forget the humanoid; build the System.

A recent article in the Wall Street Journal about Agility humanoids at Schaeffler ("When Humanoid Robots Come to a Small-Town Factory") and a Techcrunch interview with Rivian's R J Scaringe ("... we're doing robots all wrong") provided interesting insights into the state of the so called humanoids in factory environments today.   

Industrial environments are the ideal testing grounds for robotics because they are predictable and well-bounded. Early deployments are already happening at entry points such as material handling and logistics where dexterous manipulation is not required.

For these use cases, the economics of robotic labor are closing in on human labor costs.

What works today is simple, constrained, and supervised. What is not working is trying to solve everything at once and over-engineered, complex systems aren't scaling. The bottleneck isn't the AI, it's everything around it. Safety in human-shared environments, integration efforts, and day-to-day reliability are gating adoption. 

The hardest problem, dexterous manipulation, remains largely unsolved, and the most capable-looking robots are often the least deployable ones.

The solution is a better system and not a better robot. The winners own the workflows, the deployment infrastructure, and the manipulation layer that ties hardware and software to real operations. Semi-humanoid and non-humanoid form factors that fit cleanly into existing industrial environments will outperform impressive general purpose machines that can't clear the integration bar. As uptime improves and costs continue to decline, what looks today like augmentation will segue into substitution.

The transition will be won by industrial-grade systems built for operations, not by the most compelling demo. 

The Industrialization of Low Earth Orbit: Beyond Collision Avoidance

When SpaceX unveiled its Stargaze Space Situational Awareness (SSA) system last month, the positioning was largely as a collision avoidance feature. However, the architectural implications point to a more profound shift from passive tracking to active Space Traffic Management (STM).

Credit: SpaceX

As mega-constellations scale toward tens of thousands of assets, the "manual" era of satellite operations has reached its functional limit. The industry is now moving toward automated governance, characterized by two critical requirements:

👉 Autonomy at Scale: With hundreds of thousands of collision avoidance maneuvers already occurring annually, operators can no longer rely on human-in-the-loop systems. The future belongs to automated conjunction analysis and predictive orbit modeling.

👉 Data Aggregation over silos: Reliable threat identification and maneuver detection require a unified "single source of truth." Orbital intelligence can no longer exist in proprietary silos if we are to mitigate systemic risk.

Stargaze is the first evidence of this new reality at scale: a move toward a sophisticated, automated architecture for the orbital commons.

How a board should govern innovation it cannot predict (6/6)

Supervisory boards are designed to control risk, ensure accountability, and protect long term value. That logic works well for established businesses whose performance can be forecast and audited, the typical public company or private equity owned shop. 

Transformation initiatives are different. Their outcomes cannot be predicted, only managed probabilistically. 

When both activities are governed identically, boards unintentionally force management to either hide uncertainty or avoid it. Core governance expects reliable plans, budget adherence, and variance explanations. Venture activity produces evolving plans, changing strategy, and learning instead of predictability. So management adapts and presents exploration as execution which leads to late surprises, sudden write-offs, loss of trust. 

A board should never approve innovation projects. They cannot evaluate uncertain outcomes. Instead, they can evaluate whether uncertainty is being reduced responsibly and should ensure capital exposure is bounded, learning velocity is high, and escalation rules are clear. 

A board should only oversee three things:

1. Portfolio exposure
   How much capital is at risk simultaneously
   
   
2. Funding discipline
   Continuation only after evidence
   
   
3. Separation of logic
   Exploration metrics that are not mixed with operational KPIs
   
   

Board should never ever select ideas, approve technical directions, demand detailed forecasts, integrate ventures prematurely. These actions destroy optionality. 

But when governed correctly, downside is limited, upside remains uncapped, and management credibility increases. Transformation becomes auditable without becoming a foregone conclusion. 

No industrial company fails to transform because they lack ideas, talent, or technology. 

They fail because they apply operational governance to exploratory activities. 

Once the board governs uncertainty instead of trying to eliminate it, transformation stops being a gamble and becomes a managed asset class. 

Why industrial startups don't scale like software, and why that matters for corporate strategy (5/6)

Over the last decade, industrial companies have tried to adopt startup methods like agile teams, MVPs, incubator and venture units with the expectation that small teams could rapidly build scalable businesses, just like in software. Yet most industrial digital initiatives plateaued in the same place where successful pilots never became large businesses. The explanation is usually organizational. But the pattern is too consistent to be cultural. 

In SaaS, the sequence was to build product, find users, scale distribution and optimize economics. In industrial systems the sequence is to prove technical reliability in reality, integrate into operations, earn organization trust, and scale commercially. Applying the former to the latter leads to the stereotypical "pilot purgatory', and the product market fit only comes later. 

The Lean Startup thinking has popularized the concept of a minimum viable product. And in fact, the advent of LLMs, vibe coding and agents have made building software MVPs easier than ever. But an industrial MVP still requires safety acceptance, workflow integration, downtime risk, and operator trust. Learning cycles are constrained by operations, not coding speed and the experimentation bandwidth massively narrows. As opposed to software which scales with distribution, industrial solutions scale with deployment capacity from integrators, commissioning, change management, training, and liability acceptance.
Therefore growth is stepwise, not exponential.

Because risk reduces differently in industrial systems, stage gates must evaluate different evidence. Early stages must mitigate technical and operational risk, later stages market and commercial risk. 

Industrial transformation will not be driven by apps on top of factories. It will instead be driven by systems that cross the boundary between software and operations. And the highest value companies in the next industrial cycle will control operational feedback loops, not dashboards. 

Next article (6/6)

Board governance for industrial transformation - managing two business models inside one company.

How to run a corporate venture portfolio without becoming a venture capital firm (4/6)

Operational companies run on annual planning cycles. 

Venture building runs on learning cycles. 

Trying to manage the second with the first results in one of two predictable outcomes. Either the initiatives are frozen by planning, or they run outside governance entirely. 

The solution does not lie in creating a new department, but in implementing a different decision cadence that funds increasingly expensive questions

1. Technical feasibility
   
   
2. Real customer usage (-> viability)
   
   
3. Repeatable deployment (-> product market fit)
   
   
4. Scalable economics

Funding should not be a commitment to success belief, but a purchase of evidence. Capital should only be provided when uncertainty decreases. 

Most companies have steering committees, project reviews, and budget committees to evaluation progress against plan. In contrast, a venture forum evaluates risk versus evidence and is characterized as follows

• Frequent meetings (6-10 weeks)
  
  
• Very small group 
  
  
• Authority to stop initiatives
  
  
• No project ownership
  
  
• Compares initiatives against each other
  
  

This forum manages allocations, not execution. It is making kill decisions based on transparent stop conditions: 

• No repeatable customer usage
  
  
• No technical feasibility
  
  
• No economic faith
  

Because the conditions are agreed beforehand, stopping is not political. And the organization can celebrate disciplined termination more than heroic persistence. 

This requires a clear delineation of roles and responsibilities. Leadership controls the funding continuation, the strategic direction, and the portfolio size. The teams control the solution, the iterations and the learning speed. Corporate burden is reduced and outcomes are improved. 

The role of the executive changes from approving projects to continuously reallocating capital. 


All of this may sound like software venture building, but industrial initiatives behave differently:

• hardware dependencies
  
  
• pilot purgatory
  
  
• deployment friction
  
  
• long validation cycles
  
  

and so the operating model must adapt. 


Next article (5/6)

Why industrial ventures are structurally different from software - and why most corporate playbooks fail here 

Innovation culture doesn't exist - governance and incentives do (3/6)

When industrial innovation initiatives stall, the diagnosis is almost always cultural: risk aversion, silo thinking, lack of entrepreneurial mindset. 

This diagnosis is not wrong, and companies respond predictably by launching training programs, incubators, intrapreneurships, innovation days et cetera et cetera et cetera. And yet the same patterns reappear where promising initiatives expand too early, weak ones linger, and transformational ones rarely scale.

If behavior does not change after repeated cultural interventions, the cause is probably structural rather than psychological. Managers optimize for what is rewarded - approval, budget adherence, and avoiding visible failure - and thus produce optimistic forecasts, broad roadmaps and incremental proof. Clearly this is rational behavior, and the organization punishes the alternative. 

This governance creates a doom loop: An upfront business case plan is created with massive amounts of detail and the team commitments to such plan. But then the evidence contradicts the plan and the team is forced to defend rather than adapt. The funding continues to protect prior decisions, and terminations happen late and are expensive. It is the ultimate irony that nobody chose this insane path, but the governance enforced it. 

There is a better way. Instead of asking people to think like entrepreneurs, the corporation should adopt a system with three mechanisms which reward and entrepreneurial behavior:  

1. Mile stone funding focused on progress
   
   
2. Predefined kill criteria that make stopping a successful outcome
   
   
3. An independent decision forum to separate continuation decisions from project sponsors
   

An organization will always behave rationally within the rules it is given.
The leaderships job is not selecting ideas, it is designing decision environments.

Most companies understand they need a portfolio logic, but few understand how to operationalize it without losing control. 


Next article (4/6)

How to actually run a corporate venture portfolio

Every industrial company already runs a venture fund - just without the rules (2/6)

If innovation outcomes cannot be predicted upfront, funding decisions have to stop being project approvals and become probabilistic bets. At that moment, the management domain changes from operational planning to portfolio allocations. 

Yet most companies never acknowledge the transition. They still ask each initiative to justify itself individually, even though statistically only a minority of ventures will succeed. In this obviously paradoxical world, they demand certainty from activities whose economics are defined by uncertainty. 

In an industrial world, machines are expected to perform as planned. Variation is noise. Deviation is undesirable. Contrast that with new technology ventures where most create little to no value, and only very few lead to disproportionate outcomes. And if returns concentrate in very few successes, evaluating initiatives individually guarantees systematic underinvestment in winners and overinvestment in mediocrity. 

Projects are being evaluated by expected ROI, NPV and payback periods. Those metrics are appropriate when variance is small. But with high uncertainty, the expected value does not equal the average outcome and managers unintentionally end up favoring safe outcomes, resulting in incremental projects being passed and transformational ones being failed. 

Funding innovation outcomes requires a mental shift from funding initiatives to funding learning paths where capital is released to answer progressively expensive questions: 

1. Is it technically possible? 
   
   
2. Does anyone need it? 
   
   
3. Will they pay? 
   
   
4. Can it scale? 
   
   

Because success is concentrated, funding decision must compare options, not plans. Persistence without evidence of progress and customer traction destroys returns, killing projects early increases returns. The purpose of an innovation portfolio is not to avoid failure, but to make failure cheap enough so that success becomes more likely. 

Once innovation behaves like a portfolio, the organization needs new rules: 

• Who decides continuation? 
  
  
• When is stopping success? 
  
  
• How independent can the teams be? 
  
  
• What replaces annual budgets?

Those questions are governance questions, not innovation questions.


Next article (3/6)

Why culture programs fail and governance determines behaviors
 

Digital initiatives don’t fail — capital allocation does (1/6)

Industrial innovation companies have more innovation activity than ever - accelerators, labs, venture arms, partnerships - yet the economic impact remains marginal. Yet, years later, most executives struggle to point to measurable impact on growth or valuation. 

The usual explanations are cultural: risk aversion, legacy thinking, slow decision making. But those explanations don't survive scrutiny. The same organizations successfully execute billion dollar plant expansions and platform transitions. 

The real difference is more mundane: Industrial innovation inside corporations is financed like a product development program, economically is behaves like a venture investment. And it is this very mismatch that determines the outcome long before the technology reaches maturity. 


The vast majority of executives are being told they are running a portfolio, but in reality they are managing a bunch of projects and apply a project logic consisting of fixed budgets and predefined deliverables where success is measured against plan and deviations are branded as failures. Often corporate innovation projects are expected to prove they work even before funding.

Venture logic of staged capital, frequent pivots, and unknown outcomes is fundamentally different where success is measured by learning and termination is success if risk is removed. The ventures are funded to discover whether something works.

The symptoms are only to well known and are directly related to the lack of stage gates and kill criteria. Because companies require certainty upfront, business cases are inflated, teams optimize for approval and not truth, cancellations get pushed off, and scaling happens either too later or never. 

The most common questions I have encountered is "how do we make innovation succeed in my company?".

The better question would be "how should we govern investments with unknown outcomes"?

What Industrial Leaders Should Do Now About Humanoid Robots

In the recent interview Elon Musk gave on the Cheeky Pint + Dwarkesh podcast, he laid out the path forward for Tesla’s Optimus humanoid robot. 

That path also translates into five practical implications for industrial leaders who want to utilize humanoids

• First, map your 24/7 tasks.
  Humanoids will enter where operations are continuous, repetitive, and stable. Start where uptime matters and variability is low.
  
  

• Second, identify hand-complexity tasks.
  If a job requires dexterity but limited judgment, it is a prime candidate. Fine manipulation without deep contextual reasoning is the early sweet spot.
  
  

• Third, redesign future lines to be robot-friendly.
  Clearances, modular stations, standardized interfaces, digital twins. The factories that win will not retrofit blindly; they will architect for humanoid coexistence.
  
  

• Fourth, invest in simulation capability.
  Sim-to-real transfer is the gating constraint. Organizations that build internal simulation pipelines now will compress deployment cycles later.
  
  

• Fifth, secure exposure to critical components.
  Actuators, precision gears, motors, rare materials. Manufacturing scale — not AI demos — will determine who ramps first.

Points one, two, and three squarely fall into the hands of industrial leaders.
Point five is a selection criterion for their humanoid robotics providers.

The hardest problem for humanoids to be fully adopted is closing the sim-to-real gap and the scale required.

Musk was explicit about the magnitude of that challenge:

“For the robot, what we’re going to need to do is build a lot of robots and put them in a kind of Optimus Academy so they can do self-play in reality… We can have at least 10,000 Optimus robots, maybe 20–30,000, that are doing self-play and testing different tasks.”

Industrial leaders should ask themselves now: Which of our production systems are humanoid-ready - and which ones are structurally not?

Three challenges for robotics founders

Recently, Elon Musk gave a wide ranging interview in the Cheeky Pint + Dwarkesh podcast where they covered all activities Musk is involved is.

Musk gave a master class on how he is constantly addressing the limiting factor and allocating his time to it, and applied this thinking to identify three main challenges for humanoids: 

1. Real-world Intelligence

Robots must convert massive sensor input into reliable physical action. Teslas already compress gigabytes of perception into a few kilobytes of control, but robots face far higher degrees of freedom, far less data, and far less safe data collection. The bottleneck is building a repeatable learning look that closes the sim-to-real gap. 

2. Hand gripper

Dexterous interaction with the physical world requires actuators, sensing, power density, and controls that currently have no mature supply chain. This is a first-principles engineering problem, not a software abstraction layer. 

3. Manufacturing at scale

A working prototype proves feasibility, but it takes millions of unites to create a category. The constraints shift from AI capability to cost, reliability, and year. Most robotics companies still operated in R&D mode while describing mass markets. 


The first viable markets will not be general labor or households. They will be high utilization, continuous  and repetitive operations in environments designed around competition. 

Musk has a plethora of assets at his disposal which the typical startup founder doesn't. 

Founders in the robotics space need to be ruthless about prioritizing their use case and apply Musk's key principles of challenging all assumptions, deleting what is not necessary, avoiding overthinking and simplifying as much as possible while reasoning at the right risk level, accelerating using 50th percentile deadlines, and then automating to scale. 

Software Portfolio Playbook: How Industrial Companies Can Turn Digital Ambition into Scalable Businesses

For more than a decade, industrial companies have pursued the same ambition: to become serious software players. Some have made real progress. Many have not.

The pattern is clear: software outcomes are not primarily determined by technology choices. They are determined by portfolio governance—how decisions are made, how resources move, and where accountability sits.

 

The core mistake is treating software as a collection of initiatives. The companies that win treat software as a portfolio—a set of fundamentally different businesses, each requiring different operating models, metrics, and leadership attention. Because disruption does not replace the old business overnight; it forces enterprises to run multiple business logics simultaneously.

Why a portfolio playbook is now essential

The most useful starting point is the concept of technology lifecycle zones—popularized through several management frameworks (including BCG and Geoffrey Moore’s “Zone to Win”). The specifics differ, but the management implication is consistent: leaders must actively govern four distinct zones in parallel, each with its own mandate and success measures .

In practice, these zones typically include some version of

• Protect the core (where cash is generated)

• Manage the base business (where efficiency and resilience matter)

• Fuel growth to scale (where new software engines are built)

• Incubate future options (where learning and experimentation dominate)

This is not a semantic exercise. The purpose is to enable what industrial organizations often struggle to do: prioritize go-to-market resources and engineering capacity across competing demands .

Without an explicit portfolio view, resource allocation becomes path-dependent and political. With it, trade-offs become visible and executable.

The CEO’s job: make the big bet and arbitrate across zones

A credible portfolio playbook ultimately is a CEO responsibility. The CEO must place the big bet on the next growth engine—what “fuel growth to scale” means in that enterprise—and continually arbitrate between the zones as evidence evolves.

This arbitration cannot be delegated to the technology function alone. The center of gravity is not architectural, it is commercial. Software scale requires decisions about

• where to invest and where to stop

• which businesses merit priority access to distribution

• which initiatives are strategic, versus merely interesting

• how much risk the enterprise is willing to carry

The strongest operators institutionalize this discipline by having the CEO and CFO set funding envelopes annually across the zones and adjust them through a lightweight corporate system—rather than trying to “align” continuously through discussions that lack decision rights. 

Portfolio management rationale: turning strategy into execution

Portfolio management exists for one reason: to connect strategy to capital and accountability.
Every material investment is explicitly linked to a strategic initiative. This eliminates the common pattern of “digital projects” that are directionally plausible but strategically unowned.

A strong portfolio system delivers three outcomes

1. Align strategy and investments
   
   

2. Convert strategic objectives into execution
   Strategy becomes measurable actions. Leaders gain mechanisms to challenge, re-prioritize, and re-allocate.
   
   

3. Create transparency and discipline
   Category leaders are held accountable, and the portfolio view becomes visible across the organization, reducing the ability to hide behind narratives.

This requires managing across three horizons: a multi-year strategic view, an annual resource allocation cycle, and quarterly reviews. This sequencing matters. Multi-year direction without annual resource allocation becomes aspiration. Annual allocation without quarterly learning becomes rigidity.

What separates mature portfolio management from periodic planning is fact-based discipline. Funding decisions are tied to capability needs, competitor moves, and risk—not to organizational persuasion.

Decision rights: the missing operating system

Most portfolio systems fail because they are treated as a governance overlay. In reality, portfolio management is a decision system. Without explicit decision rights, it becomes performance theater.

A scalable portfolio model establishes three clear roles:

1) Corporate Portfolio Office

This is not a reporting team but an empowered function that can

• move resources between categories

• apply consistent planning processes

• enforce transparency across business units

The office is the institutional memory of the portfolio and prevents the common industrial pattern of “starting over” every cycle.

2) Executive Committee / CFO

This level must:

• arbitrate major reallocations

• set the funding envelopes

• ensure adherence to strategy

In practice, the CFO is often the pivotal actor, because portfolio discipline ultimately requires willingness to stop funding initiatives that have political support but weak evidence.

3) Category leaders

These leaders carry P&L responsibility and must deliver results within the allocation. They own the outcomes.

Critically, decision rights must operate at three levels

• Corporate level: align to strategy, balance risk/return, ensure coherence

• Category level: own performance, KPIs, and category health

• Business case level: validate assumptions, challenge resource use, monitor delivery

This multi-level structure matters because industrial software businesses often fail not at the strategy level, but at the point where execution assumptions—pricing, sales productivity, adoption dynamics—turn out to be wrong and no governance mechanism exists to correct course.

The anchor tool: a proprietary 2x2 matrix

Industrial groups often drown in complexity: dozens of products, overlapping roadmaps, and competing internal narratives. The portfolio needs an anchor.

The most effective tool is a proprietary 2x2 matrix based on market attractiveness versus relative strength, institutionalized as the backbone of investment decisions .

This matrix does not create insight by itself. It creates forcing function clarity:

• Where should we invest aggressively?

• Where should we harvest?

• Where should we fix underlying capabilities?

• Where should we exit?

The key is to make the matrix proprietary—not because the idea is novel, but because each industrial group must define “attractiveness” and “strength” in a way that reflects its economic realities: installed base leverage, channel access, data advantage, ecosystem power, and regulatory constraints.

Stop the “portfolio vs. non-portfolio” split

A surprisingly common failure mode is treating portfolio discipline as optional—applied to “strategic initiatives,” while other R&D runs independently.

The playbook is explicit: no split between “portfolio-relevant” and “non-portfolio” R&D. Everything must run through the same governance lens .

This isn’t control for control’s sake. It prevents the quiet accumulation of unowned products, orphaned prototypes, and “pet projects” that create complexity without compounding advantage.

Speed becomes structural: Agile, DevOps, and enabling architecture

Portfolio governance is not enough. Execution speed must be engineered into the operating system.

The best-practice baseline includes embedding Agile and DevOps as default delivery models, and enabling speed through microservices, cloud, low-code platforms, and AI where appropriate .
The point is not to chase the latest buzzwords. It is to ensure that the portfolio can reallocate resources without being trapped by monoliths, fragile release processes, and dependency lock-in. A portfolio that cannot shift capacity rapidly is not a portfolio. It is a collection of sunk costs.

Make learning travel across businesses

Industrial enterprises often behave like federations of disconnected companies. Portfolio management creates economic logic across them—but learning still tends to stay local.

The playbook demands explicit learning transfer: practices proven in one category must cascade to others. This can be:

• agile practices from a software unit into hardware-adjacent teams

• predictive maintenance capabilities moving from one business line to another

• repeatable sales plays scaling across regions

Cross-business learning is one of the few genuine scale advantages industrial groups can have. It rarely happens organically.

What to measure: portfolio health KPIs

Without the right metrics, portfolio management devolves into narrative competition. The playbook therefore defines portfolio health through a small, decision-oriented KPI set :

• Strategic alignment: % of spend linked to top priorities

• Balance: allocation across protect / fuel / manage / incubate

• Capital efficiency: return on invested capital by category

• Speed and agility: cycle time for reallocating resources

• Innovation vitality: % of revenue from products <3 years old

• Transparency: quality of reporting and visibility across units

These KPIs have a single purpose: enabling executives to act. They are not dashboards for dashboards’ sake. They support reallocation, exit decisions, and focus.

The industrial reality: multi-BU software fragmentation is normal

In most multi-BU industrial technology companies, software is present everywhere—and rarely coherent. The majority of software activity and acquisitions often sit within a single BU, sales is executed regionally with overlays, and only a subset of companies attempt cross-BU platforms .

This is not a failure of intent. It is a predictable outcome of vertical accountability. Portfolio governance is the mechanism that turns this fragmentation into manageable structure.

Some companies have taken clearer strategic steps, for example by committing to standalone software businesses (such as Schneider Electric with AVEVA) or establishing dedicated digital units (as in GE Vernova’s digital BU heritage) . The common thread is not the brand name; it is the willingness to assign real operating autonomy and P&L logic to software.

A final question CEOs and CFOs cannot avoid

Portfolio playbooks are ultimately designed to force one unavoidable leadership choice:

Should software amplify the core business—or become a core business?

There is no universal answer. But there is a universal cost to avoidance. Companies that do not decide remain trapped in a hybrid model where software carries the expectations of growth but inherits the constraints of hardware governance.

In an era where AI is accelerating competitive cycles and compressing differentiation, this becomes existential. The next phase of industrial software will not be defined by platforms, clouds, or algorithms. It will be defined by governance: decision rights, capital allocation, accountability, and operating autonomy.

Software does not scale because it is strategically important.

It scales when it is structurally enabled to win.