You just wrapped a research project. You finished every interview and polished the readout, complete with sharp charts and a few video clips. The finish line sits right there, and you can't wait to hear what your founders and product leads make of what you found.

You present. The last slide lands with a tidy set of next steps. The room smiles back, and then... crickets. You ask, "Any questions?" A few people stare. Some glance at their laptops. Someone answers email. Then you hear the question researchers love and dread in equal measure:

I've stood in that exact room. It feels like failure, as if the whole project missed.

It didn't. You just live too close to the users. You've sat through the interviews, so the next steps feel obvious to you. You reframe problems, sketch iterations, and picture every possible experience without effort. But those instincts don't travel from your head into a report.

So prepare to run an ideation workshop that gets your team working with the insights. And before you jump into ideation, or when you can't run a full session, take one key step first: write How Might We statements.

How Might We (HMW) statements are small, mighty questions. They reframe your insights into opportunity areas and point your team at the problems you found in research.

Each one rewords a core user need you uncovered. That keeps your team focused on the problem instead of leaping to a solution, and it keeps the work user-centered.

The recipe: start with a point-of-view statement, break it down, write as many HMWs as you can, then pick the ones to pursue.

People have used HMWs for years to spark innovation. They also get them wrong. How can something so open-ended fail? Two ways.

HMWs can be hard to write. When they won't come, break the big problem into pieces and type "How might we" in front of each piece. Write some that are too narrow or too broad. You can judge them afterward. Just write.

Stanford's d.school offers a set of prompts that generate more HMWs by changing the goal of the question. Here they are, applied to this POV: People who run long AI tasks need to know the AI is still working because a silent screen makes them doubt the result.

- Amp up the good: HMW make every moment of the wait feel useful?
- Remove the bad: HMW remove the silence during the wait?
- Explore the opposite: HMW make waiting the most reassuring part of the product?
- Question an assumption: HMW let people leave and trust that we'll find them when it's done?
- Go after adjectives: HMW make the wait feel short instead of endless?
- ID unexpected resources: HMW report progress through the channels people already live in, like Slack and email?
- Create an analogy from need or context: HMW make a long task feel like tracking a package?
- Play against the challenge: HMW make people want to check in on a running task?
- Change the status quo: HMW make the wait feel delightful?
- Break the POV into pieces: HMW show what the AI is doing? HMW estimate time left? HMW say the moment it's done?

Not every one of these is perfect or doable. They get you unstuck. Stay creative, then cut what doesn't make sense. And borrow from improv: always say "Yes, and..."

Generate your HMWs, then pick one or two to pursue. Now design and test.

Sit down with a designer, or a larger group, and sketch every solution that answers each HMW you chose. Too many ideas to test? Vote again.

Pick the best two. Work with your designer to turn them into prototypes, then put those prototypes in front of real users. Learn from what happens, and keep iterating.

That's how a room full of silent stakeholders becomes a team that knows exactly what to build next.

If your team sits on research it can't turn into product, [Mayur Maheshwari / mayur@studioaccorde.com]. Let's turn your insights into the next thing you ship.