Discovery Before Delivery: Earning the Right to Build

4 MINS

The most expensive feature is the one you build well and nobody needed. In delivery management SaaS, where every screen touches a dispatcher's workflow or a driver's day, I've learned to slow down at the start so the team can move fast later. Discovery isn't the warm-up before the real work, it's how you earn the right to build at all.

"We need a feature" is the end of someone's thinking, not the start of mine

When a request arrives fully formed, "add a button here," "build this dashboard"it's tempting to take it at face value and ship. But a request is usually a solution someone already guessed at, wrapped around a problem they haven't named. My job is to unwrap it.

A few questions do most of the work:

What decision are you trying to make? turns a feature request back into a problem worth solving.

What happens on the day this goes wrong? surfaces the edge cases that decide whether the feature survives real use.

Who's the unhappy user here? finds the dispatcher or driver who'll quietly route around it. Most of the value lives in the gap between what someone asked for and what they actually needed.

Validate cheaply before you commit expensively

Customer interviews, user testing, A/B testing, NPS analysis, these aren't boxes to tick, they're how I avoid betting a sprint on a hunch. A wireframe tested with three transporters tells me more than a beautifully built feature shipped on faith. The cost of being wrong on paper is an afternoon; the cost of being wrong in production is a quarter.

So I push for the cheapest test that can still kill the idea. If a prototype can't convince the people who'll use it, no amount of polish later will.

Stakeholder alignment is part of discovery, not a separate meeting

In logistics, the stakeholders aren't abstract, internal teams, transporters, subcontractors, and the customer all pull in slightly different directions. Discovery only counts if it aligns them, not just informs me. I'd rather surface a disagreement early, in a roadmap conversation, than discover it the week before release when it's far more expensive to resolve.

Clarity is a kindness here too. A crisp problem statement everyone agrees on is worth more than a clever solution only I believe in.

Why I protect the front of the process

It would be faster, on any given week, to skip discovery and start building. It's almost never faster over a quarter. Every unvalidated assumption gets re-litigated in three meetings and rebuilt at least once. Spending a little time up front to be sure we're solving the right problem is the closest thing to a shortcut I've found, and it's why the deliveries downstream go smoother.

From GIS Maps to Product Roadmaps

Piramanayagam skipped presentations and built real AI products.

Piramanayagam T D was part of the April 2026 cohort at Curious PM, alongside 18 other talented participants.