End Reinventing the Wheel: An Idea Taxonomy and Knowledge‑Reuse System to Make Past Experiments Discoverable

There's a specific kind of pain that shows up in innovation programs after about 18 months of running. Someone pitches an idea in a quarterly sprint. Half the room nods along excitedly. Then one person in the corner says, "…didn't we try something almost exactly like this in 2023?" Nobody's sure. There's a link to a dead Confluence page somewhere. The pilot data lives in a spreadsheet on someone's laptop who left the company. So the team runs it again anyway, spends six weeks and a modest chunk of budget, and lands roughly where the last team landed.

That's not an idea problem. That's a retrieval problem.

Most programs are obsessed with generating more ideas. Very few invest in making the ideas they already tested discoverable. And the gap between those two failures is enormous — a rediscovered experiment costs you money twice. Once to run it, once to run it again without knowing it was already run.

This post is narrowly about that: the idea taxonomy and knowledge‑reuse machinery that turns a graveyard of past experiments into something a team can actually search, cluster, and reuse. Not idea generation. Not evaluation. Just the boring, high‑leverage infrastructure that stops you from paying for the same lesson twice.

The Retrieval Failure, in Detail

Here's how it usually breaks. Not because people are lazy, but because the system quietly rots.

When an idea program launches, everything gets dumped into one bucket with freeform tags. Someone tags a pilot "customer retention." Someone else tags a nearly identical one "churn," another "loyalty," another "win‑back." Six months later there are four tags covering the same territory, none of them connected, and a search for "retention" returns a third of what's actually relevant.

The pattern underneath this: tags accumulate faster than structure does. Every contributor adds vocabulary. Nobody prunes it. Within a year you don't have a taxonomy, you have a tag cloud — and a tag cloud is functionally the same as no tags at all, because you can't predict what word past‑you used.

A second failure layer sits on top of that. Even when the idea record exists, the outcome doesn't travel with it. The idea is findable. What happened when you ran it is not. You find a card that says "test SMS reminders for onboarding" and it tells you nothing about whether it worked, why it was killed, or what the team learned. That missing outcome layer is what makes reuse impossible even when discovery succeeds.

Start with a Taxonomy That Has a Spine, Not a Tag Cloud

A working idea taxonomy needs two different kinds of labels, and mixing them up is the most common structural mistake teams make.

The first kind is the fixed spine — a small, controlled set of dimensions that never grows organically. Think 4–6 facets, each with a closed list of values. The second kind is freeform tags, which anyone can add freely for nuance. The spine gives you reliable retrieval. The tags give you flavor. Problems start when teams try to make freeform tags do the spine's job.

The magic isn't in these exact categories — adapt them to your context. The magic is that every one of these is a closed list. You can't invent a new "mechanism" on the fly. If you genuinely need a new value, that's a deliberate governance decision, not a Tuesday‑afternoon impulse. This is the single biggest lever for keeping search reliable, because a searcher and a tagger are now guaranteed to use the same words.

The freeform tags live alongside the spine, not instead of it. "SMS," "Q3‑campaign," "region‑EMEA" — fine. Let those grow messy. They're the fuzzy secondary net, not the primary one.

“

Pro-tip: Treat spine changes as governance decisions, not casual edits.

Teams resist closed lists because they feel restrictive. That resistance is worth pushing back on, because the restriction is the whole point. Freedom in tagging is exactly what produced the tag‑cloud swamp in the first place.

Automated Clustering: Let the Machine Group What Humans Tag Inconsistently

Even with a decent spine, humans tag inconsistently at the margins. This is where automated clustering earns its keep — not to replace the taxonomy, but to catch what slips through it.

1. 1
   Cluster on the spine first. Group everything that shares problem domain + mechanism. This is deterministic and cheap. Two ideas both tagged Retention + Automation land in the same neighborhood automatically.
2. 2
   Cluster on semantic similarity within neighborhoods. Inside that Retention + Automation group, compare the actual text of the idea descriptions. An idea called "auto win‑back emails" and one called "lapsed‑customer re‑engagement sequence" will read as near‑identical even if their freeform tags never matched.
3. 3
   Surface near‑duplicates for human review — don't auto‑merge. The system's job is to say "these five look related, is this a duplicate?" A person decides. Auto‑merging is how you lose the nuance that made two ideas genuinely different.

This is closely related to keeping the backlog clean in the first place. If you haven't sorted out your deduplication and hygiene rituals, clustering will just organize your mess more efficiently. The groundwork in backlog hygiene rules and deduplication workflows is really the precondition for any of this to hold up over time.

Here's a quick sketch of how that workflow looks in practice.

Modern AI‑assisted platforms handle the semantic step reasonably well — embedding the idea text and flagging conceptual overlap that tags would never catch. The useful framing isn't "AI organizes our ideas." It's narrower: the clustering pass runs quietly in the background and hands a human a short list of probable relatives to confirm. It removes the manual scanning, not the judgment.

The Reuse Decision Table — the Piece Almost Everyone Skips

Finding a past experiment is only half the job. The harder question is: what do I do with it? A found experiment can mean "stop, we already proved this," or "reuse the setup, context has changed," or "ignore, this died for good reasons." Without a rule for that decision, teams treat every rediscovered idea as a debate, and debates cost more than the experiment did.

The value here is that it forces the kill rationale and context assumptions to have been captured in the first place. A decision table with no underlying outcome data is just a pretty grid. Which brings it back to the same discipline point: your taxonomy has to capture outcome and reasoning at close‑out, or none of the reuse logic has anything to work with.

Worth flagging: the "Killed / context has changed" row is where most real reuse value hides. Ideas that died because of a technical constraint, a budget freeze, or a missing integration in 2023 are frequently alive again in 2025 or 2026 for reasons nobody re‑checks. The table's job is to make someone check.

Search Tuning and Discoverability, Without Over‑Engineering It

You don't need a fancy search stack. You need search that respects the spine. A few tuning rules that matter far more than the search technology itself:

1. 1
   Weight spine facets above freeform tags. A match on problem domain should rank higher than a match on some ad‑hoc tag.
2. 2
   Make outcome status a filter, not a search term. People usually want "retention experiments that were killed" or "…that scaled." Bury that behind free text and they won't find it.
3. 3
   Index the kill rationale and learnings text. This is where the reusable knowledge lives. If your search only reads titles, you're searching the label on the box, not what's inside.
4. 4
   Show related clusters on every idea record. Discoverability isn't only about the query someone types — it's about surfacing neighbors they didn't know to ask for.

The quiet failure mode here is teams that optimize search relevance while their taxonomy is still a swamp. Better search over bad structure just returns bad results faster. Fix the spine first.

A Short Real Scenario

A mid‑sized B2B software company — around 60 people, a fairly active internal innovation program — had run something close to 140 logged experiments over about two years. Their tagging was entirely freeform. When a product team proposed a self‑serve onboarding pilot, nobody realized a similar one had run 14 months earlier and been killed because the analytics instrumentation wasn't ready.

They ran it again. Spent roughly six weeks and somewhere in the range of $9k–$12k in team time and tooling before hitting the exact same instrumentation wall. Same lesson, second invoice.

The fix wasn't dramatic. They imposed a five‑facet spine, backfilled outcome status on the existing 140 records over a couple of weeks, and added a mandatory kill‑rationale field at close‑out. Automated clustering then flagged around a dozen near‑duplicate pairs they hadn't known about. Over the following two quarters, the innovation lead estimated they avoided re‑running three or four experiments that the old system would have quietly waved through — a rough saving in the low tens of thousands, mostly recovered team time rather than hard cash.

Nothing about that required a big platform. It required deciding that the spine was closed, and that no experiment gets marked done without an outcome and a reason.

When This Is Worth Building — and When It Isn't

When it makes sense: You've been running a program long enough to have real history — somewhere around 50+ logged experiments — and you're starting to hear "didn't we try this?" in meetings. That sentence is the signal. The cost of building the taxonomy is trivial next to the cost of one rediscovered pilot.

When it's a bad idea: You're six months in with 15 ideas. Building a taxonomy now is premature optimization. You don't have enough history to reuse anything, and you'll spend more time debating facet names than you'll ever save. Keep it loose until the volume forces the issue.

Who should not do this: Teams that won't enforce close‑out discipline. If outcomes and kill rationales never get captured, a taxonomy is decoration. The reuse layer is only as good as the data people are willing to log when an experiment ends — and if that habit isn't there, fix the habit before the schema.

Where This Sits in the Bigger Picture

Knowledge reuse isn't a standalone project. It's the memory layer of your operating model — the part that turns a sequence of one‑off experiments into an organization that actually gets smarter over time.

If your broader system for moving ideas through funding and scaling isn't defined, this taxonomy will float without an anchor. It's worth reading alongside the wider innovation operating model blueprint, because the taxonomy is the connective tissue that makes the rest of that model compound instead of reset.

The programs that pull ahead aren't the ones generating the most ideas. They're the ones that stop paying twice for the same lesson. A closed spine, a background clustering pass, a reuse decision table, and a stubborn refusal to close any experiment without recording what happened — that's the whole system. Boring, cheap, and quietly worth more than most of the ideas it helps you avoid re‑running.