Most first calls are a feature wishlist and a rough quote. A useful one produces a written statement of the problem that you agree with — before anybody talks about what to build.
The first conversation sets more of a project's outcome than any decision that follows, and most of them are wasted. The client lists features, the developer estimates them, and both sides leave with the comfortable feeling that something was agreed. What was actually agreed is a shopping list nobody has tested against the business.
The deliverable is a problem statement, not a proposal
The output of a good first call is one page that says: here is the problem, in your words, that we both believe is the right one to solve. Not a feature list, not a quote. If that page is wrong, everything downstream is wrong, and it is a great deal cheaper to be wrong on one page.
It is also a test of the room. If a client reads it and says 'yes, that is it', you are building the right thing. If they say 'almost, but the real issue is…', you just saved several weeks.
The questions that get you there
- What does this cost you today — in money, in hours, in customers who go elsewhere? If nobody can answer, the problem may not be worth solving yet.
- Who feels it, and when? A problem that only the founder notices behaves very differently from one a team hits every Monday.
- What have you already tried, and why did it not stick? Usually the most informative answer of the call.
- What would have to be true in six months for you to say this was worth it? This becomes the number.
- What is the current workaround? There is always one, and it defines the real baseline to beat.
Why the number comes before the features
Naming the metric first changes what gets built. It exposes features that sound good but cannot move it. It settles arguments later, because there is a shared definition of better. And it makes the project honestly reviewable: in six months you either moved it or you did not, and both of those are useful to know.
It also protects the client from us. A development company paid to build features has an incentive to agree that more features are needed. A metric agreed upfront is a check on that incentive.
What we listen for in how a problem is described
A problem described entirely in solutions — 'we need a dashboard, an integration and an app' — usually means the underlying issue has not been examined. A problem described in symptoms, with real examples and actual frustration, is much easier to solve well, because you can get at the cause rather than the requested remedy.
Our own first product came from a symptom, not a solution: collection pages on a live jewellery store ordered by upload date while real demand moved week to week. Nobody asked for a sorting engine. The engine was what the symptom turned out to need.
What happens after the page is agreed
Then, and only then, scope. The first version does one thing end to end and goes into real use early, because a working small thing teaches you more than a specification of a large one. Each release after that is complete on its own, so you are never waiting on a launch date to see value.
That is the whole method — listen, build, prove, grow — and the order is the point. Most projects that disappoint got the order wrong, not the code.
How to prepare for the call
Bring the problem, not the solution. Bring whatever numbers you have, even rough ones. Bring the workaround you use today and be honest about how well it works. And be prepared to be asked what success looks like in a figure — the answer is often harder than people expect, and arriving at it is most of the value of the hour.
