The right person to ask, and other lessons from product design

For a while now, my work rarely starts with code. It starts with meetings, notes, user stories and a backlog. On Isra Voyages, a booking platform for guided group trips, I held that product design and Business Analyst role. And the most useful lesson has nothing to do with method. It comes down to one question: who am I actually talking to?

The need is always moving

A need is never a fixed document handed to you. It's an idea that sharpens through conversation, shifts when the client sees the first mockup, and sometimes contradicts itself from one meeting to the next. I learned to specify inside that uncertainty: lock down what's stable, leave doors open on the rest, and above all write things so you can walk them back without breaking everything. The user stories, the diagrams, the prototype: all of it serves to decide as much as to document.

The right person changes everything

Here is the real lesson. On a project, the person who funds it is almost never the one who knows the day-to-day business. Early on with Isra, we were talking to the right budget decision-makers, but not to the people who actually run the departures, the quotas and the sign-ups. The result: back-and-forth, half-correct specs, wasted time.

The day we spoke to the people who run Isra every day, everything moved faster. Questions got precise answers, edge cases surfaced on their own. Since then, my first task on a project is no longer to write a line of spec. It's to figure out who knows, and to make sure I'm talking to them directly.

Email is a trap

A corollary of the previous point. A busy client does not answer an email with ten questions in it. They read it, tell themselves they'll reply later, and forget. You follow up, politely, once, twice. The project waits.

I ended up changing channels. When a topic stalls, I stop writing and I call, or I book a twenty-minute video meeting. Twenty minutes of talking settles what two weeks of unanswered emails could not. Email keeps a real use: recording a decision once it's made. Not making it.

What I'm not selling you

Product design isn't comfortable. You specify in the fog, you make decisions you may have to undo, and you absorb frustrating client trade-offs, sometimes against the very position you argued for. Part of the documentation you polish will never be read. And for someone who enjoys coding, spending days in meetings and tables rather than in the editor takes a real shift in posture. I won't pretend I love it every day.

Verdict

We picture design as a matter of method: the right templates, the right breakdown, the right tool. That's incomplete. A project almost never stalls on method. It stalls on access to the right person, and on the right channel to reach them. The real Business Analyst skill may not be knowing how to write a user story. It's knowing who to get it validated by.