Just Enough Software

How to calibrate technology project expectations with reality.

When organizations kick off a new technology initiative, excitement levels often go through the roof. I’d argue that excitement is actually crucially important if we want to go from having the seed of an idea to a starting a real project with a budget and a team. Why couldn’t our user’s experience be as great as Apple, or Uber, or AirBnB? The opportunity to create a great experience is real, and expectations should be set high.

But with such high expectations, where do we begin to figure out, realistically, how much we can bite off without it being more than we can chew? How much software is the right amount for a given situation? The frustrating answer, as always, is: it depends.

The Success Trifecta

In product management, products and services are often thought of as successful only if they meet the trifecta of being desirable, viable, and feasible. So a successful digital solution should be:

• Desirable: it solves the real needs of the people it is for.
• Viable: it successfully meets the needs and constraints of the organization that delivers it.
• Feasible: it can actually be built and delivered to meet the above constraints.

For our purposes, we’re going to focus on answering the question of “what is feasible for us to build?” The honest but unhelpful answer is, well, almost anything you could dream up is technically feasible with enough money, time, and expertise.

So the real question of feasibility must account for the organizational constraints of budget, time, and expertise. Here’s how I’d consider these factors when deciding on the feasibility of a given solution:

Budget: How much money can you spend on software? Is your budget capex or opex? How easy is it to get more?

Depending on the answers to these, the “right amount” of software could be some combination of purchasing software licenses, integrating some customizable Software as a Service (SaaS) applications, or building custom software.

Each of these avenues has its own pros and cons to weigh out (and they should be explored!), but the one commonality to consider is that implementing these solutions will be an ongoing process.

Time: Good software products, like the Ubers and Googles of the world, are rarely a ‘one and done’ project. Chrome wasn’t built in a day. Modern tech companies don’t build something for a year and then call it done, they see technology as a core competency that is always being improved over time.

Project deadlines are important learning tools because they help us understand if we actually have the capacity to do what we think we can. If we see them as more than just the end of a project, they can help us set recalibrate our expectations and adjust our course.

Digital Capacity: So if a capital expenditure on a new project is just the beginning of a long process towards digital transformation, how do we know if we’re on the right track? The truth is, the best case scenario at the end of a project is probably not building some perfect solution and calling it day. A better way to measure success is to assess how much you’ve learned in the process.

Being “digitally transformed”, to me, means you’ve learned how to shift your operating model to one that has build its capacity to sustainably improve its use of technology. Therefore, when starting out, a good strategy is to take the opportunity to find out where you can and can’t leverage technology to improve your core competencies.

Just enough software

Coming back to feasibility, you can see why it’s less about “can we build the solution?” and more about “can we build the capacity to build the solution?”.

From this perspective, its less tempting to see technology as a magic solution to all your problems, and more as a tool that you can learn to wield more effectively over time. When you keep this in mind, you are less likely to fall into the trap of going too big, too soon, and even if it takes some time to learn, you are more likely to build the capacity to deliver the exception experiences you set out to at the beginning.