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