4
0 Comments

The Continuous Innovation Framework

In the last 3 months, I joined an online course that fundamentally changed my maker mindset, here are some takeaways.

From time to time, a new wave of technology-driven innovation changes the way customers consume and demand products. In response to that, the way makers build products must change as well.

Back in the 50s, after the war, lots of factories were squeezed on resources and started using just-in-time manufacturing. Taiichi Ōno in Japan developed those ideas further into a set of practices that became the Toyota Production System and eventually the Lean manufacturing. Efficiency or reducing waste was the name of the game and unfair advantages came from being able to produce the most number of units at a lower cost.

As we moved into software in the early 70s, we adopted the same sequential or top-down waterfall process that we used for building physical products and applied it to digital products. There was an early stage for gathering requirements followed by a long development period solely focused on building the product. Once ready, it was released to customers. That's when the market validation happened. Planning was the name of the game and unfair advantages came from being able to execute the plan on time and on budget.

It worked for a while until we started entering the PC era around the 90s. This is when we started using personal computers in everyday work. That shift caused a new spike in customer demand and the long cycle times of waterfall could no longer keep up. It was quite typical for requirements to change in the middle of the production cycle and a new lighter-weight process was needed. During this time we embraced innovative product development methodologies like Scrum and XP. The idea here was to build products incrementally instead of in stages and incorporate customer feedback at periodic intervals throughout the product development cycle rather than just at the end. Iteration was the name of the game and unfair advantages came from being able to manage the risk of changing requirements.

Around 2010, the world changed again as products went from being developed in the box to being delivered over the internet. Customer demand took another step. It was no longer enough to simply build what customers said they wanted because by the time you built that, you learned that what they really wanted was something quite different entirely. In this new world, the only way to make sure you build what customers want is to engage with them continuously. Speed of learning is the new unfair advantage. Companies that learn fast, outlearn their competition and get to build what customers really want.

Today we are living in a world where it’s easier than ever to build products. There is a lot more competition, customers have a lot of choices, and it’s much easier for them to switch. In such a world, the fundamental question is no longer “Can we build it?” but “Should we build it?”. The challenge today isn’t building a product, but uncovering the right product to build. This is where my mindset shift started.

It’s a search vs execution mindset change - and more specifically, a discovery before validation mindset change. When you are in execution mode, you iterate over the solution. As you get feedback and refine your idea, you may find something that gets traction. Sometimes it works, but it's a sub-optimal approach because it doesn't get to the root causes that push people to do what they do. A better way is to start with problem discovery. Interview people to understand their journeys:

  • What tools do they use?
  • What are their emotional and functional drivers?
  • What do they want to achieve?

To systematically uncover these insights there is a framework called Jobs-to-be-done --> https://youtu.be/sfGtw2C95Ms

By the end of this process, you should be able to describe customers’ problems better than they do. However, not all problems are created equal, so the next step is to understand what problems are worth solving. This is where you start designing and validating your solution. You are still in search mode though. Building a product at this point is still dangerous because you are just assuming the problems you have found are worth solving. Before moving into execution mode, you need some people who have committed to your offer as proof that you really have something valuable to them. Once you have established repeatable demand and traction, you can finally answer “yes” to the previous question “Should we build it?” and start building.

This framework doesn’t apply to tech startups only. It’s for anyone who wants to find problems worth solving because life is too short to build something nobody (or not enough people) want. I learned it the hard way in 10 years of coding.

For anyone interested in this way of thinking, here are my public notes from the course https://www.notion.so/90-day-startup-68959c7a8d434f5f9ed94420ad2e297d

Also, if you want to have a chat, feel free to DM me anytime on Twitter! 🙂

Finally, here you can get a 10% discount on the next cohort with my alumni link https://runlean.ly/3h5excI.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 29 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 15 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments