Where Good Experiments Come From: Building a Growth Idea Pipeline

Good experiments come from a quantified problem in the funnel, not a features wishlist: pick the metric that's underperforming, trace it to the step where users actually drop off or hesitate, and let user research explain why before you ideate. Idea generation becomes a repeatable system - a lever framework plus a running signal inventory - instead of a monthly scramble for test ideas.

Quick Answer: Source experiment ideas from three inputs - funnel data (where the metric breaks), user research (why it breaks), and qualitative friction (what it feels like to hit it) - then route every idea through a lever-based framework tied to a specific funnel-stage metric before it enters your backlog.

Why Feature-Wishlist Backlogs Produce Weak Experiments

A backlog stocked from a features wishlist produces experiments that are easy to build and hard to justify, because nobody can trace the idea back to a quantified problem. The fix isn't more brainstorming - it's a sourcing discipline that starts from the funnel, not the roadmap. Every idea should answer "which metric, at which stage, is currently worse than it should be?"

Most growth teams don't lack ideas - they lack traceability. A stakeholder suggests a redesigned onboarding carousel, an engineer wants to try a new empty state, a competitor shipped a referral widget - and all three land in the same backlog with equal footing, none of them anchored to a number that's actually broken. When priorities get squeezed, the backlog collapses into whichever idea has the loudest internal advocate.

This is also where growth PM work diverges from core product management, which is covered in more depth in the growth PM vs. core PM skill stack comparison. A core PM roadmap is organized around shipping features that satisfy a spec. A growth idea pipeline is organized around a metric that's underperforming relative to a benchmark, a cohort, or a prior period - the feature is just the vehicle for testing a hypothesis about why.

The Cost of an Untraceable Idea

An idea with no metric attached fails in three predictable ways, and each one wastes a build-test cycle you can't get back:

1. It can't be sized. Without a baseline metric, you can't estimate the ceiling on impact, so prioritization becomes a gut call dressed up as a score.
2. It can't be diagnosed after a null result. A flat test tells you nothing if you never stated which input metric it was meant to move.
3. It can't compound. Traceable experiments build a shared map of the funnel's weak points; untraceable ones just accumulate as isolated anecdotes.

Ronny Kohavi's published research from Microsoft's experimentation platform - summarized in Trustworthy Online Controlled Experiments - is a useful reality check here: even in mature programs, a clear minority of tested ideas produce a statistically significant positive result, with a large share landing flat or negative. If most of your ideas are going to fail anyway, the ones worth running are the ones that teach you something regardless of outcome - and that only happens when the idea started from a real, quantified gap.

The Lever-Based Ideation Framework: Mapping Funnel Stages to Input Metrics

A lever-based framework forces every experiment idea to name the funnel stage it targets and the specific input metric it's trying to move, before anyone discusses a solution. This single constraint - metric first, idea second - is what separates a growth idea backlog from a features wishlist, and it's the practice most directly tied to funnel ownership as leverage for a growth PM.

Start from a funnel model. Dave McClure's AARRR framework (Acquisition, Activation, Retention, Revenue, Referral) - often called "pirate metrics" - remains a reasonable default skeleton because it maps cleanly onto most consumer and B2B SaaS funnels alike. Adapt the stage names to your product, but keep the discipline: one stage, one owning metric, one lever category.

A lever is a category of mechanism, not a specific test - "friction removal," "trigger timing," and "message match" are levers; a specific carousel redesign is one instance of a lever. This separation matters because a lever that keeps producing wins deserves more idea volume, and a lever that keeps producing nulls deserves fewer swings, independent of which specific test won or lost.

Reading the Table as a Diagnostic, Not a Menu

Don't treat the table as a checklist to run top to bottom. Instead, pull your actual funnel data and ask: which stage has the largest gap between its current metric and either a historical baseline, a comparable cohort, or an industry benchmark? That gap - not team enthusiasm - decides where you spend the next quarter's testing capacity.

• If activation input metrics are healthy but retention is declining, your lever budget should shift toward re-engagement triggers, not onboarding polish.
• If acquisition volume is rising but activation rate is falling, you likely have a targeting-quality problem masquerading as a product problem.
• If every stage looks flat, the problem is probably instrumentation, not the funnel - fix measurement before you fund more experiments.

Three Signal Channels: Funnel Data, User Research, and Qualitative Friction

Funnel data tells you where something is broken; user research and qualitative friction tell you why - and a durable idea pipeline draws from all three every cycle, not from whichever channel happens to be loudest that week. Treat them as complementary instruments, each catching what the others miss.

Funnel Data: The Where

Quantitative funnel data is the entry point because it's the only channel that tells you the size of a problem in numbers you can prioritize against. Segment every drop-off by cohort (acquisition channel, plan tier, device, signup date) before you conclude a stage is "broken" - an average conversion rate often hides a healthy majority and a severely underperforming segment.

User Research: The Why

Once a metric flags a stage, structured user research explains the mechanism behind the number. Jobs to Be Done interviewing - the method most closely associated with Clayton Christensen and refined into an interview practice by Bob Moesta - is built for exactly this: uncovering the job a user was hiring your product to do, and where it's failing to do it. The full method is covered in the complete guide to Jobs to Be Done.

Teresa Torres's continuous-discovery practice adds a cadence rule worth borrowing directly: keep a standing habit of at least one customer touchpoint every week, so research isn't a special project you spin up only after a metric alarms you. By the time you need research to explain a funnel dip, you want six months of interview notes already indexed by funnel stage, not a cold start.

Qualitative Friction: The What-It-Feels-Like

Between hard metrics and structured interviews sits a third channel that's easy to under-invest in: unprompted friction signals - support tickets, session replays, in-app feedback, and voice-of-customer notes captured in the moment something goes wrong. Mapping these against the emotional highs and lows of a user's path, using a customer journey emotion curve, often reveals friction at steps a funnel chart shows as merely "average."

Jakob Nielsen's usability research at the Nielsen Norman Group is the classic argument for why this channel punches above its sample size: a small number of qualitative sessions - commonly cited around five - tends to surface a large majority of a product's usability problems, well before a quantitative test could isolate the same issue statistically. Qualitative signal is cheap and fast; it just needs a place to accumulate instead of evaporating in a support inbox.

From Signal to Hypothesis: A Repeatable Template

A signal only becomes a testable experiment once it's written as a hypothesis that names the metric, the mechanism, and the expected direction of change - a one-line idea like "improve onboarding" isn't testable until it's been forced through that structure. The discipline of writing the hypothesis is what turns a hunch into something a team can actually prioritize and later grade.

Use a consistent template so every entry in the inventory is comparable:

If we [change], then [input metric] will [move in direction] because [mechanism, grounded in the signal that sourced it].

For example: "If we defer email verification until after a user completes their first project, then activation rate will increase because verification currently interrupts users at their highest-friction moment, per session replay and support-ticket evidence." Notice the hypothesis cites its source signal directly - that's what makes it auditable later.

Grading a Hypothesis Before It Enters the Backlog

Before an idea is logged, run it through three quick filters:

1. Is the metric named and baselined? If you can't state the current number, the idea isn't ready - go get the baseline first.
2. Is the mechanism falsifiable? A vague mechanism ("users will like it more") can't be disproven by a null result, which defeats the purpose of testing at all.
3. Is the source signal cited? An idea traceable to a specific data point, interview quote, or friction log entry is easier to defend in a prioritization review than one attributed to "team consensus."

Building and Prioritizing the Idea Inventory

A prioritized idea inventory is a living backlog - not a slide deck - where every hypothesis carries its source signal, its targeted lever, and a comparable priority score, reviewed on a fixed cadence rather than assembled fresh before each planning meeting. The inventory's job is to make sure a good idea sourced in March isn't lost by the time your team has bandwidth to test it in June.

Scoring frameworks exist to make prioritization comparable across very different kinds of ideas, not to produce a falsely precise ranking. Sean Ellis - credited with popularizing growth hacking and co-author of Hacking Growth - built ICE scoring (Impact, Confidence, Ease) specifically for high-tempo growth teams that need a fast, low-overhead gut-check rather than a heavyweight model.

Whichever model you pick, apply it consistently and revisit scores when new evidence arrives - a hypothesis that scored low before a supporting interview surfaced can jump the queue once the evidence changes. This is also where idea volume and testing throughput intersect: a backlog with strong lever coverage but a slow build-test-ship loop still starves for output, which is the exact problem addressed in shipping learnings at experiment velocity.

What Belongs in Every Inventory Row

Keep the schema minimal enough that logging an idea takes under two minutes, or people will stop doing it:

• Hypothesis (in the if/then/because format above)
• Funnel stage and input metric it targets
• Source signal (the data point, quote, or friction log entry that generated it)
• Priority score and the date it was last re-scored
• Status (backlog, scoped, running, shipped, killed) and a one-line result once resolved

Keeping the Pipeline Alive: Cadence, Ownership, and Capturing Friction as It Happens

A pipeline stays full when sourcing is a scheduled habit with a named owner, not an ad hoc activity squeezed in before a deadline. Brian Balfour's growth-loops thinking, developed through Reforge, is a useful frame here: loops need a consistent input to keep compounding, and an idea pipeline is no different - it needs a standing weekly or biweekly review where funnel data, research notes, and friction logs are actively re-scanned for new hypotheses, not just re-sorted.

Assign an explicit owner for each of the three channels covered earlier, even if one person covers all three on a small team. This is part of the broader operating discipline described in the complete guide to the growth PM role - growth PMs are frequently the connective tissue between analytics, research, and support, precisely because idea sourcing depends on all three staying current.

Where Prodinja Fits

The hardest channel to keep alive in practice is qualitative friction, because it's captured in the moment and easily lost by the time anyone writes it up. Prodinja's Journals feature is built around that specific gap: it captures Friction entries through real browser voice input, so a PM can narrate what they just observed - a confusing screen, a support call that went sideways, a user hesitating in a usability session - the moment it happens, instead of reconstructing it from memory later.

Those Friction entries accumulate as a running, searchable log that's designed to feed directly into the kind of lever-mapped hypothesis backlog described above. The point isn't the recording itself - it's turning an easily-lost observation into a durable, testable idea rather than a one-off Slack message nobody revisits.

Key Takeaways

• Trace every idea to a quantified funnel problem - a hypothesis that can't name its input metric and baseline isn't ready for the backlog.
• Use a lever-based framework (map funnel stage to input metric to lever category) so idea volume flows toward the stages with the largest measured gaps.
• Draw from three complementary signal channels - funnel data for where, user research like JTBD for why, and qualitative friction for what the moment felt like.
• Write hypotheses in a fixed if/then/because template that cites its source signal, making ideas auditable and comparable later.
• Score with a consistent framework (ICE, RICE, PIE, or Kano) and re-score when new evidence arrives rather than freezing priority at intake.
• Maintain the inventory as a living system with a fixed review cadence and named channel owners, not a document rebuilt before every planning cycle.
• Capture friction in the moment it happens - tools like Prodinja's voice-driven Journal Friction entries are designed to keep this channel from evaporating before it becomes a testable idea.