What your developers never see (and why it changes everything)

Article inspired by our conversation with Frédéric Leguédois on the On part en prod podcast.

Link to the full episode:

A team builds a mobile app for field technicians. The code is clean, the user flows are thought through, acceptance testing passes. Then the feedback starts to come back. Not a direct call, not a bug report. More like hallway noise. The app doesn't fit the job. It's not ergonomic. It's too slow. It's badly designed. The feedback is vague, contradictory, and the dev team struggles to understand what's actually wrong. On their own workstations, everything runs fine.

It takes a while to figure out that the problem has nothing to do with the code. The technician is on their feet, wearing gloves, working on a small reinforced phone screen, with patchy network coverage. What the team designed from a quiet office doesn't survive contact with the real world.

We run into this kind of scenario regularly. And in most cases, it isn't a skill problem, a budget problem, or a method problem. It's a blind spot: nobody on the dev team has set foot where the software actually gets used.

The reflex that makes things worse

In our On part en prod episode, Frédéric Leguédois lays out a simple principle: when a problem shows up, every organisation's reflex is to add. An extra control, a validation committee, a new step in the process, another document. Every addition creates complexity, and every bit of complexity creates new problems.

You see exactly the same mechanism in the relationship between dev teams and their users.

A deliverable misses the mark? We write a more detailed specification. Specifications aren't enough? We add a proxy Product Owner. The back and forth takes too long? We set up a validation committee. Validations pass but the result is still off? We add an acceptance phase.

At every disappointment, another layer. The developer ends up further and further from the user, separated by intermediaries who filter, rephrase, and sometimes distort the information. The surprises at delivery time don't go away. They multiply.

Three stories that keep coming back

Frédéric tells the story of a team that had built a floor-plan drawing tool for a laboratory. Several iterations with users, regular demos, mostly positive feedback. Delivery day comes, and the manager calls, furious. The software's unusable. The team drives over, shows up on site, and finds the problem. The users, the ones drawing plans all day long, had the smallest screens in the company. Why? They were on bad terms with IT, and IT had replaced every monitor in the building except theirs. No scoping document would have captured that. You had to be there in person.

At exFabrica, we've run into something very similar. A team was designing an app for factory operators. On paper, it all looked good: clean screens, thought-through user flows. Then we decided to go simulate real usage on site with a first testable version. We pulled out the phone and started the flow. Scan a barcode here, walk over there to scan an RFID tag. And we realised that between two operations, there are 200 metres of factory floor to cross. The scale of an industrial site doesn't fit inside a user flow drawn in Figma. We had to rethink the whole thing.

Frédéric has another one, again in an industrial setting. A sophisticated production system, with label printing. Everything was tested in a lab, on the actual machines. On install day in the workshop, production collapsed. Not because of the software: the printer was at the end of the hallway. Operators would launch their print jobs, but each one changed the paper format. The first one loads their labels, the second one changes the format, the first one restarts the job and everything comes out on the wrong stock. High-tech products, brought to a halt by a printer 30 metres away.

These three stories all share the same pattern. A technically polished project that falls apart on contact with reality. And in all three cases, the fix wasn't to add another validation step. It was to go on site, earlier.

Fewer intermediaries, more understanding

Sending a developer into the field isn't about adding a new practice to a process. It's about removing one. It's the same principle Frédéric applies everywhere in our conversation: instead of stacking more layers between the problem and the solution, you strip them out. You shorten the chain. You connect the person who builds directly to the person who uses.

Something shifts when that happens. A developer who's watched a user struggle with a tool doesn't come back with the same posture. A kind of compassion kicks in pretty quickly. They think, "this isn't right, how are they supposed to work with this?". And they start looking for the simplest answer to the most painful problem. Not the most elegant solution technically, not the most ambitious one: the most useful.

It's also an antidote to over-engineering. When a developer never meets their users, they end up leaning on what does motivate them: the tech. That's human. But when they see first-hand the conditions their code runs in (the gloves, the noise, the tiny screen, the unstable network), technical sophistication loses its appeal and gives way to what actually works.

One point tends to get underestimated here: the user persona rarely matches the developer or the designer. You can write persona sheets, work on empathy, try to put yourself in someone else's shoes, and there's still a gap between imagining someone's constraints and seeing them with your own eyes. A factory operator doesn't work like a developer at a desk. A technician on a worksite doesn't handle a phone the way we do. These working conditions change everything about how people behave with the app, and they're almost impossible to anticipate without having observed them.

So how do you actually do it?

There are two levels of practice, depending on what your context allows.

Physical fieldwork, when it's possible. That's the ideal. On a mobile-app redesign for site technicians, the first thing we did was send part of the team out for a full day with a technician in the field. Not a meeting in a room, not a projector demo: a day riding along, watching how they pull out their phone, under what conditions they use the app, what slows them down, what frustrates them. That one day changed the direction of the project. Design choices we thought were obvious turned out to be wrong, and problems that no document had ever mentioned became the top priority.

Going on site to see the actual working conditions helps you design a better app. That's true for industrial applications, but also for any line-of-business software where the usage environment isn't the development environment. And this field understanding shouldn't stop with Product Owners and designers: developers themselves need to see how users interact with what they build.

Digital fieldwork, when direct access is complicated. In many organisations, sending a developer to the end user is an obstacle course. Intermediaries, security rules, political sensitivities. That's not a reason to give up on understanding how the product is really used.

You can invite a few key users to the sprint review, to walk them through the last sprint's outcomes and collect real field feedback to feed your backlog. You can decide that every few reviews, one of them is a special session with key users as guests.

Session replay tools (Screeb, for example) let you watch real usage sessions. How the user navigates, where they hesitate, where they give up, which journeys take three times longer than expected. It isn't a tool reserved for Product Owners or UX designers. It's a tool to put in developers' hands. When a developer watches a session replay and sees a user clicking frantically on a button that doesn't respond, or filling in the same form three times because the page reloads, they don't react the same way as when they read a Jira ticket that says "improve responsiveness of form X".

An even simpler first step: run user tests on interactive prototypes or on the actual app, even over video call. The ideal is to repeat these tests throughout the project, not just once at kickoff.

Either way, the goal is the same: shrink the distance between the person who builds and the person who uses.

Autonomy and responsibility: the real difference

This isn't just a product management practice. It's a question of team autonomy, a core principle of agility.

Frédéric talks about this in our conversation: an autonomous team is one that can decide its own priorities, that can react to what it finds, that isn't waiting to be told what to do at every step. But autonomy without an understanding of the field doesn't work. You can't make good decisions about what to build, in what order, with what level of sophistication, if you have no idea of the conditions in which the product is going to be used.

That's where responsibility comes in. A team that goes on site, watches users, understands their constraints, that team can commit to the relevance of what it delivers. It isn't just building to spec anymore. It's in a position to say, "what we're being asked to do won't solve the real problem", or, "there's a much simpler answer that nobody thought of because nobody has seen the usage context".

And this is where the team's experience makes a difference people rarely measure. Going into the field is one thing. Knowing what to observe, what questions to ask, how to turn what you saw into concrete decisions, that's another. A team that has already lived through projects where the field revealed surprises learns to pick up on weak signals. It also knows how to do this without creating friction with the client, because it's learned to observe and listen before judging what's already in place. That's not theoretical knowledge, it's a reflex built up project after project.

The combination of autonomy, fieldwork, and experience gives you a team that delivers solutions that actually work in the real world. Not in a slide deck, not in a demo room. On the shop floor, on the worksite, behind the counter.

Where do you start?

Next time a project goes sideways, before adding another layer of specification or another validation step, try the opposite question: can we remove an intermediary and bring the developer closer to the user?

That can be a day in the field. That can be shared session-replay access for the dev team. It can simply be a user test over video, or a direct, unfiltered conversation between the person writing the code and the person using it.

The outcome tends to be the same: fewer misunderstandings, simpler solutions, and a product that works in real-world conditions.