Artifact §06 · Practice note

The first fifteen minutes

There is a footnote on my homepage that says two companies and 121 customer conversations taught me that most of the work happens before anything gets written down: earning enough trust, in the first fifteen minutes, that someone tells you how things really work. This is the longer version of that footnote.

I have had a lot of these conversations now. Forty-five for Optima. Seventy-six for SKADI, with skiers, coaches and judges who had no reason to give me their time. And a long run of calls to component suppliers where I was the least technical person on the line. The pattern holds across all of them. What someone tells you in minute twenty depends almost entirely on what you did in minute two.

Why the first fifteen minutes decide the rest

Nobody walks into a conversation like this neutral. By the time you arrive, the person across from you already has a theory about why you are there. Customers assume you are about to sell them something. Colleagues wonder what the conversation is really for, and whether they will have to live with whatever comes out of it.

If that theory is still standing at minute fifteen, you will get the polished version of the process. The version where nothing goes wrong and every exception is handled cleanly. That version is useless. The exceptions are the requirement.

What I do not do

• Open a laptop first

  A screen between two people changes what gets said. I take notes on paper for the first stretch, and I say out loud that I am going to.

• Lead with a template

  Arriving with a form to fill in tells someone their job is to answer my questions rather than explain their work. I have the template. I fill it in afterwards, on my own time.

• Ask what they want built

  It is the single least productive question there is. It asks a person to do my job, in my vocabulary, on the spot. Most people respond by naming a feature they saw somewhere, and then we spend six weeks discussing that feature.

• Pretend I already understand

  Nodding along to protect my own credibility costs more later than admitting I do not follow. I would rather ask someone to explain their own acronym twice.

What I do instead

1. Say why I am here and who sent me, before anything else.

   Because they are going to work it out anyway, and finding out on their own is worse. It also gives them room to tell me the question itself is wrong.

2. Ask them to show me rather than tell me.

   Because people describe their process from memory and demonstrate it from muscle. The gap between the two is where the workarounds live, and the workarounds are the real system.

3. Ask what the worst day of the month looks like.

   Because average days do not generate requirements. The system has to survive the bad day, and the bad day is the one they actually want fixed.

4. Ask what they have already tried, and take it seriously.

   Because somebody usually built a spreadsheet that solves eighty percent of it. Treating that spreadsheet as a nuisance rather than as evidence is how you lose the room. It is prior art and it was built under the real constraints.

5. Ask what would make this worse for them.

   Because nobody volunteers that a change will cost them autonomy or make their day harder. Asked directly, most people will say it, and it is usually the risk that sinks adoption six months later.

The hard version

Some of these conversations are with someone who worries the change will cost them work they are proud of. I cannot talk anyone out of that. What I can do is be straight about scope, and when I do not know something, say so and tell them who does. Guessing kindly is still guessing, and being caught doing it costs you every conversation that follows.

The thing I try hardest to avoid is treating resistance as an obstacle to route around. It is almost always information. At SKADI, the riders most dismissive of a tracking feature were the backcountry riders we had assumed would want it most. They trusted a five-dollar leash over a two-hundred-dollar tracker, said so without hesitation, and they were right. That pushback cut a feature before anyone designed it.

The hardest version I have been through was on the other side of the table: recommending that we wind down Optima after seventeen months. The same rules held. Say what the evidence says, say what you do not know, and do not soften the conclusion to protect the room. More runway was not going to change the answer, and the most useful thing I could do was say that early and in plain words.

What I send afterwards

Within a day, I send back what I heard, in their words rather than mine, and ask them to correct it. Not a formatted specification. A short summary that uses their terms for their own steps, including the parts I am not sure I understood. There is an example of one at the end of the process map.

It catches a misunderstanding while it is still cheap, and it shows them their time produced something. When the formal document arrives weeks later, they have already seen their own fingerprints on it, so sign-off is a confirmation rather than a negotiation.

The reply I want is a correction. If somebody sends back a note saying no, we only do that when the shipment is short, that is the single most valuable email of the project.

Where this still goes wrong for me

I over-prepare. Reading everything before a conversation usually pays for itself, but it has also made me arrive with a shape in my head, and a shape in your head is a hard thing to hear past. I have had at least one session where I asked confirming questions for forty minutes and learned nothing, because I had unknowingly decided what the answer was on the train.

What I do about it now is write down my assumption before the meeting and leave the note face down on the table. It is a slightly ridiculous ritual. It works often enough that I have kept it.

Written by Nasmaan Ibrahim for nasmaan.com.
Back to the record · One requirement, written out in full · Seventy-six conversations, one page