fbpx

Managing Customer Expectations in Software Product Development

Frank Zinghini

Founder & CEO
today
timer
Relaxed young workers around computer in office

As customers, we are all spoiled. We’ve become used to shopping around and having salespeople bend over backwards to cater to our every whim. Almost every need is met with several viable options for solutions, and we are often thrilled when we purchase a new product or service to make our daily lives easier. 

Not only that, but the efficient and enjoyable machine that is online shopping often puts those solutions on our doorsteps the very next day after we buy. When everything goes smoothly, our expectations are not only met, but exceeded, as most business leaders agree they should be.

Cue the crunching, grating screech of those gears grinding to a halt when you try to order a custom-built application for the first time. For those who haven’t yet dealt with the software development process, your first time can be an eye-opening and often frustrating experience:

  • Why is this taking so long? 
  • Why have they given me this barebones product? 
  • After months of waiting, they expect me to be satisfied with these results? 
  • Sure, it does what they said it would do, but that’s it. It does only what you promised it would do! It doesn’t even have any extra features yet!

When you’re a client working with a software product development team, it’s easy for you to conclude that there is something very wrong with the whole process. 

From the development side of the equation, the engineers are trying to put together a never-before-seen product from a list of requirements. They often feel that the person who gave them those requirements doesn’t understand what it takes to build software. So they would argue that the problem lies in client expectations, rather than with the development of the application. 

They are right about one thing: if the client has realistic expectations, the development process will be more enjoyable for everyone. 

In software product development, exceeding expectations is often inefficient. 

As you may be acutely aware, software development takes time. While you’re waiting, it’s tempting to hope that your development team is busy devising new and ingenious features that will add style and flair to the finished product. But the reality is more likely that they are spending that time building out only the highest-priority features that make up a minimally viable product. 

The Agile software development method emphasizes iterative improvements. Features are added one by one. Every small milestone requires further collaboration with the client  to make sure it meets their needs. 

Therefore, when your development team completes a task that results in noticeable changes to your application, you’ll know about it. Though you may spend the initial few weeks imagining all the wonderful things being accomplished behind the scenes, you’ll soon face reality when the team contacts you and asks you to approve the barebones structure of your application before they move forward with anything else. 

Shiny, flashy features will not be a part of this initial phase. If you’re lucky, you will be satisfied with this minimum viable product (MVP) version and not require weeks or months of revisions to tweak aspects that weren’t exactly what you were hoping for. 

The key word here is satisfied. Not thrilled, awed, or any of the other emotions you were hoping to feel based on years of non-software-related experiences that have conditioned you to believe your expectations will always be exceeded. 

The concept of the MVP often seems strange to customers. Why would anyone want to invest so much time, effort, and money if they will be receiving a product that just barely crosses the threshold into barebones functionality?

There are a few answers to this question, but the simplest—the minimum viable answer, if you will—is that it’s the most efficient practice.

If you think it’s frustrating to wait for your development team to make seemingly tiny changes to your application, consider what it was like for clients before the Agile software development method became commonplace. In the bad old days, clients waited (and waited, and waited) for the development team to drop a polished, fleshed-out product into their laps. 

Sometimes, these clients were happy with the end results, but shocked by how long it took to get there. Most of the time, though, the clients had many critiques, special requests, and changes in requirements for their application. By the time they received the first version of their application in its original scope of work, developers had to gut and rebuild a mostly-finished product. And then, the cycle would repeat. 

The MVP probably won’t make you bolt out of your office chair and shout Eureka! What it is, instead, is a guarantee that the product will accomplish what it needs to do. You’ll be several features and updates away from having a polished, expectations-exceeding final version, but that disappointment is offset by the fact that, at the very least, you will know your product will work for your intended purposes.

Agile brought collaboration and iterative improvements to the mainstream, giving clients and their developers a much more efficient way to bring a product to market. 

Prioritizing important updates is the key to efficiency, even if it’s less exciting than building flashy interfaces and fun features.

You’ve probably heard of the Law of Diminishing Returns. The more time, effort, and money is invested in a venture after a certain level of functionality has been reached will result in progressively smaller benefits. 

In software development, the MVP stage is generally accepted to be that level of minimal functionality beyond which all other benefits are likely to be proportionally smaller. 

At the start of a project, any work that goes toward building the MVP provides the most value because it must be done to have a working prototype. Work done after that minimum threshold has diminishing returns because, while it’s nice to have extra features and some polishing and refinements, the work is not strictly necessary.

Therefore, during the first stages of building your application, the development team will be focusing all of their effort into meeting that MVP threshold. Some features may be clunky or missing entirely. The interface will likely not be pretty. And you wouldn’t dream of releasing this version to the public. You may struggle with frustration, but you must remember that this is the most valuable work; it will be the framework for all of the prettier and more impressive elements you want to see. 

Your definition of “minimum” might be different from someone else’s.

Let’s say you’re the founder of a startup or you run a company that doesn’t have its own dedicated software developer team. You have an idea for software that you feel could really change the game. You contract with a software product development company and send it your requirements for the application. 

The MVP for your very first product will look vastly different from the MVP generated by, say, Google when it releases the first version of a new project. Google is already a market leader; they have a deep understanding of what place in the market their new product will fill; they know which features that product must provide to customers; their “look and feel” is already firmly established; and they have an in-house team of programmers experienced in the Google ecosystem working around the clock to make it happen. 

You can’t compare the resources you have to the resources of a market leader such as Google. And you can’t compare your initial MVP structure to the MVP of a Google product. 

However, you can give yourself a leg up.

Some of the initial learning curves can be smoothed out if you hire the right team for the job. 

Most of the time, startups struggle to find their footing because they don’t have all the  pieces of the puzzle. They may have specialized knowledge in some key areas and a fantastic idea for a new product, but they don’t have decades of experience taking a product from concept to production, then  have it succeed upon final release. They could even hire the best coders in the country and still fall short because, at the end of the day, they have an application that they don’t know how to market or sell. 

A software product development company such as Applied Visions does much more than simply develop your application according to your instructions. 

We are a full-service software product development company that specializes in helping you turn your game-changing idea into a smooth and efficient application that is poised for success in the market. 

If you find yourself frustrated by the initial stages of having your idea translated into a workable product, just remember: everything that happens after the MVP stage is the exciting, flashy refinement phase you’ve been dreaming of all along.