Blank and Dorf: From ‘I Like It’ to a Paid Deal

In a teaching example in The Startup Owner’s Manual, the buyer of a new enterprise software product is Karen, a chief financial officer. She has the problem, the money and the desire to buy. A founder might think all that remains is sending an invoice. But the diagram also contains her staff, the IT department, the sales executive and a chief executive who must approve the purchase.

This is Steve Blank and Bob Dorf’s invented example, not the story of a real customer. That makes it easy to examine without the magic of a successful-startup tale. Even an enthusiastic person with a budget cannot always take a product all the way to payment. A sale does not happen inside a single head.

The most useful question to bring to the book is not “How do we persuade the buyer?” but “What must happen between agreement and money received?” In the authors’ method, customer conversations serve, among other things, to discover that route—not to accumulate approving comments about an idea.

First find out whether this is a problem at all

Blank and Dorf separate two conversations founders badly want to combine. First, the problem and how someone deals with it today. Then, the proposed product. Starting with a demonstration makes it easy to mistake a polite “interesting” for a need.

In the physical-channel guide, the authors recommend preparing a short outline: the assumed problem, the present solution and your proposal. But they add a thought almost insulting to a presentation enthusiast: ideally, you will never need to show the slides. The other person should be talking.

The important answers are not simply a list of desired features. How painful is the problem? What does it cost? Is the person already putting effort into a workaround? A founder may collect good evidence precisely when the original assumptions are rejected. What this saves is not feelings, but work on an unwanted product.

User, supporter and buyer are not the same job

When the conversation turns to the solution, the authors suggest testing not just interest but the possibility of implementation. In one question, a corporate customer is asked to imagine deploying the system even if it were free. If they are unwilling to do that, the problem may not be price.

Next comes finding out who has a budget, how approval works and whether the relevant budget cycle has already closed. Months of pleasant meetings can take place with someone unable to buy anything. That does not make their opinion worthless: they may be an important user or influence the decision. Their interest simply answers a different question.

Karen’s example introduces an influence map. Who supports the change, who can stop it, and whom must you approach in what order? While that route exists only in the founder’s head, the business may be scaling the founder’s workload rather than its sales. The book proposes turning the experience of several deals into a reproducible sequence.

An order also needs to be read correctly

The authors’ term earlyvangelist means more than someone who likes new things. The person genuinely needs a solution, is ready to act and can pay. A signed order is a stronger signal than praise. Yet the book does not allow an early celebration here, either.

A first customer can demand so many special modifications that a supposedly repeatable product becomes a custom development project. That can be a business in its own right, but should not silently be presented as the original model. More dangerous still is accepting an exclusive arrangement with one customer and losing the ability to sell to others.

The test therefore concerns more than how many people say yes. Do the need, buying process and deal terms recur? Does each sale depend on a unique feat of founder heroism? The book itself refuses to name a magic number of orders: different products require different signals. Its examples should not become statistically established thresholds of success.

This part’s final check is more sobering still. Do product, channel and customer-acquisition costs add up? Will cash last while the sales happen? Even a genuine desire to buy does not establish that a supplier can earn money from it. A checklist is useful for making that uncomfortable comparison, not for certifying that a startup has passed the methodology.

A manual, not a ritual

For a Ukrainian team testing a new product, a specific discipline transfers: record the problem, willingness to use, authority to approve a purchase and step towards payment separately. This is not an account of Ukrainian procurement rules. Those need separate verification in regulated sectors or public-sector sales; the book’s influence map does not replace a lawful procedure.

The method’s boundary matters, too. The authors themselves distinguish market uncertainty from invention uncertainty. Conversations can reveal needs, but cannot establish that an unbuilt technology will work. Well-run interviews also do not guarantee sales: words and imagined budgets need testing through actions.

This is a detailed 2012 reference manual that is awkward to read like an ordinary business book. Repetition and checklists become useful when you have a task of your own; without one, they soon turn into an expedition through paperwork. Period-specific lists of internet services are not verified present-day recommendations and are not used in this analysis.

Source and scope

Steve Blank, Bob Dorf, The Startup Owner’s Manual, K&S Ranch Press, 2012. The reading covers the publication details, explanation of the electronic edition’s organisation, intended-audience introduction, reading instructions and relevant sections of the physical-channel guide: testing the problem, testing the solution, trial selling, influence mapping and final model validation. This is an analysis of the transition from interview to deal, not an assessment of every instruction or sales channel.