When I first started working in tech, I thought changing requirements meant someone somewhere had messed up.

Someone forgot to think properly. Someone changed their mind. Someone didn’t know what they wanted.

Then I started working on real projects.

Now I think changing requirements are annoying… but also pretty normal.

I’m a Founder Associate at DataSync now, but I actually started as a testing intern. Before that, I grew up working in my mum’s Chinese takeaway. Weirdly, that probably taught me more about stakeholders than I expected.

Because customers changed their minds all the time.

“Actually, no onions.” “Can I swap the rice?” “Oh, I thought this came with chips.”

And if you acted offended every time someone changed their order, you probably weren’t going to last very long.

That doesn’t mean every change is reasonable. It just means people are messy. And stakeholders are people.

First: Stop Taking It Personally

This sounds obvious, but when someone changes requirements after you’ve already started working on something, it can feel personal, especially when you’re junior. You start thinking: Did I misunderstand? Have I wasted time? Why didn’t they say this earlier?

Sometimes the answer is just that they didn’t know yet. A lot of stakeholders are figuring things out while they’re talking.

That used to frustrate me until I realised something important: most people understand the problem before they understand the solution they actually need. That difference matters.

A stakeholder might say, “We need a dashboard showing customer profitability.” Three meetings later it becomes, “Actually, we need profitability by region.” Then, “We also need historical movement.” Then, “Can we compare it against peers?”

At first, this looks chaotic. But often what’s actually happening is discovery. They’re slowly realising what decision they’re actually trying to make.

The Real Question: Is This Discovery or Chaos?

Not all requirement changes are the same. This is something that took me a while to learn.

There are two very different situations.

1. Healthy Discovery

This is when requirements evolve because people are learning. Usually you hear things like: “We didn’t realise that dependency existed.” “After seeing the first version, we realised we need something slightly different.” “The original assumption wasn’t right.”

This is normal.

Sometimes stakeholders need to see something before they can properly explain what they actually mean, especially in data projects. People say they want one thing, then when they see it they realise: “Oh. That’s not actually the question I was trying to answer.”

Annoying? Slightly. Human? Completely.

2. Actual Chaos

This is when requirements keep changing because nobody has slowed down enough to make decisions. Different stakeholders contradict each other. Nobody agrees on priorities. Requirements reverse every meeting. People keep asking for “quick changes” five times a week. Nobody owns the final decision.

This is where projects become painful. You end up building version seven of something nobody really wanted.

What I Actually Do Now

I’m still learning, but a few things genuinely help.

1. Repeat Back What You Think You Heard

Instead of saying “okay,” say: “So just to confirm, the goal is X because you’re trying to solve Y?” You’re not just repeating requirements, you’re repeating the reason behind them. Because requirements change, but reasons usually don’t. And if the reason changes too, at least everyone knows the scope has changed.

2. Write Decisions Down

At DataSync I learned quickly that memory is not a project management system. After meetings I write down what was agreed, what changed, what still needs decisions, and what assumptions are being made. Nothing fancy, just enough so that when someone says “I thought we agreed…” you’ve got a reference point.

3. Show Something Early

The fastest way to discover bad requirements is to build something small early. A mock-up, a sample, a rough draft. People react much better to something visible than abstract conversations. Before they see it: “Looks good.” After they see it: “Oh wait… actually can we…”

Honestly, better early than three months later.

4. Learn What Problem They’re Actually Trying to Solve

In my mum’s takeaway, customers rarely explained the real issue first. “I want less sauce” usually meant “last time it was too salty.” That’s completely different information.

Stakeholders are similar. “We need another column” might actually mean “we don’t trust the output” or “we can’t make decisions with this view.” The requirement is often just the symptom — the real problem sits underneath it.

Also: Sometimes It Is the Team

Sometimes stakeholders keep changing requirements because we haven’t asked good enough questions. It’s easy early on to think they’re impossible, but sometimes we rushed discovery, assumed everyone meant the same thing, or used language that doesn’t translate outside data and engineering. That part is on us too.

Where Good Delivery Helps

Changing requirements become much less painful when teams can move quickly. If changing direction takes three weeks and lots of approvals, every change feels expensive. But if teams can test ideas quickly and show examples early, conversations improve because people are reacting to something real instead of theory.

That’s one of the reasons I’ve ended up enjoying data projects more than I expected. A lot of the job isn’t just technical — it’s helping people figure out what they actually need and adapting quickly enough that the project doesn’t stall every time something changes.

At DataSync, that’s a big part of what we try to help with: reducing the back-and-forth that slows projects down so teams can get to working solutions faster. Not by pretending requirements never change, but by expecting that they probably will.

Final Thought

If you work on projects long enough, someone will change the requirements. Probably multiple times.

You can either spend your energy getting annoyed about it or get better at understanding why it changed.

The biggest lesson I’ve learned so far is this: changing requirements do not automatically mean someone is difficult. Sometimes it means the team is learning. Sometimes it means nobody is aligned. And sometimes it means the stakeholder has finally figured out what they were actually trying to ask for in the first place.

Which, to be fair, happens to all of us.

‍