Building a product is the easy part, but getting right the problem it solves and staying focused on that is the hard part. Every day you get a lot of ideas on how to improve your product. We should change the nav bar and make it sleeker. You could add this; you could add that, and damn how great it will be after we do that. Our customers request this a lot, and it should help us increase their loyalty if we implement it. But is it?

After implementing all the desired features without a purpose or goal, it ends up as a complete mess. And then you ask yourself: “How did we get here?” “Why customers don’t use our product anymore? Everybody requested it.” “They just can’t see how life changing this is.” We all get this type of thoughts after a failed attempt. But I would like to help you look at this from a different perspective. I will break it down into a couple of basic ideas on why adding new features is not always a good idea. How to go about those new ideas. How to test them and how to transition from V1 to V2 of a product.

How to determine if the feature idea you have is worth pursuing?

The very first step of every feature you want to implement should be this: “Can somebody, tell the story of a very realistic circumstance, where something happens in somebody’s life outside of the product, where this new feature is going to be useful or solve a problem?”. Having a real-life case should always be your first step. But here is where almost all of the products or features fail.

The second step is: “If we have a real case, is it connecting with all other cases that the app itself solves?” So it comes down to the core business of your product. Why people buy it? What are they using it for? And there are a million things that your product could do. So ask yourself: “Is it going to help people by doing what they are buying your product to do?

What is the problem with adding new features to a product?

Through years, I have noticed that we don’t have a deficit of good ideas. We have a shortage of products that can do one thing great. Some designers think that by changing this green to a darker tone will provide a better user experience. Or they change the navigation bar so people can have all files at hand. Or they add this great new feature that all their customers will love. These incremental changes is a rabbit hole. Some companies even pursue the race of features only because their competitors do the same thing. Thinking it will give them a competitive advantage. But is it?

Imagine you want to get in shape and have a good looking body. You eat healthy on a daily basis. But you allow yourself one meal a day at McDonald’s, and after a month you notice you have gained a bit of weight. You say it’s nothing; you will get back in shape. But you continue eating there once a day, and then after half a year, you realize you are fat. The same thing goes for products and new features. It is easy to speculate that a feature might be useful or a new change is going to improve the product. But things turn up different from the way you imagine them to be after months of designing and building it. This way you end up with wasted time and resources. But there is a better way to go about this.

So how can you make sure that new changes are actually useful?

Most of the time companies will go about implementing new features this way. Decision makers gather into a meeting room, and someone suggests a new direction. If enough people get excited, they will pursue that idea. Guess what the sad part about that is.

If you want to see if the idea is any good, you start with the questions I mentioned above, and then you have to start testing early in the process. Once you have that idea fresh, build an actual prototype and test it. This way, you will have a tangible product in front of you. And your team or customers can play around with it and give you their real opinion and see what is obvious and what not. This way you can see if the idea is worth pursuing. And not base your decision making on emotions.

After you see that the idea is worth pursuing you have to build a prototype. But how to create it and make sure we are efficient and effective? Work in cycles of no longer than six weeks. This way you don’t waste half a year building that feature only to realize it’s a failure and you consumed all your resources for it. Building a realistic prototype, coded with real data, can help you see the real potential of what you are trying to achieve. It is a next step after the rough prototype you made in InVision.

Then, in the beginning, you commit to delivering something in the six-week cycle. But how many people should work on it? You take a small team of people, let’s say, one designer and two developers. You “isolate” them from everything else in the company and let them do the job. You make this small team work only on that new feature. And don’t allow them to interfere with other company tasks or responsibilities they have to do. Why? Because the sales team may need a new presentation for a big client. Or customer support reported a bug that needs to be fixed asap. Distractions start coming in, and the team loses focus and time. The whole idea of a six-week cycle with a small group of people is to allow them to focus.

Also, they must have complete power over their time; nobody is pulling them away, asking to do something else. And that is so crucial, but in almost all companies, you never see that. You just don’t. And that’s because people in the companies who are responsible for budgeting the time are not protecting the teams.

Having the leadership involved in this is a critical element. By involved I mean, giving the team in charge for new feature full protection from everything else in the company. At your next stand up, or via company email or slack channel say that nobody can ask them anything. So they don’t lose the ability to focus and concentrate. But if you allow a small request to sneak in, you show that you allow them to be distracted. Then the support team may report a little bug. The sales team will request a landing page. Or there is a product update waiting to go live. All these small requests will end up like a snowball that builds up with every request and will be hard to stop.

What to do about a user interface that is too clean and empty?

Most of the time, when you see too much white space, you have a subconscious feeling of filling it with something. It’s a natural tendency of our brain to fill in the gaps. “Let’s add more buttons or put an illustration there.” But with the UI there are not so many things that can fit on a screen at the same time. And sometimes it is even recommended to leave the space empty. Why? See the area you have as your real estate. You already have a limited space where you could place your furniture. And the furniture is your buttons, labels, features or other elements. So there is not that much space as you think it was.

Try to see it from this perspective. For example, if you have a free space in your apartment, you could keep it empty for a long period. Then one day, you come up with a new great feature you can add there. And that feature may help 1% of your customers and take 30% of the space. Or you could leave that 30% of free space. And in a couple of years, you could have an idea will help 30% of your customers and take 30% of free space.

As an amateur investor you think that becoming rich is about buying low and selling high. But the big money is not in the buying or the selling. But in the waiting. — Charlie Munger, Vice Chairman of Berkshire Hathaway

So it is a matter of prioritization and not adding up crap features to a product only for the sake of it feeling too simple or because your competitors do the same thing.

Now once you got the prioritization out of the way, there is the question of: “What if we have too many great features that are tested and work?”. Some features will improve your product, and some of them will require to tear up significant parts of it only to implement them. Here is where it comes building different versions of your product. In this case, if the feature is excellent and will improve the product, you can leave it for a next release. And once the pile is full, you can start working on your V2.

How to transition from V1 to V2 of a product?

A lot of new features usually demand a new version of your product; otherwise, the current one will become a mess. When you release a new version of something, you typically see this negative pushback from the customers. People begin criticising the latest version of the product. And there is always some 50/50 split, some love it, and some hate it. You can notice this kind of trend with iPhones for example. Every time there is a new iPhone released you see how people react badly to it and say that it’s worse than the previous model. And this trend continues every year. With software, fortunately, there is a more natural way to go about it and get less negative feedback down the road. I will give you an example of how two companies did it, and you can take it as a model to follow.

How Basecamp did it

Basecamp went a bit more strategic about their new product versions. For example, when transitioning from V2 to V3, they rewrote the code of the entire product in a new version. So they ended up having two separate versions, and one version was the original and the other one with new features and design. They kept the previous version of the app online, and they never forced any customers to upgrade from a prior version to a newer one.

By doing this, it allows you to keep things that are working for current customers and work on new ideas that will drastically reap off the product from its foundations. So whenever you have those big ideas or crazy features to add, try to save them for a new version of your product and not implement them directly into the current one. These new versions may have years in between before going live, but meanwhile, you could add small features and rewrites that you previously tested with your six weeks cycles (as described above). So there is always this balancing act. How many customers is it going to impact? How much is it going to change what we have built? This is the type of balance you should seek.

How Freshbooks did it

Another excellent example of how to transition from V1 to V2 you can learn from Freshbooks. I love the way they do things, and they did not disappoint when offered a transition from Freshbooks Classic to a newer version. After years of providing an excellent solution for small business, they decided it was time to introduce a new version. A version that will keep up with their customers’ needs. When launching the latest version of Freshbooks, they did not make it mandatory to switch. You could choose from “stay with classic” to” move to a new home.” I, for example, stayed with the Classic version, doubting that the new one is going to be better. So I kept playing around with both versions until I made a final switch. The most interesting fact is that I did not lose any data while testing both versions. It was easy and painless to switch back and forth until I was 100% sure it is the right solution. And this is something that not all software companies do right. Instead, they remove old features and introduce new one without allowing their customers to get used to them. This way you will get a negative wave of feedback and reviews about your product. But if you find a way to keep the old version, your customers will not feel frustrated, but appreciated.

You can learn more about this topic on how to build great products and add features on our podcast episode, where I talked with Ryan Singer, the Head of Strategy at Basecamp.