Product ideation meetings that don’t suck (or just less)

A lot has been written on how to make great products. (And this book is great on the topic). We all know the story: Empathy and research, user stories and personas, design stack and quick prototyping, dev tickets and careful testing. But the human component is too often forgotten despite being at the core of the product design process.

Building products is essentially a human task and a team effort. How do you combine a set of skills and personality into a greatly executed project? How do you make sure everyone stays motivated and conflicts stay low? How do you test your assumptions and make sure all the ideas and insights are discussed early, and not mid-way through the coding time?

Nothing is more important to me than the initial ideation session. When it becomes clear we want to extend our product to solve a problem our users are facing, or when iterating on an existing capacity, you want to make sure you start the process on the best first step with a brainstorm that allows you to make the most of the insights, ideas and capabilities you have at hand. That’s the ideation meeting for us.

In my team, we’ve been very inspired by the Google Sprint mantra. Their approach to brainstorming finds a way to hear people’s ideas and foster them into a great product. But it’s hard to find 5 days for every feature you start and wouldn’t be efficient anyway for smaller features. And the risk is then to not run them at all… So how do take the best of this approach in a two hour format?

As an example, I’ll take the often debated Weather app problem.

Pick your group carefully

Let’s say you’re getting started on a new feature. Who should be in that meeting?

  • The Product Manager (You), who will structure the debate and structure the work before and after the meeting;
  • The Designer, which I consider goes in pair with the PM at this stage;
  • People with specific and relevant expertise on the topic, like people from Insights, Analytics, or even Sales and Marketing if they know that type of user well and Customer Success if it’s an existing feature;
  • Key engineers that will work on the project, giving them the option to come or not depending on their interest;
  • Some people with general overview or authority, like your Head of Product or CEO, especially if you think they’ll want to share their point of view at some point in the work (avoiding any disruption later).

You don’t want this group to be too big, but you can easily go up to 6–8 people this way without feeling crowded and inefficient. Talk to each of them before the meeting to explain the context, and give them a task so they come prepared (by telling them the theme and to come with relevant data or inspiration for example, or to check the tech stack available quickly).

e.g. Let’s say you’re creating a new feature in your product to allow users to see the weather. Is it an extension of a current feature? Check with your Customer Success how many tickets have been filed with that topic. Something customers of a certain industry have requested? Bring your sales guy along with stories to tell. The PM and Designer should look ahead of the meeting for inspiration and get a sense for which problems are solved this way, while the Insights and Analytics team look for a pattern in the persona and habits of the people that would request / benefit from that feature.

Start with a clear objective and concrete data and insights

If your meeting lasts 2 hours, give 20 minutes to defining the objective. You want to detail various definitions of the objective, and make sure people agree on which meaning they’re talking about. As the brainstorming goes, make sure to capture solutions on post-its immediately without much debate, so they don’t clog the discussion.

e.g. So why do people want a Weather indication in the app? Is it for the Weather itself or to check the consequences on their activity (going out, clothes to wear, shipments being delayed, …)? What do they use as an alternative currently? What happens if they don’t have this? Check with each participant wether (pun intended) they have another definition and make people vote silently with stickers if this prove more difficult than expected.

Then paint a portrait of the situation with insights and data. Both your analytics and insights should bring stories, data-points and trends and present them without pushing for specific solutions. Ask people one by one to present to avoid both confusion and competition in the group, as this step is crucial. Write any element on a whiteboard as you go. Another part can be to go person by person and ask why we’re not achieving what we want / what are the main problems of the current solution, noting them down as they come.

You should now have a vote / consensus over what you want to achieve, for whom, a precise profile of that user and a few hints as to what to improve.

Generate ideas silently

Typical brainstorms are the enemy of creativity. The debate will usually spin out of control and either one or two voices will drive the debate or the conflict will not lead to any solution, depending on the mix of personalities.

Give 15–20 minutes to the group, a pile of post-its and some clear rules. The goal can be for each one to generate the most ideas to test / solve the objective. Or for people to work in small diversified groups on each of the top definitions and generate more detailed solutions. The goal isn’t to have fully drawn prototypes or to compare drawing skills, but to push creativity and give some potential flows.

Fine tune the rules depending on the complexity of the problem and the controversy it can create. If too many people think the same way (for example if the project has been debated in the past or some influencers had already pushed for a solution), then push for volume and ask 6 different solutions from each person. Especially the “crazy / we’ll never do this” ones. If you think an idea has been debated but never actually thought through, make the ideation session about defining an end-to-end flow more than about a screen. Constraints bring creativity in these situations.

e.g. Ask for 6 versions per person of this weather widget. How many will solve the problem by not even showing the weather but directly the consequences of it (“bring an umbrella”)?

Regroup and structure

One by one, people will present their idea in a short / no comment format. 2 min per person should be enough. Group the post-its by themes and discuss briefly the themes that emerged. Then make people vote with 3 points per person on the one they think we should pursue to help prioritise.

Depending on the level of definition you want, you’ll either have enough material here to close the session or will need to pick 2–3 popular themes and get people to start again by focusing on these themes.

Take it offline

Finally, PM and Designer can take note of all of the ideas into a shared document, and start using these and the insights regrouped to get started on a first prototype. You’ll be amazed at how many new things will have emerged this way. While not all of the ideas will be used in the end, having participated in the ideation session should also boost the morale and motivation of your engineering team. Making that debate structured and saying clearly that not all ideas will be pursued in the end also avoid the frustration that comes from falling in love with a solution and not seeing it become reality.

Conclusion

Building products is a team exercise. Yet, too often is the ideation stage the realm of a single person only (PM, designer, manager). Opening the debate in a structured way will bring ideas that even the best PM out there would not have considered, and bring the morale and motivation higher. A great way to build better products!