The first idea is rarely the best. Therefore, it is best to generate 15 to 20 ideas for each opportunity. We can generate ideas using brainstorming, ideation, or other appropriate methods. Some problems do not require an original solution, but for strategic problems, originality sets us apart from the competition. Therefore, it is important not to restrict yourself and also consider crazy and unrealistic ideas, as they may lead to real ideas.
The next step is to evaluate ideas. First, those ideas that do not address the specific opportunity must be eliminated. This is a normal part of the brainstorming process, and ideas should be eliminated only at this point. This is followed by voting, for example, dot voting, in which each team member votes for ideas they believe are good. Each member has a set number of dots, in our case, three dots, with which to vote. The goal is to generate three ideas. The only criterion for selection is that the given idea effectively solves the specific problem. Voting for the brightest or most original ideas that do not contribute to the solution is pointless. Team members can put all three points on one idea or spread them out over several ideas. The process is repeated until only three ideas are selected.
Several mistakes should be avoided during the ideation process. One of them is including stakeholders from only one department while leaving out stakeholders from other departments. The second major mistake is creating too many variations of a single idea. Our goal is to come up with as many different ideas as possible. The third error is selecting ideas that do not solve the specific problem. Before voting, such ideas must be eliminated.
Identifying hidden assumptions
Most ideas are usually still hazy. Therefore, it is necessary to go over the details before evaluating them. This can be accomplished, for example, by using story mapping, in which each step a user must take to obtain value from a product or service is mapped.
- The first step is to imagine a ready-made solution. Our focus is now not on building the solution but on the fact that it is already ready and used by the customer.
- The following is an identification of key parties. Who must interact with whom in order for the product to work? A good example is social networks, where at least two people communicate with each other or engage in other activities. In other circumstances, it could be a seller and a buyer or a person and software (such as a conversation with a chatbot).
- The next step is to map out the specific steps both parties must take to gain value from the solution. It is critical to be as specific as possible.
- The final step is to arrange the steps in chronological order. The steps must be taken in the order that they occur. Optional steps are also added as they occur. The successful path is always shown here, while the unsuccessful path is not. At the same time, all successful paths must be displayed. See the following story mapping example (key pages are shown on the left, followed by the steps required in the map):
It is necessary to document all assumptions about the solutions. They are generated as a result of the individual steps in story mapping, in which we write down assumptions about how the given user will behave in a specific situation for each step. These assumptions are based on our experience, research, as well as our understanding of the market and customer knowledge. We evaluate these assumptions against the following criteria:
- Desirability – Is this solution desired by anyone? Will it be beneficial to customers?
- Viability – Should we build it? Does the solution work for our company? The solution should generate more revenue than we spent on its development, operation, and maintenance.
- Feasibility – Can we build it? Here we consider technical feasibility and other areas (legal, security, cultural, social, etc.).
- Usability – Is it usable? Can customers find what they need? Will they be able to use it?
- Ethically – Will the solution cause any harm? For example, is it acceptable to store data this way?
It is always necessary to consider ethical assumptions, as many teams overlook them. For example, we should consider questions such as: what data do we intend to collect? What will customers think about data collection? Will we disclose information to third parties? Can our product lead to addiction? Are we overlooking any groups of people? How can internet trolls take advantage of our product? Is this solution going to jeopardize our reputation? It is best to specify different questions and then respond to them.
Another method for generating assumptions is a premortem. It is always done at the start of a project and forces us to make assumptions about what could go wrong. To begin such a process, an appropriate question is: "Imagine that six months have passed, we have launched the product, and it is (not it can be!) a total flop. "What went wrong?" With this question, we start making assumptions.
A third option for developing assumptions is to revisit the Opportunity Solutions Tree but start from the end. We start with a solution and try to answer how the specific solution solves our chosen problem. Making some assumptions for each step along the path is a good idea.
Prioritization of assumptions
The next step is a prioritization of the assumptions. We can use a map to sort them according to their importance (regarding the success of the given solution) and the evidence we have to confirm or refute them. This is how we position all assumptions relative to one another – their position can be changed. Then we concentrate on the assumptions in the upper right quadrant; they are important but unknown.
This procedure – from story mapping through the generation of assumptions to the assumption map – is repeated for each of the three solutions that we selected with the team previously. Then comes the testing of the assumptions.
Testing assumptions, not ideas
It is always necessary to test assumptions for all three opportunities simultaneously. This will keep us from focusing too much on the idea we like best and looking for evidence to support it rather than being objective about all three selected ideas.
We focus on assumptions for which there is insufficient evidence. We aim to move these assumptions from the right quadrant (unknown) to the left quadrant (known).
When testing assumptions, it is important to try to simulate a situation that allows us to verify the assumption with the user. It is critical to define and then focus during the test on the moment when we will verify the assumption. As a result, we will be able to move from one test to another (for example, if we want to find out how the user decides what to watch on Netflix, we can give them the Netflix Home Page with various options and observe how they behave). So we begin by defining the moment we want to test, then we attempt to create a simulated situation, which we finally try with the user.
Before the test, it is necessary to agree on what it means for the assumption to be correct – to define it precisely. For example, "four people out of ten will choose the sports channel" (it is necessary to determine the number of tests we will conduct and the number of people who will participate in a specific activity). This will help us agree as a team on what is a successful test while also preventing confirmation bias when we justify what is still a successful test and what is not. There is no correct answer; the objective is to gather maximum information while engaging the minimum number of users.
We can avoid failed tests by putting more emphasis on user recruitment – we will determine our requirements and try to get a diverse range (for example, across genders, generations, or locations). It should always be clear to us why any of the tests failed – if not, we should investigate the failure. It is also appropriate to test our assumption using various research methods (for example, a prototype in a usability test, but also an interview with questions about the respondents' past experiences). This process is known as triangulation.
As a result, we gradually test all of the assumptions in the upper right quadrant (those that are unknown but important). It is not enough to test one assumption and then stop – we must test them all.
The most common assumptions encountered during testing mistakes
- extremely complex simulations – the goal is to perform rapid testing rather than spend weeks on one assumption,
- determining test success using percentages rather than specific numbers,
- insufficient evaluation criteria definition – in addition to the number of respondents and successful users, we can define other steps in the test (for example, how many users view the website, click on the CTA button, successfully choose the product, etc.),
- testing with a wrong user group,
- designing for the worst-case scenario – for example, in the first round, for a group of users that is the target group and probably the easiest to pass the test. Even here, the group may fail the test, and we will not even get to the more difficult target group.
Through this process, we will determine which solution is best suited for the given opportunity, and we will be able to advance further in the development process. As we spend time selecting the best solution, we will avoid developing a product or functionality that ultimately falls short of our users' expectations. On the contrary, it will solve their problems, desires, and needs.
Resources
Teresa Torres – Continuous Discovery Habits
