Your Client Didn’t Ask for GPS Tracking. They Asked for Peace of Mind.

An owner asks for a live GPS map of every technician in the field.

The request sounds specific. It sounds buildable. A team can picture the work immediately: location permissions, map markers, refresh intervals, alerts, a new dashboard.

That is exactly what makes it dangerous.

The request might be for GPS tracking. Or it might be for something else entirely.

In a recent product-engineering workshop, our team worked through a fictional scenario about a field-service company. The owner wanted to pull up a map on his phone and see where everyone was. It would have been easy to treat that sentence as the requirement and start estimating.

Instead, the useful work started with a different question: tell me about the last time you needed that.

The request is rarely the whole story

The owner did not spend his day checking truck locations. He called the dispatcher when a morning felt uncertain, after a storm, a run of emergency jobs, or a schedule that had started to slip. He wanted to know whether the day was still under control.

His request for a live map was a proposed solution. The real job was getting a fast, trustworthy read on the operation so he could stop worrying and get on with his day.

Those are very different things.

A live map might not answer the question at all. It can make an owner stare at dots and invent new worries. It can create a surveillance tool for technicians who do not need one. It can add software to a workflow the dispatcher is already managing well over the phone.

Meanwhile, a clear current-status summary, a lightweight morning digest, or an agreed way to escalate a genuinely off-track day could solve the actual problem with less cost and less disruption.

This is not an argument against building ambitious software. It is an argument for earning the ambition.

AI makes this more important, not less

AI has made it dramatically easier to turn a plausible feature request into working software. That is valuable. It also means the cost of committing to the wrong interpretation has dropped just enough to become tempting.

When implementation was slow, teams were forced to spend more time deciding what was worth building. Now a prototype can arrive before the conversation has caught up with the problem.

Fast execution does not make product discovery optional. It makes discovery the part that protects speed.

The expensive failure is not a slow team. It is a fast team that spends two weeks building a polished answer to a question nobody asked.

Start with evidence, not validation

People are generous when you ask them whether they like an idea. They want to be helpful. They may imagine that they would use a new feature, especially when it is presented by the team offering to build it.

That is why questions about the future are weak evidence.

Questions about the past are better. The Mom Test is a useful reminder to ask about real behavior rather than seek polite validation. In practice, that means moving from “Would you use a live map?” to questions like these:

• When did this become a problem most recently?
• What happened that day?
• What did you do to get through it?
• Who else was involved or interrupted?
• What did the workaround cost in time, money, stress, or missed opportunity?
• What would have told you the day was okay?

Notice what these questions do not ask. They do not ask the client to design the solution. They invite the client to describe the reality the solution must fit.

In the field-service scenario, the answers reveal whether the owner needs information, reassurance, control, or a better escalation path. Those needs can overlap, but they should not be treated as interchangeable.

A feature request has more than one customer

The person asking for a feature is not always the only person who experiences it.

Live location tracking may comfort an owner while making technicians feel watched. A push-notification system may keep one stakeholder informed while forcing dispatchers to define “off track” dozens of times a day. An automation that appears simple on a roadmap may create more exceptions for the people doing the work.

Good discovery looks beyond the sponsor of the request.

Who does this change the day for? What do they do now? What would make the new workflow better for them, and what would make it worse?

That does not mean every request needs a committee. It means the team should understand the tradeoff it is choosing. A feature that shifts anxiety from one role to another is not automatically a win.

Find the job before choosing the tool

Jobs-to-be-Done gives us helpful language here: people “hire” products and processes to make progress in a particular situation.

The owner was not hiring a map because maps are interesting. He was trying to make progress through uncertainty. A more honest job statement might be:

When the day starts to feel unpredictable, help me understand whether the operation is on track so I can have confidence without creating extra work for my team.

Once the job is clear, the design space opens up.

Maybe the right answer is a status card on the first screen the owner already uses. Maybe it is a concise exception summary from the dispatcher. Maybe it is a short daily ritual that does not require software at all. Maybe GPS tracking becomes part of the answer, but only after the team can say what decision it enables and why a simpler signal will not do.

The point is not to avoid the original solution. The point is to stop treating it as inevitable.

Discovery should make shipping faster

There is a bad version of this practice where every request becomes a month of interviews and a slide deck. That is not what we are after.

The goal is to learn enough, early enough, to make a responsible next move. Sometimes that is a conversation. Sometimes it is a manual workaround. Sometimes it is a small prototype with a clear success signal. Sometimes the request is obvious and the team should simply build it.

The discipline is proportionality: match the amount of investigation to the cost of being wrong.

For a small, reversible improvement, a few focused questions may be enough. For a feature that changes how employees are monitored, restructures a core workflow, or will be difficult to unwind, the bar should be higher.

That is not process for process’s sake. It is how a team protects its ability to move quickly.

The question to carry into the next call

Before a feature becomes a ticket, ask one question that gets underneath the proposed solution:

What is happening in the real world that would make this feature valuable?

Then listen for the last time it happened, the workaround people use today, the people affected, and the outcome that would make the work successful.

Clients do not need us to blindly translate every request into software. They need a team that can help them see the problem clearly, make a good bet, and build the right thing with confidence.

Sometimes that will lead to GPS tracking.

Sometimes it will lead to peace of mind.