When it comes to product development, the iterative process is designed specifically to help teas ship out your product as quickly as possible by actively reducing the initial complexity of features and functionality. This is valuable because it gets the product in the hands of users sooner, allowing our team at Launchbase to validate quickly whether the product needs to be adapted in any way. Another approach to this is the waterfall approach, which asks teams to build in all the complexity upfront and then put the product in front of customers which is much riskier and a potentially costlier outcome.

Our team uses iterative product development achieves its speed through a Minimum Viable Product (MVP) approach. MVP means taking the possible feature set that could be included in a product, or the possible functionality a specific feature could deliver, and cutting that down to the minimum needed to bring value to the end user. A great example of this would be reworking the first music streaming app, like iTunes or Spotify. It could have many different potential features beyond music streaming. Features like playlists, recommendations, search following artists etc.  Once the MVP of a product is live, our team can the quickly assess if it’s successful or not, and with minimum time invested, can move rapidly to build on the initial functionality. It is this step of the process where things can start to go sideways. The issue may start with the concept of the MVP. We aren’t geared to think in terms of MVP. In fact, our mind may take the opposite approach. When we get excited about an idea, our brain goes wild with all the possibilities. We imagine all the possible value a product could deliver and then we lose a significant portion of that value by cutting it down to the bare minimum. Even if your MVP is successful, you tend to feel a loss rather than a gain.

Running Before You Can Walk

 The MVP process is primed to regain the value you think you’ve lost. As soon as the product is live, we fall into an additive strategy where we are compelled to add new functionality to win back the ‘lost’ value.

This ‘weakness’ based mind-set gets further reinforced when we start analysing data and feedback. Because loss aversion causes us to focus on losses more than gains, we are more likely to gloss over positive signals and areas of strength and focus instead on the areas of the product that “aren’t working”. Think about the amount of effort you put into understanding why something is not working versus the effort you apply to understanding why something is working.

We should consider the amount of effort you put into understanding why something isn’t working versus the effort you apply to understand why something is working. It is rare to hear someone say, “how do we double down on this feature that is working?” Rather, we strive to deliver value by fixing what we perceive to be broken or missing. If you go back to the music streaming app example, if you believed that a playlist was a crucial feature but it was cut in the MVP, you are priming yourself to put a higher weight on any feedback where a user complains about not having a playlist because it validates your own sense of lost value. Even if that feedback goes against other signals you are receiving.

We focus on areas of weakness because they represent potentially lost value, but weakness-based product development is like swimming upstream. Areas of strength are signals from your users about where they see value in your product. When we focus on areas of weakness in the product, we are effectively ignoring those signals, often working against our existing behaviour to ‘improve’ your engagement by forcing some new value. So, many product updates only garner incremental improvement. Just keep swimming upstream.

Shifting Your Mind-Set

When you find yourself in a weakness-based mind-set in the development of your product, it can be difficult to shift your way of thinking. Here’s what we suggest shifting your approach to your product:

Ask the question: “What works in your product?”

When you observe areas of strength during the development, we shouldn’t just give ourselves a pat on the back and move on from it. We should make those areas the key focus of the next phase in development. We should be the ones to ask, why is this working and how can we accelerate this feature? We should stop chasing the new value. You are already delivering value and we build on that.

Shifting from an addition approach to subtraction approach

When you look at metrics, stop looking at weak performance as something to be improved. Instead, look at it first as an opportunity to simplify. Instead of immediately asking,

“How can we make this better? Make the first question, is this something we should get rid of completely?”

This is especially powerful in existing products. If you’ve been practicing weakness-based development you potentially have a bloated, underused feature set that’s dragging down your overall experience. What if every third or fourth development cycle you didn’t build anything new and instead focused on what you were going to get rid of? How quickly would that streamline your product and bring you back to your core strengths?

We get worried about upsetting users who have adopted features that aren’t driving our success. This should be considered a normal part of the process. Users will readjust, and yes, some might leave. But if you are clear on your product’s strengths and focus your efforts there, the value you gain will more than make up for anything you lose by cutting the things that are holding you back.