What Three Years of Writing Code Taught Me About Writing Requirements

An ambiguous line in a spec is a week of someone's life

When I was an engineer, the requirements I dreaded weren't the hard ones. Hard is fine. Hard is interesting. What killed a sprint was a line that could be read two ways, where nobody had decided which way was correct, and I only found out I'd guessed wrong in testing.

So now, when I write requirements, my test is simple: could two competent engineers read this and build two different things? If yes, it isn't done. This is unglamorous work. It is also the highest-leverage thing I do all week.

Estimates are a conversation, not a number

Banking taught me this the hard way. In a large bank, change control is real, and "we'll fix it after release" isn't a sentence anyone says. Every estimate I gave as an engineer had a set of assumptions buried underneath it, and nobody ever asked what they were.

Now I ask. When a team gives me a timeline, I want the assumptions, not the number. Which dependency are you assuming is ready? Which edge case are you assuming we're skipping? The number changes when the assumptions change, and the assumptions are what I can actually influence.

The switch that mattered

The genuinely hard part of moving from engineering to product wasn't the business side. XLRI covered that. It was learning that my job stopped being "solve this" and became "make sure we're solving the right this."

As an engineer, a well-defined problem was a good day. As a PM, a well-defined problem means most of my work has already happened, upstream, in conversations that were probably uncomfortable. Getting to a clear problem statement is the job. The build is what happens after the job is done.

What I'd tell an engineer thinking about product

Your instinct that most product decisions are under-specified is correct. That instinct is your advantage, not your complaint. Move to the side of the table where you can fix it.