For all those who are new to echo (old friends kindly ignore) –
echo is your friendly neighbourhood social planning app. It’s got a simple mission – to help you and your friends have fun. To know more, give the app a spin.
Back to what this article is REALLY about 😉
Since echo is your real world social app, for you to be able to use it effectively, you’ll want to have pretty much all your friends use it too. How else are you going to plan all your fun outings?
So we @echo thought, lets put in a Facebook login – this takes care of one thing for us – a new user can see her Facebook friends who are on the echo app.
In theory this makes perfect sense, however, our users didn’t think so. We @echo promise to listen to our users, be it – user interviews, feedback, surveys or reviews. Our users were concerned about privacy, and some just did not want to link their Facebook profiles.
So the echo team had one of our famous brainstorming sessions. (Not)
It was simple, if our users were not happy, we were not happy and in a week’s time, we pushed out a mobile number + OTP sign up method. We have still retained an the option to fetch some details from Facebook for people who thought it more convenient.
Although, migrating a sign up process is not as easy. All our existing users will now have to volunteer their mobile numbers, and we’re really hoping they can find a few friends using their phone contacts.
The journey does not end here, we will continue talking to our users and gather feedback on what they think about this. Who knows what the next round will bring us.
Till then, adios.
p.s If you like what you read, here is something else I’ve written about echo (heads-up, its way longer) 🙂
For a little more than a decade now, I have found myself at the mercy of various three-letter acronyms. It probably started with JEE, then CPI and now, over the last year as a bootstrapping founder, MVP and PMF. (I am also a part of the Startup Leadership Program, so SLP)
Before we chronicle echo’s early product journey,there is a bit of an announcement to make. We finally have a version that we are (somewhat) happy with and our iOS app is going full steam ahead on development, so yay!
When starting out, some of the most critical conversations with my founding team, early adopters and advisors revolved around building a minimum viable product (MVP). An MVP helps a product gain market validation, critical insights and ensures longevity. No one seems to disagree on this much at least, but the most interesting conversations I have had were on what exactly constitutes an MVP.
The problem with MVP
It’s probably safe to assume that no one except your team, mentors or investors really cares about the acronym or Greek letter attributed to your product. Viability, by definition something that sustains within an environment, can only be tested in a live environment. So when product teams say they are releasing an MVP in the near future, it ends up being a gross mischaracterization. In the past, quite a few of my peers and I have confused a proof-of-concept (PoC, adding to the 3-letter acronym list) or prototype with an MVP. What we’re actually doing is iterating quickly and making intelligent guesses that the upcoming release will be either viable or closer to viability.
MP vs MVP
A little experience, sound advice or reading will soon re-orient a product maker from trying to build out the glorified vision to a diminished just-does-the-job-(maybe) minimum product. This works when you’re on the bleeding edge of innovation OR your product is the only ‘painkiller’ in your chosen market. In reality however, being the only one is unlikely – especially when we talk about products and startups that benefit from the great leveler of playing fields – technology.
Today, customers and users have little patience to be treated as guinea pigs while we and our competition iterate, inching closer to an unseen finish line.
It’s a bit funny how, as early stage startups stuck in a rat race of our own, we’ve become comfortable viewing our users as lab rats too. (tweet it>)
Outdated literature on MVP
Analysing startup success and product best practices post success, in retrospect is easy. While you’re in the midst of it, there are just too many variables at play. Almost every success measure – revenue, traction, data, all these kick in at the MVP and beyond.
A lot has been written on rapid iterations; a common cliche is if you’re not embarrassed of your version 1, you’re too late. There’s also a whole host of startup zealots, fostering this romantic notion about users paying for a broken product and how that’s the tell of a unicorn-ish startup.
At echo, we’ve been through this. Rapid iterations?
We release two updates to the Playstore a week. Android folk, check out the app here.
Just ask our early adopters about how many times they launched echo to something absolutely new (and sometimes unfamiliar).
We can’t throw garbage at potential customers and expect them to dig for gold. Over the last year, our team has developed a new found respect for users. Our attitude to an app crash has gone from, “it happens in beta”, to “we’re sorry, we’ll fix this, today.” The world’s changed, chances of someone else working on the same idea as you are the same as you both owning the same mobile phone. Features are easily replicated, designs and UI copied; and we struggled for a while on how to differentiate ourselves.
The human factor
We’re building a conversation with our users. This is a behind-the-scenes, under-the-hood effort that is driven primarily by the founding team and will be unique to each such. As a product manager, I want to know what users are thinking about echo every day/week/month.
Trying to isolate what tickles each user’s fancy the most which could take us in one of two directions – deep personalization or aggregated best-fit.
While I dissed on a lot of literature on MVP, I do like the concept of MDP (minimum desirable product) by the awesome Andrew Chen. In my next post we’ll write about how we’re communicating with our users, personalization and more!