Offer

Your job is to make the first version smaller than they want it to be, and to make sure it is the smallest thing that is worth paying for rather than the smallest thing that is easy to build. Those are different, and only the first one is useful.

Find the one job

From the validation notes, find the single job the customer is hiring this for. Not the three jobs. One. Say it as: "they hire this to ______, and they will know it worked when ______."

If the second blank cannot be filled with something observable, the offer is not defined yet and no amount of building will fix that.

Cut

List everything they think version one needs. Then sort every item into:

• Core — without this the job is not done. Usually two or three things.
• Expected — the customer would be surprised by its absence. Often fewer than people think, and worth checking rather than assuming.
• Later — everything else. Say this out loud: later is not never.

Then ask the question that does the actual work:

If you could only ship the core, could you charge for it?

If yes, that is version one. If no, find out what is missing from expected, add only that, and ask again.

Do it by hand first

Before anything is automated or built, ask whether the first ten customers could be served manually. Almost always they can, and it is almost always the right move: the person learns what the product needs from doing the work, and they can charge from week one instead of month six.

Say this plainly. It is the highest-value advice in this skill and it is the advice people most want to skip, because building is more fun than serving.

Specify it

Write the first version as something checkable:

• what the customer gives you
• what you give back, and in what form
• how long it takes
• what is explicitly not included
• what "done" looks like, from the customer's side

That last one is the specification. Everything else is detail.

Make it finishable

Ask how long they think it will take, then ask what they are assuming goes right. Set a date, and set the scope to fit the date rather than the other way round — scope is negotiable, calendars are not.

If it cannot be finished in about a month, cut again. A first version that takes a quarter is nearly always three versions that were never allowed to ship separately.

Price it enough to hurt slightly

Do not leave pricing to the end. Give a starting number now, anchored on what the customer currently spends on the alternative, including their own time. Underpricing the first version is the most common and most persistent mistake in this whole process: it is very hard to raise a price on people who already bought.

If the number needs proper work, run sell.

What to hand back

offer.md: the one job, the core / expected / later split, the specification, the date, the price, and the manual version of the process that runs until automating it is obviously worth doing.

Do not

• Do not let "while we're at it" add anything. Write it in later and move on.
• Do not build infrastructure for a scale that does not exist.
• Do not ship something that does not do the job in order to ship on time. Cut scope sideways, not through the middle.
• Do not spend a month on the thing the customer never sees.

Next

brand if it needs a name. presence if people will look for it. sell if it is ready and needs a price and a conversation.