The clues that come when customers build around you

Mercury was building a new digital platform for a complicated logistics service, and there was no shortage of opinions about what it should become. The temptation was to start designing. Instead, I wanted to understand what problem the platform was actually supposed to solve.

It sounds obvious, but it wasn’t. People were already talking about interfaces and features with references to mature consumer tools. It could easily have become a design brief. I started asking different questions. Not what features should it have, or what should the interface look like, but what business problem is this platform the answer to? What was the opportunity, and how did it fit the company’s longer-term positioning and business model?

Mercury moved time and temperature-sensitive shipments for life-science customers. The service depended on specialized knowledge: different commodities, different geographies, different requirements, and lots and lots of exceptions. Much of that knowledge lived with the experts handling the shipments, the squads. Not everything was documented, but with people working in close proximity, an answer was rarely far away. The new platform was being asked to turn all of it into a better system. Before deciding what it should do, I needed to understand the people already living inside it.

The system customers had built for themselves

I spent time with the squads. They worked across multiple monitors, email, spreadsheets, and shipping systems, often moving information manually.

Then we talked to customers, and what they described looked surprisingly similar. One customer started every morning with a spreadsheet, manually transcribing shipment information from email. Twenty minutes of work before their day had really begun, just to understand where things stood. Another had built lightweight automation to track shipments, delays, and contacts. Even then, figuring out what was actually inside a shipped box could be a challenge. Another sent multiple emails each morning to make sure their shipments were seen before cutoff. Missing it meant additional charges.

These weren’t people asking us for a nicer interface. They had built parallel systems because they needed them to do their jobs. They prided themselves on being the person their colleagues would ask.

The service itself was very valuable. What surrounded it sometimes created uncertainty, repetition, and stress. Customers were compensating for gaps in the system with spreadsheets, emails, reminders, and their own ingenuity. They had started designing the product.

Platform = squads + system

Customers weren’t asking us to remove the people from the service. Quite the opposite.

They knew the subject-matter experts in their squads. They trusted them to triage complicated cases, navigate exceptions, and step in when something went awry. That expertise was part of what they were paying a premium for. Not one participant complained about the squads.

What frustrated them was everything they had to do to understand what was happening around them: reports, communication, status, and visibility. Both the supplier and the buyer were playing the same game of “where’s my stuff?”

That distinction mattered. Customers will accept friction when it increases their chances of success. The goal wasn’t to eliminate every human interaction or smooth every bump. It was to work out which complexity belonged in the product, which belonged with the experts, and which was simply noise created by the way the system worked.

“Platform = squads + system” had been an idea, but the research provided teeth. They were fundamentally part of the product.

Make the hidden system visible.

I built a journey map that looked at both sides of a transaction: what the customer was trying to accomplish and what the internal teams had to do to make it happen.

I kept the larger picture intact while hiring designers, building a tokenized design system, standing up a research practice, and working alongside development and a product manager.

The map let us ask better questions. A red or green status wasn’t enough. If a customer had to provide another piece of information, what did that enable internally? If an employee had to check something by hand, could the product surface it earlier? If a shipment was delayed, who else needed to know?

Customers wanted to know what had happened and why. What Mercury was already doing about it, and if they needed to do anything. That gave “visibility” a different meaning. It wasn’t about more data on a screen but just enough at the right moment to stop worrying.

Research became a way to make decisions.

Once we understood the problem, research had a specific job. Not to validate finished designs, but to test assumptions before the organization invested engineering time.

We ran two rounds of customer interviews several months apart, documented and tagged the sessions, ran surveys, sentiment analysis, and tree testing, and pressure-tested the thinking through prototyped workflows.

Some of the most important decisions were about what not to build. The platform could have opened the way enterprise tools typically do: a dashboard filled with metrics, charts, and account summaries. But nobody we interviewed asked for it. They weren’t opening the product to admire their logistics operation. They wanted to know what was happening and whether they needed to do something now or later.

So the home screen did three things: track, pickup, ship. That same discipline carried through the rest of the product. Some problems belonged in the interface, some in automation or APIs, and some with the practiced judgment of the squads. Others weren’t product problems at all. Research didn’t give us a longer list of things to build. It helped inform the difference.

Collapsing clues into product problems

At the beginning, the question was what business problem this platform was supposed to solve. I assumed the answer would eventually become a product strategy, but it became something a lot more human.

Customers didn’t need software to replace the people they trusted. They needed a system that made those people’s expertise easier to access and understand, and removed the coordination work they had built themselves. Their spreadsheets they shared had been telling us this all along. They weren’t evidence of a bad workflow; it was evidence of customers building what they needed around a service they truly valued.

Some complexity belonged in software. Some belonged in automation. Some still belonged with a person who knew what to do when a time-sensitive shipment didn’t behave as expected. The design challenge wasn’t making a complicated service look simple. It was deciding where the complexity should live, so the customer didn’t have to carry it.

“I can just hear everyone’s voices when you first started asking for this or that feature, versus speaking with customers and learning from them.”