10 Version One Product Missteps — and How to Avoid Them

Developing a new product is hard. Research done by global strategy consulting firm, Strategy&, shows that 66% of new products fail within two years. Doblin says a startling 96% of all innovations fail to return their cost of capital. How do you address product development challenges, and turn ideas into actions that enable product survival? Start by identifying common product missteps.

Here are 10 version one product missteps and how to avoid them:

1. Focusing on the label.

MVP, V1, Beta, Alpha — we’re all familiar with these product labels. As developers, labels may seem important, but intent is what matters. Is your intent to build a product that solves a problem in the simplest way? Do you want to gather insight to evolve the product and provide a valuable user experience? Whatever your goal, focus on intent, not the label.

2. Believing more is better.

Many product development teams believe adding features increases customer value and subtracting them eliminates value. This is a fallacy, especially for early product versions. Take for example the Amazon Fire Phone released in 2014. Amazon believed an endless array of features — including “dynamic perspective”, a screen that provided a 3-dimensional effect without the need to wear 3D glasses — would enable the Fire Phone to take the lead in the high-end smartphone market. However, the features did little to spark consumer enthusiasm. Reviewers called the device “forgettable” and “mediocre”. Even after a series of price cuts, Amazon ended up taking a $170M write-down due to the Fire Phone’s lack of sales.

Product adoption is not dependent on the number of product features. Do not allow the “more is better” philosophy to be your product’ downfall. Instead, center product development on value instead of feature volume, and embrace that less can be more.

3. Not targeting a market need.

According to CB Insights, the number one reason startups fail isn’t because they ran out of cash, it’s lack of market need. Don’t create a solution in search of a problem. If you can’t clearly identify a market need, and explain how your product solves the problem, keep working. Tackling a problem that’s interesting to solve, rather than one that serves a market need, is a risky venture. Even with the best technology, the lack of market need — not to mention customer base — will destine your product for failure.

4. Solving low-value problems.

Problems are the foundation of product development — but are you solving the right problem?

It takes the same amount of time and energy to solve a low-value problem as it does a high-value one. The difference lies in the end results. A product that tries to solve more than one or a low-value problem will end up solving nothing. To avoid this dilemma, evaluate the problem, clearly define how your product will provide a solution, and identify who you’re solving the problem for. Otherwise, you’ll spend valuable resources shipping solutions to problems customers may not care about.

5. Don’t compare to a decade old product.

Version 1 of your product shouldn’t and won’t be like a product that has been around for 10 years, with hundreds if not thousands of people working on it, and with 10 years of use and feedback. Get over yourself. This is your ego at work and you need to take control of it. This is one of the reasons enterprises struggle with innovation. Their egos as people and as a company won’t let them release something that doesn’t appear to have been around for 10 years from the onset.

6. Fear drives, not shipping.

Anyone who develops a new product has the same fears. What if people don’t like the product? What if they don’t use it? What if users quickly abandon the product? What if this is a waste of time, energy, and money?

We don’t ship products as early as we should because of fear and ego. Ego protection holds us back from accomplishing many things we would like and derails new initiatives and products. Keep your ego in check and overcome the fear of shipping a product you know isn’t perfect. It will never be perfect anyway.

Instead of avoiding the fear by building the product in a vacuum, get the product in front of users as soon as you can — and look at their feedback not as a defeat, but a valuable opportunity to learn and improve the product.

7. Making decisions based on what is hard vs. easy.

If you are making product decisions based on what is easy or hard, you are making bad choices. You should be making product decisions based on feedback from users and where the product needs to go to drive the business outcomes you need from it. Too often, hard things are put off in favor of easy things that can be done quickly, but don’t provide users with value or don’t advance the product towards your objectives. Functionality should never be a question of easy or hard to do, it should be a matter of what is going to provide the most value, right now.

8. Coding before understanding.

We’re wired to build. Building feels like progress. However, one of the most common mistakes is writing code before truly understanding the problem you’re solving and how you are going to solve in the simplest, most elegant manner possible. Take the time to truly understanding the problem and how customers or users will value your approach to solving it. This will enable you to create a simple, clean user experience to solve the problem. You may even be able to sign customers with little to no code if you can demonstrate that you identify with and can effectively solve their problem.

9. Lacking a product owner.

Whether you are a startup or an enterprise building a new product, someone needs to own the product. Not a committee. Not a board. A person. Of course, the product owners should gather input from all relevant sources to have the information and insights to make product decisions, but in the end, someone has the make the decisions on the product footprint. The companies that are best at product have empowered product owners.

10. Forgetting to validate.

Nothing that hasn’t been validated should make it into a version 1 product. Everything can and should be validated when you are this early on with a product. Adding functionality without validation at this stage is lazy and driven by ego. You might have the answer, and you might get it right, but customers are not only more likely to point you in the right direction, in the end you need them to buy and use your product. Validation not only makes the product better, it makes the company better at marketing, sales, and support.

What product missteps would you add to the list? Do you have tips to share? Tweet us at @AWHNET.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store