From flywheel
Design pricing and monetization strategy using Madhavan Ramanujam's framework from "Monetizing Innovation". Walks through leaky bucket → WTP signals → segmentation → configuration → model → price points. Reads the positioning canvas and produces an active pricing decision grounded in value chains and segments. Use when pricing a new product, repricing an existing one, or revising pricing after WTP signals from /fw:copy or /fw:pitch sessions. Supports multi-canvas portfolios via the --canvas flag.
npx claudepluginhub untangling-systems/flywheel --plugin flywheelThis skill uses the workspace's default tool permissions.
<monetize_context> #$ARGUMENTS </monetize_context>
Verifies tests pass on completed feature branch, presents options to merge locally, create GitHub PR, keep as-is or discard; executes choice and cleans up worktree.
Guides root cause investigation for bugs, test failures, unexpected behavior, performance issues, and build failures before proposing fixes.
Writes implementation plans from specs for multi-step tasks, mapping files and breaking into TDD bite-sized steps before coding.
<monetize_context> #$ARGUMENTS </monetize_context>
Work through Madhavan Ramanujam's core monetization framework (from his book Monetizing Innovation). The output is an active pricing decision at docs/pricing/current.md — a strategic artifact, not a one-off spreadsheet. It covers the leaky bucket, WTP signals, WTP-based segmentation, product configuration, monetization model, and price points with a corridor.
Ramanujam's central argument: most product failures are really pricing failures. Feature shock (too much in one product), minivation (innovation nobody will pay for), hidden gems (value you never charged for), and undead products (nobody wanted at any price) all come from skipping the willingness-to-pay conversation. This skill forces that conversation early.
This skill reads a positioning canvas to ground every pricing decision. Path resolution order:
--canvas <path> in the user's arguments. Use that path.--canvas, scan docs/positioning/ for .md files (excluding portfolio.md and archive/). If exactly one exists, use it. If multiple exist, list them and ASK which canvas this pricing decision is for.docs/positioning/current.md.All references below to docs/positioning/current.md should substitute the resolved canvas path. This matters especially for multi-canvas portfolios where each track or product has its own segments, value chains, and competitive alternatives — pricing for the wrong canvas will produce a defensible-looking but wrong decision.
Pricing path derivation: Once the canvas path is resolved, derive the pricing output path by taking the canvas filename and placing it in docs/pricing/. Examples:
docs/positioning/current.md → docs/pricing/current.md (existing behavior, no change)docs/positioning/track-a.md → docs/pricing/track-a.mddocs/positioning/enterprise.md → docs/pricing/enterprise.mdAll references below to docs/pricing/current.md should substitute this derived pricing path. WTP interview guides (docs/pricing/wtp-{slug}-{date}.md) and the archive (docs/pricing/archive/) are not canvas-scoped — they remain at fixed paths.
/fw:monetize wtp)/fw:copy, /fw:pitch, or real-world outcomesPricing sits on top of positioning. Without a canvas, pricing has nothing to ground against — you'd be guessing at what to charge for a product whose value you haven't articulated.
docs/positioning/current.md."Pricing is built on top of your positioning canvas — segments feed WTP grouping, value chains feed WTP anchors, competitive alternatives feed reference prices, and the market frame signals what monetization model the buyer expects. I couldn't find
docs/positioning/current.md. Run/fw:positionfirst, then come back and we'll build the pricing decision."
## 1. Competitive Alternatives) → reference prices + price corridor anchors + buyer's expectation of how value is priced## 2. Unique Attributes) → input to the leaky bucket analysis## 3. Value) → input to WTP probes (outcomes with quantified value become WTP anchors)## 4. Customer Segments) → starting point for WTP-based segmentation (which you will then re-group)## 5. Market Frame of Reference) → signals the buyer's mental model, which drives monetization model choiceSome positioning canvases define more than one market frame — e.g., a product with two distinct buyer types each with their own frame. Pricing decisions for different frames are almost always different (different WTP, different segments, different models), and a single pricing decision cannot serve both without compromise.
If the canvas has multiple frames: Identify them and ask the user which frame this pricing is for. Surface the choice explicitly:
"Your positioning canvas defines multiple frames:
- Frame A: [summary] (serves [segment])
- Frame B: [summary] (serves [segment])
Pricing for different frames is almost always different. Options:
- Price one frame at a time (recommended) — pick one now, come back for the other later. Each gets its own section in
current.md.- Price both at once — one session, two sections in the output. Only works if you're confident they share most of the decision.
- Split into separate files —
current-a.mdandcurrent-b.md. Use this only if the decisions are very different (different model, very different tiers)."
Record the chosen frame in the pricing decision's frontmatter (frame: A or a short label). The canvas's "not for" segments still apply — a pricing decision for Frame A should not try to serve Frame B buyers.
The weakest part of most pricing decisions is the WTP signals section. Founders often start with "I think customers would pay X" — which is exactly what Ramanujam calls the core failure mode. The skill should do the legwork of surfacing real signals before the sequence starts.
Search the other knowledge stores for pricing-relevant signals:
docs/copy-tests/ — Read any files with ## Outcome Notes sections. Look for mentions of price, sticker shock, "too expensive", "would pay", or conversion data. Copy tests that performed well or poorly often reveal WTP.docs/pitch-storyboards/ — Read any files with ## Outcome Notes. The ask section and buyer responses are a direct source of WTP signals — what the buyer agreed to, what they balked at, what they asked about.docs/growth-experiments/ — Read any files with status: completed and a populated result:. Experiments involving pricing pages, tier comparison, or conversion often produce quantified WTP signals.docs/pricing/wtp-*.md — Any prior WTP interview notes the founder has already collected.Surface what you find:
"Before we begin, here are the WTP signals I found across your other sessions:
- [signal 1 — specific quote or data, source file]
- [signal 2 — specific quote or data, source file]
We'll revisit these in Step 2 (WTP Signals) so you don't start from scratch."
If no signals exist, flag it early:
"I didn't find any WTP signals in copy-tests, pitch-storyboards, growth-experiments, or prior WTP interviews. That means Step 2 (WTP Signals) will need to work with whatever you remember from sales conversations or lost deals — and Step 6 (Price Points) will be your weakest section until you collect real signals. Strongly consider running
/fw:monetize wtpto design an interview guide before committing to numbers."
Invoke the pricing-researcher agent (or read directly if simple) to search docs/pricing/ for:
wtp-*.md interview guides and findingspattern-*.md cross-session pricing patternsIf a current pricing decision exists, surface it:
"You have an existing pricing decision from [date]. Here's what it says:
- Model: [summary]
- Tiers: [summary]
- Price points: [summary]
- Confidence: [level]
- Frame: [if multi-frame]
What do you want to do? 1. Revise specific sections, 2. Start fresh, 3. Review and sharpen."
Parse the argument to determine mode:
Triggered when the argument contains "revise", names a specific section (e.g., "revise tiers", "update model"), or describes a triggering reason (e.g., "lost deal at $50").
Load the current pricing decision as the working baseline. Jump to the target section(s). Run the full step with enforcement. After updating a section, check downstream propagation:
| If you change... | Ask whether these still hold... |
|---|---|
| Leaky Bucket (Step 1) | Configuration (Step 4) — do the tiers still anchor on the right features? |
| WTP Signals (Step 2) | Segmentation (Step 3) and Price Points (Step 6) — do segments still hold, do prices still match the corridor? |
| Segmentation (Step 3) | Configuration (Step 4) — do tiers still map to segments? |
| Configuration (Step 4) | Model (Step 5) and Price Points (Step 6) — does the chosen model still fit, are prices still right for the tiers? |
| Monetization Model (Step 5) | Price Points (Step 6) — the pricing format follows the model (per-seat vs per-use vs flat) |
| Price Points (Step 6) | None downstream — update the pricing statement and save |
For each downstream section, present the current content and ask: "Does this still hold given the change above, or does it need updating too?"
Add a ## Revision History entry to the pricing decision.
Triggered when the argument contains "wtp" or "interview".
Skip the main 6-step sequence. Instead, walk the user through designing an interview guide using references/wtp-interview-guide-template.md. Ask:
Save the guide to docs/pricing/wtp-{slug}-{date}.md with type: wtp-interview-guide in frontmatter. After the user runs the interviews and fills in findings, they come back to /fw:monetize to update the pricing decision with the new signals.
Default when no pricing decision exists or the user explicitly says "start over". If an existing pricing decision exists, ask whether to archive it to docs/pricing/archive/[date].md first.
If the user provided arguments (product name, revision target, frame), acknowledge them. If not, prompt:
"What are you pricing? A new product, an existing one, a specific offer — and any context about what prompted this (new feature, lost deal, customer feedback, launch prep)."
Work through all 6 steps in order. Each step builds on the previous one. Use references/enforcement-prompts.md for redirect and warning text. In revision mode, only the targeted steps and their downstream propagation checks run. In WTP interview mode, skip this sequence entirely.
Going back is allowed. Later steps often reveal that earlier answers need sharpening. Encourage this — it's how the framework works.
"Before we talk about price, let's diagnose which features actually create value worth paying for. Ramanujam's leaky bucket sorts every feature into one of four categories: differentiator (customers will pay extra for it), filler (nice to have, but they won't pay extra), loser (makes the product worse — cut it), or leader (the feature that closes the deal even though it's not what they pay for). This diagnoses feature shock and hidden gems before they become pricing mistakes."
What you're looking for:
## 2. Unique Attributes) placed in one of the four buckets/fw:position)Enforcement triggers:
/fw:positionWhen this step is done: You have a 4-bucket table with every canvas attribute placed.
"Now the core question: what do you actually know about what customers are willing to pay? Not what you hope they'd pay — what you've observed. Past sales, lost deals, support asks, competitor prices, customer conversations. Every claim in this section must cite a real source. If you don't have signals, we'll design an interview guide before going further."
What you're looking for:
## 1)Enforcement triggers:
/fw:monetize wtp to design an interview guide before proceeding; offer to switch modesWhen this step is done: You have a table of cited signals (or an explicit acknowledgment that signal quantity is thin and an interview guide is the next action).
"Ramanujam's key move: don't segment by demographics — segment by willingness to pay. Two customers in the same demographic might value your product totally differently. Regroup your canvas segments by how much they'd pay and what they most care about. This is what determines whether you have one tier or three."
What you're looking for:
## 3)Enforcement triggers:
When this step is done: You have 1-4 WTP-based segments with price corridors.
"Now you decide how to package. Good/Better/Best tiers. Or bundles. The goal is one tier per WTP segment — and each tier should anchor on a differentiator from the leaky bucket. The biggest configuration mistake is feature shock: putting everything in one tier and hoping everyone pays the top price."
What you're looking for:
Enforcement triggers:
When this step is done: You have a tier table where every tier serves a WTP segment, anchors on a differentiator, and has a clear upsell reason.
"Pick how you charge, not how much. Subscription, usage-based, outcome-based, freemium, per-seat, per-transaction, dynamic, license. The right model is the one that matches how your buyer thinks about value — not the default model of your industry. A data API might feel natural as usage-based (data buyer) but wrong as subscription (rancher)."
What you're looking for:
Enforcement triggers:
When this step is done: You have a chosen model with reasoning, rejected alternatives, and tier structure that fits the model.
"Finally, actual numbers. Every price has three components: the list price (what you advertise), the floor (the lowest you'd go in a negotiation and still capture value), and the ceiling (the highest a segment at the top of its corridor would pay). All three come from Step 2 signals and the competitive alternatives. No guessing."
What you're looking for:
Enforcement triggers:
When this step is done: You have a price table with list/floor/ceiling per tier, every number cited.
After all 6 steps are complete:
references/pricing-canvas-template.md"Here's your pricing decision. Read through it — does anything feel like guessing, like a number you couldn't defend in a conversation, or like a tier you wouldn't actually offer? The test is whether you could send this to an experienced pricing consultant and have them agree it's defensible."
Every claim in the pricing decision must trace to either the positioning canvas or a documented WTP signal. Drift check is non-optional — pricing with ungrounded numbers is the single biggest failure mode Ramanujam warns about.
Inventory grounded sources first. Extract:
## 2. Unique Attributes## 3. Value## 1. Competitive Alternatives, including any published pricesdocs/pricing/wtp-*.mdThis is your grounded-claim inventory.
Walk Step 1 (Leaky Bucket):
## 2. If it doesn't, either update the canvas or remove the attribute from the bucket.Walk Step 2 (WTP Signals):
Walk Step 3 (Segmentation):
## 4 OR be a regrouping justified by Step 2 signals.Walk Step 4 (Configuration):
Walk Step 5 (Model):
Walk Step 6 (Price Points):
## 1.For each drift flag, present options to the user:
"I flagged [N] items that don't trace to a grounded source:
- [item] — [where it came from]. Options: (a) remove, (b) replace with grounded version [suggested], or (c) mark as deliberate departure and plan to collect the signal next (update
docs/pricing/current.mdwhen you have it).- [...] Which for each?"
Output the drift report into the pricing decision's ## Drift Detection Report section, even when every claim is grounded — future sessions benefit from seeing the inventory.
After user approval:
{resolved pricing path} to docs/pricing/archive/{YYYY-MM-DD}-{canvas-stem}.md (where canvas-stem is the canvas filename without extension, e.g. track-a){resolved pricing path}---
type: pricing-decision
tags: [pricing, monetization, tiers, ...]
confidence: high | medium | low
frame: [A, B, or omit if single-frame canvas]
created: YYYY-MM-DD
last-updated: YYYY-MM-DD
canvas-version: [created date of the positioning canvas used]
source: [session description]
---
## Revision History:
## Revision History
- [date]: Revised [section(s)]. Reason: [triggering signal]. Changes: [what changed].
For WTP interview guide mode, save to docs/pricing/wtp-{slug}-{date}.md with type: wtp-interview-guide frontmatter. Do not overwrite current.md.
Use AskUserQuestion:
Question: "Pricing decision saved to {resolved pricing path}. What next?"
Options:
/fw:monetize wtp — Design an interview guide to fill WTP signal gaps before committing/fw:copy — Write a pricing page that translates this decision into landing page / outreach / one-liner copy/fw:pitch — Revise your sales pitch ask now that you have concrete price points and a corridor/fw:compound — Save learnings from this session (especially non-obvious insights about WTP)WTP before price. You cannot pick a number before you have signals. If the signals are thin, design an interview guide and collect them — don't guess. Guessing at pricing is the single biggest product failure mode.
Leaky bucket before tiers. Tiers depend on knowing which features are differentiators vs. fillers. If you skip Step 1, you'll put the wrong features in the wrong tiers.
Tiers before model. The model (subscription vs. usage vs. outcome) has to fit the tier structure. Picking a model first and bending tiers to fit it is backwards.
Model before numbers. The price format (monthly, per-use, percentage-of-outcome) comes from the model. Picking numbers first and reverse-engineering the model produces weird hybrids that confuse buyers.
Numbers defended with a corridor. A single price with no floor and ceiling is a number you can't flex in a conversation. Always three numbers per tier: list, floor, ceiling.
Honest about gaps. Missing signals are not failures — they're the most valuable output of the session, because they tell the founder exactly what to go ask customers. Surface them explicitly.
The decision should feel uncomfortable. If the founder isn't squirming a little when naming their price ceiling for the top tier, they're probably underpricing. Discomfort is a signal the decision is sharp.
When invoked with disable-model-invocation context:
--canvas <path> if provided; otherwise apply Canvas Path Resolution silently (single canvas: use it; multiple: use docs/positioning/current.md and flag the assumption; none: use docs/positioning/current.md)