Quick iterations and why you shouldn’t start polishing too early

One thing to really think about when it comes to product development and creating “new things” is you won’t be 100% right about every assumption you make. You might even be wrong on a lot of things.

So a crucial part of creating great products is to be able to iterate on things. Either before you release something or after you have launched.

The more iterations you can make the better and that means the shorter each iteration can be made the more iterations you can make and the closer you will get to something great.

A good idea is worthless without impeccable execution and a commitment to iterate
Zach Klein

Optimize how you work for quick iterations until you see really strong signals and data on that what you do is correct.

That means getting things out there early and getting feedback, users, customers, whatever.

Then go back and improve things and then go back again. Do this fast and you will be rewarded.

If you do it slow it will cost a lot of money and a risk is that you won’t bother iterating and just say: “Fine, let’s launch this and push the marketing button”. And you are trying to launch and market a product that isn’t ready yet.

You haven’t actually reached product/market fit. That can be an expensive mistake.

Don’t polish your product early

Another mistake some people make is confusing product/market fit with polish. For a few things polish can be important. But I have seen so many early products that are unpolished and somewhat buggy that were right where things are important and worked anyway.

Don’t polish early. You might have to throw things away, and polishing slows your iterations down.

Iterate. Iterate. Iterate. Then when you see good signals. You can polish and see if that improves things.

Some ways to shorten your iterations

Keep the team small. Fewer people that are really good makes for much quicker iterations. Less overhead. Less meetings and talk throughs.
Change the team if they can’t commit to quick iterations. You might not have that possibility but at least try changing the setup if the iterations are too slow.
Give the team space when working on the next iteration. Saving feedback until the end. Corrections can happen after each iteration if they are fast.
Timebox everything. It can’t take 3 days to create the login. You get 4 hours. Solve it. It can be buggy in v1.
Safety to fail. It’s OK to do something that is broken. Better broken than slow.
Take shortcuts. If there already are a great video/email/hosting/image solution available that you just can plugin. Do it. It might cost per month but it’s much cheaper than to spend months building something custom that you might throw away later.
Throw away stuff. Just because you made it you don’t need to save it. Throw away things that clearly don’t work or isn’t important in the beginning. You will move quicker by being lighter.
Use simple tools for communication and backlog. Don’t over think the systems. Trello works fine. Slack works well. A whiteboard can also work.
Less hierarchy but clear roles. If people have a clear mandate to make decisions they move faster than if they are unsure of their role.
Really narrow down the MVP. What is really needed to accomplish the goal.
Don’t be afraid to talk to people. This can actually add time to the iteration. But you save time in the long run by avoiding simple mistakes and getting a better picture of what is important.
Don’t scale too early. By committing to something that isn’t ready yet it will be much harder to do short iterations. It’s faster in the beginning. But don’t wait too long either. Just get it right.

Also remember that working in sprints towards a goal is not always the same as iterations. I have seen so many “agile” teams working in 2 or 3 week sprints that are just broken down water falls basically.

Also read What is the definition of a MVP?