How to focus on the Problem Space by Killing your Idea Backlog

Why you should kill your Idea Backlog

Whether you call it an idea bank, an idea long list, or something entirely different, chances are that you're maintaining an Excel file or a Confluence page where you park these "great" ideas people around you are coming up with regularly.

Get rid of it. Here's why.

The biggest problem with an idea backlog is that it shifts every discussion about "what should we do next" towards solutions. Teams and entire departments will revisit these idea backlogs to decide what to work on next. This feels natural to many people because specific solutions give you this (perceived) control over what the team will be doing next, what to tell the CEO, and what to sell to the customers.

The biggest problem with an idea backlog is that it shifts every discussion about "what should we do next" towards solutions.

The first problem is, as you maintain this idea backlog, it gets filled with garbage. You primarily store ideas that didn’t make it out on top of an ideation session. That means most ideas in there are out of date or lack connection to an actual problem worth solving.

Here’s how this article will help you:

• What to do instead of avoiding Hard Conversations
• How to focus on the Problem Space of Product Discovery through the Mission Briefing
• Utilizing Collaborative Product Discovery Alignment
• Dealing with new Feature Ideas during Product Discovery
• The Myth of the "Really Great Idea"

What to do instead of avoiding Hard Conversations

The second problem is that people use it to avoid hard conversations about what to do and what not to do. For example, management wants an idea to work on later. So everybody agrees to "add it to the idea backlog."

Instead of deciding it, you choose to do it “someday." This helps the idea to creep back into roadmap or prioritization discussions. This is especially likely when prioritization decisions are close calls.

Don't get me wrong: a focussed, cross-functional effort to manage ideas is an integral part of Product Discovery and outcome-oriented product management in general.

That's why I focus so much time in my Adaptable Product Discovery Course on how to properly plan, set up, and facilitate ideation workshops during Product Discovery. But maintaining more ideas than you will validate or even implement in the short-term future will only lead to spinning the hamster wheel faster, not exiting it.

Maintaining more ideas than you will validate or even implement in the short-term future will only lead to spinning the hamster wheel faster, not exiting it.

Here's what you should do instead:

If your team/department maintains an idea backlog, revisit it, look at every individual idea, and ask yourself/your stakeholders/your team: WHY would we want to do this?

In the example of an analytics company, we might discuss the idea for a Reporting PDF Export.

Why would you do this?  So account managers can share results with clients faster.

Why would we want to do this? So account managers consider us an excellent solution for working with their clients.

Why would we want to do this? So we can increase revenue from agency markets that purchase our solution.

Repeat this until you arrive at something measurable— even if it's theoretical. If you can't, that means someone wants the idea to be done for their unspoken reasons, an enormous red flag to avoid.

Use those actual reasons as the input for your next roadmap meeting, your OKR definition workshop, or Product Discovery prioritization efforts. This way, the discussion around what to do next starts with the goal and not the solution. From there, you can then do one of two things:

1. You can go broad again and start to think of new solutions you could pursue to achieve the goal because you have evidence that this goal is worth solving (e.g., qual/quant data or a clear connection to your Product Strategy Choices).
2. Or, if there's no evidence supporting this goal, you can dismiss it for good. It shouldn't be a priority.

Now that we see why Idea Backlogs are primarily useless let’s look at how the Mission Briefing can help you avoid unnecessary feature requests.

How to focus on the Problem Space of Product Discovery through the Mission Briefing

Almost every product manager knows the situation: Your boss or a stakeholder approaches you with particular features (i.e., solutions and not problems) they want you to add to the product.

By "coincidence," this feature also seems to be magically connected with a high-level company KPI, which is super important right now. But after giving in and shipping this feature, one of two things happens: It's either impossible to track its contribution to the company level KPI, or you’re forced to use a set of pretty but meaningless vanity metrics to measure its success. That applies to measuring KPIs the "regular" way and to using OKRs in Product Management.

It's either impossible to track a feature's contribution to the company level KPI, or you’re forced to use a set of pretty but meaningless vanity metrics to measure its success.

Here's why stakeholders and management love to talk about solutions: At the end of the day, they're like your users. They don't know what they want. But talking about particular features gives them a sense of control and predictability about what is about to happen. It is their way to remain involved in the product development process continuously.

The key challenge for product teams is determining where this new feature request comes from. You have to reverse engineer your stakeholder's feature requests back to the 'jobs' they want you to fulfill for them or your target user.

Utilizing Collaborative Product Discovery Alignment

The best way to do that? Invest in collaborative alignment. One framework which I've seen work effectively over and over again is the Mission Briefing.

The Mission Briefing is a 5-level alignment framework that aims to clarify essential cornerstones of a Product Discovery Mission without discussing feature details.

The five levels of the Mission Briefing aim to provide a holistic look at the work ahead:

1. The Context
2. Strategic Fit of a Problem Space
3. The intent of the Product Team
4. Areas of Uncertainty
5. Boundaries

There's a lot of value in using this outline to structure thoughts on a problem space for yourself. But the real power comes from co-creating a Mission Briefing. By getting your bosses and team members in the room, you will establish a shared understanding of where to go next.

But don't treat the Mission Briefing as a group brainstorming. Instead, set it up like an ideation workshop with enough time for individuals to structure their thoughts. This way, you can avoid group thinking and get an understanding of everybody's perspective.

Dealing with new Feature Ideas during Product Discovery

No matter how much you try to stay focused on understanding the problem space first during Product Discovery, somehow, the F-word finds its way into your team’s conversations. Yes, I’m talking about features.

Whether it’s inspired by an early morning epiphany, a recent competitor release, or an example mentioned by a user during an interview session, we get exposed to solutions. While there’s nothing inherently wrong with that, discussing features should have a dedicated time and place - Especially during the early phases of Product Discovery.

Discussing features should have a dedicated time and place - Especially during the early phases of Product Discovery.

What can you do to avoid having the team converge on a solution prematurely, without censorship or a “Feature Jar”?

First, the whole team should be on board with the structure you set up for your Product Discovery. During the alignment phase, it’s essential to talk about the areas of uncertainty and where you want to focus on next.

And to avoid unnecessary lead times for research or ideation sessions due to spontaneous planning, scheduling these ahead can be helpful. This way, you can point impatient team members (or stakeholders) to a specific occasion during which it makes sense to talk about solutions in more detail.

Maybe it’s a Design Sprint or “just” a structured ideation session. Both will provide plenty of room to write down and share feature ideas. Make sure to think of how you want to incorporate these approaches into your Discovery and bring in an experienced facilitator to make sure the conversation stays focussed and doesn’t just become an “idea presentation show.”

The Myth of the "Really Great Idea"

But what if the question arises about what to do “with really great ideas?”

First, this might be a good time to remind people how you want to work as a team. If you treat the Discovery as a joint effort (with different degrees of involvement per phase), deciding which ideas to focus on should be the natural result of the process.

It shouldn’t just be one individual pitching ideas. Instead, you want to structure the idea generation process so that everybody involved has the same context as a starting point and an equal share in getting heard.

You want to structure the idea generation process so that everybody involved has the same context as a starting point and an equal share in getting heard.

I recommend not keep a public backlog for new ideas. The reason is that this can lead to prematurely picking a solution and getting attached to it.

If one of your team members is so full of creative energy that he or she continually thinks of potential ways to solve existing problems, that’s great. But make sure this person keeps these primarily to themself, but encourage them to bring this energy and passion into the solution space when the team “gets there.”

Remember, at the very core; Product Discovery and using Product Discovery Resources is about answering two questions:

1. Is this a problem worth solving?
2. Is this a solution worth pursuing?

Both questions are important, but skipping the first one without actual evidence, will lead to less valuable answers to the second question.

That's why I break down the different key phased of Product Discovery as a range of options Product Teams can choose from in this video: