Startup Advice From the Trenches

If memory serves me right, I remember watching an interview with Kevin Systrom, founder of Instagram, where he talks about the importance of going deep on a few core features and not building every bell and whistle into your product. As is so often the case, it’s one’s own journey and making the same mistakes that serve as the best teacher. We should definitely strive to learn from the mistakes or advice of others, but it’s generally our own mistakes that leave lasting impressions on us.

When we first started building SwarmIQ, our process was to build out a large number of features and measure what features our users engaged with the most. We’d then focus on those and build deeper functionality for that subset of features showing high engagement. We didn’t want to fall into the trap of knowing what’s best. We’d try out a large number of things and see what stuck. We’d let the data do the talking and let usage drive the product’s evolution. It seemed like a reasonable approach at the time. Our process was helped by the fact that we had a team that could rapidly deliver product. At various points through the evolution of the product we’ve had a twitter-style hashtag based messaging system, a comments system, aggregation of RSS, Twitter, Facebook and LinkedIn feeds, and sharing across all of these networks. We’ve even indexed and organized the entire Stack Overflow Q&A base for Search and by #topics. One thing we were good at was engineering and rapidly pushing out product.

One of the main problems was that we confused our users. They didn’t have an easy way of understanding what their actions would lead to. For instance, what did it mean to send a message with a #hashtag. We could have added videos and tutorials, but that really wasn’t the problem. It was the complexity of the product. Unfortunately it took us a long time to realize that this was a mistake, because we got half of it right. Letting the data speak, Measuring engagement and usage. They were definitely key and still valid. All the entrepreneurs we talked to swore by this process and this was reinforced repeatedly. The problem was the first half of our approach in trying multitudes of new features. It took us awhile to separate the two out and understand what we were doing well and where we were screwing up.

In hindsight, a lot of it is obvious. While our interest is in putting out multiple minimum viable features if you will, our users want something more meaningful to interact with. Why would a user engage with a shallow feature. We needed to make it worth the time to use it. Another lesson lost in today’s trends with the Lean Startup Movement and Minimum Viable Product is that it’s not just Minimum, the word Viable is in there too. The other key of MVP is to build out the minimum set of features that are relevant to testing a hypothesis. While we understood and tried to stick to the Lean Startup philosophy, our enthusiasm got the best of us and we ended up putting out multiple MVPs within a single product, leading to the user confusion I describe above.

Well, what is a deep feature? The simplest example I can think of is a product we use every day, Google. All we see is a simple white page with a textbox in the middle that allows you to search the web. What could be simpler for a user to understand. However, it’s a deep feature of the most extreme variety. Behind the simple box is 10s of thousands of servers processing user requests, indexing the web, sorting out relevance, overlaying social graphs and multitudes of other things. If you want your users to love your product give them the simplicity of a few meaningful features but pack a powerful punch underneath the cover, so to speak.

via Business 2 Community http://www.business2community.com/startups/startup-advice-trenches-0631209?utm_source=rss&utm_medium=rss&utm_campaign=startup-advice-trenches