WINNER TO REVENUE - framework, protocol, and specification for turning a potentially winning idea into a full-fledged business product or service
Version 3, Oct 29, 2026. Owner: Revenue Test Lab. Status: active reusable method. Reusable across ideas; not tied to any single idea.


1. WHAT THIS IS

This is the reusable method the lab runs after an idea earns a WINNER verdict. It takes a potentially winning idea from verdict to one of three terminal states: LAUNCHED (a scaled offer live, first payment received, repeatability proven), KILLED (a named failed gate with evidence), or PARKED (a named reopen trigger). It is idea-agnostic. The RTL-012 security-check plan is its first instance, not the framework itself; this document exists because a plan for one idea is not a method for every idea.

Inputs: a WINNER from the lab intake (KEEP on both lenses, or strong independent revenue evidence plus a defined bounded test), its review Doc and TTS version, its Idea Tracker row, and its evidence ledger. A KEEP (revenue) enters only if Paul upgrades it in writing.

Output: a gate-by-gate record ending in one terminal state, plus the artifacts and acceptance tests each gate produced.

2. WHERE IT SITS IN THE PIPELINE

Order: a source enters rev-ops for the two-track review; RTL intake scores it through the revenue and content lenses; verdicts are DISCARD, SAVE, KEEP, NEAR MISS, or WINNER; a WINNER triggers the creator sweep. This framework starts there. Content-side winners go to the TOV production pipeline; this framework is the revenue lane.

It reuses existing skills rather than duplicating them: rev-ops decision-standard for evidence rules, naming-architect when an idea becomes a named product, done-means for the completion audit before launch, solve-it for terminal states on open problems, wrap-protocol for prompts Paul hands over, authentic-content-writer for anything written in Paul's voice, tts-script-converter for listening versions.

3. DEFINITIONS

Winner: an idea that passed intake per the rtl-video-intake verdict rules. A winner is a test worth running, not proven money.
Demand signal: dated, buyer-side, independent evidence that people with the problem want it solved. Owners' own posted problems and requests count; proof of purchase is not required. A seller's marketing is supply evidence, not demand.
Buyer signal: behavior toward our specific offer: a qualified reply, a booked call, a paid pilot, or a deposit.
Offer: the smallest sellable promise: named buyer, named problem, named outcome, price hypothesis, and a delivery plan the team can actually run.
Pilot: the first paid delivery, bounded in scope and time. Payment is received before or at pilot start, never after unpaid work.
Launch-ready: the route to money is prepared end to end (offer, page, checkout, booking, fulfillment plan) but no customer has paid. Launch-ready is not a terminal state and is never reported as a verified path to money.
Productized service: the offer plus the repeatable delivery machine: SOP, templates, automation map, unit economics, and a named leverage mechanism or an honest "none."
Terminal state: LAUNCHED (scaled and paid), KILLED, or PARKED. "Still thinking," "next steps," and "launch-ready" are not terminal states.

4. THE SIX GATES

Every idea passes through six gates in order. A gate is a decision with written entry evidence and exit criteria. An idea may not skip a gate, and a gate may not be marked passed on evidence meant for a different gate.

G0, PACKET CONFIRMATION. Confirm the winner packet is complete and honest. Entry: the intake verdict. Work: verify the review Doc exists with per-lens verdicts and readiness stated; the sweep ran if the verdict was WINNER; the tracker row exists and matches the Doc; every demand claim carries a dated buyer-side link; internal mechanics and run details are out of the user-facing record. Exit: packet complete, or gaps closed first. Owner: lab agent. Routine research and verification need no approval.

G1, DEMAND VALIDATION. Confirm demand independently of the intake evidence. Work: re-open every demand URL and confirm it is live and says what the review claims; label any link older than 30 days with its computed age; add buyer-side signals where evidence is thin; run the bounded desk check (for example last30days on the buyer problem, not just the creator) if not already run. Counterevidence counts only when it matches the same buyer, mechanism, and price point. A creator's claim stays a claim whether it supports or undermines the idea. Exit: demand confirmed, or KILLED with the failed gate named.

G2, OFFER ENGINEERING. Design the smallest offer that survives "what happens on a yes." Work: write the offer one-pager (buyer, problem, promise, price hypothesis labeled as hypothesis unless verified comparables exist, delivery plan, capacity check). The delivery plan must be runnable by the current team under the lab's standing constraint: nothing that needs a hire or ongoing manual hours. The capacity check tests fulfillment as well as reach, acquisition, conversion, and expansion; a demand filter that blanket-declines back-office work is refuted by the lab's own capacity examples and is not allowed. Rehearse delivery before selling, using the rehearsal that fits the offer type (section 10). Exit: offer one-pager plus delivery-rehearsal evidence plus Paul's written approval of the offer. The test's data value never justifies a promise the team cannot fulfill.

G3, BOUNDED BUYER-SIGNAL TEST. Run the smallest test that could produce a first buyer signal inside a stated window. Rules: window from the test's own dependencies (pool reach time, buyer decision cycle, approvals waited on) with reasons; success and failure criteria written before launch; informative zero handling; cold pools only, never friends, family, past clients, or warm contacts; the send ramp (10 per day, then 20, then 30, growing only while bounces and complaints stay near zero) sizes the test; Paul approves every new template and every individual send before it goes; dedupe against the Contact Registry and skip anyone touched in the last 90 days; Apollo credits only on validated segments; a hard bounce spike, spam complaint, or opt-out stops the lane while the cause is investigated. Exit: signal achieved (advance), or window closed. On a closed window: iterate once with one named change, or KILLED with the evidence. No open-ended retries.

G4, FIRST PAID PILOT AND FULFILLMENT. Convert the buyer signal into the first paid delivery; the first paid pilot precedes any repeatability proof, so no unpaid production work is required to advance. Work: agree the pilot terms from section 10 (bounded scope, price approved by Paul, payment route, timeline, success criteria, end-of-pilot decision); rehearse delivery first using the rehearsal that fits the offer type, with checkout routes tested without any real charge and no retained fees; collect the first payment; fulfill; record the invoice and receipt. Exit: payment received and fulfillment underway, or revisit the window decision from G3 with the evidence.
G5, REPEATABILITY, PRODUCTIZATION, AND SCALE LAUNCH. Prove the paid delivery repeats without equal increases in operator hours (the scalability criterion, distinct from the no-hire constraint), then scale. Work: write the SOP, templates, and automation map; compute unit economics per delivery; complete two or more paid deliveries total, or a written repeatability case Paul accepts; name the leverage mechanism or record an honest "none"; run naming-architect if the offer becomes a named product or service; take the scaled offer live with Paul's approval of the launch, the pricing, and any spend. Terminal state LAUNCHED requires first payment already received plus repeatability evidence, and carries the done-means completion audit as the finish-line check. LAUNCH-READY remains a non-terminal reporting label for a prepared route, never verified money.

5. OPERATING PROTOCOL (rules at every gate)

Quality and readiness are separate. Rate the opportunity on evidence; state readiness (READY NOW, READY AFTER a named gate, or BLOCKED) beside it. Holds, ramp limits, existing rows, and segment fit set timing and permission, never the quality verdict.

Evidence standard: source status and verification status stay separate. A quote proves what was said, not that the claim is true. Demand evidence is buyer-side, dated, and independent. Verification links the proof and names its scope. A working internal artifact verifies capability, not buyer demand.

Bounded test design: every test states window, success criteria, failure criteria, owner, and what each result means before it starts. Windows are labeled test design, never forecasts. No forecasts from views, followers, creator earnings, or invented funnel ratios.

Terminal states only: every open question ends FIXED with verification, FIX CARD for anything only Paul can do, or NOT A PROBLEM with the evidence in one line. No parked decisions without a reopen trigger.

Reporting: each gate ends with a short gate report appended to the idea's review Doc and mirrored in the tracker row. Paul sees decision asks only, each with the recommendation and its evidence. He never has to audit a trace to find the decision.

Permission boundaries: this framework creates no permissions. Apply the user's current instructions and approvals to every action; analysis, drafting, desk verification, and routine research follow the existing scope. Outreach, spend, publishing, account changes, launches, and any new audience each require Paul's explicit approval at the gate that needs them. A passed gate is a recommendation, never a permission.

6. CONTENT AND PROMOTION PLAN (reusable section)

Every idea that advances past G2 gets a one-page content and promotion plan, because the lab's show is both proof and distribution. Template: (a) the show episode candidates the idea's own tests generate, each with a different thesis than any source creator, a specific audience question, and a proof plan the lab can actually produce; (b) the distribution channels that fit the idea, ranked by buyer density, reach cost, and ramp fit, with exactly one primary channel per test; (c) the measurement per piece, chosen to match the objective: audience learning, saves, qualified comments, resource use, or commercial response, with no invented audience sizes or conversion rates; (d) the handoff: episodes enter the TOV production pipeline, never drafted here. Community rules apply as channel constraints: r/lovable and r/nocode ban commercial replies; job boards including Upwork are closed as channels (rule of Oct 5, 2026); paid offers go to cold pools only. Never manufacture content to rescue a weak revenue idea, and never invent revenue to rescue a good content idea.

7. CHANNEL CHOICES

Choose channels from the buyer, not from habit. Selection criteria: where the named buyer already states the problem, what the ramp and pool rules allow, cost per reachable buyer, and whether the channel can produce a buyer signal inside the test window. The lab's standing channels: cold email from charlie@fullrefit.net under the ramp; the booking funnel infrastructure (Cal.com event type plus payment checkout) as the conversion endpoint; the show as proof and inbound; the demand-signal creator map for where the audience already listens. Integration rule: one offer, one primary outreach channel, one conversion endpoint, one measurement sheet per test; do not run simultaneous uncoordinated pushes. Named exceptions to the cold-pool rule (Barry, Eleanor, Greg) are standing grants, not a pattern to extend. A referral introduced by a paying pilot client is a new channel decision for Paul, not an assumed extension of the cold-pool rule.

8. PARTNER AND INTEGRATION DISTRIBUTION (reusable section)

Distribution through partners and complementary products is a channel in its own right, designed here as a reusable pattern; any named partner is a research candidate, never a claimed relationship or deal. Template: (a) partner selection: complementary products or services the named buyer already pays for or trusts, where our offer is additive rather than competitive; (b) value exchange: what each side gets, stated concretely (revenue share, bundled offer, qualified referrals both ways, integration value), and never promised beyond what Paul has approved; (c) co-marketing formats: joint webinar or workshop, guest episode on the show, bundled pilot, listing in the partner's marketplace or directory; (d) integration mechanism: the lightest real connection that delivers the exchange, from a tracked referral link to an actual product integration, with the build cost named; (e) lead attribution: how partner-sourced leads are recorded and credited in the tracker before the first partner conversation, so credit disputes have no room to grow; (f) permissions: Paul approves any partner outreach, any named partner, and any shared branding, and partner channels are never a workaround for the cold-pool rule; (g) partner failure contingency: what happens to shared leads, client commitments, and bundled offers if the partner exits, written before launch. A partner plan with no signed or approved agreement is labeled design, not distribution.

9. SALES CALL AND OBJECTIONS (reusable section)

First-call protocol, adapted per offer: locate the real constraint across reach, acquisition, conversion, expansion, and fulfillment capacity; get numbers per stage, and when the business cannot state its numbers, measurement becomes the paid first step because unmeasured work cannot be credited; never propose a system the client has not already proven manually - improve what works before automating it. These qualification rules, drawn from the creator method, are treated as hypotheses the lab tests, not verified laws. Objection library template, filled per offer before the first call: price (anchor against verified comparables or the measured cost of the problem), trust (proof assets from the show and the synthetic rehearsal), timing (the bounded pilot as the low-risk step), do-it-yourself (what the rehearsal showed DIY misses), tool-only objections (what the service adds beyond the tool). Every call ends in a recorded outcome code: qualified, pilot offered, follow-up with date, disqualified with reason, or informative zero. Outcome codes feed the G3 window decision; they are data, not forecasts.

10. PILOT TERMS AND DELIVERY REHEARSAL (reusable section)

Pilot terms template: named client, bounded scope, price (approved by Paul), payment route, timeline, success criteria the client agreed to, and what happens at the end (retainer offer, referral ask, or clean close). Prepare and test the payment route without a real charge first; collect the first real payment only within an approved pilot. Fulfillment kickoff checklist: scope confirmation in writing, access and materials received, delivery owner named, timeline confirmed, measurement in place. Delivery rehearsal adapts to the offer type: for an audit or diagnostic service, a synthetic benchmark with planted findings, negative controls, and stop criteria before any client data; for a product or template, an end-to-end walkthrough of the actual checkout and fulfillment path with no real charge and no retained fees; for education or content, a pilot cohort with named participants. The invoice and payment receipt are recorded as the LAUNCHED evidence; a prepared route with no payment is reported as launch-ready, never as verified money.

11. REFERRALS, UPSELL, AND CROSS-SELL (reusable section)

Referral ask: timed after a delivered result the client acknowledges, one direct ask with an easy forward, recorded in the tracker. Upsell: the pilot's end-of-pilot review presents the retainer or next bottleneck explicitly, using the pattern that fixing one constraint surfaces the next; the upsell is offered, never assumed. Cross-sell: only offers already approved in scope; a new offer for the same client goes through G2 as its own offer one-pager. All three remain subject to the standing contact rules: no cold outreach to friends, family, or past clients, and no client name or story in public without approval.

12. RISK AND ROADBLOCK MITIGATION (reusable section)

Every idea past G2 carries a risk register: risk, likelihood, early signal, mitigation, owner. Standard entries to adapt, not copy blindly: deliverability failure (early signal: bounce spike or complaint; mitigation: lane stops, cause investigated before resuming); offer fails on yes (early signal: delivery rehearsal misses; mitigation: shrink the promise before selling); capacity overrun (early signal: pilot hours exceed the unit economics; mitigation: automate or narrow scope at G4); platform dependency (early signal: API, pricing, or policy change at a vendor; mitigation: document the migration path per dependency); evidence decay (demand links older than 30 days are re-verified before they support a decision); compliance and disclosure (the standing public-writing and contact rules). A roadblock with no mitigation converts to a FIX CARD for Paul or a KILLED gate with the evidence; it never sits as "monitoring."

13. OPERATIONAL ARTIFACTS AND ACCEPTANCE TESTS (reusable section)

Artifacts per gate, each with an acceptance test that defines done: G0 winner packet (review Doc and TTS exist, tracker row matches, demand links dated and live); G1 demand memo (every claim linked to buyer-side evidence, ages labeled, counterevidence matched to mechanism); G2 offer one-pager plus rehearsal evidence (survives "what happens on a yes", Paul's written approval); G3 test plan card (window, criteria, owner, dedupe proof, approved templates) plus results record (outcome codes, window decision); G4 pilot terms plus payment receipt and fulfillment record (rehearsal evidence, checkout tested with no real charge); G5 SOP, templates, automation map, unit economics, launch spec (positioning, page, checkout, booking, measurement, fulfillment SOP, support boundary) plus the done-means completion audit. Artifact naming: winner-to-revenue_<slug> in the rev-ops Drive folder; intake reviews keep rev-ops_<slug>_MMDDYY. Tracker status vocabulary: CANDIDATE, VALIDATE, PURSUE, PILOT, PRODUCTIZE, LAUNCHED, KILLED, PARKED; every status change records the gate evidence in the row notes.

14. STATE MACHINE

CANDIDATE enters at G0. VALIDATE covers G1-G2. PURSUE covers G3 while a test runs. PILOT covers G4 from agreed pilot terms through first payment received and fulfillment underway. PRODUCTIZE covers G5 before the scale launch. LAUNCHED is terminal success at the scale launch and requires first payment already received plus repeatability evidence. LAUNCH-READY is a reporting label inside PURSUE or PILOT for a prepared but untested route, never a terminal state and never reported as verified money. KILLED is terminal failure with the named gate. PARKED holds an idea with a reopen trigger and an owner for the check. Backward transitions are allowed only with new evidence named in the row notes.

15. SKILL INVOCATION CONTRACT

Triggers: an idea earns a WINNER; Paul says "winner to revenue," "turn this winner into a business," or "productize RTL-xxx"; a tracker row enters VALIDATE. Inputs: tracker row ID, review Doc link, evidence ledger. Steps: run G0, then one gate at a time, reporting each gate report and decision ask. Outputs: gate reports in the review Doc, tracker updates, decision asks to Paul, the terminal-state record. The skill package (SKILL.md, this framework as its reference, and the gate report template) is a user-authored deliverable: it documents the method, it grants no permissions, and nothing in it overrides the standing constraints or Paul's approvals.

16. FIRST INSTANCE: RTL-012 SECURITY CHECK

The security-check idea (RTL-012) is the first idea run through this framework. Honest status as of Oct 29, 2026: G0 complete (review Doc, TTS, tracker row, published plan page). G1-G2 evidence is gathered in the plan, but the idea-specific validation outcome is independent of this framework's existence and still owns its own gates. Nothing in this document changes RTL-012's permissions or timeline.

17. WHAT WRONG LOOKS LIKE

An idea-specific plan delivered as "the framework." A gate passed on enthusiasm or on evidence meant for another gate. Demand "corroborated" by a seller's marketing or a creator's unverified incident claims. A test with no written window or success criteria. A readiness hold treated as a quality failure, or a quality failure laundered into a readiness note. A forecast dressed up as test design. A prepared checkout described as money received. A generic delivery rehearsal forced onto an offer type it does not fit. Outreach, spend, or launch treated as authorized because the analysis was thorough. A skill file described as installed or authoritative when it is neither.

18. STANDING CONSTRAINTS (authority: rtl-video-intake and rev-ops decision-standard)

The team is Paul, Charlie, and agents; nothing needs a hire or ongoing manual hours. Paid offers go to cold pools only, never friends, family, past clients, or warm contacts; do not ask Paul for warm contacts. Ramp: 10 per day, then 20, then 30, growing only while bounces and complaints stay near zero. No purchases without Paul's specific approval. Every new cold template is approved by Paul before its first send; every individual send is approved by Paul. Apollo credits only on validated segments; dedupe every candidate against the Contact Registry and skip anyone touched in the last 90 days. No invented facts; verify load-bearing claims against primary sources. Public writing: no em dashes or semicolons, no AI tells, no property management or apartments, Paul is never the punchline; writing as Paul goes through the content workflow, never drafted here. Never name Tracker Products. Intake and analysis are read-only; a verdict or a passed gate is not permission to act. Job boards including Upwork are closed as channels (rule of Oct 5, 2026); r/lovable and r/nocode ban commercial replies.