Of Facebook mobile integration and this is how you develop a feature

Try doing a Forgot Password in any of the web app and unless they store the password in text format, the app will send you the Reset URL via email. If you do it multiple times, you will get a different reset key all the time.

Sometimes it’s really difficult to understand which one is the right reset key, as email delivery takes its own sweet time which one cannot control (so is the latest email the one containing the latest reset key?).

And now, take a look at Facebook mobile integration. Recently, I connected my mobile number to my Facebook id and as part of the process, I was sent a SMS with a confirmation code. I didn’t receive the code for for 20 minutes and followed the entire process again.
A ‘normal’ webapp would have just given me two different confirmation codes, but here is what I got (sorry for the broken screen, but life isn’t fair).

Same confirmation code (sent at diff. times)

What’s the Big Deal?

Great products are mostly about those small features that make the difference. Most importantly, it’s a lot  about ‘the soul’ (read: Entrepreneurs : Define What’s Non-Negotiable. Define a Soul) that shows up in these small features.

At the end of the day, a product is all about ‘making things simple. If Facebook wants mobile integration (which is why the feature was developed), Facebook just needs to ensure that the mobile integration is done neatly (and sorry for the cliché, shouldn’t make a user think twice). And the whole process should be very simple to ensure that the dropout rate is minimal.
If they had sent me two different confirmation codes, it would have taken two clicks (probability of 50%) to get it right. And frankly, it’s not that big a feature (for me) to try after 1 failed attempt. But by ensuring that the confirmation codes are same, they just got me in (single-click).

Period. Story over. I am in, Facebook (you have my mobile number).

Still wondering what’s the big deal? Depends on how you look at things – but for whatever excuse you have (“hey! we do not have resources”), just keep ensuring that such small utilities/features are not marked as Priority10 in your feature triage list. It’s these features that drive adoption, unless you plan to spend $$s in A/B testing before getting the feature right.

Recommended Read: Is That You? [Which is Which and Who is Who]).

Leave a Reply

Sign Up for NextBigWhat Newsletter