Sami Surakka

I have described a particular kind of morning at Insta Response in almost the same words for years. Between 2015 and 2019 we took developers out of the office and into 112 centres. They watched operators handle live emergency calls. They saw the pauses, the workarounds, the extra confirmation while someone on the line was in trouble. What they brought back was larger than what a ticket or a spec can hold.

I have been reading Marty Cagan’s Transformed, and I hit a line about exposing engineers to customer interactions that sounded almost exactly like how I used to describe those visits. He has used almost those words for a long time. In The Foundation of Product he writes that you do not need every engineer on every visit, but “the magic happens” when an engineer sees a user struggling with their product. Developer Powered Innovation is even closer to how I used to talk about those mornings: connect developers with actual users and let them witness, first hand, the good, the bad and the ugly.

I had been calling it magic too, years before I read him on it. I still think it is the right word, even if it sounds a bit much on the page. Something in how a developer prioritises changes after they have seen the work in the room.

This piece is for product and engineering leaders who already agree that discovery matters, and who still transmit most of it through tickets because getting people on site is awkward.

What we actually did

I started at Insta Response in 2015, covering maternity leave on Finland’s national emergency response product. Research had lapsed. I ran a guerrilla survey, took the findings to our VP, and used that to get backing for proper visits. Then we went: not only me, entire teams, sitting with operators in their context.

I coached people who were not UX on how to run a contextual interview and how to write down what they saw. I wanted them in the room. A summary from me does not travel into the backlog the same way.

To make it last beyond a single trip, I set up UX ambassadors: a developer in each of five to six teams who volunteered to champion usability. I trained them in heuristics, interview technique, and UI practice, and they sat in a review loop with me. The model worked when the person cared. Enthusiasm is not a process. Mentoring and structured reviews had to sit behind it, and as the UX team grew from one to three we could absorb more of that load.

The longer Insta story, including the public call-answering figures, is in the emergency response case study. I am leaving the KPIs there. This piece is about the transfer.

What they took away

A spec can say “reduce time to dispatch” or “fewer confirmation dialogs”. It cannot make a developer feel the extra second in the room. After the visits I watched people argue differently in refinement. They pushed back on their own ideas. They remembered particular operators. Some polish items got treated as safety items.

That is the transfer a ticket is bad at. You can write a better ticket. You still lose the sensory part: the room, the pace, the cost of a pause.

Cagan’s version of this is that engineers sit closest to what is just now possible, so they see solution options the PM and designer miss. I saw that. I also saw something more ordinary, and in a safety-critical product maybe more useful: they became harder to satisfy with a workflow that was merely complete.

When you cannot go

At Tietoevry I tried to get the same kind of access with clinicians in hospital districts and ran into regulatory constraints. We had excellent internal SMEs, doctors and nurses on staff, and they were valuable. There is still a gap between “we understand the domain” and “we have watched the shift”. I would push even harder for direct access if I ran that engagement again. Some environments will not allow it. Then you use proxies, and you stay honest about how confident the decisions can be.

Treat field access as part of how engineering learns the product. It is easy to file it under UX extras, and then it never gets scheduled. When you cannot have it, name that as a risk, the same way you would name missing instrumentation.

Pushbacks worth taking seriously

• “We have researchers for that.” Researchers should run the study. Developers still need to see some of it. A readout is a document. The visit is a different artifact.
• “We cannot spare the sprint capacity.” You do not take the whole org. Cagan is explicit: not every engineer, not every visit. A few people, with some coaching so they do not derail a sales call or a live operation. At Insta the coaching was part of the trip.
• “We already do user interviews, the PM writes notes.” Notes are necessary. They still compress away the thing that changed how those developers argued the next week.
• “This is a consumer / B2C trick.” The Insta visits were a B2G operations floor. High-stakes B2B is where a two-second pause is expensive enough to justify the travel.
• “Ambassadors will scale UX without hiring.” They help. They do not replace a UX function. Ours depended on the person, and we still grew the team.

In Part 1 and Part 2 I wrote about release as a product event: the org and the customer have to be ready for what shipped. Field trips sit on the other side of the same operating model. Discovery has to land in the people who will build, or you are back to transmitting everything through a ticket.