Give the AI service story a second customer

TL;DR: Build your service story around a recognisable customer problem. Before calling the offering productised, show what it costs to solve that problem again.

zoomer's SMMA playbook argues for founder-led positioning around a specific pain point, followed by a repeatable offering and a public problem-solving story. Its AI example is retrieval: an assistant finds the wrong context and gives a poor answer. That is a clearer starting point than another broad promise to transform a business with AI.

For an engineer building a consulting offer, the useful move is the narrower problem. A prospective buyer can recognise a failed answer, explain its consequence and show you another instance. You have something to investigate together.

My addition is a second-customer test. A good first story demonstrates that one problem was solved. A second engagement reveals how much of the solution was actually reusable.

As an illustration, I would scope a retrieval diagnostic around a fixed set of failed questions, the passages returned and a short explanation of each failure. The deliverable would separate missing source material, poor retrieval and an answer that ignored adequate evidence. Those categories make the proposed repair reviewable.

For the next customer, I would record what carried over and what needed fresh work. Reusing a report format is useful, but it is a smaller achievement than reusing a reliable diagnostic method. Hours spent understanding a new corpus still belong in the delivery cost, even if the final report looks identical.

This changes the public story too. Explain a recurring failure, demonstrate the diagnosis and state where the method stopped working. That gives a buyer a way to judge fit instead of asking them to trust your confidence.

The article's scale and negligible-fulfilment-cost ambitions are not supported by operating results in the text. I read its argument as positioning advice; it does not establish demand, margins or an empty market for retrieval debugging.

A repeatable problem earns a clear story; a repeatable delivery earns a productised service.