In our last Nimble Hippo post, we talked about generating and capturing ideas: the raw material of innovation. Now, we’ll talk about moving all of these ideas into buckets: problems that need to be solved and experiments that can be conducted.
How do we deal with all these ideas that were captured in our last post? Possibly thousands of ideas have been generated. There are ideas about new products, ways to save customer’s money, ways to save the company money, and many, many more. Some of the ideas are big ‘moonshots’ that may change the world, while others are incremental process changes that will save the company money and help the environment. Then there are all those ideas in between.
In a previous blog post, we talked a little about moving from ideas to prototypes. Today we are going to dive deeper into this issue of how to create hypotheses out of these ideas and begin to test them.
As the ideas are captured from our employees, stakeholders, and partners, a system needs to be in place to tag these ideas in certain ways. The ways we suggest are:
Timeline — How quickly can it be acted on.
Type — Product, service, or process improvement.
Impact — Moonshot, extension, or core.
By tagging the ideas, you can go back to the Innovation Council (IC) with some suggestions of next steps.
As I mentioned in my previous blog posts, the IC should be involved in moving these ideas into the next phase which would be “problem identification”: How can we take all of these ideas that have been generated and turn them into problem statements that can be tested?
Design thinking pioneered this concept, originally created by Tim Brown and others from IDEO, with the goal of designing products and experiences that focus on empathy and the customer. Every company (well, almost every company) will say they are customer centric, but very few companies actually use empathy and design thinking to drive customer-facing outcomes.
So how do we put these together? We have a bunch of ideas, they have been categorized, and now we need to use a process like design thinking to transform these ideas into hypotheses that we can test.
A hypothesis is a statement that starts further investigation. The best way to explore this is to walk through an actual example.
Company X is a national financial services company looking to improve the way they market a specific product, new home mortgages. Many of the ideas that came out from an employee challenge were focused on making it easy to apply for a mortgage using a smartphone. The assumption was that since most first time home buyers are younger and more digitally savvy, they will want to use more mobile applications to purchase their mortgage.
The IC got together and decided that this was a great idea and that they should build a mobile application. The IT leader on the IC had a mobile team that was hungry to do more interesting development, and the marketing and product teams were looking to attract more first time buyers into their financial institution. They looked around the market and there were a few players attempting this but nothing came out as a clear market leader, so the discussion was around how to build the mobile application.
The chair of the IC, the Chief Innovation Officer (CIO), was very familiar with the design thinking process and pulled the conversation back to the hypothesis. His question to the group was “What assumptions can we test to ensure the product will resonate with customers?”. The group talked about a number of things but the ultimate assumption that needed to be true for this product to be successful was that new home buyers would choose a mortgage using their phone.
The data supported the assumption that this demographic, and most demographics, were doing more shopping on their phones, and using their phones for banking, so it was an easy leap to say that they would also shop for mortgages. The CIO convinced the group that this was a worthwhile assumption, since if this was not true, the project would fail.
The point is that the group immediately went to building the mobile mortgage application solution without really testing the hypothesis — that new home buyers will buy a mortgage using a smartphone. They may, but we don’t know. If not, the mobile mortgage application will ultimately fail. By driving back to a hypothesis, the group can now move onto the next phase, which is building the problem statement and coming up with a minimum viable product (MVP) and test it in market, which will be the topic of next week’s post.
Lessons learned:
- Tag and categorize all the ideas so they are easy to search later
- Share with all of your employees and stakeholders the process of this idea consolidation so they understand that all ideas were considered and just consolidated into a bigger hypothesis
- Ensure that the Innovation Council focuses on the assumptions that must be true instead of the solutions they want to build
- Build a hypothesis that can be tested in the prototype phase
Related Blog Post: Your team has great ideas. Now what?
Previous Nimble Hippo Radio: Introducing Nimble Hippo Radio.
