How To Avoid Building Software That No One Uses

Problem identified. Now, how can I solve it? Product managers confront this question every day. (Usually many times a day.) Most folks would say that the first step is to methodically evaluate the issue from all sides so that you can define the problem clearly. But I would say the examination is not the most important part of solving a thorny problem. It is the motivation and mindset of the person doing so that matters.

Those of us who build technology products are well aware of the stakes — it takes fierce dedication to create something truly valuable.

Yet even with big effort and good intention, so much of what we build ends up being trash. I mean literal waste — unused, nonessential tech debris. If you read this recent blog post then you know that I define software waste in a somewhat unconventional way. (If not, go check it out quickly and come back.)

Most folks in software would say that software waste is any code, feature, or functionality that the customer does not need or derive value from. But I suggest that the real waste begins much earlier in the product development process. I am not being harsh — this waste is the unfortunate reality of building software products in oversaturated markets with lots of free money, pressure to win, and little accountability.

Rejecting software waste starts with a mindset. You have to go boldly towards what you think is true and ignore what does not create value.

I have been building products for decades, culminating in a software suite created expressly for fellow product builders. As the co-founder and CEO of Aha! I remain deeply involved in product development and speak to customers regularly. So I can say with experience that building anything new is always a risk. There is so much that is not within our control. And it simply is not possible for everything we create to be additive — eventually something detracts.

It might not be possible to eradicate waste. But as I wrote in the earlier blog, software waste starts with poor customer understanding and a misalignment between our hopes for what we are building and the value it actually provides. This is a good thing because it means there is also hope for realignment if you are willing. There are things each of us can do, regardless of title or tenure. It starts with instilling a culture where:

Value is valued

There is a shared commitment to delivering value. This must be in place for any hope of avoiding the software dumpster. It can be hard to overcome if you are the only one in the organization who is willing to put in the effort to aim for product lovability over mere viability. But you can champion and influence others — be the one in prioritization meetings to bring the conversation back to goals, effort, and customer need.

Motivations are known

There is a deep understanding of the customer. No guessing or snatching snippets from others — you are learning directly from customers what they want and need. And you are devoted to internalizing and understanding their input within the context of your strategy and your product. Talk to customers and listen closely. Provide a variety of options for delivering feedback (polls, submissions, live chat sessions) so that you can gain learnings from everyone.

Goals are obvious

There is a clear strategy. Everyone understands product goals and those goals materially impact the business. You can launch exciting new things — but to be a sustainable offering, your product needs to deliver value back to the organization. When people are unsure or conversations get heated, centering around those goals will help you get unstuck.

Process is repeatable

There is a defined approach to product development. Roles and responsibilities are explicit. People know what is expected of them and what they can expect from others. This helps you avoid one-off work cycles that burn time and lead to waste. The team evaluates the process periodically and looks for ways to streamline, automate, or apply highly productive flows to other groups. You might even say you reduce, reuse, and recycle.

Communication rules

There is good communication. This applies both to the type (transparent) and frequency (constant). I think written documentation is especially important in communication within product teams because so much of how we work is asynchronous. Process flows, how-tos for specific tasks, status updates, questions, action items from meetings, launch checklists — make it all accessible to everyone.

Accountability happens

There is a sense of ownership. Both individually and as a team, folks are fully invested in the work. There is shared pride and a relentless commitment to progress. In my experience this is best achieved when the product team takes responsibility for estimating the value of every idea and request from intake through to build. Scoring value at critical points in the product development cycle and measuring the worth of what you actually delivered helps reduce finger pointing and blaming. There are fewer surprises and you can more easily see where the team can improve those estimates next time.

Reality is honored

There is no hiding from the truth. Even your best effort with a wonderful group of teammates can result in something that is good, but not great — maybe even bad. But because you are dedicated to eliminating waste, you do not dwell and you do not double-down on something you know is not working to avoid criticism or make others happy. Pay close attention to performance metrics. Keep engaging with customers and stay open to feedback. Do not invest in what is clearly not working and let go, even if it stings your ego.

Avoiding waste is about focusing on what is most essential and questioning what does not clearly bring value.

Human beings can be wasteful creatures. We cannot help it — making and acquiring stuff is a core behavior of our species. But so is the drive to learn, bond, defend, and achieve. I speak with so many folks in product who are passionate about leveling the extravagance and decay happening in tech right now that I know we can surmount our lesser nature. Time to take out the trash.

Aha! software transforms product development teams. Are you ready to try?