Do you want to get a better understanding of Spring web application architecture? If so, get started right now!

Getting the Best Bang for Our Buck – Building the Right Thing

Pareto Principle on Napkin

One of the biggest problems of software projects is that we have no idea whether we are creating waste or value. The scariest thing is that 80 percent of software’s features are not used on a regular basis. Thus, it is very likely that we are adding waste to our software right now. This should scare the shit out of us because we are basically burning money without knowing whether we are solving the right problem or not.

Luckily for us, there is another way and this blog entry will help us to find it.

It Is Not About Quantity

The first thing we have to learn is that the number of features will not make software better or worse. This requires a mental shift that is hard for us because we are afraid that if our software does not have many features (or more features than its competitor has), it is considered inferior. This approach is flawed because whether we like it or not, the fact is that most of the features of enterprise software are not used on a regular basis.
We have to break free from our feature craziness for two simple reasons:

  • We spend more money than we should, which has a negative impact to our return of investment.
  • Customers do not care how many features a software has. They want that the software has the right features.

This leads us into a simple conclusion: Our goal is to find the right features with least amount of work.

From Paralysis to Analysis

The first thing that we usually do when we start a software development project is to create a list of features that must be implemented. This approach is based on two assumptions:

  • The world is a static place (and the needs of our customers are static too).
  • We know what our users want.

Unfortunately, both of these assumptions are false. The “build it and they will come” approach is great if we are 100 percent sure that we know what we should build. In other words, it is almost never the right strategy. This strategy has two major problems:

  • If the situation changes (and trust me, it will), we have to either ignore the change or react. If we choose to react, we might make some changes to our product. The problem is that we have no way to verify that our decision was the right one.
  • We cannot get any real feedback from our customers until the product is finished. If they don’t like it, we are screwed.

The truth is that we are guessing. We are guessing what problems we should solve and how we should solve them. And after we have guessed enough, we commit to a list of features that must be done. It is of course possible that some of them are not implemented but when was the last time this happened? The reality is that if a features is added on that list, it will be implemented sooner or later. We are paralyzed, and all we can do is to enjoy the ride.

The lean startup movement has created a technique called Minimum Viable Product that shifts our attention from the features of our software to our customers. It is specified as follows:

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

This technique has three advantages:

  • We can start learning from our customers as soon as possible.
  • It minimizes the amount waste that we add to our product.
  • It helps us to save a lot of money.

It is time that we move from paralysis to analysis.

From Vision to Product

Unfortunately, before we can start applying lean techniques such as the Minimum Viable Product, we still have to figure out what our product should be. The techniques described here will help us to validate our hypothesis about customer behavior, but they cannot help us to determine what our product should be. However, they are very valuable tools for answering the following questions:

  • Does our product make sense?
  • How our product should work?

The question is, what should we do next? we can use this the Minimum Viable Product in our software project by following these steps:

  1. Build the absolute minimum feature set that is useful. It can hard to decide what features are essential and what are not, but we must ensure that we don’t do more work than it is absolutely necessary. This is one of the corner stones of the Minimum Viable Product. We must understand that our goal is to let our customers “tell” us what they want us to do. We have to strip features until there is nothing more to strip. After that we can implement the features that are left.
  2. Release it.
  3. Gather feedback and usage statistics. It is a common practice to gather so called vanity metrics that makes us feel good. The problem is that they do not help us to learn from our customers. Instead, we should concentrate on metrics that are actionable, accessible and auditable.
  4. Analyze the obtained feedback and statistics. We must remember to keep the focus and follow our vision. It is easy to lose focus if we start running on different directions because that is what our customers are telling us. We must remember that it is impossible to please everyone.
  5. Decide what we do next. At this point we have got two options: we can either repeat this process or stop it.

The main idea is to keep the length of this loop as short as possible so we can maximize the amount of learning. Also, if our findings proves that the product is might not be viable, we should not be afraid to cancel the project. Sure, We lose some money but it is better to call it a day and minimize our losses than spend shitloads of money to solve a problem that should not be solved in the first place. However, we should not make this decision too soon because false positives do exist.

Taking Action

The greatest thing about the Minimum Viable Product is that it does not matter whether we are great a brand new product or a new feature to an existing product. We can use it in both situations. This means that we can (and we should) take action right away. After all, isn’t our goal to build great and (very) profitable products?

Right?

If you enjoyed reading this blog post, you should follow me on Twitter:

About the Author

Petri Kainulainen is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

About Petri Kainulainen →

0 comments… add one

Leave a Comment