Why speaking to users is a good idea.
Most software features fail to add value. Speaking directly with users dramatically improves your odds.
As a software engineer, most of the features you write will go unloved or unused. That’s a depressing thought, right? All that time struggling to fix that null pointer exception, optimize that algorithm or line that UI up was wasted. No-one’s going to use it anyway.
Let me try and back that up with some links:
Pendo's product analytics data revealed that “almost 94% of features are untouched and ignored”.
Microsoft research said that only about a third of features add value (a third are bad!).
Rich Mironov's research suggests that up to half of developed features provide no measurable value to customers (or even negative!)
At Google and Bing 80-90% of features are negative / neutral.
At Airbnb, 250 ideas were tested with only 20% having a positive impact on the key metrics.
How on earth did we get here? And what’s the simplest thing we can do to improve the odds in our favour?
From specs to user feedback (1960 - 1980)
In the early days of software development, we had this idea that if we could ask the users exactly what they want and write it all down, we could build software perfectly first time. Requirements to analysis to design, coding and finally a working product. Job done!
We’ve retroactively reframed this idea to be known as “waterfall development”. Except it never really existed! The 1968 Nato Report on Software Engineering acknowledged that users don’t know the true problems they have.
But that implies that they are able to say what they want. Most of the users aren’t able to. One of the greatest difficulties will be out of our field as soon as the users realize what kind of problems they have.
Since the very dawn of the computing industry, we've known that requirements change, but we've struggled to design processes that effectively accommodate this reality.
User-Centred Design (1980–2000)
The 1980s was the start of the PC revolution. A PC on every desk was the goal, and slowly but surely everyone became subjected to the frustration of programs that aren’t intuitive and don’t solve real problems.
As graphical user interfaces became commonplace, the user-centred design movement emerged, together with the field of user experience. Practices like usability testing and involving users early started to gain traction. In 1987, Tandy Trower established a new group at Microsoft that focused on usability testing, interface design and UI guidance. These practices improve the usability of applications, yet the core problem of building the wrong thing still remained.
By the 1990s, industry studies (e.g. the CHAOS report) were explicitly calling out lack of user input as a top reason projects failed.
Agile and beyond (2000s–Today)
In 2001, the agile manifesto was launched. Originally a way of software developers organizing themselves to solve real problems, it included the key line “customer collaboration over contract negotiation”. A clear recognition that working with users was the best way to get work done.
As SaaS grew in popularity the pace of iteration increased and encouraged more quantitative feedback from users by tracking their behaviour. With SaaS we can deploy two versions of solving a problem and quantitatively measure which one is best.
The Lean Start-up (great book!) puts users as a core practice and encourages direct conversations with users to help test assumptions which reduces the risk of building something no-one wants.
The result is a broad industry consensus that building with users (not just for them) is key to creating products people love.
How do I talk to users (and not screw it up)?
For me, there’s only one thing that matters. Approach conversations with curiosity - you are talking to a potential user of your system to learn about them. That’s it.
Of course, it’s not quite that easy. Not only have you got to find users, but they’ve got to be willing to give you the time. Incentives work! Spend $100K building a feature no-one wants, or give away some gift cards?
If you’re pre-product launch, finding users is harder. You’ve got to meet them where they are and the best way to do this is to immerse yourself in the domain. You can’t solve a problem if you can’t feel it yourself.
Once you’ve found willing people to speak to, there’s some traps to avoid such as:
Offering solutions - It’s human nature to want to suggest a solution to a user problem (”why don’t you just…”?). You must resist! Your goal is understanding. Solutions come later!
Asking opinion - humans want to be polite and encouraging. If you ask them directly about whether they like your idea, they’ll say what you want to hear. Instead, ask about experiences, challenges and behaviours.
Listening to only the vocal ones - go to any community and you’ll find 90% of users are silent, 9% contribute a little, and 1% account for almost all the action (90-9-1 rule). Make sure the folks you speak to truly represent your users.
Once you've started having these curious conversations with users, you might wonder if all this effort actually pays off. Let's look at whether this approach truly delivers results.
Well, according to the Design Management Institute, design-driven companies have outperformed the S&Ps 500 by 228%. I’m sceptical of studies like this, instead the best way to understand it is to look at the products you love to use and those you don’t.
Conclusion
Most features fail because teams don't deeply understand their users. Engineers who speak directly to users bridge this gap, turning abstract requirements into solutions that address real pain points.
Without doing this, there’s a real risk that the coding part of your job becomes commoditized. Invest in the domain understanding and you’ll become invaluable.
Make talking to users a fundamental part of your development process.