Without customers, who would we sell our software products or projects to?
That’s obviously self-evident; it almost seems cheeky to even mention it. And yet we don’t always think of those same customers when it comes to listening to them and letting them help us, to some extent, improve what we do and how we do it.
Generally, we’re not programming or working on a project where we ourselves will be the client or user. In one way or another, we’re always building something for other people to use. So I don’t understand why we don’t work harder at actively listening and collecting suggestions and criticism to improve what we do.
There’s a classic saying in software: “the client doesn’t know what they want” until you start showing them something concrete from that abstract cloud of features and requirements they ask for. Few—very few—projects begin with a clear and exhaustive set of requirements. So it’s perfectly normal for the client or our users to start refining their requests and asking for new functionality once they finally have something they can touch and use.
This isn’t bad; we haven’t done anything wrong. It’s simply what usually happens. We have to accept it, and knowing it in advance lets us anticipate possible problems with schedule and effort overruns.
In fact, that lack of an initial definition is a great advantage if we know how to use it properly.
Regardless of who has the most contact with your end users, actively listening to their suggestions, opinions, and criticism (positive or otherwise) is essential to improving what you do, since they’re the ones using the result of your work.
Why? Because that’s the only way to get very valuable information:
- You’ll better understand the client’s specific needs.
- You’ll better understand how they use the product.
- If you stay open-minded, you’ll receive ideas for improvements you never would have thought of yourself.
Ultimately, you’re letting the users of your product (who also pay for it, directly or indirectly) shape it so that it better fits their needs.
As developers, we sometimes forget that we don’t build a product or project for ourselves, but specifically so that others can use it to solve a particular problem. The client or user, ultimately, has the final say in deciding whether what we deliver is good, bad, or rather mediocre. Without happy users, there’s no product (obvious), and no one to pay for our work either (also obvious).
It’s not always easy to acknowledge that something we’ve spent a long time working on turns out to be useless (because no one uses it). Nor are we usually open-minded enough to accept criticism that sounds negative to us.
I’ve had some very good experiences with this over the past year. For some time now, one of the products we sell at the company I work for (whose development I’ve led from the very beginning) has been evolving and growing largely thanks to active feedback from the established customers who use it.
The result?
I’d like to think that, by actively listening, we’ve gained the following:
- We recognize the improvements clients need in their day-to-day work.
- This feedback is extremely valuable information that lets us build a product even closer to the needs of that particular market.
- Clients feel valued when their suggestions are taken into account.
- The product evolves, so customers feel they’re using (and paying for) something that improves over time.
At the same time, it can be difficult to distinguish between a client’s highly specific, individual request and something that could genuinely be added as useful new functionality to the product.
That’s exactly what’s behind a lean approach to launching products, as Eric Ries describes in his book The Lean Startup.
There’s plenty of experience and advice around using an MVP (minimum viable product) to create new products and validate ideas. In other words, before investing a lot of effort in developing something you think will work, you first release a simple (and inexpensive) prototype for the people closest to you to validate—friends and family can be perfectly suitable. The information you gather from them will tell you whether your original hypothesis holds up. If it doesn’t, you’ll still have enough information to abandon the idea (because no one is interested) or pivot—that is, evolve it to better fit a larger base of potential users or customers.
We can be excellent software developers and build clean, evolvable, mature solutions, but if no one uses them, all we’ll have is a pretty, useless weekend hobby or exercise (and many wasted, pointless hours of effort). That’s why I’m so interested in all those aspects that surround the success of a software product, whatever kind it may be: a heavyweight desktop application, a web portal, or a mobile app.
I was reminded of this recently while reading To Sell Is Human, by Daniel H. Pink. It’s a very interesting book that I recommend, and it treats selling as an inherent part of everything we do. Deep down, we’re all selling something; that is, we need users or customers who will pay for what we do. We’ll sell more and do it better if we also stay open to listening and encourage and welcome all kinds of feedback.