Strategy, speed, and agility vs. Agile. Image via Midjourney.
Responding to the next most important problem to solve
Finnish company Nokia had reinvented itself enough times throughout its 147-year history to pride itself on its “Business Agility.”
They successfully used their speed and adaptability to outmaneuver rival Ericsson in the race for global mobile device superiority during the 2000s.
But they were about to face the biggest test of their agility.
Dawn of a new mobile era
In 2006, top Nokia management learned everything about Apple’s secret upcoming “iPhone” project, including detailed specifications.
And how well was Nokia able to respond to the threat?
Ironically, it was hard at work on its top-secret, next-gen “MeeGo” device featuring a touchscreen graphic interface to leapfrog Apple, but its launch was repeatedly delayed.
The iPhone launches…
In 2007, as the iPhone debuted, Nokia was valued at over $150 billion.
The following year, as of 2008, Apple and Google launched their iOS and Android App Stores, and Nokia lost over 60% of its value.
By 2009, Nokia had shed ⅔ of its value, down by over $100 billion.
And still no response from the most “Agile” of companies.
Nokia answers
Finally, two years later, in 2011, Nokia responded with their “MeeGo” device and associated app store.
By the time it finally debuted, Nokia’s MeeGo was simply too little, too late. Now four years behind Apple’s high-end iPhone and three years behind Android’s fast-follow, low-end offerings, it offered no compelling or differentiating user value.
As of 2012, even though MeeGo phones registered a respectable 13 million app downloads per day, Apple and Google’s app stores were registering billions of daily downloads. Later that year, Nokia collapsed to less than one-tenth of its peak value, at under $15 billion.
A year later, in 2013, Nokia sold its flagship mobile phone business to Microsoft for $7.2 billion, a fraction of its original worth.
Nokia’s fall ranks among history’s most spectacular business failures, right up there with Kodak and Blockbuster.
All three collapses share one trait: The companies knew exactly what was coming.
The global Agile Operating Model champion
One of the biggest ironies was that Nokia, the self-proclaimed “Business Agility” champion, was also one of the first big companies to fully embrace Agile, emerging as the largest Enterprise Agile implementation.
They were so committed to Agile that they even established the “Nokia Test,” a set of Scrum principles that included:
- There is a product backlog prioritized by Business Value
- The Product Backlog has estimates created by the team
- The team generates burn-down charts and knows its Velocity
These guidelines would set the benchmark for Agile in large organizations for years to come.
It was never about Agile
Despite having the most crucial piece of competitor information, and a product in development to answer it, the world’s dominant mobile player and most “Agile” company couldn’t respond in time.
Some would argue that Nokia lacked the “pristine” conditions for Agile to succeed and provide its benefits.
But it’s not that Nokia’s conditions weren’t “pristine” enough at all.
Agile alone won’t save you
There’s a widespread belief that if your company can become “Agile,” it can respond to shifting customer needs and build valuable products and services faster, better, and cheaper.
And while “Agile” is touted as the savior of modern software development, the truth is that Agile Transformations have a 46–96% failure rate. And “failure” doesn’t always mean the company went back to its old ways. 30% of failed Agile Transformations resulted in the company closing its doors.
And we’ve seen how well Agile worked out for Nokia.
The best don’t care about Agile
Yet despite Agile Transformations’ checkered track record, many legacy Enterprise companies still somehow believe Agile will help them finally solve customer and business problems through quality software.
The unspoken truth is that none of the best product companies work this way, and their approaches are easy to observe and copy for any organization interested in improvement.
Agile processes simply have very little, if anything, to do with the sustained success of any of the best companies.
Once it had achieved top status in the mobile device industry, Nokia couldn’t identify and focus on the next most important problem to solve until it was too late.
And that’s exactly what strategy is for.
The true enablers of agility
What the best companies have that Nokia lacked were four key strengths across the organization:
- Strategy, brought to life by “The Product Trio”:
- Product Management
- Design
- Technical excellence
Strategy is the key foundation because it helps us identify the right problems to solve and unites us around a set of choices we believe will solve those problems.
Product Management, design, and technical excellence are the enablers to bring that strategy to life to solve those problems and maintain consistent customer and business success.
The Product Operating Model
But great strategy alone cannot deliver its benefits if we focus on a top-down “execution” model.
Strategy and its enabling capabilities can be most effective in a model focused on problem-solving over feature output.
Marty Cagan and his SVPG group outline the three key transformational shifts companies need to make in their latest book, TRANSFORMED:
- Changing how you decide which problems to solve — Strategy, sizing the appropriate problems and strategies to the appropriate teams.
- Changing how you solve problems — Continuous Discovery through regular client contact.
- Changing how you build — Design and technical excellence-enabled iterative ways of working, taking advantage of CI/CD, automated testing, and continuous deployment.
In contrast to Agile, it’s important not to approach these as a one-size-fits-all set of processes to be applied.
Cagan has summed up the underlying principles of an effective product model transformation because there are many ways to succeed in strategy —and product-driven environments.
Transformational
I have been part of five Agile Transformations, ranging from full-on Enterprise-level overhauls to small stealth mobile startups within global retail powerhouses.
What made the best ones stand out?
It came down to laser focus on a simple set of client-centric strategic choices to solve a clear problem, combined with strength across the Product, UX, and Tech Lead/Architect roles.
Choices and emerging Product leadership
But even my favorite transformations didn’t start off easy.
Case in point: I was paired up to coach a VP with deep industry knowledge who was new to Agile and iterative ways of working.
This person spent months combing through research and then went off with the UX team to design a complex, beautiful application.
They were shocked when the engineering team pushed back, saying the designs simply couldn’t be built given our team, the timeline, or our available tech stack.
Continuous Discovery
I advocated for a different approach based on an iterative, client-centric Continuous Discovery and cross-functional collaboration between Product, Tech, and UX.
Given we were clear on our problem to solve, our goal would be to quickly test and iterate through the pared-down designs with end-users and the engineering team, allowing us to design something we could rapidly build and pilot.
Seeing their top-down, big-bang approach slip away, the VP took me aside and let me have it.
“This “Agile” stuff is bull* — you just want to show your stakeholders you have something to show.”
Certainly not the best way to kick things off.
I didn’t take it personally and was feeling positive about the team’s direction and progress.
But things were about to get harder…
Team shifts
We suddenly lost our Product Manager, Design lead, and Tech Lead/Architect in rapid succession.
Fortunately, other team members stepped up into the key Design and Tech roles, but churn around the Product role persisted, with me taking on the role on a fractional interim basis.
We continued to create prototypes in close collaboration. Before writing a single line of code, we tested every interface and user flow both internally and with target clients.
After iterating and making substantial changes throughout, we finally developed the streamlined version of the app we’d use to pilot with customers in the field.
Initial Promise
Through every phase of our rollout, from a single location to a city, and then to a region, we continued to iterate with feedback from the sales team, eventually covering the entire country.
Product clarity
After several months and a number of coaching conversations, the VP fully bought into the idea of collaborative, iterative Discovery and Delivery, and stepped into the Product role. With this person’s leadership, our app took off. They did an amazing job keeping stakeholders informed and at bay, allowing the team to focus and evolve the application.
One big breakthrough was creating a quarterly “Problem-Based” roadmap focusing on addressing customer and business problems through simultaneously discovering and delivering continuous product upgrades.
Our small, autonomous, and empowered team eventually grew our product into an industry-leading app that scaled from zero to millions of conversations and formed the foundation of the organization’s go-to-market sales strategy.
Picking the Playing Field — Strategy
The takeaway? Strategy will always be our highest-leverage intervention point, as long as we have the right skills to make it real.
For those unfamiliar with strategy, it’s a client-centric, problem-solving framework represented by sets of choices made under uncertainty and within constraints.
Strategy focuses on influencing client behavior, which we recognize we have no direct control over.
The best-laid plans
Planning, by contrast, is a purely internal exercise in which we analyze our resources and sequence our activities to achieve a result.
Design Thinking and creativity allow us to understand and empathize with our clients’ unmet needs and work backward from those needs. Our best product strategies will always come from senior leadership working closely with the Product Trio — Product Management, Tech, and UX.
This allows us to create and iterate our products to provide customer value in ways that also work for our business.
The Key Strategic Role — Product Management
Great Product Managers understand how product-level strategic choices must support higher-level company strategic choices.
The hallmark of an experienced, well-staffed, and capable Product organization is an experienced strategy practice that provides structure and focus for every product choice to bring overarching company strategy to life.
When there’s clarity around which problems to solve, and the strategy is simple, clear, and well-understood across the organization, product-level decisions become simpler, without the need to resort to the “band-aid” of prioritization frameworks.
From Agile to Product Transformation
The difference between the Agile and Product operating models is moving from a delivery approach focused on process adherence, to understanding and solving real customer and business problems in a learning model.
We start from our strategic choices at the higher organizational level to choose the right next most important problem to solve. We then figure out how to solve that problem through client-centric Continuous Product Discovery.
This allows us to work backward from client needs to achieve the desired client behavior change outcomes.
Moving from certainty to looking to be wrong
In the Agile delivery model, having working, tested increments of software is our highest value.
In the Product model, while part of the team is still focused on delivery, the Product Trio uses continuous client interviews and prototype reviews to rapidly test assumptions, intentionally looking to prove those assumptions wrong.
In the product model, it’s what we choose not to build that has the greatest value.
Empowerment depends on Strategy
One core Agile belief is to empower the teams, and leave all decision-making up to them.
But when we’re focused on delivery at the team level, this can lead to teams optimizing for their own needs.
Empowerment can help us boost our overall “agility,” but only if we’ve first taken the time to make and clearly communicate a set of strategic choices.
Takeaways
As Nokia’s failure shows, if our goal is Business Agility to rapidly identify and respond to changing conditions, we must look beyond “Agile” processes alone.
Raising awareness around and developing core, in-house competencies around strategy and the necessary “Product Trio” skills necessary to bring it to life
- Product Management
- Design
- Technical Excellence
And adopting the Product Operating Model’s shifts:
- Changing how you decide which problems to solve — Strategy, sizing the appropriate problems and strategies to the appropriate teams.
- Changing how you solve problems — Continuous Discovery through regular client contact.
- Changing how you build — Design and technical excellence-enabled iterative ways of working, taking advantage of CI/CD, automated testing, and continuous deployment.
Setting clear strategic context gives teams something to rally around and aspire to, leading to continuous learning, progress, and shared understanding, which improves our ability to respond to change.
Taken together, they give us an opportunity to create something great and sustain it by iterating and continuously responding to changing client and market conditions.
Join Product Strategy Decoded, 10X’ing your strategic skills
You must be logged in to post a comment.