The brief always arrives looking finished. A list of features, a deadline, sometimes a screenshot of someone else’s app with “like this, but for us.” Everything looks like it’s ready to start building. We’ve trained ourselves to do the opposite, to sit still and listen first, because the brief is almost never the problem. It’s someone’s best guess at a solution to a problem they haven’t fully said out loud yet.
So our first move on a project isn’t technical. It’s human. Before we scope a thing, we try to understand the people who’ll live with it, and we mean understand, not survey. Some of the most useful people in our studio aren’t engineers at all. They’re closer to mediators, people who can sit in a room, hear what’s being said under the words, and draw out the real need while most people would still be arguing about the features.
Listen past the position
Negotiators have language for this. Roger Fisher and William Ury, who more or less wrote the book on it, separate positions from interests. A position is what someone says they want. An interest is why they want it.1 “Build me a dashboard with twelve charts” is a position. The interest underneath might be “I’m scared I’ll miss something and get blamed for it on a Monday.” Those two sentences ask for completely different software. Build the first and you get twelve charts nobody opens. Hear the second and you might ship one quiet alert and hand somebody back their weekends.
Hearing the second thing is a skill with a name, active listening, described by the psychologist Carl Rogers and his colleague Richard Farson back in the 1950s.2 The heart of it is almost embarrassingly simple. You say back what you think you heard, in your own words, and you watch the person’s face. “So the real worry is the Monday surprise?” Either they relax and say “yes, exactly,” or they correct you. Both are gifts. That small loop, said back and confirmed, is where the actual requirements live.
Find the job, then the essence
Once you’re listening for the need instead of the request, a better question opens up. Clayton Christensen called it the “job to be done.” People don’t really want your product, they hire it to make progress on something in their life.3 Nobody wants software. They want the shift to end on time, the grant to get filed, the worried parent to feel a little less worried. The feature is a means. The job is the point, and it usually sits one layer below whatever got asked for.
Getting to that layer is mostly just refusing to stop at the first answer. Toyota built a whole practice around it, asking why roughly five times until you hit something real instead of a symptom.4 We do a gentler version out loud, asking why that step exists, who added it, and what breaks if it’s gone. Half the time we find a process that made sense in 2014 and a person quietly working around it ever since. You can’t turn a process into honest software until you understand the essence of it, and the essence is rarely written down anywhere.
A brief is someone's best guess at a solution. The need is still upstream, waiting to be heard.
Listening is the build
None of this is a warm-up before the engineering. It is the engineering. Fred Brooks put it as plainly as anyone in 1987. The hardest single part of building software is deciding precisely what to build, and no other part of the work so cripples the result if you get it wrong.5 Code you can refactor. A misread person you usually can’t, at least not cheaply, because the misunderstanding ships in the shape of the whole product.
So we spend the extra hour in the room, asking the question behind the question, then the one behind that, working out what a person actually does and actually fears before any of it turns into a feature. Slower at the start, sure. Much faster everywhere after. Build before you’ve listened and you’ll ship something technically correct and quietly useless. Listen first, really listen, and the technology mostly tells you what it wants to be. The connection comes first. The code is downstream of being understood.
References
- Fisher, R., & Ury, W. (1981). Getting to Yes: Negotiating Agreement Without Giving In. On positions versus interests. pon.harvard.edu
- Rogers, C. R., & Farson, R. E. (1957). "Active Listening." University of Chicago Industrial Relations Center. wholebeinginstitute.com
- Christensen, C. M., Hall, T., Dillon, K., & Duncan, D. S. (2016). "Know Your Customers' 'Jobs to Be Done'." Harvard Business Review. hbr.org
- Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. On the "five whys." lean.org
- Brooks, F. P. (1987). "No Silver Bullet: Essence and Accidents of Software Engineering." IEEE Computer. cgl.ucsf.edu