Before you build
Why the smartest data engineers still build the wrong thing, and how to never do it again.
This article is part of the Plan and scope like a data product manager playlist. Click here to explore the full series.
You just spent three weeks building something you’re proud of. Clean pipelines. Better schema. Faster ingestion.
You ship.
The client says, “Thanks.”
A few hours later, they come back and drop the hammer:
That’s not what we asked for.
It’s not that they changed their mind. You just never asked the right questions.
I’ve been there. Too many times.
You get a request, maybe through Slack or some PM doc, and you just start building. You assume the goal is obvious. You figure the details will sort themselves out. You trust they know what they want.
And three weeks later you’re cleaning up the mess.
Here’s what I’ve learned the hard way:
The biggest source of rework isn’t bad code. It’s unclear expectations.
And the worst part is most of the time, you could’ve prevented it.
Want the full version?
Download the full Stakeholder Clarity Playbook for FREE. It includes real examples, fill-in-the-blanks, and the questions I use on every project.
Let’s talk about that.
The real problem: you’re not asking but assuming
Most rework doesn’t happen because your code sucks.
It happens because you never got clear on what the hell you were actually building.
You thought you were fixing a pipeline. They thought you were giving them a report. You thought they needed it fast. They were just spitballing.
You assumed. Because that’s what we all do.
You get the Slack message, you nod, and you dive in. You think, “I’ll just get this done. I know what they mean.”
But you don’t.
You think cleaning the pipeline means refactoring the whole thing. That “we need this by Friday” means “drop everything right now.” And you think that stakeholder knows what they want.
They don’t.
And now you’re 30 hours deep in something they didn’t ask for.
Not because you messed up the build, but because you skipped the conversation.
That’s the part no one tells you:
Rework isn’t a technical problem. It’s a communication problem you created by staying quiet.
So yeah. It’s on you.
And once you see that, you can start fixing it.
Ask these before you build anything
Here are five stupidly simple questions that’ll save you from rebuilding half your project next month.
Don’t read these. Answer them. Right now.
If you stall, you’re already behind.
1. What does success actually look like?
Not in your head. Not in their head. Out loud. In writing.
What exactly does a “good outcome” mean for this request?
You think: “Well, working pipelines, of course.”
They think: “We need one clean number by Thursday.”
Totally different.
Say this:
Just so we’re aligned, if I deliver X by Y, is that success?
Write your version:
Success = …
2. Who’s the real audience?
Spoiler: it’s usually not the person who made the request.
It’s their boss. Or their team. Or a deck for some VP you’ve never met.
And the audience changes everything: the numbers, the timing, the format, the stakes.
Say this:
Who’s actually going to use this? Like, who opens it first?
Write your answer:
Audience = …
3. What decision does this support?
If this doesn’t change a decision, it’s noise. You’re not building insight but a vanity metric.
Say this:
What will someone decide differently once they have this?
Write it down:
Decision = …
4. What are the must-haves vs. nice-to-haves?
Everyone wants everything. Your job is to draw the line before you get buried in revisions.
Say this:
If I only delivered two things, what would they be?
Write them now:
Must-haves = …
Nice-to-haves = …
5. What’s the real deadline?
“By Friday” sounds urgent until you realize there’s no meeting, no report, no deadline behind it.
You don’t need their dream date. You need the trigger.
Say this:
What happens if we ship Monday instead of Friday?
Be honest:
Deadline = …
These five questions take 3 minutes to ask. They’ll save you 3 weeks of fixing work you didn’t need to do.
Trust me. Future you will thank you.
Why this works (and why people start trusting you)
Most people think asking questions slows things down.
It doesn’t. It speeds up everything that matters.
You stop doing guesswork. You stop chasing “one last tweak.” You stop rebuilding the same thing with a different label.
But here’s what’s even better:
It builds trust.
When you ask clear questions, early and confidently, people feel it. You’re not the “quiet backend engineer” anymore. You’re the one driving the project toward clarity.
You showing leadership without calling it that.
You say:
“I care about what this is actually for.”
“I’m not here to blindly ship.”
“I’m here to make sure this thing works for real humans.”
And that’s what makes stakeholders remember you.
Not because your DAGs were elegant, but because your work mattered, and you made sure of it.
Final thoughts
Most data engineers are obsessed with being right.
Clean code. Smart pipelines. Bulletproof infra.
It’s how we measure ourselves, and how we think others measure us too.
But here’s the thing:
Being right doesn’t matter if it’s the wrong problem.
No one cares how technically elegant your system is if it doesn’t solve what they actually needed.
And no one’s going to stop the meeting to applaud your airflow config.
They’ll just say, “That’s not quite what we were looking for.”
And move on.
Asking better questions sounds boring. Too simple. Too soft.
But it’s the thing that separates you from the engineer who keeps shipping invisible work.
This is how you stop being replaceable and start being trusted.
Thanks for reading,
Yordan
PS: And remember, if you want to lead projects, earn trust, and finally get seen as a strategic data engineer, here’s how I can help.
Excellent! 👌
But what if stakeholder not bothered about giving ans to these questions? are we at right place