Product Innovation

I’ve addressed the Product Innovation topic numerous times in the BLOG, and much of the referenced literature concerns Product Innovation. Having worked with various organizations, and joined various network discussions, my aim is here to share my (subjective) understanding of where we in Europe should be in terms of Product Innovation, and what we’re struggling with, in getting there.

Some context

Even the best high-tech Product Companies have to step up their game.

Who would have imagined that the indisputable king of searches, Google, would face real competition? Enters ChatGPT and other Language Models with ground-breaking ways to search information, making the good old Google search look like some relic from the past.

Look at the automotive industry. Until very recently, the European automotive flagship was indisputably found in Germany with VW, Mercedes, Porsche, and Audi. Not so long ago, you would find these quality brands dominating the streets in China. Not anymore. The Chinese automotive industry has shown an impressing pace of innovation, leaving the Europeans on the roadside. Now the Chinese are driving in locally designed EVs. And – Chinese EVs like BYD, Polestar, Aiways, Nio, Xpeng, Maxus, and Hongqi –  just to mention a few – are entering the European roads.

Look at the financial sector. The traditional brick-and-mortar banks have been in a safe haven with literally no competition. Cryptocurrency, online banking, and now solutions like Stripe and Lunar. That haven is not that safe anymore.

What is happening? With the worn-out term, disruption is what is happening. If you do not relentlessly keep innovating your products and the way you do it, you’ll get overtaken.

The goal, Product Innovation, is the same, but the means are very different

The BLOG and the literature section make no secret out of the fact, that I’m highly inspired by a few thought-leaders on Product Innovation, like Marty Cagan, Teresa Torres, Matthew Skelton, Melissa Perri, Christina Wodtke, Katherine Radeka, and others. Furthermore, numerous strong product companies exist, such as Netflix, Amazon, Apple, Tesla, and Google.

What are these thought-leaders guiding us towards, what makes these product companies so successful, and how is this similar or different from what is found in Europe?

I’ll throw in my two cents.

Before moving on, let’s be clear on the fundamental difference between a Project and a Product (not wanting to start a big dogmatic discussion)


    • Has a start date and an end date
    • Serves the specific customer, asking for / sponsoring the Project


    • Continuous Discovery, Development, and Delivery
    • Serves a multitude of customers / users

Though being fundamentally different, the two can and will often share some toolboxes and techniques. In the Stone Age, you would characterize a Project by the “Iron Triangle” (scope-cost-time) under the assumption that requirements/scope could be agreed upon and fixed up-front. 

Realizing that often not being realistic, the notion of “Agile Projects” has entered the scene. You would still fix costs and time now having the flexibility in scope. It is still having the characteristics of a Project, not a Product.

It is fair to say, especially if you’re a start-up, that your Product typically starts with a Project in your quest for product-market fit. 

In this article, the focus will be on the Product, not the Project.

Spoiler: Product Innovation is not about being excellent with some “Agile Framework”. In the best case, these are helpful means in the toolbox, but not what drives Innovation. In the worst case, this Framework fixation distracts the organization from working with the real impediments, preventing effective Innovation.

The biggest missing value statement in the Agile Manifesto is:

Successful outcomes over efficient deliveryJeff Patton

Achieving Product Innovation

The world’s top product-led companies

The key is highly empowered, loosely coupled, and highly aligned product teams

    • provided with a strategic context (Product Vision, Product Strategy, Technology Strategy)
    • with high-frequent customer interaction and hypothesis tests
    • being measured on, and held accountable for outcome for solutions to (hard) business/customer problems


We believe the key is about having the right (Innovation-) processes, and the more “process-mature” we are, the better.

When we fail to innovate, we blame the processes – not by reducing the complexity and process volume – but by adding even more rigid process prescriptions, governance bodies, controllers, checklists, and KPIs in a quest towards predictable output (Features to build).

We love

    • CMMI
    • PMI
    • PRINCE2©
    • SAFe©
    • Six Sigma

The strategic context provided to product teams

The Strategic Context (Product Vision, Product Strategy, Technology Strategy, and high-level architecture) gives the product teams meaning, direction, and focus. In addition, it helps define a topology of loosely coupled, yet highly aligned product teams.

Product Vision: Being a subset of the full Company Vision, it provides the big WHY and common North Star for the product organization to navigate towards.

If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.

Antoine de Saint-Exupéry

Product Strategy: The overall plan for which customer/business problems should be solved by the product teams in which sequence → Focus, as highlighted by Christina Wodtke on OKRs, is fundamentally important for success

I believe the one thing that makes the difference between excelling and flailing about in mediocrity is focus.

OKRs are a framework for creating and ensuring focus on what really matters, but they don’t work if you stuff them full of every single business-as-usual initiative you have going.

Christina Wodtke, RADICAL FOCUS second edition p. 134

Technology Strategy and high-level architecture: This is e.g., about ensuring the company has an architecture capable of delivering the functionality, scalability, reliability, security, and performance it needs to compete and thrive. The architecture caters to a Team Topology with loosely coupled yet highly aligned product teams.

Encapsulated / loosely coupled teams are one of the prerequisites for real Business Agility. Jeff Bezos has made no secret out of that, concerning what encapsulation and decoupling mean in software:

1) All teams will henceforth expose their data and functionality through service interfaces.

2) Teams must communicate with each other through these interfaces.

3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

4) It doesn’t matter what technology is used. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.

5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

6) Anyone who doesn’t do this will be fired.

Internal mail in Amazon from Jeff Bezos

Fast-paced Innovation

Pace of innovation is all that matters in the long run

Elon Musk @Twitter, Apr 2020

Firstly and fundamentally, your organization needs Technology Excellence in your field of operation. Without it, you’re irrelevant. I’m here assuming that to be the case, including the existence of a strong Technology strategy. It is like the foundation of a high-rise building. Having that assumption in place, what else do we need in our quest for high-paced Innovation?

This article suggests an answer, centered around the illustration below, assuming a multidisciplinary product. 

Fast-paced innovation

In another article, I’m complementing the above with what I’ve coined Innovation Power:

Business agility

How to strengthen your Product / Innovation Culture

A strong product culture means that the team understands the importance of continuous and rapid testing and learning. They (ed.: the product organization) understand that they need to make mistakes in order to learn, but they need to make them quickly and mitigate the risks. They understand the need for continuous innovation. They know that great products are the results of true collaboration. They respect and value their designers and engineers. They understand the power of a motivated product team. 

Marty Cagan, INSPIRED p. 82-83

Clearly communicate that innovation is not something reserved for specially selected people in an “innovation lab”. In a truly innovative product culture, the best ideas often come from unexpected places. Invite for and encourage to contribute to the innovation process. Crowdsource innovation in your organization.

How to strengthen your Organizational Structure

It does not make sense to hire smart people and tell them what to do. We hire smart people to tell us what to do.

Steve Jobs

Remember my attempt above to differentiate between Project and Product

Not like this

The Old days

Your (Project-) Teams are disconnected from your customers via a multi-layer proxy.

More like this

Modern Times

Your (Product-) Teams have been moved closer, much closer, to your customers.

In this Just Product 2023 talk, Sebastian Borggrewe provides an easy-to-grasp illustration of why you need to treat your Product as a Product; not as a Project container:

How to improve your Servant Leadership practices

General Patton

Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.

General, George S. Patton

Lead with context, not control!

Leslie Kilgore, NETFLIX @ Twitter

Good leaders focus on culture and purpose because culture drives innivation and performance. The greatest capital of an organization is its people. To innovate, people need autonomy and meaning.Marty Cagan, EMPOWERED p. 372

First and foremost – unlearn the hierarchical “command & control” way of leading, substituting it with “leading by context“. Core elements in this context are the Product Vision, Product Strategy, and Technology Strategy. It is from this context, that the product teams are tasked with (hard) customer/business problems for which to discover the best solution.

Give room, let the team shine, control your ego, show trust, and most important of all – show through your actions that you embrace the Product Culture.

Pave the way for the teams to function at an optimal level. Sometimes a small stone for you is a major blocker for the team.

Minimum Viable Governance & VC-style funding

Innovation is only expensive if you use traditional business planning to make investment decisions. Innovation, when done right, is about making small bets, testing ideas cheaply and quickly to identify the winners in which you then invest more resources

Tendayi Viki, Pirates In The Navy: How Innovators Lead Transformation

Run an experiment. Allocate a chunk of the development budget for later allocation via an internal VC forum. Start small and learn before you scale up.

Be very critical with large investment programs / Big Bets. Their size in themselves poses a significant risk. Make sure that these monoliths are in fact what serves you best.

Tell your CFO nicely that his need for control (which in fact is not control, because it is impossible to forecast the correct budget distribution one year ahead) is secondary to our ability to do the right things in our quest to serve our customers.

Minimum Viable Process Prescription and a rich pick & use Buffet

I don’t believe in process. In fact, when I interview a potential employee and he or she says that ‘it’s all about the process,’ I see that as a bad sign. The problem is that at a lot of big companies, process becomes a substitute for thinking. You’re encouraged to behave like a little gear in a complex machine. Frankly, it allows you to keep people who aren’t that smart, who aren’t that creative.

Elon Musk

Fundamentally, as organizations grow, there are two main ways today that organizations attempt to scale.

One is by scaling their leaders (the managers). The other is by scaling their process.

Marty Cagan

Start by asking yourself the very basic question: “Do you trust the judgment of your employees and their professionalism enough to let them decide on solutions to problems without you policing them?”

If YES – show it!

If NO – challenge yourself. Are you hit by a process disease being a way indirectly to control your employees?

Finally, ask yourself: “Despite Amazon & Tesla being digital natives, what prevents you from turning down the volume on your process obsession and moving in the direction of Amazon and Tesla?”

Not all processes are evil. Some are highly needed and valuable. The delicate challenge is to strike the right balance between Process Prescription and a rich pick & use Buffet.

Technology excellence

Cut to the bone, technology is the product! 

Solid engineering practices and deep technology expertise are of course a must during both Discovery, Development, and Delivery.

One thing that can kill your business agility is poor engineering practices resulting in, e.g., global dependencies. No matter the engineering domain, your engineers must follow the lead from software development, ensuring decoupling via encapsulation behind stable interfaces – not to forget the fundamentally important Configuration Management discipline as mentioned above.


We, in Europe, love CMMI, PRINCE2©, PMI, SAFe© (yes – we believe that “A” stands for “Agile”), big home-grown prescriptive project models, PLM models, governance bodies, checklists, and PMOs / process excellence offices. When we fail to innovate, we blame the processes, not by reducing complexity, but by adding further complexity, more controllers (paper-pushers), and more rigid checklists. After all, your top guys are impatient and want to feel in control, pushing you towards even more process fixation – unfortunately moving you further away from where you should be focusing.

Boiled down to its essence, we can achieve more in Europe by learning from the best: 

    • Stronger context, less control
    • More empowerment, less process prescription – though a versatile toolbox facilitating knowledge sharing is highly valuable

Yes, this can seem far-fetched and scary if you’re currently caught in your (own) process web, maybe even with a burning platform. You need fundamentally to free yourself from the gravitational field of process fixation, towards a Product Operating Model

Taking the first steps

First and foremost, you need to 

    • Scale down on the bureaucracy/process fixation that prevents your product teams from focusing on the single most important topic: discovering solutions to your customer’s problems, balancing the core risks, being
      • the solution is Valuable for your customers
      • the solution is Useable for your customers
      • the solution is Feasible for us to build, maintain, and produce (in case of a physical product)
      • the solution is Viable for our business
    • Leverage the bureaucracy/process fixation with a strong context within which your product teams will thrive
      • A clear North Star / Product Vision for all the Product Teams to navigate 
      • A Strong Product Strategy, giving direction as to what customer/business problems the product teams should discover solutions to, thus facilitating the fundamentally important focus
      • A strong and modular architecture, facilitating loosely coupled teams

If you’re currently driven by measuring Output/Features (like with Scrum burn-down charts) from teams, try this litmus test: Are you able to agree on the WHAT to be delivered by the teams (leaving the HOW-to Discovery to the teams)? 

YES: At least it seems that you have something going for you, being able to cater to basic agreement management. Don’t stop here. Work on the above context, aiming for having Problems to solve in your team’s backlogs, not Features to build.

NO: You’ll probably need to work on your agreement management practices, as a minimum, getting things under control. Sorry – you have a long way to go.

If you’re currently driven by measuring Outcomes (like with OKRs) from teams, try this litmus test: Firstly, congratulations – you’re already well underway freeing Innovation talent. Do you know what now is most important for your product teams to focus on, and do you make tough choices on what is important? 

YES: Great – continue sharpening the saw.

NO: With the words of Christina Wodtke “… one thing that makes the difference between excelling and flailing about in mediocrity is focus.” You need to work on your Product Strategy because it seems that it does not help you enough to understand what is important now.

Ready for some more inspirational background?

Steve Jobs – The Lost Interview

Marty Cagan – Common Transformation Pitfalls