or the Keep Things in Order or Waste Time and Money post
When we were working on Fun Bucket this summer, a few friends and users suggested (rightly) that it would be great to have Facebook integration from the start.
Better conversion rates from easy registration. Better user demographics from the oh-so-helpful Facebook user data. Easy implementation and great scalability for future feature upgrades. (again, a great suggestion)
What “we” didn’t plan on–and as Founder and Product Manger, “we” means “I”–was that we might be jumping the gun on building the functionality in. Afterthought always seems so much more foreshadowing than aforethought, don’t you think? (Hint: get used to it.)
In short: I went forward with contracting login with Facebook. We put it into the Fun Bucket alpha/prototype (RIP) and it tested, then worked, perfectly.
About a month later, after not really reviewing the code or the process flow diagram completely–a key factor in my “Read More” initiative–we launched the private beta of Fun Bucket. It is now open here. The Facebook login flow did something that worked great in the alpha, with a very simple pageflow and user registration funnel. The fancier, flashier, salesier home.php page that I set up for the beta launch pretty much broke half of the Facebook functionality.
Half Broken? Not so bad, right?
Wrong.
Because it was half broken, my users could “Log In With Facebook”. Facebook would authorize the app. Then, nothing. On our side of the app (the non Facebook side), nothing was happening. And because nothing was happening, we weren’t creating user accounts. No accounts meant that when you tried to sign in with Facebook we would throw an alert that basically had nothing to do with the problem at hand. And now we have a third category of user that is Facebook authorized, but not Fun Bucket ‘registered’.
[insert not having a technical full-stack co-founder whining here :-(]
Because of resources (money), I wasn’t willing/able to contract getting this fixed until now. I’m using Elance and adding some other functionality into the project, but we’ve lost a ton of time relative to our competitors–plus a bit of cred with some of our targeted early adopters.
I do have to shout out support to my friend that texted me about the problem when he first ran into it. Not being familiar with the Facebook Developer process, I did not realize until later that I could create dummy accounts and use them to register/test the registration process. So my original developer, tester, and I could still log in and out fine with the existing Facebook functionality. Still, getting a text from a friend you want to be excited about the app that it isn’t working…while out of town, and then trying to fix it from a Starbucks, is not ideal.
What We Could Have Done Better
- If you are planning on recoding a system that other systems are going to depend on. Put that in front. i.e. If you know that you are going to switch from a multi-page interface to a jQuery/JavaScript heavy one [cough], either wait until that is done, or make sure that your development team knows they need to be able to work with the current system and also the new system. I think that it would have been better for us just to wait. It was a relatively inexpensive $$ mistate, but cost us a lot of time trying to fix it.
- Testing. If you think you have a sufficient testing plan, script, and process–you’re probably missing something. Go through each individual change you’ve made and think about all the different existing features and functionality it impacts. Take an extra few hours to think about it or an extra day/week to test out the different dependencies. It is better to find the problem before your customer/user does.
What We Did Right
- As soon as I figured out what it was and realized I could not fix it in-house, I disabled the false functionality. You can’t be afraid to take a feature back when it isn’t working in the wild. Ideally you want to quickly fix it and get it back up/in user’s hands . But in the mean time, if it is getting in the way of the user experience and serving your users/customers–cut it!
Any suggestions or feedback for other things we could have done better around this? Comment away!