October 27, 2025
Most failed data projects have perfect requirements but wrong success criteria.
Here’s what I mean:
Scientists rarely come to me with detailed requirements. They come with vague wishes: “I wish we had historical data for our controls.”
My job isn’t to take that at face value. It’s to dig deeper.
“Really? You want this? Tell me more! What would you do with it?”
“Well, it would help us assess how our pipeline performs over time.”
Now we’re getting somewhere. She doesn’t just want historical data - she wants to track quality trends and catch drift before it becomes a problem.
Lucky for her, I had designed our data warehouse to keep historical data neatly organized and right at my fingertips. A handful of days later, she had a web-based dashboard showing control performance over time. Her team was thrilled.
𝗧𝗵𝗲 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲 𝗯𝗲𝘁𝘄𝗲𝗲𝗻 𝗿𝗲𝗾𝘂𝗶𝗿𝗲𝗺𝗲𝗻𝘁𝘀 𝗮𝗻𝗱 𝘀𝘂𝗰𝗰𝗲𝘀𝘀 𝗰𝗿𝗶𝘁𝗲𝗿𝗶𝗮:
→ Requirements describe WHAT someone wants
→ Success criteria reveal WHY they need it and WHAT outcome they’re trying to achieve
Scientists typically don’t arrive with a spec sheet. They have a vague idea of what they want, shaped by whatever tools they’re already comfortable with. My role is to bridge that gap - translate their scientific need into a technical solution they might not even know is possible.
This is why interdisciplinary communication matters so much. I need to understand their workflows well enough to recognize when I can show them something better or faster than their familiar approach.
𝗧𝗵𝗲 𝗸𝗲𝘆 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 𝗜 𝗮𝘀𝗸:
→ What would you do with this?
→ How would this change your workflow?
→ What decision would this help you make?
→ Walk me through what a typical day looks like now
These questions help me understand not just what they’re asking for, but what they actually need. Sometimes the answer is exactly what they requested. Often, it’s something adjacent that solves the underlying problem more elegantly.
And when you’ve built your infrastructure with foresight - like keeping historical data organized from day one - you can deliver solutions in days instead of months.
What questions do you ask when someone brings you a vague request? How do you bridge between what people think they want and what they actually need?
