Here's the situation I was trying to fix.
I had a workflow that worked. It saved me real time every week, it held up under a full-time job and family constraints, and I'd documented it well enough that a colleague could follow it. So the obvious next step was to sell it. Right?
Almost. I spent a weekend sketching a service package and pricing it, and then I sat down with a list of questions I hadn't answered. Six weeks later, after working through them, I had a much smaller offer—and a much better chance of it being worth someone's money.
This piece is that list. It's the gate between "I have a workflow" and "I have something to sell." Not a business plan. A filter.
Why the Jump From Workflow to Offer Fails
Three failure modes, and they show up in that order.
The Workflow Only Works Because You're There
Your workflow may depend on context nobody else has: the history of the data, the relationships, the unspoken rules about what the numbers mean. You run it and it works. Hand it to someone else and it produces a technically correct output that's still wrong.
Automating your judgment isn't the same as transferring it. If a buyer needs your judgment to make the workflow useful, they're buying you, not the workflow—which is a different business with different constraints.
The Value Is Real but Small
Time saved isn't automatically money saved. If the workflow saves two hours a week and the buyer's loaded cost is fifty dollars an hour, the work is worth a hundred dollars a week. That's a fine personal win. It's not obviously a service someone will pay a premium for, especially once you add onboarding, support, and the trust required to hand over a process.
Value has to clear a bar that varies by buyer. What feels like a big deal to you may be a rounding error to the company you're pitching.
The Buyer Isn't Who You Think
The person who feels the pain is rarely the person who controls the budget. The analyst who hates the weekly report isn't the director who approves the spend. And the director doesn't feel the pain directly—they just see the output. If your offer targets the pain-haver but the money lives with the outcome-owner, the sale stalls at the handoff.
Most first offers die here, quietly, after a promising first call.
The Five Questions
Work through these in order. Each one can kill the offer, which is the point.
Question 1: What Changes for the Buyer, in Their Words?
Not "saves time." Not "improves efficiency." What specifically stops happening, starts happening, or gets easier—and how would the buyer describe it if they weren't trying to be polite?
If you can't write the answer as a sentence the buyer would actually say, you don't have the offer yet. You have a feature.
Question 2: Could a Competent Stranger Run It Without You?
This is the transfer test. Hand the workflow to someone smart who doesn't know your context, with only written instructions. Do they produce something useful?
Yes, reliably → you have a system that can be taught or templated.
Yes, with support → you have a service with a real support cost. Price accordingly.
No, not without you → you have a personal capability, not a product. That's fine, but it changes the business model.
Most people skip this test and discover the answer during their first client engagement, which is an expensive way to learn it.
Question 3: Is the Value Big Enough to Be Worth a Transaction?
Run the rough math on what the buyer gains, then compare it to the friction of buying.
The friction includes: finding you, trusting you, onboarding, reviewing your work, and the internal cost of managing a vendor. If the value is smaller than the friction, no price makes it work—even free has a cost to the buyer.
A useful test: would a reasonable buyer spend thirty minutes on a call to get this outcome? If not, the offer isn't ready. If yes, you're in range.
Question 4: Who Actually Owns the Budget, and Do They Feel It?
Identify two people:
The pain-haver: the person who suffers the problem daily.
The outcome-owner: the person whose numbers or priorities change if the problem goes away.
Your offer needs a reason to matter to both. The pain-haver needs it to be easy. The outcome-owner needs it to be worth paying for. If you can only name one of them, you've found the gap.
Question 5: What's the Smallest Credible Version?
Strip the offer to its minimum: one buyer, one problem, one deliverable, one price, one clear outcome. No tiers, no add-ons, no "and we can also."
The smallest version is what you test. Everything else is expansion, and expansion before validation is how offers become unfocused and unsellable.
What the Answers Look Like in Practice
Vague answers kill offers. Specific answers don't.
Weak: "It saves teams time on reporting."
Strong: "It turns the weekly reporting scramble into a thirty-minute review, so the analyst stops working Friday nights and the director gets the numbers before the Monday standup."
Weak: "Anyone can run it."
Strong: "A competent analyst can run it in ninety minutes after a two-hour setup call, and needs about fifteen minutes of support the first month."
Weak: "It's worth a lot."
Strong: "It saves roughly six hours a week for a person whose time is worth sixty dollars an hour. At four hundred dollars a month, the buyer breaks even in week one and the friction is one onboarding call."
Weak: "Managers will love it."
Strong: "The analyst feels the pain; the operations director owns the reporting budget and is measured on timeliness. Both need to see the same demo, but the pitch is different for each."
Weak: "I'll offer a few options."
Strong: "One buyer: a five-person ops team drowning in weekly reporting. One deliverable: a working report system plus a handoff doc. One price: fixed, first three clients only."
Notice what's absent: adjectives, guarantees, and revenue projections. The answers are about scope, friction, and who feels what.
What Still Needs You
The parts of this gate that can't be outsourced or automated:
Honesty about the transfer test. It's easy to believe a workflow is teachable because you could explain it to someone who already knew the context. Test it on someone who doesn't.
Knowing the buyer's reality. Budget ownership, political dynamics, and risk tolerance are human facts. A model can help you think through them, but it can't know the specific room.
Deciding what to cut. The smallest credible version is a judgment call about which piece actually creates the value. Cut too much and it's not worth paying for. Cut too little and it's not an offer.
Being willing to stop. If three of the five answers are weak, the right move may be to keep the workflow for yourself and not sell it. That's a real outcome, not a failure.
The questions do the filtering. You decide whether what survives is worth the work of selling.
The Two-Hour Version
If you have a workflow and you're wondering whether it's an offer:
Write the buyer's sentence. If you can't, stop here.
Run the transfer test on one willing person.
Do the rough math on value versus friction.
Name both the pain-haver and the outcome-owner.
Write the smallest credible version in one paragraph.
If all five come back clean, you have a testable offer. If three or more are fuzzy, you have a workflow—and that's still worth something. Keep it, run it, and revisit in a month.
There's no rush to convert a good workflow into a business. The workflow is the asset. The offer is a decision that should be made with evidence, not enthusiasm.
Better work first. More options next.
Make the workflow earn its place.
No feedback yet — submit the first.