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)
Project
- Has a start date and an end date
- Serves the specific customer, asking for / sponsoring the Project
Product
- 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.
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
Europe
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.
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
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.
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:
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.
Fast-paced Innovation
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.
In another article, I’m complementing the above with what I’ve coined Innovation Power:
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.
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
Remember my attempt above to differentiate between Project and Product?
Not like this
Your (Project-) Teams are disconnected from your customers via a multi-layer proxy.
More like this
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, George S. Patton
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
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
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.
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.
Wrap-up
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
- 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
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