***The post below is by Zac Cohn, CEO of Wonful Consulting
To all that are curious about our process of generating customer insights, then turning customer insights into prototypes that can be tested with business owners, the post below outlines the methodology and steps we have been following:
Intro to the Innovation Process
The Office of the CIO has been exploring, under the guidance of Wonful Consulting, new and innovative processes for creating valuable solutions for the business owners of Washington State. In order to determine the "most right solution" and avoid solving important, but perhaps not the most important problems, we've used a combination of Liberating Structures, Customer Development, Lean Startup, and other pre-Agile techniques.
This has resulted in a system that starts by gathering data from one-on-one interviews with customers, then groups this data into themes. From these themes, we generate insight statements, which allows us to begin the process of prototype ideation and testing. This eventually lets us exit the pre-Agile stage and transition into a more traditional Agile product development process with the knowledge that we're not investing significant time or resources building the wrong product.
Customer Interviews
The first stage in the pre-Agile Innovation Process is performing many one on one, face to face customer interviews. During these interviews, the emphasis is on "pulling" the customers' problems out of them (with questions like "Tell me about the last time you-" or techniques like the "Five Whys"), rather than "pushing" preconceived notions of the problems you think they have onto them ("Have you ever forgotten to file a form?" or "Is it ever hard to use this website?").
The reason we "pull" rather than "push" is to ensure the problem we end up solving is a "Top 3 Problem" for the customer. If we suggest a problem, they may agree that it's a problem. If we pull problems out of them in an unbiased way, you can be sure they'll bring up their biggest problems first. If they don't volunteer the problem we thought they might have- it's an indication it isn't a very big problem for them.
Affinity Mapping
Every time we complete a round of interviews (ten to fifteen tends to be enough to get interesting results), we transcribe our notes from these interviews onto Post-it Notes. As a team, we then go through the painstaking process of reading each note from each interview out loud and placing them on the whiteboard.
After all the notes are read, the team begins the chaotic process of affinity mapping. Everyone rearranges the board and moves Post-it Notes with similar themes into groups, calling out new themes as we discover them. A few of the many examples of themes from our project include "Methods of Communicating with the State," "B&O Taxes," and "Remind Me, Don't Reprimand Me."
At the end of the process, some groups are re-affinity mapped while others are cannibalized. If necessary, we'll go through the process a second, or even third time as new themes emerge toward the end of each cycle.
Insight Generation
The next step is repeated for every theme. We select one (for the sake of example, lets use "Remind Me, Don't Reprimand Me"), read all the Post-it Notes within that theme to refresh our memory, and then identify any particularly unique insights.
For this example, it could be something like "Business owners want to be notified, with enough time to respond and in the medium that they choose, before some action must be taken." It's important to note that Insights Statements are about problems, they are NOT solutions.
To help us transition to the next stage, create a "How Might We-" statement for each insight. "How might we provide businesses with effective and efficient notifications that are relevant to them." (Occasionally, this will just be a simple restatement of the insight. That's okay, just don't take the easy way out and jump straight to restating it.)
Prototype Ideation
Once each theme has an insight attached to it, it's time for the prototype ideation stage. Go back and read an Insight Statement, the How Might We- statement, and the associated Post-it Notes. Then, set a clock for 3 minutes.
Individually, each member of the team brainstorms as many different solutions as we can. At the end of 3 minutes, we paired up and spent another 3 minutes sharing what we came up with. We'll "Yes, and" each other into new ideas that get written down too.
Finally, each pair shared with the group what prototype ideas we came up with. We continue the process of "Yes, and"ing to new ideas, but purposely didn't get down into the details of any given idea.
We repeated this process for each Insight Statement. Sometimes 3 minutes wasn't enough time to generate ideas for solutions, so we did several cycles of this process rather than increasing the 3 minutes. More and faster cycles are better than fewer, slower ones.
DVF
Once every idea had a number of prototype ideas attached to it, we ran each idea through the DVF Framework: Desirability, Viability, Feasibility (How much do people want this, what is back of the envelope estimate of the impact of this thing divided by the estimated cost, do we have the technical capability to actually make this a reality), with values of 0 (low) to 10 (high) assigned to each category.
As we processed each prototype idea, we tried to "Yes, and" it into whatever would be the most desirable solution (based on the empathy we've built by interviewing customers), and then estimated the viability and feasibility of that.
Once all prototype ideas were DVF'd, we marked the following ideas: Ones that scored high (all 7s or above), ones that were 9s or 10s in Desirability, but scored low in Viability or Feasibility, and then any prototype ideas that appeared for multiple Insight Statements.
Prototype Planning, Assessment, and Testing
Based on the above groupings, we identified which prototype ideas we wanted to move forward with and begin testing. Develop a plan around the simplest, easiest, fastest way we could test that idea, all the information and resources that would be required, and then we assigned a specific person within the team to be responsible for that idea.
They don't have to do all the work, but they're responsible for leading the rest of the testing process for this particular idea.
Conclusion
After thoroughly testing many prototypes with customers, we'll be using the results of the tests to narrow down which prototypes should proceed. The fidelity of the prototypes will increase slowly, from conversations to literal napkin sketches to wireframes and eventually to software mockups. This allows us to disqualify certain ideas without investing large amounts of time and money into building a fully functional, high fidelity prototype until we know it's the right thing to build.
It can be tempting to take each insight through the entire process before starting with the next insight, but it's important to do go step by step. It's slightly less efficient because we have to keep re-reading all the Post-it Notes that make up an insight, but we benefit by hearing everything many times and developing a deeper understanding of the global context, which lets us identify connections between insights that might have otherwise gone undiscovered.
Staying committed to this process appears to add a lot of time to the overall length of a project. There's a large amount of time spent "not building anything" and appearing to not make progress. Often, we might appear to make negative progress.
But the reason we adhere to this process is to ensure the output, the thing we'll eventually build, is the "most right product." The opportunity cost of spending an additional 4-6 months up front is desirable compared to the risk of not following this process and building a solution that doesn't adequately solve a problem, or worse - solves the wrong problem.