The thing I kept getting wrong
During recent client work, I noticed something about myself that I’d been ignoring for a long time.
I’m a developer. So my instinct, my number one concern, was always implementation. How do I build this? How do I handle the edge cases? How do I make it faster? That’s the part I enjoy, and that’s the part I poured my attention into.
But over the last few projects, that instinct kept letting me down. Not because the code was bad. Because I was building the wrong thing well.
The real lesson, the one I should have learned earlier, is this: before anything else, I need to find out what the requirement actually is.
I had this backwards
For a long time I didn’t pay much attention to the requirement. I treated it as the boring part you skim before you get to the real work.
So I’d jump straight into the implementation. I’d think hard about how to handle this odd input, how to shave time off that loop, how to make the whole thing clean. And then somewhere down the line it would turn out the thing I’d carefully built wasn’t what the person asked for in the first place.
That’s the mistake. I was optimizing the answer to a question nobody asked.
After this happened a few times, it finally clicked. The implementation is not the first problem. Finding the requirement is the first problem. Everything else comes after.
Say it back in your own words
The habit I’ve picked up now is simple. When I get a requirement, I don’t just nod and start coding. I restate it in my own language and check it back with the person who gave it to me.
Not their words. My words. Because if I can only repeat their phrasing, I haven’t actually understood it, I’ve just memorized it. When I rephrase it and they say “yes, that’s right,” then I know we’re actually aligned.
And when they say “no, not quite,” that’s the best outcome. I just caught a misunderstanding for the price of one sentence instead of one week.
The blue problem
The way I think about this is colors.
Say we both agree the answer is “blue.” Sounds aligned. But the blue in my head might not be the same blue in yours. Mine might be closer to navy, yours closer to sky. We both said blue, we both walked away happy, and we’re building two different things.
That gap is where the real conflict comes from. Not from people disagreeing out loud, but from people agreeing on a word while meaning different things underneath it.
So the job is to keep checking the level of blue. Not just “is it blue?” but “is it your blue or my blue?” That sounds small, but it’s the whole game.
Alignment is for everyone, not just the client
This isn’t only a client thing. It’s the same with teammates, with coworkers, and now with AI agents too.
An agent will happily run off and build whatever it thinks you meant. If your instruction is fuzzy, it fills the gap with a confident guess and keeps going. Exactly like a person would, and it’s the same blue problem underneath. The alignment step doesn’t go away just because the other side is a machine. If anything it matters more, because the agent won’t pause and feel awkward about a vague spec.
So whoever is on the other side, client, coworker, agent, the first move is the same. Get aligned before you build.
Prototypes are how I get there
Talking about a requirement only gets you so far. Words are exactly where the blue problem lives.
So the way I actually solve it is with fast prototypes. Instead of describing my understanding, I build a quick, rough proof of the idea and put it in front of the client or my teammate. “This is what I think you mean. Is this it?”
A prototype is concrete. You can’t hide a mismatch behind a vague word when there’s a real thing on the screen. People look at it and immediately know whether it’s their blue or not. I’ve found a quick prototype is far more powerful for alignment than any amount of careful discussion.
When the client doesn’t know what they want
Here’s the harder case I keep running into. Sometimes the client doesn’t actually know what they want. The requirement isn’t clear in their head either, so there’s nothing for me to align to.
What works for me there is to stop waiting for them to figure it out and instead offer my best guess. I provide what I think the requirement should be, and I make it concrete.
The strongest version of this is offering multiple prototypes. A few different takes on the idea, each one a little different. That flips the whole conversation. Instead of “what do you want?”, which they can’t answer, it becomes “which of these is closest?”, which they can.
They might pick one. They might pick parts of two and ask me to combine them. Either way, we’re moving.
And there’s a quieter benefit. By offering a set of options, I’m also setting the boundaries. I’m narrowing the space down to something we can actually talk about, instead of leaving it wide open. That makes the whole process faster and the conversation clearer for everyone.
Where I’m landing
None of this is technical, which is funny, because I’m the person who always wanted to talk about the technical part.
But the lesson I keep relearning is that alignment comes first. Before the edge cases, before the performance, before any of the implementation I actually enjoy, I need to be sure I understand the requirement, and I need to be sure the other side and I are seeing the same blue.
I’ve made the mistake of skipping that step too many times. Starting to build before I was honestly one hundred percent sure what I was building. So now I do it the other way around. Find the requirement, say it back, prototype it, confirm the blue. Then write the code.
You can write perfect code for the wrong requirement. Get aligned first. Make sure your blue is the same level of blue as theirs, then build.