👷 Stop Starting Data Projects
The minimum viable process for turning vague stakeholder requests into shipped, adopted work
This article is part of the Data Project Management playlist. Click here to explore the full series.
A colleague of mine was one of the most talented engineers I have ever worked with. Sharp, fast, technically thorough. When a stakeholder came to him with a project, he would disappear for six weeks and come back with something impressive.
The stakeholder would look at it, go quiet, and say something like “This is not quite what I had in mind“.
And every single time, his response was the same. “They are stupid. I know what they need. They should use it“.
The project would either get quietly cancelled, or the stakeholder would ask someone else to redo it. I watched this happen twice. Same engineer, same pattern, different projects.
The thing is, he was not wrong about the technical side. The code was clean, the logic was sound, and the solution was, in his view, objectively correct.
He just never learned the business process. He never asked the stakeholder to show him how they actually worked. He heard the request, translated it into a technical problem, and solved that problem in isolation. Then he was genuinely confused why nobody wanted what he built.
The truth is that nobody gets fired for writing good code. They just stop getting the interesting projects. The stakeholder quietly routes around them. And they never quite understand why.
It is a process problem. And process can be fixed.
Here is the exact process I use, from the moment a vague Slack message lands to the moment I close a project out.
The Scripts That Keep Projects on Track
Know exactly what to type at every stage, from the first vague request to closing the project out.
Reply to the Slack Message Before You Touch a Keyboard
The vague request is not a problem at all. It is the starting point.
Most engineers read a message like “Hey, can we get a dashboard for the sales team?“ and immediately start thinking about the data model. That is the mistake.
Instead of a spec, the request is an opening. Your job at this moment is to open a conversation without making it feel like a process.
Do not schedule a meeting. Do not send a list of questions. Send one message back.
Here is what I type:
This kind of a message signals you are taking it seriously without turning it into a project before you know what the project is.
When the call happens, most engineers ask “what do you want the dashboard to show?“
But that is the wrong question. It gets you a list of metrics that may have nothing to do with how the stakeholder actually works. Instead, ask them to show you their current process.
Here are the three questions I ask on every first call:
Can you walk me through how you’re doing this currently?
What does a good week look like for you, in terms of this data?
If this was done and working perfectly, what would you do differently?
The third question is the important one. It forces them to think about behaviour, not features. The answer tells you what the project is actually for.
This publication is not about tools.
It is about operating as a data professional in a world that has no idea what you do or why it matters.
The Definition of Done Is a Contract
Before you leave that call, you need one sentence that both of you agree on.
Here is how I get it:
Let me make sure I’ve got this right. What we’re building is X, and we’ll know it’s done when Y. Does that sound right to you?
If they say yes, you have your definition of done. If they hesitate, you have just saved yourself six weeks of building the wrong thing. Keep asking until the sentence lands cleanly.
Write it down and send it in Slack after the call. Something like:
Ideally, you create a channel for that project. Now both of you, and everybody interested in that project have it in writing.
Know Who Can Kill This Before You Build Anything
Before you write a single line of code, you need to know two things:
who can kill this project
who will fight for it
Most engineers talk to the person who sent the Slack message and assume that is the whole picture. Sometimes it is.
Often there is a manager who needs to sign off, a team that will be affected, or a senior stakeholder with strong opinions who has not been in the conversation yet. Finding out about them after you have built something is expensive.
You do not need a stakeholder mapping workshop, but you need to ask one question on that first call:
Is there anyone else I should loop in, or anyone whose sign-off we’ll need before this goes live?
That one question will surface 90% of what you need to know. From the answer, you are looking for three types of people.
The decision maker: The person who can say yes or no to the final output. Everything you build needs to satisfy them, even if they are not the one who sent the request.
The champion: The person who wants this to exist and will push for it internally. Usually the person you are already talking to. Keep them close.
The informed: People who need to know this is happening but have no power over the outcome. A quick message every now and then is enough.
Once you know who you are dealing with, agree on delivery stages. You just need two or three rough checkpoints and an expected delivery date. Something you can type in Slack in four lines.
Here is what I send:
That message does three things. It sets expectations, commits you to a timeline, and signals that you will be showing progress before the end. Your stakeholder now knows they will not be waiting in silence for six weeks.
The RACI Nobody Will Ever See
You do not need to show anyone a RACI diagram. But you need to have done the thinking.
Take five minutes, on your own, after the first call. Write down who is responsible for building this, who is accountable for the outcome, who needs to be consulted, and who needs to be kept informed. No template, no meeting, and definitely no slides.
When something goes wrong mid-project, and something always does, you will know exactly who to call and what to ask. That clarity is worth more than any amount of documentation.
Build the MVP in Under Five Days
McKinsey research on 5,400 IT projects found that the average large project delivers 56% less value than predicted. The number one reason is building in the wrong direction for too long before anyone checks. The fix is embarrassingly simple:
Build something ugly and show it fast.
The rule I follow is five working days from the moment I actually start building. Not from the first call. From the day I sit down and open Neovim (and mostly Claude Code nowadays).
It will have hardcoded values, missing edge cases, and placeholder logic. That is fine. The goal of the MVP is to confirm you are moving in the right direction before you invest more time going in the wrong one.
Here is how I introduce it:
That framing removes the pressure from both sides. The stakeholder is helping you steer.
Don’t look for the “I love it” responses. This doesn’t matter. Listen for whether they are reacting to the right problem.
If their feedback is about polish, you are on track. If their feedback reveals a fundamental misunderstanding about what they needed, you have just found that out in week one instead of week six.
How to Handle “This Isn’t Quite What I Had in Mind”
This is the moment most engineers dread. It does not have to be.
If the stakeholder sees the MVP and tells you it is not what they expected, that is the process working. Here is what I say:
That’s really useful, thank you. Can you explain me what you had in mind? A rough sketch or an example would help me get there faster.
Then you go back, adjust, and show them again. The loop is fast because you have not built much yet.
The other outcome is rarer but worth being ready for.
Sometimes a stakeholder sees the MVP and realises they do not need the project at all. Seeing something concrete makes them understand that what they actually wanted was a process change, or a conversation with another team, or something that has nothing to do with data.
When that happens, you have saved everyone a significant amount of time. Close it and move on.
Show Progress Every Three Days or Lose the Project
Once the MVP is signed off and you are building toward the real thing, most engineers go quiet. They are heads down, making progress, and they assume the stakeholder knows that.
The stakeholder does not know that.
After three or four days of silence, they start wondering.
After a week, they are telling their manager the project might be stalled.
After two weeks, they have mentally moved on and started looking for alternatives.
You are still building, but the project is already dying.
The rule I follow is simple.
No more than three days without sending something.
It does not need to be a status report, or a meeting. It can be one Slack message.
Here is what I send msot times:
This takes less than 30 seconds to write. It resets the clock on stakeholder anxiety and signals that the project is moving.
Over time, the stakeholder starts getting invested. They follow the progress, and start telling colleagues about it. By the time you deliver, they are already its biggest advocate.
That is not a small thing. A stakeholder who is invested in a project will push for its success, defend it in conversations you are not part of, and use it after delivery.
That kind of adoption happens only if you keep them close while you are building.
When Your Stakeholder Goes Ghost
Sometimes the silence goes the other way.
You send an update and hear nothing back. You share a progress demo and get no response. You follow up once and still nothing. In my course, I call these stakeholders Ghosts.
Silence at different stages means different things:
Early in the project, no response usually means competing priorities. They are busy, the project is not urgent, and they will come back.
Mid-project silence is a warning sign. It often means they have lost confidence, or something has changed internally that they have not told you about.
Post-MVP silence, after they have seen something concrete and gone quiet, almost always means they did not know how to say “this is not what I wanted“.
In all three cases, the move is the same. One message that forces a yes or no without making it feel like a confrontation.
Here is what I send:
That message gives them an easy out if something has changed, and it gives you the information you need to decide whether to keep building.
Most of the time, you will get a response within an hour. Either they apologise for being slow and re-engage, or they tell you something has shifted. Both outcomes are better than building in silence for another two weeks.
Plus, having this in the dedicated channel means you have a documented go/no-go decision.
You already know the problem.
The gap between "knowing what to do" and "doing it" is just a decision. Inside the paid tier you get the frameworks, scripts, and templates I used to build my career over 16 years. Field-tested stuff!
Stop When It’s Good Enough
At some point, the project is done. Not perfect, but done.
This is harder than it sounds. Engineers are wired to improve things. You finish the main deliverable and you start noticing rough edges:
The query could be faster
The dashboard could be cleaner
The logic could handle three more edge cases
So you keep going, and your stakeholder is sitting there wondering why they still do not have the thing you promised them.
The signal that you have hit good enough comes from the stakeholder. When their feedback shifts from “can we change X“ to “this is great, when can we roll it out“, you are done.
Here is how I close a project:
I think we’re at a good place. Here’s what’s been delivered, here’s how to use it, and here’s who to contact if something breaks. Is there anything critical missing before we call this done?
That last question matters. It gives them one final chance to raise something real. If they say no, the project is closed. If they raise something small, you make a call on whether it belongs in this version or the next one.
And this brings you to scope creep. Every project attracts it. The stakeholder sees what you built, gets excited, and starts asking for more. New reports, new dimensions, new use cases.
These are all reasonable requests, and all belonging in a different conversation. I have a full article on how to handle that without losing the relationship, linked at the end of this one.
The other exit is the kill decision. Sometimes the right call is stopping entirely.
Final Thoughts
The engineers I have seen succeed long term are not always the most technically gifted. But they are the ones whose work gets used. Their dashboards are open every week, their pipelines run without anyone filing a ticket, and their stakeholders mention them by name in meetings they are not part of.
That happens because they treat the non-technical part of the job with the same rigour they bring to the technical part:
They ask the right questions before they build anything
They show their work early and often
They keep people close instead of going silent
The process in this article is the minimum required to make sure your technical work actually lands. Most of it happens in Slack, and none of it requires a bureaucracy.
Even a project that looks doomed can be turned around with the right moves at the right time. I have seen it.
The engineer who gets that call, who steps in late and still manages to deliver something the stakeholder trusts, is never the one who worked the hardest. It is always the one who communicated the best.
—
Yordan
PS: Paid members consistently share they got promoted or praised because they apply my guides. When ready, upgrade here.
Gold as always, these are something we can’t learn easily unless we experience it. Thanks for sharing your valuable knowledge Yordan
thx for the article. it’s great to be reminded about the basics every once in a while. i feel like it’s too easy to forget and go straight to the solution