Before became Slack, I was working for a 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. Slack startup We could have still launched. We were not far behind. Everyone knows that 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 . Later we pivoted and made bots our prime focus. I was long gone by then; but I took one important lesson with me: . In this post I will tell a few ways in which you can . shipping beats perfection cupcake we were making turned into a wedding cake Speed is the biggest competitive advantage you can have as a startup adopt speed as a habit There are 2 types of decisions you make everyday at work: 1. irreversible decisions which require a lot of planning and discussion Critical reversible ones which can be decided on the spot and can be changed later Non-critical I feel we spend most of our time over thinking the easily reversible ones. Here is an example: While building Reminders for we had to decide on the interaction for repeat functionality. See the screen below. Flock 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 to arrive on the best version of the product. iterate fast 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. . Here at 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. It is fatal to wait for consensus Flock 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 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. build the quickest possible v1 Start thinking in terms of and . Adopt processes which reduce ambiguity in decision meeting. One example of a really good framework is which you can use to make difficult decisions. are even more important than processes, frameworks or mental models. The Product Team here at Flock has only one goal: Get while putting the possible. and always be which don’t deliver ROI. frameworks mental models SPADE Commonly shared values maximum output least amount of dev effort Optimise for learning fearful of building bloated products/features Lastly remember that speed only works when you know where you are going. 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. You may be the fastest runner on the planet but unless you know where the finishing line is you will never win a race. Like what I write? Follow me here: @manas_saloi
