Spreadable Logo

This is the first part in our four-part Spreadable post mortem. Part II will be live on Tuesday June 14th.

Our Vision for Spreadable

Spreadable was designed to allow business owners to harness the power of word of mouth generated by their happy customers.  We were trying to solve three big problems:  1) People find it hard to ask satisfied customers for referrals 2) It’s hard to quantify the impact that referrals have on your business 3) Developing a referral program from scratch takes significant time and effort.

At the beginning, we envisioned our ideal customer to be a small to medium sized business who sold primarily through the web. Specifically, we saw SaaS and ecommerce companies as two very attractive target markets.  There are obvious benefits in terms of measurement. It’s much easier to track an online conversion than an offline one and we had a better shot at measuring true conversions for customers who sold online.

Drew Houston, of Dropbox, has spoken quite a bit about the referral program responsible for much of their incredible growth.  Our goal was to systemize a similar program and allow our customers to build a referral program with minimal technical investment.

The referral form that Spreadable allowed our customers to create was modeled after the one we had built for ourselves for the Grasshopper product the previous year.  At Grasshopper, we had experimented with several different referral platforms before deciding that none of them really did what we wanted – so we built our own. It was a pretty typical “scratch your own itch” situation.

The vision was straightforward for the Grasshopper prototype – provide our happy customers with a vehicle to email or share an exclusive offer and encourage their friends to sign up. From a technical perspective, we’re talking about a simple email form and some API integrations with major social services.

We were inspired to build the app mainly because of the incredible success the Grasshopper referral program continues to have.  We consistently see conversion rates north of 15% and the program generated 100K in additional revenue last year – all at a CPA that is much smaller than our other sales channels.

There were several enterprise players in the space, but their systems came with an enterprise price tag. We liked that fact that it was a niche category and believed the enterprise guys were ripe for disruption.

Team Structure & Alignment

Some may disagree with me, but I believe that most of the mistakes I’ll cover were a direct result of how our team was structured.  There were three big problems:

First, the team didn’t have one person acting as the Founder of the business. By Founder, I mean the person who has responsibility for two key things: 1) Final decision making power for things like UX, design and marketing 2) Responsibility to adhere to a clearly defined budget. This torch was passed around several times throughout Spreadable’s life. With no Founder and no real financial constraints, we spent significant dollars with very little market validation to show for it.

We had no checks and balances in place to know when or even if we had validated/invalidated the assumptions we had about our business model. We also didn’t do a good job of documenting our initial assumptions or communicating how they changed over time. A Founder should have owned these things and reported back to our management team just like an entrepreneur would communicate to investors.

Second, because there was no Founder with sole decision making power, there were multiple instances where someone from within the organization would swoop in and shift the strategic focus of the business. These changes were based purely on intuition and until the end, had very little data to support them. There was also never a time when all of the decision makers within our organization got into a room and agreed upon a unified vision for the product. There was always finger pointing after the fact.

Third, the team was too big. The size of the team shifted over time from anywhere between four and seven contributing members.   In terms of skillsets, we were strong in two areas: Ruby on Rails Development & Marketing.  Our general mantra was that having more developers on the product would accelerate our path to success. In reality, adding more developers to the team was simply leading us down the wrong path, faster. We hadn’t done the upfront learning necessary to warrant the additional firepower.

Because of how we integrate into our customer’s web sites, Spreadable is a product that is fairly intricate on the front-end. We would have greatly benefited from a Javascript expert initially. We didn’t get that expertise until it was too late and it resulted in a lot of technical tail-chasing.

Looking back on it, we should have started smaller. One product and one technical person could have validated that a real problem existed. They also could have gathered enough data to determine whether or not there was an attractive market for the solution.

All the while, this small team should have been frequently communicating that learning back to people in the organization. Making the learning process transparent is especially important for making unified decisions about what that team should do next.

Takeaways

Stay tuned for Part II: Developing the App which will be released next Tuesday June 14th.

Download the entire case study here.