Startup Lessons Learned from One Year of Building muHive [Wash. Rinse. Repeat]
[Guest article by Sagar Vibhute, cofounder of MuHive. The startup recently completed 1 year and the team shares their journey]
Knowledge is knowing that tomato is a fruit. Wisdom is not putting it in a fruit salad. ~ Anon
There is an incredible amount of joy in building something from scratch. If you are a technologist, the first few months of building a prototype is an exhilarating ride! While the demands of running a business come with an eventual shift in priorities – more sales, adoption, marketing – for many of us the product remains the first love.
At some point a product turns into a being for its creators – many of us start attributing behaviors and personalities to it – but then a product is a complex system. I’m sure many of you would have seen the TED talk by Tim Harford (of the Undercover Economist fame) on the importance of good mistakes (embedded towards the end*). As first time wannapreneurs, we have had the good fortune of making our share of mistakes, mistakes that have taught us plenty, many-a-times the hard way, but we are better product people today that we were a year ago because of those.
I thought it would be appropriate to share our lessons with all of you, especially those of you in the early stage of a product-business lifecycle. Some of these you might already know, and we did too. It has taken us a year to realize this knowledge and gain more. So, without further delay, I present to you DIFFER.
Don’t make me think: Aside from being the title of Steve Krug’s book this is also his first law of usability. While a deep dive into this is far beyond the scope of this post, I can share three tips from our experience:
- Avoid verbosity. Don’t use two words where one suffices.
- Intuitive navigation. Put a functionality where it logically belongs (as a start, take clues from your favourite apps)
- Conventions. Your audience relates certain terms with they are most widely used for. A term like Submit usually means approving a form, while Cancel signals that you don’t want to change anything. Likewise, follow the accepted norms.
For e.g., muHive is an engagement product so we have tried to recreate an email inbox experience as that is what people are used to when it comes to interacting with people.
Instant gratification: Every product company fears the c-word. You know, churn. Twitter circa 2009 had nearly 60% monthly churn rates, even though traffic and data were peaking every day. Turns out, not everyone got the fact that you have to follow someone else to be able to participate. Since then Twitter have tried different tricks so as to show tweets to new users and encourage them to come back. The current method is to enforce that you follow 10 people so you start seeing tweets instantly.
In muHive we have attempted to resolve this by populating a user’s account with instructional messages that look like how actual incoming messages will look like once she sets up her account.
Another trick is to showcase analytics on publicly available data of a known brand to convey the level of functionality you offer.
First time defaults: Along with good coding practices, in muHive we were also keen on building a framework-like system. This would in some sense let a user create her own features instead of restricting herself to those that we provide. What could be cooler than a feature to create features? Right? Wrong.
Read this carefully: users are interested in what your product can do for them at this very instant! It is critically important that the system has defaults for all (or at least optimal) features when the user signs in for the first time.
In muHive we are attempting to resolve this by providing a library of automation rules and default issue tracking, because those are the two features which if not setup do not give a complete experience.
To get users to experiment, suggest changes and new tricks over a period of time. When a user has more faith in your product she will experiment with new features.
Feedback: We would like our users to spend all day everyday on our product but not even if you are Facebook is this true. With the number of products that a user is surrounded with today you are fighting for attention more than anything else, especially as a new kid on the block. To be noticed your product has to provide an adequate amount of feedback to the user.
We built this proactive approach in muHive with the following:
- Daily update e-mails to provide a summary of engagement activities
- In-product notifications (check out favico.js, might be of use to you)
- Auto-refresh to check for new incoming messages
and are planning on adding many more.
Easy is good. Easier is not: Is your product simple to use? Yeah. Sure? Pretty much. How simple is it? … eh …
Albert Einstein famously (perhaps apocryphal) said,
“Everything should be made as simple as possible, but no simpler.”
While I don’t intend to get into a philosophical discussion of what the great man was talking about, it is a great thing to remind yourselves when you are designing/coding/bootstrapping your product; there is no end to the simplicity argument. The one reliable way to approach ease of use for your product is to work closely with your early users, especially the ones whom you can count on for good feedback. Over a period of time your product will get simpler and cleaner.
Part of your product’s ease of use will come from following what users are accustomed to i.e. using conventions. Remember, all happy products resemble one another, each unhappy product is unhappy in its own way
Repeat: Wash. Rinse. Repeat. On the road to excellence there are no destinations! Keep chipping away at what seems not required, reduce feature bloat (yup, you will inevitably end up building a few too many) and always lookout for more feedback from your users to sharpen up features.
All credit for illustrations goes to @itsmeritesh!
* TED Talk: Tim Harford: Trial, error and the God complex.