Surprise! Delivering valuable software is difficult. (Ok.. maybe not that surprising.)

Maybe it started out well – but over time it grew stale. Or it was wrong from the very beginning. Despite the common belief that software is an asset – it’s just as easily a liability. 

Let’s start with how do you define “Meaningful” software? Developers know when something they are working on doesn’t matter. Sometimes the indicator is a lack of interest in investing further or it’s heavy investment in something that gets little usage. Either way meaningful software must be a win-win for both creator and consumer.

“Meaningful software delivers value to a substantial segment of the target user group and directly supports the goals and objectives of those delivering the software. “

I’ll argue that any software feature or platform that fulfills this criteria will produce positive results. I’ll also suggest that it can be challenging to achieve and maintain this balance.

Example 1: “Hey – we should build our own shopping cart system”

If you are competing against Amazon in the high volume retail market and need proprietary AI recommendation systems – then it’s a worthy investment. If you are selling flowers at the corner market, probably not. It sounds simple on the surface but the question you always need to ask is: will it give me a competitive advantage and help me directly achieve my goals?

Example 2: “Hey, power user X says they would love this feature”

Power users and early adopters are extremely valuable. But it’s important that you obtain and test feedback against a larger market. Investing in a feature that is utilized by a few users doesn’t contribute to growth. Will it deliver value to a large portion of my target users?

Why is this important?

Software that isn’t meaningful isn’t sustainable.
If it doesn’t meet the objectives of its creators, they should be building something else.  If it doesn’t deliver value to a substantial number of target users then they don’t really need it or should be using something else.  When one or both of these conditions have not been met it creates an imbalance that generally results in a slow painful death for the platform.

Software that isn’t meaningful creates unnecessary costs for its creator. This takes many forms – time, opportunity, and financial cost. The long term impact of holding meaningless software with active users is dangerous because its toxic byproducts are usually hidden in the depths of technical teams.  If your are interested in learning more about the costs associated with building features, this is a great article that highlights the risks.
 

Software that isn’t meaningful disrupts focus on key objectives. It creates confusion, takes over meetings, hurts morale, and ultimately can derail strategic direction. The real danger of meaningless software is it appears to be “low hanging fruit” and usually brings a level of comfort that attracts all sorts of “feature requests” and “ideas”.  If the creators lose sight of its intended purpose then the strategic objective quickly shifts from whatever it was originally to the ambiguous effort of making the software “better”.
 

Delivering meaningful software is an art.

Mastering the ability to distinguish meaningful from meaningless requires discipline. You have to be honest with yourself and objective about what it is you are producing.  You cannot fall in love with your creation. You have to be willing to refactor design, listen to concerns, take time to organize, reject tradition, kill exciting (but distracting) ideas, and ignore the urge to “make things” right without purpose.  It requires focus and it requires constant re-evaluation. It’s uncomfortable – but once you know you are building something that matters – it all clicks.

Shaping software into something meaningful requires thinking holistically.  Understanding the goals of stakeholders, needs of target users, cost of building, validation techniques, and methods of promotion are just as important as the mechanics of how the software functions. Alignment and positioning of effort is key to the “meaningful” attribute of the art.

Producing meaningful software requires a fundamental understanding of how software is created, tested, and distributed. It’s also not enough to make plans and collaborate with stakeholders – it’s very important to understand capabilities, risks, and mechanics of how software is made and maintained. You don’t have to be a developer to deliver meaningful software, but you do need to know how to communicate with one. Mastering this is how the “delivery” happens.

The end product speaks for itself. If you can’t deliver it or what is shipped doesn’t provide direct value then start over or re-work. Much like an artist would paint over the canvas or toss it away – there is no value (only risk) in maintaining meaningless software.  Attachment to sunk cost, “technology” hording, and pet projects are guaranteed ways to fail or prolong the achievement of goals.

If you want to improve your ability to contribute to and drive the delivery of meaningful software I’d encourage you to follow along on this journey – sign up for my weekly newsletter.