You’re a business owner, you’ve got a vision, and you’re building something. But there’s this nagging question, isn’t there? This feeling that maybe, just maybe, we’re doing it all wrong. We’re hiring these brilliant minds, these developers who are crafting the future, and where are we putting them? In a box. In an office. Four walls, fluorescent lights, and a ping-pong table that collects dust. It’s time we talk about it.

Here’s the rub, and you’ve felt it. You launch a new feature, a new app, a new system. It’s perfect on paper. It runs flawlessly in the test environment. But then it hits the real world, and suddenly, it’s clunky. It doesn’t quite fit. Users struggle. Why? Because the people who built it weren’t there. They weren’t watching the small business owner in a city struggling with slow internet, or seeing the mechanic on a dusty farm in a rural area trying to access data on a phone with greasy fingers. They were imagining ideal scenarios, not battling reality. We’re asking our creators to build for a world they are often only experiencing through a filtered lens. How can they truly solve a problem if they haven’t intimately understood its contours, its nuances, its frustrations in the wild? They can’t imagine all the ways their designs might fail, but experience will show them every single one.

Google Wave was an ambitious collaboration tool released in 2009 that combined email, instant messaging, and document editing into a single, real-time platform. Developers loved the technology, and many were impressed by its real-time functionality and potential. The interface tried to do too much at once, leading to user confusion and cognitive exhaustion. It didn’t solve a clear user problem or serve a specific purpose effectively for most users, being neither clearly consumer-focused nor enterprise-focused. The lack of onboarding and the complexity of the interface meant users spent more time learning the tool than communicating. Google Wave did not integrate with essential tools like Outlook or Gmail, making it difficult to adopt for many businesses and individuals. It was considered a “moonshot” with a focus on innovation rather than addressing existing user needs or pain points, according to YouTube. After a year of abysmal usage, Google shut down the product in 2010. Google open-sourced the core technology, and the Apache Software Foundation adopted it as an incubator project, continuing its development.^[1]

My philosophy has always been about understanding the user. Deeply. Obsessively. And how do you understand someone? You walk in their shoes. You see their world. Watching users interact with their creations, not through analytics dashboards, but in real-time, observing their expressions, their hesitations, their workarounds. Realizing that a feature that makes perfect sense on a high-speed fiber connection in Sandton might be utterly useless for someone dealing with intermittent mobile data in a rural area. Often, the most profound problems aren’t articulated; they’re lived. A developer embedded in the environment will spot these unspoken needs, these unmet desires, long before they ever appear in a bug report or a feature request. Imagine a developer who builds a feature and then immediately sees its impact, gathers feedback, and can pivot and improve, all within the same day or week, on-site. That’s not just efficiency; that’s alchemy. Empathy, not just for the user, but for the problem itself. It’s the engine that drives truly meaningful, disruptive innovation. Stop building ivory towers of code. Tear down the walls that separate your creators from your customers. Empower your developers to be explorers, to be ethnographers, to be problem-solvers in the truest sense.

This isn’t about developers ditching the office entirely. It’s about redefining their purpose. It’s about understanding that the ultimate laboratory for them is the world itself. In South Africa, as an example, with its diverse landscapes and varied infrastructure – from bustling Johannesburg to the quieter, more remote areas of the Karoo or the Wild Coast – this approach is even more critical. To justify that mocking is not enough, you need to understand that mocking a user’s experience is like tasting a meal by only looking at the menu. You might see the ingredients, but you miss the true feeling of the moment—the flavor, the atmosphere, and the unexpected mess—all of which are essential to building a great product. You cannot build effective solutions for a country like this from behind a single desk in a city. You have to experience it all. Give them the mandate, give them the tools, and give them the freedom to get out there. Let them feel the sun on their faces, the dust on their shoes, and the pulse of the real world. Because that’s where the magic happens. That’s where innovation doesn’t just get coded; it gets lived. And that’s how you build things that truly change the world.