Technology that works for real people: what almost every project forgets
Amid hype, new tools, and promises of digital transformation, what truly makes a difference continues to be the ability to solve real problems for real people.
In 1996, our team launched the first transactional web service for citizens in Brazil. It was a debt-inquiry system for a state agency. There was no trendy framework, no sprint review, no one posting on LinkedIn about "disruption." There was a concrete problem: millions of people needed to resolve a pending issue, and the only path was a physical queue.
The technology we used was limited by today's standards. But it worked. And it worked because we started from the problem, not from the tool.
Thirty years later, with incomparably more resources, more tools, and more available knowledge, the majority of technology projects continue to fail. Not due to technical incapacity — but because they lose sight of the human problem they were supposed to solve.
Plenty of technology, little real result
There is a phenomenon that repeats in cycles. A new technology emerges — cloud computing, blockchain, the metaverse, and now generative artificial intelligence — and immediately a wave of projects is born not to solve problems, but to "use the new technology." The budget is justified by novelty, not by results.
Cal Newport draws attention to something similar in the individual context: we adopt tools out of fear of being left behind, not because of evidence that they solve anything. In organizations, the pattern is amplified. Entire departments are created, consultancies are hired, and roadmaps are drawn to implement solutions that no one is quite sure what problem they will solve.
The result? Projects that take two years to deliver something nobody uses. Platforms that cost millions and generate reports that nobody reads. Chatbots that irritate more than they help. Beautiful dashboards that change no decisions. It is over-engineering at an organizational scale — complexity built to impress, not to solve.
In 40 years of technology, I have seen this cycle repeat with mainframes, ERP, web portals, mobile apps, and now AI. The technology changes. The mistake remains.
The most common mistake: starting with the tool, not the pain
Simon Sinek proposes that effective organizations start with the "why" — the purpose that justifies their existence. The same logic applies to technology projects: before choosing how to solve something, you need to deeply understand why that problem matters and for whom.
It sounds obvious. It is not.
The most common path I see — in government, in private companies, in startups — is the reverse: someone discovers a tool, becomes fascinated by it, and then goes looking for where to fit it in. "Let's use generative AI." Great. To solve what? "We'll figure it out later."
In 2019, our team took over the management of a critical system acquired by a state agency. The system was in crisis. Delays, bugs, a demoralized team, a manager under pressure for results. The natural temptation was to do what everyone does: over-engineer the solution — redesign the architecture, propose a cloud migration, swap out the entire stack. But the first thing we did was sit down with the people who used the system and understand where it hurt.
The problem was not the technology. The problem was that no one had asked the real users what the real bottlenecks were, reorganized the priorities, and involved the technicians who knew what the real problems were. When we asked, the solution turned out to be simpler than anyone expected. In six months, the crisis was resolved.
It was not magic. It was focus on the right problem.
What changes when the focus returns to people
When a project begins with the human problem, three things change immediately.
The scope shrinks. Instead of a "complete digital transformation," you solve what hurts most first. This is counterintuitive for those who sell consulting, but it is the difference between delivering results and delivering slides.
Adoption happens naturally. Systems that solve real problems do not need a change management campaign to get people to use them. People use them because they want to — because they make their lives easier. That 1996 web service did not need to convince anyone to look up their debts online. It just had to work.
The team becomes engaged. People want to work on things that matter. When the team sees that what they are building solves a real problem for real people, the motivation shifts. You do not need gamification or Friday pizza — you need purpose.
Having led people both at Celepar and at the church where I serve as a pastor, I learned this in very different ways. At the company, people have contracts and salaries. At the church, I also lead volunteers — no one is required to be there. And in both contexts, the principle is the same: people dedicate themselves when they understand that their work matters to someone.
A concrete case: when "not having the best tool" did not stop anything
In 1995, our company launched the first government website in the state. Commercial internet in Brazil was only months old. There was no Google, no WordPress, no AWS. There was no manual called "how to build a government website." We had basic HTML, a modest server, and one conviction: citizens deserve access to public information without depending on a service counter.
A year later, we went further and launched the first transactional web service for citizens in the country. Again: no sophisticated tools. What we had was clarity about the problem — and the willingness to solve it.
Looking back, would those projects have been "better" with today's technology? Probably. But would they have been more relevant? No. Because relevance does not come from the tool. It comes from the problem you solve.
Today, with generative AI, advanced automation, and nearly unlimited computing power, the projects that truly change people's lives continue to be those that start from a simple question: what is the real problem we are trying to solve, and for whom?
How to evaluate whether a technology is worth it
Before adopting any new technology — AI, automation, a new platform, a new tool — ask three questions:
1. What concrete human problem does this solve? If the answer is vague ("it improves efficiency," "it modernizes processes"), stop. Go back and find the real problem. Who is suffering from the current situation? What is the pain? If there is no clear pain, there is no project — most of the time there is only hype.
2. Will the person with the problem notice the difference? If only the technical team notices the change, the project is about infrastructure, not transformation. It is fine to invest in infrastructure. But do not call "digital transformation" something that the citizen, the customer, or the employee will never feel.
3. Does it work without the buzzword? Remove the technology's name from the sentence. Instead of "we will implement generative AI in customer service," try "we will reduce citizen response time from 3 days to 3 hours." If the sentence without the buzzword does not make sense, the project probably does not either.
The right technology is the one that works
Over four decades, I have seen programming languages born and die. Frameworks emerge with enormous promises and disappear without a trace. Platforms that were "the future" turn to vapor within five years.
What remains? Solutions that solved real problems for real people.
Technology does not exist to be admired. It exists to work. When we lose sight of that, we invest money in projects that impress at conferences and fail in reality.
The next time someone presents a revolutionary new technology, before asking "how does it work?", ask "who does it work for?" The answer will tell you everything you need to know.
Robson Valentin is the Manager of Digital Engineering and Platform at Celepar, Brazil's first government IT company, where he has worked for 33 years. An ordained pastor, mentor, and speaker, Robson leads more than 200 people across his professional and ministerial roles.