Innovation dies at the handover
Your team has been hard at work on a new innovation for months.
The ideas were generated.
The options were prioritised.
The prototype was developed.
Customer feedback was incorporated.
And the implementation plan was polished.
Everything was done to set up the project for success.
And yet, when it was handed over to the operations team (or whoever else should implement it), everything fell apart. Problems were discovered, priorities changed, enthusiasm dissipated and slowly what was once seen as an exciting new innovation gathers dust in a list of zombie projects somewhere.
What many companies fail to realise is that you can give an innovation team all the resources they need or want. But innovations fail at the handover points.
The times when one part of the project team finishes their work, and the next stage needs to be completed by another team.
The classic example here is an idea developed by a team of “innovation specialists” based on Design Thinking, tested with potential customers to validate demand, and then given to a development team to code and ship. After all, the Design Thinking team can’t code, but they can come up with the concept. In the minds of the Design Thinking Team, once they have given the task to the Development team, then further progress is no longer their responsibility.
The problem is that the development team will then lack all of the context and insights that were part of the idea’s journey up until that point. They will also not feel the same sense of ownership or involvement that the team which originally developed the idea had.
And so once the Design Thinking team has completed the handover, the development team may not see this innovation project with the same priority at all.
The absolute worst way to do a handover is to “throw it over the fence” so that the next set of tasks “land in someone’s lap” without them expecting it.
You can guarantee that they won’t be thrilled about this unexpected additional workload, and it will not get their highest priority. And if the handover they receive is something that risks their status quo, they will be even less enthusiastic about making it a success.
So how do you prevent these issues with handovers?
Well, there are a couple of “options”, some better than others:
- Train everyone in your innovation teams to be able to handle every possible task from an idea to launching the product (incl. idea development, graphic design, UX, coding, debugging, app store management, payment gateway configuration, setting up bank accounts, legal document review, company incorporation, legal disputes, manufacturing, supply chain, licensing, filling the copy machine with paper, answering customer support calls……. you can see where I am going with this). This way, the team can do all the work themselves from start to finish and require no handovers. But unless you can hire immortal staff who will have several lifetimes to get education in every possible field, the best you can hope for is a team full of people who are all Jack-of-all-trades but master of none. And the result is likely to be a substandard final result.
- Make sure your innovation team is made up of a diverse group of people, who together could do all the tasks. While this may work for a small-scale startup, it cannot scale well. After a certain stage and size, certain team members will begin to take over 99% of the day to day work, such as operations. If the team were only working on this one innovation, that would result in a lot of people wasting time either waiting for people with the skills at the early stage of the development process to complete their work, or people having little to do once someone else with specific skills has taken on the next set of tasks. Or worse, everyone still wants to be involved at every step of the process, even if their skills are not appropriate for each task. This is a trap many startup founding teams can find themselves in.
- Accept that in order for your innovation to succeed, it will need work by numerous different teams, and handovers will happen. So plan for them in advance. Create a stakeholder map, and figure out who in the organisation is likely to have a stake in each step of the process, the skills or resources required for the next step, and make sure they are invited and understand when and how their involvement is required from the beginning.
In case it is not obvious yet, option 3 is the one which is most likely to actually work.
And option 3 has a final, vitally important benefit.
By involving diverse teams who may be impacted by the innovation idea from a early stage, across the various teams will be a mix of skills, knowledge and experience to spot potential issues with the idea before they materialise.
After all, in order to be successful, every idea needs to be desirable, feasible and viable.
Yet most people are hired by a company because they have specific skills and experience (such as graphic design, financial modelling or accounting, or manufacturing). And people with different skills and experience may be able to see potential issues with one of the three aspects mentioned above, but not others.
For example, the team generating ideas at the front-end of innovation is likely to be very good a gauging customer interest and desirability of an idea. But they might not have the development or manufacturing knowledge to assess the feasibility of actually producing the innovation, or the management and financial understanding of what it would take for the innovation to be viable as a business offering.
By bringing in multiple stakeholders earlier, these potential gaps which any one individual or team may not see, will likely be seen by the wider team working together.
So make those handovers work by getting everyone involved together, earlier. You’ll reach the finish line much faster that way.