Context

Petra Wille introduces a simple technique she calls trash can tracking: marking discovery and delivery boards with a trash can symbol wherever a team deliberately decides not to pursue a customer problem or a proposed solution. Teresa Torres pushes on it in real time, working out what an empty trash can versus a full one actually signals about a team's discovery culture. The conversation matters to PMs because it turns "are we doing real discovery?" and "are we innovative enough?" into something you can literally see on a board, instead of a vague cultural question nobody can point to.

The Big Idea

How often a team throws customer problems and solutions into a "trash can" is a visible signal of whether real discovery is happening, but an empty trash can isn't automatically bad and a full one isn't automatically good.

The signal only means something once you read it in context: a team with a sharp strategy might legitimately have an empty problem trash can because bad-fit problems never make it onto the board at all. The technique's value is that it forces the conversation about why the trash can looks the way it does, rather than answering the question by itself.

Key Insights

The golden trash can marks wasted delivery work

Petra's core example: a feature goes all the way through discovery, gets built, QA'd, released through every cycle, and put in front of users, then the team learns nobody uses it, hates it, or it just isn't solving the customer's problem. The "golden trash can" sits at the end of the delivery board for exactly this outcome, and reaching it usually means real discovery didn't happen, otherwise the team would have caught the bad idea earlier. The two steps most teams skip once they get here are acknowledging that the feature failed, and actually removing the dead code rather than leaving it in the codebase.

Discovery needs its own visible trash cans, earlier

Petra places a second, earlier trash can on the discovery board itself, arguing discovery work should be as visible as delivery work, whether that's one board or two closely linked ones owned by the team. Within discovery she distinguishes two trash cans with different meanings:

• Problem-space trash can: a customer problem gets explored (how many customers have it, how big is it) and then deliberately dropped, for example because only a small, low-value slice of customers has it, or because pursuing it (say, chasing a competitor's new feature) would need a partner the team doesn't have and can't find quickly.
• Solution-space trash can: a prototype or click-dummy actually gets tested with real users in scenario-based interviews, and the team learns either that the underlying problem wasn't real after all, or that the specific solution doesn't fit. Petra's live example: users increasingly expect to just talk to a product rather than fill out a form, so a solidly designed form can still land in this trash can once that expectation makes it the wrong solution.

Not throwing anything away can be a red flag, or a good sign

Teresa's initial read is that a team with an empty trash can is worrying: if you can't say no to any customer problem, that suggests either weak strategy (nothing is being filtered out) or a lack of psychological safety (nobody feels safe telling leadership or sales that a requested problem isn't worth solving). But she then flags the opposite reading: if a team already has a clear vision and strategy, every problem reaching the board may have already passed that filter before it ever got written down, so an empty trash can there could mean the filtering is working upstream, not that it's missing. Petra agrees the two readings aren't mutually exclusive, and says telling them apart takes real context about the specific team and organization, not a formula this technique alone can supply.

The two discovery trash cans are easier and harder to read

Petra says the later, solution-space trash can is the easier one to diagnose: if it stays empty, the team almost certainly isn't comparing and contrasting multiple solutions or thinking in options, which is a clear symptom of weak discovery on its own. The earlier, problem-space trash can needs more context to interpret, because (per the insight above) its being empty could mean either a strategy gap or a strategy working well, and telling those apart takes a senior product leader's judgment about that specific team, not a rule you can apply from the outside.

Bubbling up problems needs psychological safety

Teresa and Petra agree the input side matters as much as the filtering: an organization needs every channel (customer care, sales, engineers, interns, board members, customers) able to surface a candidate problem, which then gets assessed quickly against the product vision and strategy. If problems aren't bubbling up in the first place, or if there's no shared framework for assessing the ones that do (weighing the classic risks of software development plus the opportunity cost of not solving it), the trash can has nothing to sort, and that absence is itself the thing worth investigating.

Mental Models & Frameworks

Trash can tracking

A lightweight visual convention for task boards: attach a trash can symbol to columns or stages where a team can deliberately abandon a problem or solution, then treat what lands (or doesn't land) in each trash can as a diagnostic signal.

• Golden trash can (delivery board): work that shipped, was measured, and failed to deliver value, then had its code removed. Wanting to avoid landing here at almost any cost is the whole point of doing better discovery earlier.
• Problem-space trash can (discovery board, early): a candidate customer problem, assessed and deliberately dropped before real solution work starts.
• Solution-space trash can (discovery board, later): a tested prototype or design, dropped after real user testing shows the problem or the specific solution doesn't hold up.

Petra's real-time image, added mid-conversation: put the golden trash can (something to celebrate) on the discovery board, and use a dump truck or demolition image on the delivery board instead, since removing shipped, failed code is closer to tearing down a building than quietly binning an idea. Use the technique by literally marking these stages on your team's board (physical or virtual) and periodically asking, as a team, what's landing in each one and what that says about your discovery.

Practical Application

Add trash can markers to your own boards

Pick a discovery board (or add a lane to an existing one) and a delivery board, and mark specific stages with a trash can symbol: one for problems dropped after early assessment, one for solutions dropped after user testing, and one at the end of delivery for shipped work that measurably failed. Review what's landing in each on a regular cadence, not just when something obviously goes wrong.

Diagnose an empty trash can before assuming it's fine or broken

If your team's problem-space trash can is empty, don't default to either "great, our filtering upstream is working" or "bad, we have no psychological safety." Bring in someone with real context on the team (a senior product leader who knows the org, the strategy, and how problems actually get surfaced) to help tell which explanation actually fits, since the technique alone can't distinguish them.

Require the golden trash can to actually remove code

When a shipped feature is confirmed to have failed (no adoption, no impact on the metric it targeted), treat "delete the code" as a required, tracked step, not an optional cleanup. Petra's point is that most teams stop at acknowledging the failure and never do the removal, which is the part that would actually make a difference to the codebase.

Track the ratio of trash to shipped work, not just the count

Watch how much moves into your solution-space trash can relative to what ships. If almost nothing ever gets tested and dropped, that's a sign the team is designing one option and shipping it rather than comparing multiple solutions, which Petra calls a clear symptom of weak discovery on its own, independent of the harder-to-read problem-space trash can.

Bottom Line

Trash can tracking makes discovery visible by literally marking where customer problems and solutions get deliberately abandoned, but the resulting signal (a full or empty trash can) only means something once you know the team's strategy, culture, and psychological safety well enough to interpret it, so the technique's real value is forcing that conversation, not replacing it.