Home » mvp

Tag: mvp

don't waste time creating new products.

Don’t waste your time creating new products

Here is a mistake that I have made way too many times. 

I have this bright idea for a new product or service. I am so excited about it! But, I want to keep it a secret least someone would steal it from me. 

I work hard to implement it, test it, polish it. I am making sure it looks like how I imagined it. 

After months of effort, I finally launch…

… to crickets. 

There is no one out there who cares about my product or service, let alone steal it. 

The problem is that this is a selfish way to create a product or a service. You are choosing to work in a void in your head, and you are not doing it for an audience, so you never bother to ask for feedback or even ask if they need such a product. 

A better way is to test your assumptions before you spend any time building stuff. Building a useless product costs you time and money that you could have used to make something relevant and remarkable.

Testing can be as simple as saying this: 

“Here is what I am working on next. What do you think? Would you spend $100 for early access and an opportunity to give feedback on how I make it?”

Two things can happen:

  • less than ten people signup for the early access: good! – you thank and refund everyone and let them know there is not enough interest to build the thing. Don’t skip the “thank you” part, as they are your biggest fans! And now you just saved time, money, and effort that you can put into testing the next idea.
  • a lot of people signup – good! – the pressure is now on to build the thing, and you have feedback from people that will help you make it very relevant. You also get testimonials for the official launch date. Again, make sure to reward the early adopters for making this possible.

Innovation is messy

A hard lesson I have learned recently. 

I like to be right. I like to be efficient. I like to do things the correct way the first time around. I would like to believe that my experience would allow me to do so. 

But some projects present an interesting problem. To understand the problem, let’s imagine we are the architects of a tall and spectacular building. 

We know how the building is supposed to look. We know what purpose it will serve and who will use it. With this information, we can start making our plans starting from the ground up. We design a solid foundation, and then we layer on top of that floor after floor until we finish. 

However, this is not innovation. Is following a well-established workflow where there are little to no unknowns. We can make good decisions about what materials to use where and a reasonable estimate about when the job will be done. We don’t expect many surprises along the way. 

But what if we have this idea to use a new material, and design this building to serve some innovative purpose that no one has done before. Now there is no way to lay down a solid foundation because you cannot answer the question: “solid for what?”. 

You may discover halfway through that most design decisions do not help you achieve your vision due to some unknown limitation that was invisible right until you got to this point. So you have to dynamite the whole thing, learn your lessons and try again. 

Large, innovative software projects are like that. The architecture you started with may have looked great in the beginning but ends up feeling very limiting when you suddenly realize you need to make a dramatic shift in your project, and your “foundation” does not allow for it. Tearing down a software project is free, compared to dynamiting a building, but you still won’t get your money back from all the work that you cannot use anymore. 

But not all is lost. Because in this process of trying and failing, you learn and you grow into your idea. You stumble into the things you didn’t know that you didn’t know. And drip by drip, you make the unknown, knowable. 

This “failing often” is a challenge for me to accept and work with because it feels wasteful. In hindsight, “I could have done better!”. But thinking like that is a trap, and it suffocates the very creativity required for innovation. You need to be ok with failing often. 

Now that we can agree that innovation is messy and it feels wasteful, what can we do about it? 

1. Don’t start with a big spectacular thing. Instead, try to come up with an MVP (minimum viable product) that you can build on (or next to) in the future. 

2. Budget for the messiness and the learning process. Make sure you have enough money to make the mistakes required to get the learning experience you need to bring your idea to life.

3. Aim for many small mistakes, so you don’t make one massive “end of game” mistake. This idea expands on (1) above. Move fast, but take small steps. This approach will make it easier to backtrack and change direction. Significant commitments are giant leaps forward that give you less flexibility to turn around. 

4. Don’t worry about optimization and edge cases in the beginning. If you do, you may end up doing tedious and lengthy work on a feature that may not even make it into the final product.

5. Try again tomorrow. Some days it may feel like you are getting nowhere, and this is all doomed to fail. That is normal. Take a break, go back to the original vision that got you excited and try again tomorrow. 

6. Be patient. You are playing the long game.

7. Once you have your MVP, you can start again and “do it right” this time. It will no longer be innovation because you have learned your lessons. Now is the time for the polished, optimized, and secured product. 

How do you deal with innovation in your projects?