The Spreadable Story: Why We Shut Down a Business That Was Making Money & Getting New Customers Every Day (Part II)

June 14, 2011

0

0

  

This is the second part in our four-part Spreadable post mortem. In the second part, we will explore the development of the app along with a few mistakes we made in the midst of it. See Part I.

Version 1.0

We assumed that because Grasshopper’s referral program worked so well, it would easily port over to the businesses of our customers. Therefore, simply recreating that referral platform appeared to be the most efficient route to getting an app launched.

We spent the first three months building in a black hole known as Basecamp (37signals project management software). It was not grounded in any real customer learning – just our own judgment calls based on internal debate. We didn’t get out of the building nor did we try to learn what real problems existed in the minds of our potential customers.

At the end of the first development cycle, members of the team didn’t believe the app fulfilled even part of what its future potential could be. We were embarrassed to show it to people.

In May of 2010, we scrapped the first iteration of Spreadable and started to rebuild the entire app from scratch, reusing pieces of development work where we could.

This reset was our first crucial mistake.  Showing customers something we were embarrassed about would have been much better than not showing them anything at all. We would have learned more from people telling us the app sucked. Then at least we could have asked why.

Takeaway

• Ship the first version of your product – no matter how embarrassing. We would have saved months of development time by seeing how people interacted with that first iteration.

Version 2.0

After another three months of design & development, the app was at a point where we were ready to show it to people. Up to this point, we hadn’t shown any UI to anyone which would come back to bite us.

Informed only by the experiences we’d had when building the Grasshopper referral program, we designed a severely over-featured product.  The resulting experience was an over-complicated, feature-bloated UI that confused the heck out of our early customers.  If this is the Spreadable Post Mortem, that redesign was the Cause of Death.  The experience was bad and we ended up ripping out about 50% of the features in the end.

There are good things and bad things about the democratization of low-fidelity prototyping tools like Balsamiq and Omnigraffle.  Non-designers now have ability to communicate their ideas visually, but actual UX work should be left to those trained to do UX. I know – because I take responsibility for much of the confusing UI we ended up incorporating into the app. Engaging a real UX designer would have paid back tenfold down the road.

To start getting feedback, we reached out to friendly first contacts and built a small group of people that we believed fit the criteria for early adopters. We conducted qualitative interviews and user testing sessions in parallel. I can’t say enough about these people. Their feedback was invaluable. Finally talking to customers allowed us to make decisions based on actual data vs. our own unfounded opinions.

We learned that the real pain for a lot of people was around thanking their best customers for making referrals. What they wanted was a very lightweight system to incentivize people to make referrals on their behalf. Customers wanted to reward their customers with small tokens of appreciation like gift cards or branded t-shirts.

The alternative that most customers had experimented with already was affiliate marketing.  Our customers’ pain was that asking their best customers to sign up for an affiliate program just didn’t feel right. They also didn’t want to incentivize their best customers with cash. No value was added to their brand when they did that.  Affiliate programs were too much of a hassle and they saw Spreadable as an alternative.  Since we hadn’t learned this early on, Spreadable wasn’t equipped to solve this problem for people.

Takeaways

• We paid for not having a professional UX designer involved early. It resulted in an experience that was confusing and overly-complicated
• We ended up ripping out half of the features that were originally “must-haves” (Rodrigo & Jeff will never let me live this down)
• We re-aligned once we started learning from customers and started focusing on building things that mattered to our customers, not just internal stakeholders

Implementation Issues

Right before we started taking paid accounts, we made a critical decision to change part of our core technical infrastructure. Our referral widget had historically been served in an iframe that would render when a customer of ours had implemented the Spreadable JavaScript snippet on their site.  Serving our content in an iframe protected us from any malformed code on the customer side that would affect how our CSS rendered when a Spreadable button was clicked.

In order to allow our customers greater control over the visual styling of the referral form, we made the decision to get rid of the iframe and inject the HTML & CSS of the referral form directly into the document object model (DOM). This allowed our customers to directly manipulate the CSS of the form themselves.

This turned out to be our second big mistake.

Taking the referral form out of the iframe opened us up to all kinds of strange CSS conflicts that were not only difficult to diagnose, but were also isolated to specific customers.  Every bug was different and equally bizarre.

Other scripts, Flash, and who knows what else caused our referral form to degrade to a level that was in many cases unusable. Despite re-architecting our CSS so that it was uniquely identified from existing styles on customers’ sites, we still had support issues come up daily. Many new customers simply couldn’t use the embeddable version of our widget at all.

For the first few months, we tried to triage conflict bugs and address them one by one. As our customer base grew, this became unsustainable. We simply couldn’t manage the number of isolated bugs that were resulting from outside factors impacting our code. So, we stopped trying to.

After the change, many new customers had a bad first experience and cancelled immediately. We had no choice but to go back to the iframe. We lost of lots of development time backtracking, rather than focusing on hardening our platform.

Takeaway

• Re-architecting  our product to appease power users turned into a technical disaster

Part III: Marketing & Pricing will be available Friday, June 17th.

• The Spreadable Story
• Part I: Our Vision & Team
• Part II: Developing the App
• Part III: Marketing & Pricing
• Part IV: Final Decisions

Download the entire case study here.

• Comments 4
• Date June 14, 2011
• CategoriesEntrepreneurship, Marketing & Brands, Startup