Speed as a competitive advantage

Before Slack became Slack, I was working for a startup which wanted to transform enterprise collaboration. The team had spent a couple of years developing the entire platform. Our main focus was on security and access control, and we were quite bullish regarding our initial launch. We had all the features Slack later launched with minus their integrations. Slack ended up launching before us and became the toast of the town. Slack was fun. Slack made enterprise products sexy. And for the first time people had their hands an enterprise product which did not look ‘enterprise’y. We made a lot of mistakes; but I still feel our biggest one was waiting for too long, iterating our product again and again based on whims and fancies, and finally letting another competitor come and eat our pie.

We could have still launched. We were not far behind. Everyone knows that shipping beats perfection right? But we kept adding more and more features, trying to be better than Slack while Slack iterated and launched features faster than we could have ever imagined. Soon the cupcake we were making turned into a wedding cake. Later we pivoted and made bots our prime focus. I was long gone by then; but I took one important lesson with me: Speed is the biggest competitive advantage you can have as a startup. In this post I will tell a few ways in which you can adopt speed as a habit.

There are 2 types of decisions you make everyday at work:

1. Critical irreversible decisions which require a lot of planning and discussion

2. Non-critical reversible ones which can be decided on the spot and can be changed later

I feel we spend most of our time over thinking the easily reversible ones. Here is an example: While building Reminders for Flock we had to decide on the interaction for repeat functionality. See the screen below.

We had to communicate to the user that she can use ‘Repeat Weekly’ for her reminder. This is the kind of thing which earlier took hours of discussion. Eager to show off our deep knowledge of UX we would endlessly argue without any data or usability testing to back our claim.

This time we just decided to go with two different options based on our hunch : Weekly and Custom. Later we removed the Custom option and just kept Weekly as we realised having 2 options was confusing our users during the initial testing. After the feature was built we took it and did usability testing on a few more users. This time we realised that the best option was to keep one option but with Weekly (Custom) as the micro copy.

During the development of Reminders we decided to start with the best guess possible regarding copy/interactions and then iterate fast to arrive on the best version of the product.

In the absence of data what we generally try to pass as fact is just our opinion. Don’t waste hours on discussing opinions when you can validated anything with data/usability testing later. It is fatal to wait for consensus. Here at Flock we have spent months trying to perfect our product building process. In our meetings we bring all required data which can help us arrive at a decision faster.

Want other ideas?

Try to think of all the things you accomplished yesterday. Ask yourself: Was there any way you could have completed your work faster? I do this exercise not just for myself. I also keep asking my Devs if there is anything I can do to help ship a feature faster than the estimated date.

Here at Flock we always try to build the quickest possible v1 of a product. We release this version internally, and as our employees start dog feeding the feature, we fix all the design issues and functional bugs. Once we are satisfied we release this build to Prod for everyone. Only if the v1 gets sufficient adoption we go for an enhanced v2 with better functionality and UI.

Start thinking in terms of frameworks and mental models. Adopt processes which reduce ambiguity in decision meeting. One example of a really good framework is SPADE which you can use to make difficult decisions. Commonly shared values are even more important than processes, frameworks or mental models. The Product Team here at Flock has only one goal: Get maximum output while putting the least amount of dev effort possible. Optimise for learning and always be fearful of building bloated products/features which don’t deliver ROI.

Lastly remember that speed only works when you know where you are going. You may be the fastest runner on the planet but unless you know where the finishing line is you will never win a race. For an organisation you have to first figure out the reason for your existence. The unique problem you are solving. Your vision. Your commonly agreed upon values. Without that you will be just running fast without getting anywhere.

Like what I write? Follow me here:@manas_saloi