Time flies. We’re already at the 10 year anniversary of the Lean Startup. Yes, it was a little over 10 years ago that Eric Ries started sharing a series of blog posts and giving talks on a new way of building products — ideas that went on to spark the global Lean Startup movement.
By now, “almost everybody building products” has at least heard the term and has been exposed to the big ideas. Yet, when we look around we don’t find the corresponding adoption across teams. And what we do find usually isn’t a rigorous enough implementation… but rather a cherry-picking of tactics and tools — often part of a mandated checklist imposed upon teams.
I’m always happy, for instance, to see Lean Canvas posters in conference rooms. That happiness, however, is short-lived when upon closer inspection, I find them blank, not up to date, or a list of problems invented to justify the solution the team is already committed to building.
It’s like going from WAgile to WatLean.
Using a Lean Canvas does not a Lean Startup make.
(Feel free to replace Lean Canvas with your favorite tool or tactic — mvp, experiment, a/b test, etc.)
Has this all just been a huge waste of time?
I have spent the last several years focused on this question.
I’ve watched teams come to my workshops and leave with a full understanding of the framework. Yet, when I follow up with them weeks later, it’s back to business as usual. There is always something else that needs to be built first — that mythical killer feature always lurking.
That’s when it dawned on me:
The challenge to adoption isn’t about just the merit of the framework or motivation of the teams, but overcoming old habits and new anxieties.
Adopting anything new takes effort.
It requires us to go from being experts in the old way (the familiar) to becoming beginners in the new way (the uncertain). This is uncomfortable — especially when we are met with negative versus positive reinforcement like a failed experiment (which is almost a certainty with initial experiments), or probing questions we can’t answer yet from our stakeholders and team members (all processes are easy until you add people).
What happens next is quite predictable — we revert back to the old way.
This is just the nature of behavior change.
The good news is that we now understand the science of behavior change a lot better thanks to the work of people like Daniel Kahneman, Amos Tversky, BJ Fogg, Dan Ariely, Charles Duhigg, Nir Eyal, James Clear and more.
We encounter behavior change challenges all the time.
We, for instance, know certain activities are good for us like eating healthy, exercising regularly, and saving money. Yet, we struggle to implement them into our regular routines.
Adopting a fundamentally new product development process is no different.
Once I viewed process adoption this way, it completely changed my approach. I shifted my attention from lecturing at teams to studying causes for their anxieties and habits and looked towards devising new ways of overcoming them.
In the picture above, we don’t need more PUSH or PULL, but need to devise ways to reduce INERTIA and FRICTION.
A bootcamp was born
That’s when I had the idea of running an immersive 10-week bootcamp. I would recruit the most motivated early adopter practitioners and lead them through a high-touch coaching program. My logic was that if I couldn’t get them to apply this framework successfully, there’s no way it could work with more mainstream innovators.
I launched the first bootcamp in September 2012 with just a napkin sketch of a curriculum. Even though everyone didn’t make it to the desired outcome (problem/solution fit, in this case), the transformation created was obvious.
So I doubled down.
I have since then run dozens of bootcamps over the last seven years with hundreds of startup and corporate teams spanning the globe — all delivered virtually from Austin, TX where I live.
Each bootcamp built on the previous one and underwent many iterations with lots of experimentation. Along the way, I got to see what worked and what didn’t, patterns emerged, more tools got built, another book got written.
Immersing oneself in the world of customers and their problems is the best way I know for finding solutions to problems worth solving.
This is exactly how I wrote all my books and developed tools like the Lean Canvas. And exactly how this bootcamp evolved from a high-touch coaching program to a repeatable and practicable set of stage-based playbooks.
Start with mindset shift
One of the a-ha moments when developing these playbooks was realizing that the early stage is all about investing in people and teams — not ideas.
We spend too much time building barriers during ideation with heavyweight processes like business planning, for instance. This is the #2 killer of ideas. Most good ideas never look that way at first because they often propose challenging the status quo which our tribal brain resists.
The answer isn’t doing more fictional analysis but gathering enough evidence of traction for the idea.
Fast idea validation >> Elaborate idea generation
especially when speed to market is the new unfair advantage
This requires a mindset shift both on the part of innovators and their stakeholders. Investing in people and teams is not about judging their idea submissions but leveling up their critical thinking and problem-solving skills.
This is the long game of innovation.
Good teams will quickly recognize and kill off bad ideas and eventually find good ideas.
Bad teams can’t tell a good idea from a bad idea and they either stick with bad ideas too long or hopelessly fumble good ideas.
Investing in people and teams specifically means first enabling key mindset shifts before investing in skills, tactics, or grand strategies.
All our playbooks follow this structure:
What is a mindset shift?
Mindset shifts are universal principles, like first principles in science, that serve as the building blocks for developing better critical thinking and problem-solving processes.
While we rightly place a lot of emphasis on doing, thinking precedes doing. And the quality of your output (results) is directly dependent on the quality of your inputs (ideas).
Over the years, I’ve collected many mindset shifts or principles as I’ve evolved my own thinking on product development:
- Release early, release often.
- Less is more.
- Right action, right time.
- Get outside the building.
- …
I synthesized these first-principles into 10 key mindsets that define the operating system of the Continuous Innovation framework:
Before coaching any team, we first expose them to these 10 mindsets with lots of examples of each in action through our Foundations playbook.
We don’t expect an immediate transformation in behavior, but planting these mindsets early, allows us to then revisit them more contextually in later playbooks when the team is faced with making their own product decisions.
Mindset shift is like a good tea — some steeping time is required and it can’t be rushed.
If you’d like to take a deeper dive into these mindsets yourself, sign-up for the Foundations playbook — it’s free.
Before building a skyscraper, you have to seemingly move in the opposite direction, digging a multi-story hole for the foundation.
