Choosing your most productive way forward.

As a builder of software tools for over 20 years now, one of the most common questions I get asked is: “How do I decide which features to build into my software and which to leave out?”

In one way, the question is very simple to answer: “Build it if you can produce an ROI with that feature.” But, in another way, it isn’t simple at all because, what do you consider is the benefit and can you quantify that specific benefit to fit neatly into an ROI calculation? So, I get asked how I determine if it is worth building the feature or not?

Now, as a developer of software tools for others (my customers), they are kind of asking the fox to guard the hen house…but, my customers trust my advice because, I’m not the fox…often, I have arrived after they have experienced a predatory software development company (a.k.a. a fox).

The guidance that I provide to them is as follows:  I can’t make the decision for them - it is their business and they are the ones that will be using the software that I build to produce the return…so, they have to make the assessment of value, not me.  And, the assessment they are making is one of Value, not strictly ROI.

An assessment of value is more difficult to make than just an ROI, because it includes more than just numbers that you enter into a formula that spits out a number. In the end, you will likely end up with a number derived from an ROI calculation, but the work you do prior to the calculation will make all of the difference.

My approach includes the following four questions:

1. What are the consequences of building it and of not building it?

This is actually a pretty big question to answer because it includes both possibilities - building and not building. What you are really assessing is how important is this capability to your mission. Of course, your mission doesn’t exist in a vacuum. Missions are in the context of the marketplace you are operating in which includes your competitors, the economy, any political regulations, your customers, employees, vendors and partners. There will be consequences in each of these contexts - you need to include them all in your analysis. That said, this analysis can be pretty fast and easy too. For instance, if your competition has the capability and you are losing customers to them because you don’t - then some innovation needs to be developed to counter the competitive pressure you are under.

2. How will this capability be useful?

To be useful, the capability must either make something possible, make it lower cost, or improve a capability that already exists. The key to usefulness is the story that you (or your stakeholders) have about how the capability will support the users of the software. And, that support must be something that your users care about - not just some cool thing that you can build - it has to make their life better. If it doesn’t, then it likely won’t pass the usefulness test. Some examples of generally useful capabilities: increasing the speed of the application - making something faster is almost always interpreted as more useable and more useful. Reducing the number of clicks is also both more usable and useful. Reducing the time to produce some outcome - not just performance of the application, but performance of the team using the application. There are many other ways a capability can be “useful”, to know what they are, you have to know a lot about your users/customers.

3. Is the time, energy, money and lost opportunities required to build it worth it?

This is where the math comes into play - your standard ROI analysis. But you have to find some way to quantify the usefulness and the consequences from the first two questions. You will notice, that my question doesn’t focus on just money - this ROI analysis includes total costs associated with the production of this capability. All of those costs must be included to get a clear understanding of the worth of building the capability. If, in the end, the capability is valuable enough to be consequentially appropriate, meaningfully useful to its users, and produces a high enough return, then you may think you are ready to build…but there is one more question that must be answered.

4. Why does this capability/feature need to be built now?

Everyone’s resources are limited. Not even Amazon or Google can build everything they want to build all at once. So, if you can’t answer this question positively - meaning, if there is no reason the capability is needed now, then don’t build it. Now, obviously, software can’t be built instantly, so include the time required to build the capability in your assessment of “now”. But if it isn’t needed now, then it probably makes sense to focus your development budget on what is needed now - because something is always needed now.

Cautionary note: There are plenty of ideas that the creative people that typically build software can invent to justify almost any feature…but, what makes this feature required now? In some organizations, there is seemingly no end to “good ideas”, be careful by the seduction of “good ideas” - for more insights on “good ideas” check out this blog post.

If you can’t justify the need to build the software now, then you can move on. It doesn’t mean this isn’t a capability worth doing…just not now. You may have more valuable capabilities that have to be built first - no one has infinite resources, so focusing on what matters to your business now (or next) is a great way to make productive progress toward fulfilling your business mission.

At 8 Penny Labs, our practices help our customers remain focused on the capabilities required to make the best use of their software development budget. If you don’t think you are making the most productive use of your budget, we can help.

Follow and connect with us on LinkedIn (8PennyLabs) to be the first to learn when a new blog post drops.