You can come up with the most fantastic ideas. But if an idea does not solve a problem for the user, the user will not pay for it either. That is why it is important to validate the idea during the start-up phase of the innovation process. It goes without saying that research is done into what the product should be able to do. Even more interesting for validating an idea is how exactly the product will be used. But also: does it match the user’s environment?
This research takes time, but is very valuable:
You want to work with multidisciplinary teams from the start of the process. By actively involving stakeholders and working with multiple areas of expertise, you can think outside your own comfort zone. Think about it: someone who is mechanically skilled will quickly solve a problem based on his/her expertise – i.e. mechanically. Even though a software-oriented solution might be better. This is important during the initial concept phase, but certainly during the development phase you will encounter challenges whose solutions lie outside your discipline. It can also happen that something appears to be a problem at first glance but is not a problem at all for the user because it is not used that way. Only by thinking from the viewpoint of different discipline(s) and involving stakeholders in the process can you arrive at the best solution. Keep each other sharp throughout the innovation process and communicate intensively.
Things we know feel safe. They are within our comfort zone, the place where you minimize risk. But thinking from that safe place does not necessarily lead to the best solution. It can even increase the risk. That is why it is good – especially in the early phase of product innovation – to think creatively and experiment together with the various disciplines on your team. This doesn’t have to be a big all-out project: experiment with small parts and discover what works and what does not.
Experimenting in the early phase has several advantages:
When testing a solution, we often think of testing the entire product. But it is precisely in interim tests where opportunities lie. By involving end users during the process, risks can be identified early on. This limits expensive adjustments that might be needed later on.
Do not make interim tests larger than necessary. See where the product interferes with the end user's process. Then make the problem as small as possible, so that it can be tested with the simplest possible means. This can be done with simple drawings or cardboard scale models, or more extensive 'proof of concepts' with which part of the product is emulated.
With interim testing, risks can be identified at an early stage. That does not mean that risks should not be thought about more deeply. That can be a challenge. Because the technical, creative brain is often (too) optimistic and does not want to think about possible problems. Nevertheless, it is important to tame that optimistic brain by thinking beforehand with the multidisciplinary team about risks that may present themselves sooner or later. This partly prevents later (expensive) investments and saves you time.
When you are working on product innovation, it's tempting to think big. There is nothing wrong with that, but it is better to refrain from it during the definition and development process. Keep it simple! By keeping the idea small and simple, you can get it to market quickly. In addition, the investment is minimal, limiting risks and generating income faster. And speaking of risks: a minimum viable product in practice brings out more (unforeseen) risks than when just thinking about it behind your desk.
A smaller scope therefore ensures a lucrative and more efficient process. By entering the market with a minimum viable product, you can learn from the field in no time ➞ these learnings can be applied in the product ➞ the next version will certainly meet the needs of the end user even better.
When you have a good idea, you usually don't just think about the problem. The solution is already waiting in the corner of your mind. That can make it challenging to look beyond the solution you've come up with. It is therefore wise not to formulate the product in solutions, but in functions, behaviour and interfaces.
An example of these formulations:
Solution: Use Bluetooth to connect to a PC
Function or interface: A wireless interface between the device and the PC
By sharing only a direction instead of the solution you have in mind, the product development team has plenty of room to come up with a solution. This team devises the best solution based on knowledge in various disciplines.
You are excited about your idea and cannot wait to get your hands on the product. This can lead to a fast, unstructured approach. The result: a product that is ‘originated’ and not ‘designed’. For successful product innovation it is important to work in a structured way. Clearly define what the product must comply with. This definition, coupled with an architecture that can handle maintainability and possible growth of the product, helps to realize a product that is optimally put together. This creates robustness, (if necessary) futureproofing, the lowest cost price, etc. In addition, a clear scope and structure save time in the development process and make it easy to adjust with advancing insights.
You think big, have plenty of ideas and look ahead to a beautiful horizon. Keep that in mind, but work in small steps at the same time. It is tempting to include all ideas in the process. But it is much more interesting to gradually anticipate what the world of tomorrow has to offer. Moreover, all those future functionalities entail costs and time. These are investments that may never pay off. So do not stretch your horizons too far and work in small steps.
As you have read, thinking big comes with challenges. There is also the risk that the development will become much too extensive. As a result, the actual testing keeps getting postponed and there is a chance that you start too late. Even though testing provides the most insights! It is therefore important that you test risks as soon as possible in ‘the real world’. With this approach, you will find challenges that you might not have thought of before. You will also receive feedback from users. You can process this feedback at an early stage, perfecting your product.
A practical example of this is to prepare parts of the design at an earlier stage, so that other disciplines can get to work. Think of employing basic hardware so that software can already be programmed and tested. Take your time to go fast
On the one hand you want to keep up the speed, on the other it is important that you take your time. That sounds contradictory. And yet it is easier than you might think: by taking your time in the initial phase and going through all the steps, you lay a foundation for moving quickly further on.
Because of this you:
In short, “take the time to go fast” is worth keeping in mind!
During the development of a product, the flow of ideas continues. This can cause ‘feature creep’: a phenomenon where you keep adding functionalities that do not necessarily add value for the user. This makes the product too complex, too difficult to use or simply too expensive to produce. To avoid that, it is important to remember that the last idea or need of the last user you spoke to is the most important. Make that need quantitative.
At the same time, there is always room for advancing insights and (small) adjustments if these are consciously implemented and discussed with all stakeholders. An apparently small modification to the housing can have major consequences for hardware development, for example. That is why it is extra important to implement changes thoughtfully.
Finally, ensure that there is support for the innovation. And preferably as (organizationally) broad as possible. Innovation often comes from technology or customer demand, but having support from sales, marketing, management, service, etc. is just as important. Each discipline has its own importance. As long as there is support, you can use this to your advantage during a product innovation. Involvement of management, for example, can provide additional support and capacity. Nothing is more demotivating and cost-promoting than an innovation that cannot proceed smoothly due to discussions about necessity or budget. Therefore, involve the various stakeholders in the process and create (and maintain!) support.
Product development is a costly process with risks. It is, after all, a ‘first time’. This ensures that it is not a linear process. It is a process in which setbacks will be a fact and having to take a step back is always a possibility. In addition, the more complex the product, the longer it takes to develop and the more difficult it is to oversee everything. Just think of large government projects: they almost always run late. A clear process and a controlled scope help to keep the development as predictable as possible and to minimize risks. Chart the long term, detail the short-term plan, and take the time to get it right.