In many product organizations, the backlog has become a clean trash can.

An idea comes up? Backlog.

A customer request? Backlog.

A non-urgent bug? Backlog.

A discovery lead? Backlog.

A Product Manager's hunch? Backlog.

A sentence overheard in a sales meeting? Backlog.

You throw everything in "so you don't forget." And a few months later, you end up with 300, 500, sometimes 1,000 lines that nobody really understands anymore.

That's not transparency.

That's noise.

A backlog that holds everything clarifies nothing. It only creates the illusion that the information exists somewhere, when in reality it has become unusable.

The backlog shouldn't be a repository of ideas. It shouldn't be a database of customer requests. It shouldn't be a discovery tool. It shouldn't be an archive. It shouldn't be the graveyard of bugs nobody wanted to deal with.

A backlog is a tool for action.

It exists to organize information already mature enough for several people to work on it together.

Transparency Is Not About Showing Everything

The classic argument for putting everything in the backlog is transparency.

"At least everything is visible."

In theory, it's appealing. In practice, it's often false.

A 500-line backlog isn't transparent. It's opaque. Nobody really knows what matters. Nobody knows what's still valid. Nobody knows what's strategic, what's old, what's been declined, what's just an idea, what came from an important customer, what has already been discussed three times over.

Everything is visible, so nothing is legible anymore.

Useful transparency isn't about exposing everything. It's about making decisions understandable.

Why is this topic on the roadmap?

Why isn't that one?

Why is this bug being handled now?

Why does this customer request remain a signal rather than becoming work?

Why was this topic declined?

An immature idea can stay out of the backlog without being hidden. It's simply not yet ready to become a collective object.

You have to distinguish between spaces:

• a product memory;
• a signals database;
• reflection notes;
• decisions;
• rejections;
• a backlog.

Not everything has to become backlog.

Before the Backlog: The Product Manager's Personal Space

Before a topic enters the backlog, it can live elsewhere.

And that elsewhere doesn't need to be standardized.

One Product Manager can work in Obsidian. Another in Apple Notes. Another in Trello. Another in a notebook. Another in a more structured database. The name doesn't matter much: the PM's garden, the airlock, the parking lot, personal notes — it doesn't matter.

As long as the work stays individual, everyone can use whatever tool works for them.

It's even preferable.

The PM's personal space serves to absorb the storm of ideas. You collect there, you connect things, you dig, you let things sit, you delete. Some ideas will mature. Others will disappear. Many never deserve to be seen by anyone else.

That's normal.

A three-line idea dropped in "so you don't forget" has no place in a collective tool. It's not yet ready to command the attention of a developer, a designer, a data analyst, a salesperson, or a C-level.

As long as an idea remains an individual thought, it doesn't need a collective tool.

The Backlog Begins When the Topic Becomes Collaborative

The real rule of entry is simple:

The backlog begins when a topic stops being an individual thought and becomes collective work.

If the Product Manager keeps digging alone, it isn't backlog yet.

If the topic requires a feasibility study, you need to talk to the developers. That's where the backlog can become useful.

If the topic rests on a usage or value hypothesis, you may need to explore the product data with a data analyst. That's where the backlog can become useful.

If the topic requires interface design, you need to work with design. That's where the backlog can become useful.

If the topic comes from support, you may need to bring together support, product, data, and development. That's where the backlog can become useful.

But entering the backlog doesn't mean dropping three lines and asking everyone else to figure it out.

The Product Manager has to get at least a minimum of what's in their head out onto the page:

• why we're looking at this topic;
• which audience is concerned;
• which pain or opportunity is being targeted;
• what value is expected;
• which question needs to be settled;
• which signals already exist;
• what collaboration is needed.

This isn't a bureaucratic checklist. It's the minimum needed to let other people work with you.

A request like "run me a data analysis on this topic" isn't enough. A request like "check whether it's worth it" isn't enough either.

The backlog should enable structured collaboration. It should not delegate a thought that's still fuzzy.

The Backlog Doesn't Replace the Conversation

There's an opposite trap: wanting to formalize everything.

Creating templates everywhere. Adding fields. Imposing checklists. Turning every ticket into a mini-dossier. Writing to cover yourself rather than to work.

That's no better.

The level of detail needed depends on the team, the topic, and the shared context.

When a Product Manager has been working for three years with the same developer, they don't always need to write as much as when a developer joined three months ago.

When the team talks every day, some things can stay verbal.

When the team is new, distributed, or on a risky topic, you have to make more of it explicit.

The notions of Definition of Ready and Definition of Done can help. They provide reference points. But they have to stay alive. They must not become a bureaucracy that replaces judgment.

A developer shouldn't accept a ticket they don't understand.

If elements are missing to assess feasibility, they should ask for them.

If the business context is missing, they should ask for it.

If they don't understand the value, they should say so.

A user story was never meant to replace the conversation. It's meant to trigger it.

The backlog should be thought of the same way.

It structures the conversation. It doesn't replace it.

A Backlog Must Be Bounded

An unbounded backlog contradicts a bounded roadmap.

If the NNL roadmap is supposed to protect the company from spreading itself thin, the backlog can't absorb everything the roadmap turns down.

In a Now / Next / Later roadmap, the Now depends on the team's real capacity. The Next has to stay bounded. Even the Later, which is supposed to represent the field of possibilities, can't hold fifty different directions. Otherwise it turns back into an inventory.

The backlog has to extend this constraint.

There's no point in having a clear roadmap and a backlog that holds all the rest.

Same logic for bugs.

If you apply a zero-bug policy, a real defect must be fixed. If it's not a defect, it can be reclassified. If the topic isn't worth handling, you own that and you throw it out.

But piling up bugs in the backlog for later is sweeping dust under the rug.

You think you're preserving information. In reality, you're keeping a decision you haven't made.

A bounded backlog protects the team's capacity. It also protects mental energy. An infinite list creates a permanent tension: everything you haven't done, everything you might do, everything you're keeping just in case, everything sitting there for no clear reason.

That's not neutral.

A backlog that keeps growing is exhausting.

If I Add, What Do I Remove?

The rule of hygiene should be simple:

If I add this, what do I remove?

To choose is to give up something.

Adding without removing amounts to denying the team's real capacity. It's acting as if time, product attention, developer availability, design capacity, data analysis, and support load were all extensible.

They're not.

A topic can leave the backlog for several reasons:

• the world has changed;
• the business has changed;
• the product strategy has changed;
• product knowledge has advanced;
• the topic is no longer relevant;
• the topic is too weak;
• the topic is off-roadmap;
• the topic never matured.

You have to be able to throw things out.

The backlog shouldn't protect old ideas from deletion. It should protect the team's capacity to act on the right topics.

Old Tickets Rot

The aging of tickets is underestimated.

An idea created today and reread six months later isn't necessarily good memory. It's often stale.

The product has changed. The customers have changed. The market has changed. The priorities have changed. The team has learned. The technology has evolved. AI may have made possible what wasn't, or made useless what seemed important.

Picking up an old ticket can be worse than starting from scratch.

The danger also comes from loss aversion. Because the ticket exists, you want to preserve it. Because someone wrote something, you hesitate to throw it out. Because a request was captured, you want to give it a chance.

But a ticket isn't an asset just because it exists.

An old ticket isn't necessarily memory. It's often a moldy hypothesis.

If the topic becomes interesting again, you can reopen it cleanly. But you have to reassess it in the current context, not mechanically pick up an old formulation.

A Single Backlog to Break the Silos

I don't believe in backlogs split by type of work.

A product backlog.

A technical backlog.

A bug backlog.

A support backlog.

A discovery backlog.

Within a single team, this fragmentation breaks prioritization.

Of course, if several teams work on different scopes, they can have several backlogs or several views. But within a given prioritization space, you need a single backlog.

Why?

Because you don't prioritize categories. You prioritize pains, risks, and value.

A topic coming from support might require support, a data analyst, and a developer.

A product topic might require product and design, with no major technical stakes.

An export topic might require no design, but demand strong business knowledge and technical validation on data processing.

The right reasoning isn't: "which backlog does this topic go in?"

The right reasoning is: "what problem are we addressing, and which people do we need?"

This is also why the bug / feature distinction is often too thin. The customer feels a pain. They don't wonder whether it belongs in the bug backlog, the product backlog, or the technical backlog.

The question is: which pain is a priority given the strategy, the customers, and the real capacity?

A Customer Request Is Not a Backlog Item

Capturing a customer request matters.

But a customer request is not a backlog item.

It's a signal.

Customers are often very good at explaining their problems. They can describe a pain, a constraint, a context, a frustration, a business obligation.

They're far less reliable at proposing the right solution.

So you should treat the request as learning material, not as an execution order.

A customer request can feed the backlog. But it's not automatic.

It can stay in a signals database.

It can be linked to other requests.

It can resurface later.

It can never resurface.

It can fail to match the product strategy.

It can fail to fit the roadmap.

It can concern too isolated a case.

It can be interesting, but not important enough.

The backlog shouldn't absorb every customer request on the pretext of not losing them.

A customer request is learning material, not an execution order.

Tracking Some Rejections Without Recreating a Hidden Backlog

Should you track rejections?

Sometimes, yes.

But tracking a rejection doesn't mean keeping a topic to do.

Some rejections deserve a trace because they create historical knowledge. You turn something down today for a given reason: cost, strategy, feasibility, lack of skills, weak demand, bad timing.

A year later, the decision can change.

The business may have evolved.

The product's position may have changed.

AI may make feasible what was too costly.

The team may have hired a data analyst.

Technical feasibility may have evolved.

In those cases, it's useful to understand why the topic had been turned down.

But not all rejections deserve a trace. Plenty of weak ideas can simply disappear.

If the rejection is structural, recurring, or cross-cutting, it can even become a PDR. You then document the decision, its context, its alternatives, and the conditions that could make it change.

The trace of a rejection should serve memory. It shouldn't recreate a hidden backlog.

In the Age of AI, the Backlog Is No Longer Where You Think

The most important point today is perhaps this one: the backlog is no longer the right place to think about the product.

Tools like Jira, Notion, or their equivalents remain, for the most part, card tools. Souped-up word processors. Spaces where you organize items, statuses, fields, comments.

They can be useful for coordinating action.

But they're very weak for building product thinking.

The AI agents built into these tools sometimes improve a piece of text, rephrase a ticket, offer a summary. That's useful at the margins. But it's not a thinking system.

The real asset is upstream.

A rich product context can contain:

• sources;
• transcribed interviews;
• atomic notes;
• thematic notes;
• glossaries;
• decisions;
• PDRs;
• standards;
• product data;
• SQL queries;
• analyses;
• customer signals;
• links between existing features and missing features.

With AI, this context becomes queryable.

You can ask for the blind spots.

Compare options.

Connect interviews.

Identify recurring patterns.

Generate a SQL query to check a behavior in the data.

Turn an interview into themes.

Link a customer pain to existing or missing features.

Build a ticket only at the end.

In this logic, Jira or Notion become output chains. You push information into them once it's ready to be worked on collectively.

The ticket is no longer where you think.

It's where you push the result of thinking that's already structured.

The Discovery Backlog Is a Bad Container

The "discovery backlog" then becomes a bad concept.

Discovery handles rich signals. It requires comparing, connecting, analyzing, cross-referencing, rephrasing, synthesizing.

A customer interview shouldn't end up directly as a card.

It can be transcribed. Broken down into themes. Linked to pains. Linked to customer stakes. Linked to product stakes. Linked to existing features. Linked to missing features. Cross-referenced with other interviews. Verified against the product data.

A backlog isn't good at doing that.

A list of cards is too thin to carry this work.

Discovery needs a brain.

The backlog is only a tool for action.

Some discovery outputs can obviously end up in the backlog. But only once they become mature enough for structured collaboration.

The backlog shouldn't be where discovery does its thinking.

The Backlog Is Disposable

Finally, you have to accept an unpleasant idea: the backlog is disposable.

A backlog item is useful up to delivery.

After that, it loses much of its value.

Tickets drift out of sync. Specs drift out of sync. Trade-offs change during implementation. The final behavior in production often differs from what was written at the start.

The only lasting reality is what gets delivered.

The source code.

The product's behavior.

The documentation maintained from that reality.

This doesn't mean the backlog is useless. It serves to coordinate. It serves to get several people working together. It serves to move from an intention to an action.

But you shouldn't treat it as a sacred archive.

You should spend the minimum useful time in it.

Enough to collaborate.

Enough to act.

Not enough to produce documentation that will rot.

The backlog isn't a source of truth. It's a temporary coordination aid.

Conclusion

A good backlog doesn't contain everything the company could do.

It contains what the company is ready to work on together.

What's immature stays out of the backlog.

What's a signal stays a signal.

What's rejected can sometimes be tracked, but elsewhere.

What belongs to discovery is worked on in a context system.

What's a real bug must be fixed, not stored.

What enters the backlog must be able to move toward action.

In the age of AI, this distinction becomes even more important. The Product Manager can build a far richer context upstream: sources, interviews, notes, glossaries, decisions, analyses, data, an AI sparring partner.

The backlog stays useful.

But it has to stay in its place.

It's not the brain of the product.

It's not the company's complete memory.

It's not a repository of ideas.

It's a tool for action.

Pour en savoir plus

Zero bug: let's stop managing stockpiles of defects The NNL Roadmap: Aligning Without Scattering Why Organizations Prefer Soft Decisions