Resources
l

The Spreadable Story

Why We Shut Down a Business That Was Making Money & Getting New Customers Every Day

Spreadable dDownload the PDF

At Grasshopper Group, our core purpose is to build scalable products that empower entrepreneurs to succeed. Our flagship product, Grassshopper.com, has served over 300,000 entrepreneurs in the last seven years. Like any business, we make mistakes and learn from them. By writing this post mortem analysis on our third product, Spreadable, our goal is to help other entrepreneurs avoid some of the mistakes we made.

Abridged Version

We shut down Spreadable on April 1st. It was making money, growing every day, and got significant coverage in the press. We made a lot of mistakes along the way and learned an immeasurable amount while bringing the product to market. We decided to stop continuing to invest in the product for three primary reasons:

  1. The product was most effectively sold in a manner that doesn’t align with the core strengths of our company
  2. The size of the market for the product we had built was significantly smaller than the markets our other two products reside in
  3. Investing financial and team resources in continuing to build Spreadable would not have yielded a return a similar investment in Grasshopper would have

Full Version

It’s been a little over one month since we made the decision to stop investing in Spreadable, the third product launched by Grasshopper Group. The app will sit dormant until the end of the year and then we’re planning to shut it down completely on December 31st.

Many people have asked why we made this decision for what was seemingly a successful, growing application. My two goals for writing this post mortem analysis are 1) To crystalize my own thinking about what happened and 2) Help other entrepreneurs learn from our experiences and avoid some of the mistakes we made. Most startup advice is very situational in nature, so keep that in mind as you read on. This was our experience – yours will undoubtedly be different.

I spent a little over a year of my life working on the app in a couple of different roles. The most significant was as Product Manager. It became my responsibility to make sure we were building a product that people cared about, that solved a real business problem, and delivered on the promise to help our customers grow their businesses using word of mouth referrals.

Without question, working on Spreadable became much more than my job. I truly believed in the idea of the product. Most importantly, I truly believed we could solve a real problem for our customers while building a profitable business.

The experience was about as close as you could get to feeling the entrepreneurial rush. Anyone who’s been through it can tell you that it’s an incredible emotional roller coaster. I’ll never forget highs like the day we got our first paying customer, or lows like the day we pulled down our marketing site and told everyone internally that we were shutting down.

As I reflect on the last year, I know that our team learned valuable lessons about what it means to build great software and I’m grateful that I got to work with such an outstanding group of people. I’d especially like to thank our customers – many of whom stuck with us from the beginning just because they believed in us.

Our Vision

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 industry was 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.

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.

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.

Premature Marketing Launch

When you’re working on something new, it’s hard to resist the urge to go out into the world and tell anyone who’ll listen. We made that mistake by focusing on a premature launch event and PR instead of continuing to learn from our customers. Everyone thought, “We need to build buzz.”

Planning and executing a marketing launch takes a ton of time and effort from people across your entire organization. If done at the wrong time in a product’s life, it ends up being more of a distraction than anything else.

Parties are a great way to get out there and meet people, but are they the right people? Are they your target customers? If you haven’t found product/market fit yet – how can you be sure? We were there pushing a demo, not learning from customers. Launching loudly had other negative side effects:

It created looming artificial deadlines for our development team. Saying “We need this feature for the launch party!” caused our development team a lot of unwarranted stress. It didn’t have to be that way. We could have just shown people mockups or screenshots. We didn’t need the entire feature to be done. We’ll think about ways to demo cheaply next time.

We also missed a significant opportunity to get a bunch of paying customers. When we threw the party, we weren’t even ready to accept credit cards. It sounds so crazy looking back on it.

If you’ve done your job building a small group of visionary customers, launch your product with those people first. They are the ones who will help you hone your product and your message.

Not Charging from Day 1

The advent of freemium has given many of us the idea that offering our products for free will build user numbers faster and result in more feedback. More sign ups = more feedback = better future iterations of your product, right? In my experience, that hasn’t been true.

When we initially launched Spreadable in “Beta”, we didn’t charge anything. Though it felt good to have a whole bunch of users, we were missing the opportunity to find out if what we had built could actually generate real revenue. Customers saying they will pay you money is very different then a customer writing you a check. There is no better form of validation than revenue. If you’ve got bugs, don’t worry about it. Customers who’ve paid you will be very prompt about letting you know.

When customers aren’t paying anything – they don’t feel as compelled to invest themselves in what you’re building. If a customer has paid you, feedback becomes pointed and immediate. It’s not always pleasant feedback – but it’s feedback you need to hear.

When you don’t charge something from day one, you don’t learn how much a new customer is worth to you. More importantly, you don’t learn if your free customers will ever feel compelled to pay you for your service. Ours didn’t.

Conversion Lessons Learned

When we started charging real dollars at the beginning of 2011, we launched with a fairly straightforward pricing model: Two plans, monthly and annual, $49 & $489, respectively. Conversion was unacceptable using this model, so began a barrage of experimentation to improve it.

From January 1-March 1, we churned through multiple marketing site mini-redesigns, a full redesign, a copywriting overhaul, seven different iterations of our sign up flow, five price changes, introduced a free trial, and produced a three minute video about the product.

We were making these changes in a relatively un-scientific way, opting for quicker iterations instead of incrementally rolling out changes in calculated tests. We chose speed over quantitative confidence and it was chaotic to say the least. The following is my best effort to highlight the key learning:

Anchor Pricing

Launching with two plans seemed like a simple way to present our product. We learned a lot about pricing strategy as our market invalidated that assumption. There were two big takeaways:

First, prominently displaying the annual plan at $489 on the first iteration of our pricing page deterred many new customers from signing up. $489 is a scary number for most folks and it wasn’t immediately clear that this was for a yearly subscription. The visual emphasis was in the wrong place.

Second, when we launched a pricing page with multiple plans, we saw a notable increase in conversion. In fact, the increase can be attributed to a theory called anchor pricing. The high level idea behind anchor pricing involves setting a potential customer’s “anchor” at a higher price point than what you actually want to charge them. In our case, we set our anchor at $199 for a monthly plan with some additional features. In reality, we didn’t expect anyone to sign up for it.

Not only did overall conversion increase, but we saw about half of customers signing up on the middle and top tier plans. Had we scaled the business and kept the same sign up mix, it would have meant a substantial increase in revenue over the old pricing model.

Throttling

Observing the change in sign up mix from the pricing model shift, I wanted to dig deeper into the thought process of people signing up on our more expensive plans. There were a couple of differentiators between each plan, but I wanted to find out what was motivating the people who signed up on the Grow or Max plans.

It turns out that the absence of certain features on the lower tier plans really wasn’t it. Instead, it was the fact that we were throttling the right key activity across the plan mix: Referrals.

By capping the number of referrals you could theoretically receive, people instinctively chose the plan where they believed they would never have to worry about missing out on receiving a referral. Since in most cases a referral was worth more than the $25 difference between Start and Grow, people felt more comfortable paying for that security.

The Power of Video (or lack thereof)

As we struggled to get conversion up to an acceptable place on the marketing site, we learned from many potential customers that it just wasn’t clear what Spreadable actually was. To remedy this, we made some significant copy changes to the site and hypothesized that a short video would go a long way in explaining our product. We looked into working with a couple of the well-known studios in the space, but quickly realized that price was going to be an issue. So, we started hacking a solution instead.

We used Mechanical Turk to transcribe the audio of four product videos we really liked and then dissected each script to find out what made them so good. We discovered that there was a pretty consistent framework used throughout all of them and set out to develop a script of our own.

When the script was done, we worked with an extremely talented motion graphics designer to bring the video to life. When it was done, the reaction we got from people was that they finally got Spreadable and the value it could create for their business.

Despite the reaction, the video didn’t have the effect on conversion that we expected. In fact, it had the opposite effect. After adding the video to our primary landing page, conversion went down. There are too many potential reasons to guess at why this occurred, but the key learning here is that people had a better understanding of our product and still didn’t sign up. This served as another red flag as to why this market may not have been right for us.

Fake It

Earlier I wrote about how impactful moving to a three plan mix was on conversion. Well, guess what? We didn’t actually have any of the features advertised on the more expensive plans. We were faking it.

While we were actively working on those features, putting the new pricing page out there was really a big experiment. As I explained earlier, we had hypotheses around the effectiveness of throttling and the plan mix itself. If we had launched the three plan pricing page and continued to see dismal conversion, we would have had a very different problem to solve in terms of our product offering. Instead, when we launched the new page conversion doubled.

I get some funny looks from people when I tell this story. In some ways, it feels a little bit dishonest to be selling something you don’t actually have. But imagine the alternative. You spend all of this time and money on a product that no one wants, when you could have simply created a pricing page to tell you if anyone would have bought it.

We didn’t actually take anyone’s money either. If a new customer signed up on either Grow or Max, I personally reached out to them and refunded their first month. I thanked for them choosing us and explained that I needed their help to shape our future offering. I enlisted them as an advisor and used their expertise to help us build a better product. I didn’t get one negative reaction from a customer.

In your experiments, you may not have such a forgiving customer base. In those cases, just apologize and make it right. There is only one thing a customer likes better than signing up for your product and having a great experience, and that’s being apologized to and having a situation rectified.

Guarantee vs. Trial

Our first pricing model launched with a 30 Day Money Back Guarantee for customers who weren’t happy with the product. If it was within 30 days of signup, we would refund people’s initial sign up fees with no questions asked. We heard inklings from potential customers that they would have liked to have had a free trial, but it wasn’t until we tested the change that we realized how impactful it could be.

Moving to the 30 Day Trial was our last big effort to increase conversion. It nearly tripled conversion rate on our marketing site. It’s important to note that these aren’t real conversions yet – but the number of people we were moving through the app increased significantly. We didn’t make it long enough to see how many of those leads became real paying customers, but my guess is that it would have been a significant improvement over conversion with the 30 Day Guarantee.

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.

Marketing Learning

The Grasshopper product has gotten to a place where we get a very predictable return relative to the number of marketing dollars we spend. With that mindset, we decided to experiment with some marketing dollars for Spreadable and see what resulted.

We experimented with various banner networks, PPC, and radio spends. Of any channel, radio was the most effective for new customer acquisitions. The problem was that it drove a customer that we weren’t prepared to support. The radio ads we ran were fairly high level in terms of what our offering was and focused heavily on the benefits of getting more referrals. More referrals = more business. Sounds great, right? When I reached out to these folks to see how their implementation was going, it seemed like many of them came to us without any idea of what the actual product was but bought purely on the benefits explained in the ad.

They also didn’t fit our original hypothesis for target market: small businesses who sold online. Most of the people that radio drove had businesses that were largely offline. In addition, they had little knowledge of HTML or how to implement our code snippet on their site. Not that these weren’t great people, but they required a level of support that we didn’t have the resources to supply. It was almost as if we had to sell Spreadable again after they had already signed up.

We also learned there is a threshold in terms of the number of customers a business needs to have in order for a referral program to be effective. If you’ve got a small number of customers, your business more than likely depends on less frequent, larger conversions. Using Spreadable to encourage those kinds of transactions just didn’t work as well as it did for more frequent, smaller, online transactions.

The important takeaway here is to be specific about your target market and be honest about how you intend to sell to them. If offline businesses were our target, it would have required us to sell and support them in a completely different way than we’re used to. Every business has strengths, and direct selling is definitely not one of ours.

The Decision to Shut Down

One of Grasshopper Group’s core values is “Always Entrepreneurial”. What it boils down to is that everyone in our company is always looking for innovative ways to solve problems: whether it’s in our everyday work or launching a new business like Spreadable.

In terms of person hours and marketing, it cost us well over $500K to bring Spreadable to market. That number could have been far less if we’d built this product with a lean mentality.

Part of being an Entrepreneur is knowing when an investment, time or money, isn’t the right investment to make. There wasn’t one standalone reason why we made the decision, but a combination of many that led us to shut Spreadable down and refocus on our other products. In summary:

What’s Next

The Spreadable team has been shifted around to other parts of the business. Of the core team of six, four of us are now working on Grasshopper related projects. We’re also got another product in the works, which we’re hoping changes the way you think about surveys. Stay tuned.

This was a team of A+ players and I consider myself incredibly lucky to have worked with them. I also feel equally lucky to have been given the opportunity to start and launch a new product from the ground up. It was thrilling to say the least.

We’re taking what we’ve learned and are applying it to building bigger and better products for Entrepreneurs. I’m willing to bet that the next one of these I write will have a very different ending.