How is #innovation fundamentally different than implementing technology?

I've spent the past 18 months trying to build use cases on top of new technology and I've learned a few key elements which are critical to apply when dealing with non traditional technology implementation.

Unknown ??

The amount of unknowns and unknown unknowns in innovation building is off the charts. You start with a high level use case, and the more you drill down, the more you discover edge cases, show blockers, limitations, or unrealistic expectations. Forget about committing to a timeline, you'll focus on the deadline and will ship half baked products most of the time as you cut corners to overcome these discoveries. Instead, break down the elephant ?? , not in slices, not in steaks, but as granular as minced meat. Why? Because you will expose a big list of small deliverables which you will be able to attribute with a confidence score, and if 5 or 6 out 30 deliverables are late or not happening, this is much less a big deal than if the whole project is impeded.

Another advantage of having smaller deliverables is having the ability to experiment and iterate faster (see next point), and therefore the opportunity to pivot faster.

Iterations ?

The faster you iterate the faster you clear/identify unknowns. Agility comes into play here. Take a small deliverable, develop it and let's say that during testing you figure out that the success metrics are not attained and will not be unless you spend months of improvement and fine tuning. This is not an acceptable business outcome. However, because you iterated fast, the sunk cost for this feature is low and part of the innovation business case. Having frequent touch points with the business owner helps communicate challenges and showcase what is realistic or not. Understanding that realistic part of an innovation project is never set in stone. It evolves during the project and the perception from the business owners should evolve the same way yours does.

Pivots ???

Throwing a feature to the sunk costs bin is not a catastrophe. You should embrace it as a learning allowing you to identify a different way. Because your deliverables are small and you iterate fast, the cost of reaching a dead end and turn back (pivot) to the previous crossing is becoming lesser and much less impactful. The road to innovation is paved with many dead ends, but once you have figured out the right path, this is where you have the competitive edge you were looking for.

Collaboration ???

Business is traditionally less innovative than technology. This means that you need to work hard in developing the right perception of what you are doing to your stakeholder. You will need their help! Either to convince management of something, or to brainstorm with you on the use case itself. Pivoting is never a technology only decision. You often need to compromise on the use case, reduce ambition, or create new streams? / sub use cases.

Another important aspect of collaboration is communities. Most of the time you are going to rely on open source packages or some vendor technology that might be in very early stage. Joining their developer communities and actively contributing is key. You'll learn more about their solution, the challenges of people using it, you'll discover use cases you didn't think about, or features you had no idea about. You'll get to interact with the founders or active contributors and sometimes co-develop with them. More than a rewarding experience, it is a source of ideas you cannot neglect. You will also be able to identify talents you might want to hire or take on contract. I found that discord communities are a very good source of talents.

Change Management ???

Similarly to previous section, business (and even more management) being less innovative, changing their mind is key to create sustainable innovation cycles.

There are a few key points to adhere to when dealing with business or management to create change sponsorship:

• do not overpromise
• be transparent on your challenges
• be transparent on your own competences and team competences
• be transparent on your reliance on external technologies / advisors
• do not try to achieve perfection (80/20 rule applies perfectly here) but...
• do not compromise on timelines, shipping faster is the enemy of innovation. You need time to fine tune and eliminate unknowns. The end user first impression is what matters most, and shipping fast to improve later is going to make you loose your end users.
• Finally, manage expectations. Explaining in detail the volatile nature of innovation is key in developing the understanding that such project could fail, have ups and downs, etc... but the rewards if successful are huge. If the expectations are right, you'll get support instead of push back.

Creating trust through transparency is key. Acknowledging failures, wrong expectations, is not the end of the world. This is part of the innovation lifecycle.

Business Case ??

How do you build a business case for innovation?

You will start by identifying a use case which is critical to competitiveness of your business. As they say in the VC world, scale what doesn't scale.

To prove value, you'll have to resort to 2 tactics. The first one is to prove a classic ROI through revenue capture, market share capture, monetization model... Your second tactic is going to be the fear tactic. i.e. fear of missing out, or risk aversion. If you can't prove value, you need to prove that you reduce risks or costs.

Another key aspect of your business case is waste management. You are going to have a significant portion of your development which goes to waste due to the inherent nature of innovation. These are the dead ends we talked about earlier. A typical figure would be about 30% of budget going to waste.

There are many more to discuss about, and innovation is a continuous learning journey, but I think these few points are already a good base for innovation projects.

(image generated with AI Snap )