Right-sizing a custom software project
July 20, 2017 | Kelly Kimmich, Far Rach, Inc.
When you’re getting ready to jump into a software project, you inevitably think about all the possibilities—about how great it could be some day. This is not a bad thing. By all means, dream big; know where you want to go with it.
Keep in mind, though, that your big vision won’t happen overnight.
Following are some words of wisdom about how to realize your dream in a way that keeps your idea lean, focused, and as valuable as possible.
Step Back
Because your big vision won’t be realized overnight, one of the most important steps after defining that big vision is determining what’s best to build first—here and now. Go ahead and lay out your dream product, but then step back and prioritize. Prioritize the functionality and features that will add the most value for your users (and therefore for you). Save the nice-to-have features, no matter how cool they seem, for later in the process.
A simple example of a nice-to-have feature is an awesome graphic, fully animated with CSS, that displays after a user logs in successfully. While this feature can be labeled cool, it probably can’t also be labeled necessary and/or valuable. The real value is in the user successfully accessing the system. Snappy graphics might add to the visual experience, but they don’t help the user accomplish anything. Consequently, their value is limited. These should go to the bottom of the list.
Cost Vs. Benefit
Is the cost of waiting a year to launch something “perfect” worth it? Or is there a higher cost in waiting to launch and missing a market opportunity or finding out you built the wrong thing? It might be tempting to think “perfect” is the way to go, but waiting to launch actually introduces significantly more risk (and cost) than rolling out a smaller subset of features and iterating to continue adding more and more value for your users.
Building everything you can think of before launching costs more in the short run, of course, but there are also long-term costs of building more than you or your customers need. With additional functionality comes additional support and maintenance costs, the costs of confused customers who leave, and the often-forgotten opportunity costs of not building something else that customers are actually asking for.
We can tell you from past experience that it’s a terrible feeling finding out you spent time, money, and effort to build something your customers don’t really want. When you reflect back on what that energy could have built had you just started small, it’s an eye-opener. It’s a lesson we won’t soon forget (and will continue to pass on, like in this blog post).
We Can, But Should We?
The answer to, “Can you build this?” is almost always, “Yes.” That’s one of the benefits of custom software as opposed to off-the-shelf solutions.
However, the ability to build a feature or function shouldn’t be the ultimate criteria for whether or not you actually build it. Value to the customer and business value should be the greatest considerations in what to build.
As you begin working with us, you’ll consistently hear this conversation*:
Client: Can we do this?
Far Reach: We can, yes.
Client: Make it happen.
Far Reach: Where does it fall in priority compared to X, Y, and Z?
Client: Oh. We for sure need X, Y, and Z.
Far Reach: What’s the value for you or your users of adding this new functionality?
Client: I’m not sure.
Far Reach: Let’s put this in the backlog and prioritize it among everything else.
Client: Good plan.
*This conversation is dramatized and doesn’t reflect any individual Far Reach client.
After working with us for a while, you’ll naturally start to think in terms of priority. When you come to us with something that could be added to the system, you will have already thought through the value to you or your customers and where it falls in priority order.
What’s the Least I Can Build?
Ask yourself this question: What is the smallest set of features I can build that starts delivering value to my customers and/or my business? We call this an MVP: Minimum Viable Product.
An MVP helps you gain important insight into what features your customers use, how they use them, and what additional features they would value—all for significantly less effort than building a full-blown, feature-heavy system.
More often than not, when it comes to software development, less is more. Having a small number of key features that truly fulfill the needs of your users is always more valuable than having every potentially usable feature fully built out.
If you’re having trouble narrowing your system down to that impactful MVP, reach out.
This column first appeared on Far Reach, Inc.'s website.