“How Might We . . . ” is a group brainstorming
technique we have used for about six months to solve creative challenges. It originated with Basadur at Procter & Gamble in the 1970s and is used by IDEO, Facebook, Google, and fans of Design Thinking.
“How Might We . . . ” is a collaborative technique to generate lots of solutions to a challenge. Our team modified the technique slightly to ensure that we also prioritize those solutions. More on that below. . . .
In essence, “How Might We . . . ” frames problems as opportunity statements
in order to brainstorm solutions. For example:
- How might we promote our new service to the audience?
- How might we improve our membership offering?
- How might we completely reimagine the personalization experience?
- How might we find a new way to accomplish our download target?
- How might we get users excited and ready for the Rio Olympics?
How might we works well with a range of problem statements. Ideally the question shouldn’t be too narrow or broad.
How Might We sessions involve a mixture of participants: product (product owner/BA), technical (developers/tech lead/QA) and stakeholders. The duration is 1 – 1.5 hours.
The format is:
- Scene setup (background/constraints/goals)
- Introduce the question (how might we . . . )
- Diverge (generate as many solutions as possible)
- Converge (prioritize the solutions)
1. Scene setup
Scene setup is about introducing the background, constraints, goals, and ground rules of the How Might We session.
For example, we held a session about “How might we get app users excited and ready for the Rio Olympics?
” We invited 10 participants across product, technical, and stakeholder teams. For five minutes, we set up the scene:
- Background: Rio 2016 is the biggest sporting event. We expect record downloads and app traffic. There will be high expectations. There will be hundreds of events and hours of live coverage.
- Constraints: We want to deliver the best possible experience without building a Rio-specific app.
- Session goal: Generate ideas for new features and to promote current features.
- Commitment: We will take the best ideas forward to explore further.
2. Introduce the question
The “How might we” question is presented to participants and put on a wall/physical board.
The question shouldn’t be too restrictive; wording is incredibly important. Check the wording with others before the session. We circulate the question to participants ahead of the session — this allows them to generate some solutions before the meeting.
Framing the question in context/time will help. It makes the problem more tangible. For example:
“It’s three days before the Olympics. How might we get users excited and ready for the Rio Olympics?
Use a technique like Crazy 8’s to generate ideas. Give people 5–10 minutes to think of many solutions to the question.
These solutions are typically written on Post-It notes. At the end of 10 minutes, we ask each participant to stand up and present their ideas to the group. Participants explain their ideas; common ideas are grouped together. For example:
With 10 users, you can generate 50 – 80 ideas. Once ideas are grouped together, you can have 20 – 30 unique ideas.
We ask people to pick their favorite idea. It can be their own idea or another person’s. For 10–15 minutes, explore that idea in more detail.
Participants can add notes, draw user flows, write a description about the idea. At the end of 10 minutes, each participant presents their idea back to the group. For example:
Once each participant has presented their idea (10 people = 10 ideas), participants are invited to dot vote. Each participant has 3 votes to select their favorite 3 ideas.
Typically this is where a HMW ends.
But we would often find ourselves in a position where the top-voted idea was the most difficult to implement. The top ideas were often elaborate and had a cool factor — but they were very complicated to build and/or offered limited business value. For example: “We could build VR into the app. It would offer all sports in immersive 3D and recommend videos based on the user’s Facebook likes.”
We also found that stakeholders weren’t comfortable having an equal say
(3 dot votes) as QA/developers in terms of the product proposition.
So we implemented a further step to converge on more realistic options. We took the top-voted ideas plus any ideas that stakeholders were particularly keen on. We allowed UX to explore these ideas in more detail. An example of a more refined idea is an Olympics branded menu:
We took these ideas into the prioritization session.
With the more refined ideas, we held a prioritization session with the key stakeholders (product owner, tech lead, primary stakeholders). As a group, we would rank these ideas in terms of business value and technical complexity (1–5). The business value was driven by a KPI or agreed mission. The technical complexity was an estimate of effort.
- Complexity 5 = hard
- Complexity 1 = easy
- Impact 5 = high impact
- Impact 1 = low impact
We would end up with a relative ranking of the top ideas. For example:
The top left quadrant is tempting (high impact, low effort). The bottom right quadrant is not tempting (low impact, high effort). We used the relative weightings and dot voting to select the best idea.
We would go on to shape and build the best idea.