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?