Ditching Facebook Login – ‘coz echo users said so

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) ¬†ūüôā

Our MVP is ready! What year is it?

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!

The beard is legit.

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.


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 is what it is
sobs&babs – these guys get it.

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.

Incremental improvements?
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!

Moment of zen:

if users still pay for it, we got a winner


Challenge Accepted: Building echo

When I first spoke to echo’s co-founder, I was working a 60 hr week at one of India’s best UX studios.¬†I have to admit, across the genres of apps that I’ve worked on, I’d never had a go at something like echo.

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¬†, use access code¬†fbwelcome

We started off with what we thought was our MVP (Minimal Viable Product). All I did at that point was add a layer of interface design for the app. The plan was to give it a test run and find out what our users thought. Well, that’s when the hypothetical shit hit the fan.

watcha gonna do when they come for you?

Challenge 1

People already have their methods of making plans with friends  which, have become conditional reflexes. We had to disrupt this mechanism. Challenge accepted indeed.

Let’s face it, with or without an app like echo, people have been and will continue making social plans with friends. We spoke to some people who fall into our user base and it turns out there are a variety of ways in which people¬†do this – whatsapp groups, facebook messaging, calls, what have you. Our users regularly use these other apps all the time and are accustomed to them.

So, we went back to the basics – more research. What is the hardest part about orchestrating social gatherings? It was clear that the initiators suffer the most. They have to lead all conversation, keep trying their luck with different groups and then track all those parallel conversations.¬†After all this, just imagine, someone puts up a picture of a cute kitten or something and all that effort’s down the drain.

clever, clever plan

The initiator became our primary persona, these only had the persuasive powers to switch a bunch of people to echo. For them we wanted to make it as seamless as possible to make a plan and have a place where all relevant info about the plan would be displayed. Hence, ‘make plan’ journey & ‘plan info’ were birthed.

Challenge 2

After attempting the herculean task of disrupting existing habits, we now have to get our users to create new ones. Learn new processes which no app had offered before.

Now, if we were a Tinder, a first of its kind app, then it would be great to introduce a shiny new process to be able to achieve the purpose of our app. They said swipe left to discard and right to express interest. With echothe effort to learn new interaction could negate the benefits gained from using echo.

We did not realize this right away, after all there was no precedent to echo.¬†So we went on as gunslingers, building interactions that we thought were both super cool and novel. As we took the prototype to our users, we realized they seemed to take a while to grasp these. If we weren’t sitting in front of them, they’d probably uninstall the app right away.

Countless articles and dozens of app I’d designed, did not come to the rescue. We went back to the drawing board created new wireframes, tested these with users, iterated & pushed out design 2.0

Plan info evolution
Evolution of the plan info…

We leveraged all that our users already knew from other apps, we held their hands when they explored echo the first few times. We added more context, more familiarity, more relevance.

Challenge 3

Echo is like a vitamin, not an antibiotic of the app world.

Taking a step back and looking at echo on the whole, is it an app people can survive without? Probably yes. It is a must have? We want it to be – just like Facebook, Snapchat or Instagram. The world now wants everything to get simple, seamless, hassle-free. However, with echo these benefits were not obvious. The people we went to, with prior appointments for usability testing, were quite keen on using echo. Nonetheless, if they hadn’t caught a glimpse, they may not have been with us. Now we know that if we just got some conversation going, we could be loved.

We didn’t really know how to face this. So we did/are doing everything. We write better descriptions on app stores. We speak to people. We blog, we tweet, we post. More than anything else, we onboard users.

We have a multi-layered onboarding process – it starts with receiving an invite from a friend. This invite takes you to our web app where we show you the glimpse of the plan.

Glimpse of our 'new user' onboarding journey

Glimpse of our 'new user' onboarding journey
Glimpse of our ‘new user’ onboarding journey

We let users, take advantage of our web app to get acquainted with echo and then make a conscious decision to download echo as & when they deem fit. If you do choose to get echo, then we have some visuals and punchlines which attempt at summarizing what echo is with the least possible effort on your side. Finally, as and when you unravel the mystery that a new app brings, we hold your hand through it.

There you have it folks, some of the challenges we faced building echo. I’m hoping to write a ‘Part 2’ because honestly, I just know there are going to be more ¬† ūüôā

Hope you liked it, I sure loved the challenges. If this has made you somewhat curious about echo –¬†¬†give the app a spin¬†, use access code¬†fbwelcome

echo tech team geeks out with location tracking

As engineers we want life to be easier than breathing. We want apps to replace unnecessary (random) human interactions, bots to replace assistants,¬†even swiping left or right over the awkward effort of initiating contact the 90’s way.¬†¬†Usually, these thoughts find little resonance with the ‘others’ but here’s a use case¬†where we finally felt accepted, understood, at one at last with those who think Calculus was primarily a Tintin character.

Every other evening, we’re out for drinks, or a movie or some other shindig. More often than not, one person in the group reaches the venue first and then either waits around thinking about the cosmos or for the more frantic kind, starts calling everyone else with the usual questions, “where are you at?”, “how long are you going to take?” and so on. This is usually frustrating for both parties – the one that needs to chill and the one that needs to be more punctual.

We all know what happened here...

So we figured, if we could let our friends know whenever we are on our way, and all of us who are in for the plan that evening can see each other on a map, that would be cool, right? The challenge with this use case is that users haven’t really accepted¬†the somewhat creepy ‘Nearby Friends’ or the always-on Latitude (RIP).¬†If users were to adopt¬†this behavior,¬†understanding their context would be critical. This is when the echo team had a voila moment. Users on echo were already doing –

  1. making plans with their friends to meet at a place of their liking
  2. all the friends in the plan were automatically added to a ‘messaging group’
  3. these ad-hoc groups were tagged with a tentative time and date

Problem solved! So we thought. As it turned out, for a typical plan, we had 4-5 people coming from different parts of¬†the city. It wasn’t simply a matter of sharing one’s location like we would on whatsapp or some such platform. We also needed to:

  • poll a user’s location, refresh every few seconds, share it to a common database so other users can access it.
  • calculate the eta and save that in the database (for i < n, i = 0, i++)
  • fetch the location and eta info from the database and post it to eligible users

In addition to this, we also wanted to show each user in the plan on a map, give users full control in case they wanted to stop transmitting, factor in connection issues, end the trip once the user is at the destination and a thousand other things without which the feature set just did not make sense.

Simply put, as an early-stage 2 person startup, time is our most valuable resource. We never had the bandwidth for a science project in order to develop a feature we really wanted in the product.

Ain't Nobody got time fo that - Tracking as a service? Ain't nobody got time fo' thatAlong came HyperTrack Рknown to us since it was founded by two seniors from IIT Bombay (heya insti folks!). HyperTrack was servicing the logistics arms of consumer-focused business, giving them the means to provide their end-users an Uber-like experience.

They had SDKs for Android, iOS¬†for a business’s driver and consumer apps. A delivery professional could easily start a trip in his driver app and the consumer at the other end could see in real time, the driver’s ETA and location as he arrives at the drop point. If you ignore the terms for a minute, it was apparent how this could easily fit into echo’s use case. Once someone is on the move, going to their chosen destination, they could theoretically transmit via the driver SDK. At the same time, her friends could receive via the consumer SDK. Of course, these folks in the plan would all be ‘drivers’ and ‘consumers’ at the same time and we already know who is eligible to ‘consume’ what.

When we proposed this to the HT team, they were excited by the prospect of extending their architecture to support the multiple user tracking case. In just a little over a week, HyperTrack came back to us with revised SDKs that would support our use case.

Neat documentation, their python library that we set up in 1 day, SDK integration in 1 day and figuring our own sh*t out in 4 days later, we had the feature set ready to test in our staging environment.

We registered our users as drivers and consumers on sign up. echo also triggers a push notification at a fixed interval before your plan is due to start. Celery came in handy for task scheduling. The push notification allows the user to easily start their trip – a delivery task of sorts – which is then shared with appropriate friends.

On the other side(s), the friends’ consumer SDKs take the list of tasks assigned to them, shows the current location and ETA of every task being fed in on the map and updates it in real-time.

There are straightforward methods for starting, completing and tracking tasks. The map provided in the SDK is highly customizable; we can simply override methods to change the UI of map, its markers and other UI elements associated.

In conclusion, a feature we really really wanted in echo, was built only because of HyperTrack and for this they shall have our undying love.

The Avengers can see each other on the way :-P

echo is currently in a private beta and if you would like to give it a spin, shoot us an email at ss@echoplans.com

Keep up with us on Twitter @echoplans

echo comes to IIT Bombay campus

10 years ago I entered the IIT Bombay campus for the first time. I’ll be honest, the infinite orientations, infinite clubs & activities and the infinite usage of the word infinite – all left me¬†a bit overwhelmed.

There was one single truth I chanced upon – it’s the people that matter. Friends, who will stick by you when you’re late for a class¬†or nervous before an exam or rejected by that first boy or girl you propose to.


echo is an app for just you and the friends you like to meet. Be it going for a sport in the fabulous IITB gymkhana, a drink (juice) to the nearby Laxmi or diluted brown stuff at the beloved coffee shack, you can make and share all kinds of plans on echo.

We are a bunch of IIT alumni making echo the best experience possible with much love and care. We are also packing in a whole bunch of cool features like – auto-creating groups based on who joins the plan, seeing who is on the way without having to text or call them and a LOT more coming.

Within a week, all IIT Bombay students can use their roll numbers to unlock echo access. Very soon, echo will feature all kinds of events happening in and around campus.

So echo your plans and have fun!

get echo from the playstore

If anyone else in the world needs access, shoot us a mail at ss@echoplans.com and we’re happy to give you early access. ūüôā

PS: iOS app coming soon…