Discovery: the first meetings

Customers know their symptoms well and their problems less well. Discovery turns a vague request into a problem everyone can agree on. Done well, the solution often looks obvious by the end. Done badly, you build an impressive answer to the wrong question.

Before the first meeting#

Spend an hour on homework so the customer's time goes on what only they know. Read what they publish: annual reports, job ads, product pages, recent news. Find out what they already bought from your company and how it is being used. Learn the names and roles of the people attending.

Then write down three things: what you think the problem is, the assumption you are least sure of, and six questions that do not give away a solution. You will probably be wrong about the first. Writing it down lets you notice when.

Find the cast, including who wasn't invited#

In almost every engagement four roles matter. One person can hold more than one of them, and the job titles will not tell you who is who.

Senior people describe the problem as it appears on their dashboards. That is useful context, but not the facts you design from. Treat what executives tell you as the frame. Get the detail from the champion and the users.

Gatekeepers are the people most often left out of the first meeting, and the most expensive to meet late. Find them by asking directly: "Who else will be affected by this? Who approves new vendors or data access? Has security seen anything like this before?" Then meet them to understand their rules, not to defend your design. A security lead who helped shape the guardrails will approve them. One who first sees them in a review will question everything.

Look through three lenses#

The classic way to miss something is to understand the software perfectly and the organisation not at all. An old lens from IT consulting helps: look at the people, the process and the technology, and treat a gap in any of the three as unfinished discovery.

The process lens is the one engineers most often skip. Walk the work from trigger to outcome: what starts it, what decisions are made along the way, where it changes hands, and where people work around the official system. The handoffs and workarounds are where delays and errors live, and where automation either helps or makes things worse.

Climb the question ladder#

Neil Rackham studied thousands of sales calls in the 1970s and 80s and published the results as SPIN Selling. His finding was that successful calls used four kinds of question, roughly in order: situation, problem, implication and need-payoff. Sales is not discovery, but the order transfers well, because people answer harder questions once they can see you understand the easy ones.

1. 1

   Situation: how things work today

   Rackham found that too many of these bore people. Ask only what you couldn't find out beforehand.
2. 2

   Problem: where it hurts

   Ask about concrete recent cases. 'Tell me about the last renewal that went wrong' gets you further than 'what are your challenges?'
3. 3

   Implication: what the pain costs

   Follow a problem outward: who else does it affect, what does it cost, what happens if it gets worse? Engineers tend to skip this, and it is where budgets come from.
4. 4

   Payoff: what fixing it would be worth

   Ask what a fix would make possible. When the customer describes the benefit in their own words, you can quote it back in your proposal, and it carries more weight than anything you could write.

A benefit the customer describes is worth more than one you claim.

Techniques that get you facts#

Funnel from open to specific

Begin with a question that invites a story, then let each answer pick the next, narrower question. At a builders' merchant: "How does a trade customer usually order?" leads to "which orders cause the most phone calls?", then "the ones with substitutions?", then "what happens when the substitute is wrong?". Broad questions surface what you didn't know to ask. Narrow ones get you counts.

Mirror the words that carry feeling

Chris Voss, a former FBI negotiator, popularised a simple technique: repeat the last few important words someone said, as a gentle question. A yard manager says "we just end up guessing on Fridays". You say "guessing on Fridays?", and wait. People nearly always explain, and the explanation tends to hold the detail they wouldn't have offered to a direct question.

Write numbers down as you hear them

Customers mention numbers in passing: the size of the team, how many orders a day, how long a check takes. Write each one down where they can see you do it, and read the set back at the end of the call. Numbers confirmed in the meeting become the baseline everyone agrees on, and the first sentence of your business case.

Leave room

Discovery calls go wrong most often because the engineer fills them. When you finish a question, stop. Count to five in your head if a silence feels long. If you catch yourself explaining how something could work, you have drifted into a pitch; ask another question instead.

Plan a short call around three outcomes#

You rarely get more than half an hour with senior people. Rather than scripting the minutes, decide the three things you must leave with, and steer towards them.

Leave with something written#

A great conversation is worth little if it lives only in your memory. Send a short recap the same day: what you heard, the numbers they gave you, open questions, and the agreed next step with an owner. A recap sent within hours signals that the meeting mattered, and it doubles as the first draft of the problem brief.

After two or three conversations, the brief should be able to state, on one page:

• The problem, in one or two sentences the sponsor and the users would both sign.
• Who decides, and how they will judge success, as a number.
• The forces at play: fears, competing goals, the deadline and why it exists.
• Boundaries: data that is off limits, systems that cannot change, required accuracy.
• The baseline: what it costs today, in time, money or risk.