Pipeline Brief
A micro-SaaS I researched, designed, validated, and killed — and what the six weeks taught me about language, credibility, and knowing when to stop.
This project was killed on purpose. The kill decision is the outcome — evidence of validation doing its job before six months went into being wrong — not a setback to recover from.
- My role
- Product Designer (solo project)
- Duration
- 6 weeks
- Process
- Research → Concept → Validation → Kill decision
- Year
- 2026
- Status
- Killed at validation stage
- Outcome
- Language framework published as a Medium essay
The problem I went looking for
The risk isn't bad data. It's indefensible language about that data.
I'm a product designer — I don't work in demand gen. But I became interested in a specific gap: the distance between what pipeline data shows and what people say about it.
Most demand gen leads at small B2B SaaS companies report pipeline weekly to executive leadership. They pull data from three or four platforms that never agree, reconcile it by hand, write a narrative summary, and send it to people who will quote that summary back to them months later when the numbers shift.
The data problem is annoying but manageable. The language problem is where careers get damaged. “Google drove 7 new deals this week” is a causal claim. The data supports association, not causation. But at 8am on a Monday, with a CRO who wants clarity for the board, “drove” is what comes out. Two months later a different attribution window tells a different story, and the old update is on record.
Attribution conflict
Three or four platforms that never agree, reconciled by hand every week into one number that has to hold up in a board meeting.
Inconsistency
The same metric described three different ways across three weeks — because the language is improvised under pressure, not governed by a rule.
Overclaim
“Drove,” “caused,” “because of” — causal words the data can't support. The claim is on record long after the attribution window has shifted.
Three failure modes, each named from real war stories in the research
The insight that shaped everything
Radiologists already solved this problem.
While researching how domain experts communicate under uncertainty, I found a structural parallel that reframed the whole thing.
A radiologist reads a scan — inherently ambiguous data with multiple interpretations — and produces a report designed to survive cross-examination. They don't write “the patient has cancer.” They write: “There is a 12mm hypodense lesion. Cannot exclude malignancy. Recommend follow-up. Clinical correlation advised.”
Every word is chosen for defensibility. The language separates what the scan shows from what it might mean from what the physician should do — three layers, clearly labeled. And silence (“no significant finding”) is a valid result. The parallel to pipeline reporting was exact.
| Radiology | Pipeline reporting |
|---|---|
| Findings | Observable associations |
| Impressions | Directional assessment |
| No significant finding | No clear signal this period |
| Cannot exclude | Insufficient data to assess |
| Recommend follow-up | Monitor persistence before adjustment |
| Clinical correlation advised | Operational context required |
I called this the language discipline framework — vocabulary rules that prevent causal overclaims, enforce structural consistency, and default to silence when the data doesn't support a finding. This became the conceptual core of the product: not a dashboard, not an attribution tool, but a language layer sitting between messy CRM data and the executive communication that depends on it.
The product thesis, in three sentences
What you'd write
Google drove 7 new deals this week.
What the memo says
7 opportunities showed observable association with Google Search within a 14-day influence window.
What you'd write
LinkedIn isn't performing. We should cut spend.
What the memo says
LinkedIn opportunity count declined to 3. No measurable pipeline effect from the reduction to date. Monitor persistence before adjustment.
What you'd write
Organic is flat — nothing to report.
What the memo says
Organic / direct: no meaningful delta. Consistent with the 4-week average. No clear signal this period.
Research: validating the problem
Eight out of eight recognized it. Then they split into three camps.
Before designing anything, I needed to know the problem was real to the people who live it. I posted to r/demandgeneration — 15,000 professionals — describing the problem from the inside and asking if others dealt with it.
Every respondent recognized the problem. Zero pushback — nobody said “you're overthinking it.” But the thread split into three distinct behavioral camps, and that split became the most important research finding of the project.
“Just pick one source and commit”
Solved the problem with a behavioral decision — pick HubSpot, footnote the rest, stay consistent. They'd traded accuracy for sanity and weren't looking back. The free workaround felt sufficient.
Not buyers.
“I've built a manual system and it's exhausting”
Rejected the Camp A trade-off and independently built elaborate processes: methodology headers, trend-based language, proactive monthly syncs. One had even arrived at “LinkedIn-associated deals” — almost my exact framework — through their own trial and error.
The target customers — already paying in weekly effort.
“You need better attribution tooling”
Reframed the language problem as a data problem and recommended attribution platforms.
The gravitational pull every positioning decision had to work against.
Industry research corroboration
Beyond the thread, I mapped the existing discourse — Energize Marketing's 2026 State of Demand Generation (71% of leads measured on pipeline, most lacking operational consistency), McKinsey's 2025 CEO–CMO research (agreement on top metrics only half the time), Transmission Agency's work on inconsistent B2B language, and a run of LinkedIn posts from demand gen leaders and fractional CMOs.
The pattern was consistent: the problem is widely recognized, the prescriptive advice is always behavioral (“be more disciplined,” “pick a model and stick with it”), and nobody has productized the solution.
Design decisions
The landing page was the design artifact — not the product.
Pipeline Brief was designed as a Google Sheets add-on: connect HubSpot, Google Ads, and LinkedIn via OAuth, reconcile weekly on consistent influence windows, generate a memo draft in the framework's language, and let the user add operational context before publishing. Sheets over a standalone app was a deliberate choice — data transparency and build speed — not a constraint.
Three landing pages, three positioning pivots
I built the landing page first — not to launch, but to force clarity. If I couldn't explain Pipeline Brief in five sections, the concept wasn't clear enough yet.
Google Sheets productivity tool
Framed it as a reporting add-on. Soft language (“stories,” “insights”). Led with the delivery mechanism, failed to communicate the stakes.
Credibility-grade memo system
Introduced audit-grade language and the ICP filter, and cut causal claims from the copy itself. Closer — but the demo showed output without showing the transformation that produced it.
The fake-door test page
Stripped to five sections, one email field, two form fields. Built for demand validation, not conversion optimization. Every section had a single job.
The “I can do this myself” problem
The original demo was a single mock — a reconciled sheet on the left, a narrative sidebar on the right. The problem: a demand gen lead saw a pivot table and a ChatGPT summary. The hard parts — reconciling three contradictory attribution sources, writing in influence-based language under pressure, holding structural consistency across twelve weeks — were invisible. The mock collapsed the distance between where the user was and where the memo put them. That distance was the product.
The fix was a three-layer progression that showed the work, not just the output:
Layer 1
What your data sources report
Three platform cards with contradictory raw data — HubSpot 22 contacts, Google Ads 18 conversions, LinkedIn 9 leads (4 overlapping). A red conflict bar: “These numbers cannot be presented together without reconciliation.” The visitor thinks: yes, this is my Sunday night.
Layer 2
Reconciled data + memo draft
The same data after reconciliation, annotated with the exclusion logic (18 conversions → 7 matched, 11 excluded: 6 form-only, 3 duplicate, 2 no deal), the memo sidebar showing influence-based language. Now they can see the work that produced the clean table.
Layer 3
What leadership receives
The published Slack memo — reviewer's context woven in, methodology disclosed in the footer, source links attached. The full arc: chaos → reconciled sheet → defensible memo with a name on it.
Validation design
I designed the validation as carefully as the product.
Building a product nobody validates is easy. The point of validation is to find out you're wrong before you build — so the instruments had to be honest.
Fake door test
The landing page was the primary instrument: two fields (work email, CRM used) and a Calendly link on the confirmation page. No pricing, no feature list — just the problem, the transformation, the language proof, and a form. Typing your email is a higher commitment signal than a comment or a reaction.
Reddit as research
The post never mentioned Pipeline Brief. It described the problem from the inside — 90 minutes every Monday, three dashboards that disagree, language quoted back in budget meetings — and tracked responses against three criteria: does the problem resonate, does the language framing land, would they pay.
Direct conversations
I DM'd the two highest-signal respondents from an honest position — product designer, not demand gen — to avoid the credibility collapse of faking peer status. One engaged substantively. That conversation became the kill signal.
Validation scorecard
8 / 8 on problem recognition · 5 / 8 on the language-specific framing · 2 / 8 on a willingness-to-pay signal. The problem was real. Paying for a solution was not.
The kill decision
One honest no from your best lead beats eight polite nods.
My strongest lead was Camp B — the person who'd independently built a manual version of Pipeline Brief, who understood the language problem most precisely. When I asked if a product that automated this would be worth paying for, they gave me the clearest answer I could have received.
“I'd probably lean in the direction of LLM + n8n. I would just create it myself and be happy with that 90% product.”
— My strongest Reddit lead
The last 10% — the language discipline, the structural consistency, the silence-as-a-finding defaults — was intellectually appreciated but not financially painful. So I stopped building Pipeline Brief. Continuing after that signal would have been sunk-cost reasoning: “I've built the landing page, done the research, designed the memos, I should keep going.” But the point of validation is to find out if you're wrong before you build. I found out. The right response is to stop.
The decision required two honest separations:
“Real” ≠ “people will pay”
Both were true at once. The attribution-language problem is real — every source confirmed it. But the workaround (LLM + n8n, manual discipline, or just accepting 90%) was accessible enough that the last 10% didn't justify $79/month.
Finding the buyer is a product problem
Camp B was my target — but Camp B was technical enough to DIY. The non-technical lead who genuinely couldn't build it existed, but couldn't be found through my channels. If you can't find your buyer during validation, you can't find them during acquisition.
What survived
The insight didn't need the product to be valuable.
The language framework — the radiology analogy, the terminology mapping, the practical principles — was published as a Medium essay. Any demand gen lead can apply it manually starting Monday morning. The essay is also a research artifact: traction in demand gen communities is retroactive validation of the problem; silence is one more confirmation the market wasn't as ready as the thread suggested.
The validation method, reusable for any 0-to-1 idea
- 01Post the problem statement in a relevant community before building anything.
- 02Categorize responses by behavioral camp, not sentiment.
- 03Build a fake door before building a product.
- 04Find the strongest possible lead and have one direct, honest conversation.
- 05Set a kill criterion in advance and honor it.
Reflections
What I'd do differently.
Start with the buyer, not the problem
I validated the problem across a broad community. I should have first validated whether the specific buyer I needed — non-technical demand gen leads too junior to have analytics support — was reachable and concentrated enough to build a business around.
Test the output before the concept
The concierge phase — producing memos by hand for a few paying customers — should have come earlier. One real Pipeline Brief memo in front of my strongest lead before the DM might have reframed the “I'll use n8n” objection, or confirmed the kill faster. Either way: output before concept.
The delivery model was wrong for the ICP
A Google Sheets add-on assumes comfort with Sheets. The most technical buyers were the ones most likely to say “I'll use n8n”; the less technical ones might not be Sheets-first. It solved for build speed and transparency, but may have created friction for the actual buyer.
Product design isn't wireframes. It's the sequence of decisions that determines whether something should exist and what form it should take — research design, problem framing, positioning, information architecture, validation, and a kill decision. None of it required a line of code or a pixel in Figma.
The most valuable skill in 0-to-1 work isn't ideation or execution. It's the discipline to find out you're wrong before you've spent six months being wrong.
Next · 01