Back to notes

The Buyable Product Framework: from idea to something people pay for

28 Sep 2026 · 2 min read

Most ideas don't fail because the code was bad. They fail because nobody wanted to pay for them. This is the framework I use with founders before a single screen gets designed. It moves an idea from "I think people want this" to "people are paying for this", and it tells you when to stop.

The Buyable Product Framework, ten steps from idea to decision
The Buyable Product Framework, ten steps from idea to decision

01. Idea

Write the idea as one sentence: who it's for, what it fixes, and why now. If it takes a paragraph, it isn't clear yet. That's fine, but don't build until it fits in a sentence.

02. Customer

Name one specific customer, not "small businesses". For example, "clinic owners in Illinois with two to five doctors". The narrower the customer, the easier every later step becomes.

03. Problem

Find the problem they already spend time or money on. A problem they complain about but never pay to solve is a weak signal. A problem they patch with spreadsheets, WhatsApp groups or an assistant is a strong one.

04. Evidence

Collect proof before building: ten conversations, the spreadsheet they use today, the price of what they currently pay for. Write down what they said, not what you hoped they said.

05. Buying signals

Look for intent, not compliments. "Can I use this next week?", "What does it cost?" and "Can my partner see it?" are buying signals. "Nice idea" is not.

06. Offer

Turn the solution into an offer: what they get, how fast, and for how much. If you can't price it yet, you don't understand the value yet.

07. Minimum Buyable Product (MBP)

An MVP asks "does it work?". An MBP asks "will someone pay for it?". Build the smallest version a customer would pay for. It's usually one core flow, done properly, with payments switched on from day one. For most of my projects that means 7 to 14 days, not three months.

08. Validation score

Score the launch on real behaviour: sign-ups, activation, paid conversions and repeat use. Decide the thresholds before you launch, so the numbers can't be argued with afterwards.

09. Next experiment

Pick the single riskiest assumption left and design one focused test for it. Change one thing at a time, or you won't know what worked.

10. Go, pivot or kill

Make the call with the score in front of you:

Killing an idea early is a win. The expensive failure is the one that runs for a year on hope.

If you have an idea sitting in your notes app, this is how we'd start: one call, steps 1 to 6, and a clear plan for the MBP.