Shifting from siloed work to a collaborative flow isn’t always easy, but the results are often game-changing. It’s clear in hindsight why this works so well.
Improving a digital product’s customer experience is a multidisciplinary task, and even small tweaks can have a huge impact—if they’re the right ones. But how do you know that before implementing them?
In the past, we relied on vocational training and experience, and it took ages to measure real results. Now, with real-time customer behavior data, we can move faster and smarter. Unfortunately, many companies still treat data like a quarterly stat dump. Instead, integrate it into your daily workflow, and watch improvements skyrocket, even in short cycles.
How? Let’s dive in.
The team and the challenge
At one of the biggest real estate developers, residents don’t just own their apartments—they collectively own the whole building and the company itself, since it’s a cooperative. In fact, percents and percents of the population could be considered shareholders. That means the digital tools people log into for services around their homes are a big deal.
The team recently taking charge of the core login experience—the hub for profiles, settings, and shortcuts—faced some pretty hairy challenges. The tech was lagging by a few generations, slowing customers down when using mobile and making faster iterations an uphill battle for the team.
So, as per usual in modern digital product development, the challenges were multidisciplinary. To add insult to injury, the organization had been stuck in silos defined by competences: business teams wrote requirements, passed them to design, then handed everything to developers, with no feedback loops in between. Long lead times, little collaboration, and zero customer input led to deliveries that didn't quite have a product-market fit by the time they shipped.
In short, they were a bit out of sync with the real world.
Three steps towards mob programming
Most people reading this are probably thinking: "Just shorten the iteration cycles and learn from each release!" Sure, that’s the go-to play for speeding up time to market and boosting value. But how do you actually pull it off? And what’s the vibe in the team when you do? How do you make the shift fast and still crank up quality without the transition becoming painful? And—bonus points—have fun along the way?
Step One
Get all the key players in the same room. BI? Check. UX? Check. Frontend? Backend? Double check. Sounds like a dream team, right? But here's the plot twist—left to their own devices, they just kept doing what they always had done. It’s like putting a rock band together, and everyone’s still playing solo. Sure, all the different musicians are in the same band now, but no one's jamming. Requirements were still produced by BI as documentation first and then handed over to the UX designers. Who sat on their own, producing kilometers of screen design before handing that over to the front-end developers.
Explaining to the others in handovers what people had done on their own chewed through 30% of workdays. And scheduling? A nightmare—finding open slots was like playing calendar Tetris, dragging out the whole process even more. Recording the different stems isolated from each other and as a relay race didn’t really produce a song that was a piece of harmony.
Step Two
With many different skill sets in the same team, it’s also easy to fall into the trap of trying to optimize each individual’s time. Like making sure you have x user stories with y story points for UX. And the same for the front-end, et cetera, et cetera. Again, this encourages people to work alone or limited to their competence silos within the same team. Again necessitating handovers, increasing lead times. It’s actually a way of using agile terminology to disguise traditional time/project plans.
So instead we helped the team to slice stories vertically. A story that only contains UX isn’t possible to release to production since there’s no coding yet. But if a story deals with both interface, front-end and backend it can be deployed. Wait, said several. Doesn’t that mean that the user stories grow in size? Good question! And you get the answer if you repeatedly solve another one: What should the scope of the story be if it a) has to be vertical, and b) also has to fit into one iteration?
Instead of a whole view, you might iterate on a module in that view. Instead of a whole customer flow you upgrade a phase or a step of it. If we don’t have the studio time to compose and record the whole song in one go, record the chorus so we can play something to the A&R people.
Step Three
Now the team had the tools. People playing the different instruments we needed for the music were in the same team. And they could scope down the work in a way that made it fit in the available time. Now the big question: when's the studio booked? Time to bring the magic to life.
Enter mob programming—a brilliant way for teams to collaborate, regardless of whether they're coding or not. Picture this: the whole team works together on a single user story. Roles rotate between ‘driver’ and ‘navigator,’ while everyone else provides real-time feedback. The driver handles the keyboard, executing the navigator's directions. Every twenty to thirty minutes, the roles switch, giving everyone a chance in each seat.
At first, the team had the usual doubts: Wouldn’t it be more efficient if those “just watching” worked on something else? If you’re stuck in the mindset of splitting tasks and reuniting in meetings to show results, mob programming might feel counter-intuitive. But after plus twenty-five years of use, it's shown a general productivity boost by fifteen to twenty percent. And if you think about it, it’s not that strange. Even if the keyboard player ends up not tracking on the chorus we record together, they might be the one having an amazing idea for the verse just because they were present.
This is what’s called ‘knowledge sharing’, and it's the reason why mob programming also gives teams a much higher resilience. If someone is away sick or on vacation, the other members can fill in easily.
When the real estate team had scoped down the work to a part of, or module in, the login experience, they had a telling moment during an early mob programming session. Everybody was looking at and working together on the design of a module in Figma, when a new team member – used to working for a design consultancy and unfamiliar with mob programming – asked “But when is this supposed to be done?”
And the subtext was really loud: I guess we’ll say goodbye soon and then go home and work on this and then meet up again in three days? Because you could see the look of utter surprise on their face when another team member answered.
“We’ll do it now, today!”
Since there was no handover of the design – the developers were present and part of the mob programming – but just a continuous and natural progression in what the navigator and driver were doing, the team delivered the new login view within half of the iteration.
Which in turn made it possible to deploy, get user feedback and prioritize which improvements to do next. Within two iterations the team was able to deliver twice, the second time with data-driven improvement based on customer feedback from the first release.
And by then the team could watch skyrocketing customer satisfaction.
