Speed

Recently I read this blog post titled “Why speed matters” and, together with a couple of events that happened earlier this week prior to reading the post, I can’t seem to stop thinking about it and thought about writing my own thoughts about it.

The post “Why Speed Matters” essentially nails what I always tell to my colleagues when they pitch me a project timeline, or when I see something that’s moving slowly. That is done is better than perfect, and move fast and break things.

At the start of the week I had to provide some feedback to a project a colleague of mine is doing. I used to avoid providing feedback unless they were my close friends. But after reading the book “No Rules Rules,” a book about the culture at Netflix, I find myself more willing to provide more feedback because providing no feedback or keeping feedback to yourself, you are doing more harm than good to a person or an organization.

I will not go into details about the first event—maybe a story for another day.

But the second one is a startup that would take a year to make an MVP. And my feedback was that there’s no way I could support an idea that takes a year to make an MVP. I have been down that road before, trying to work for months making new things that end up being used by no one.

Now I would just spend a weekend on an idea, show it to people to see if they are interested and then just scrap the idea, or pause it until I see an opportunity. The Spark editor was also something that started as a simple project that went on to be a good project through rapid iterations.

So I had to explain that it would be difficult to spend a year in MVP development, without even having a potential client. And even with a client I would not spend a year developing an MVP.

So build, release, get feedback, iterate and repeat.