As the Business Guy at Carbonmade, I'm always thinking about business metrics, and particularly last week I was thinking about ways to reduce churn. Without taking metrics into consideration, you're building blindly, but with too much emphasis on data, you end up building a watered-down product. It's a fine line. However, at scale — Carbonmade's over 275,000 members — even a .1% reduction in churn can mean thousands of dollars, so it's worth exploring. The thing about reducing churn is that you first have to identify why people are leaving your service.
Start of the Day: Laying out the Spec
We're five people now, all working on different things, so one of the most difficult things these days is organizing the priority of our project queue. When it was only Jason, Dave and myself, we'd only be able to work on one project at time, but with the addition of Sigler, we're able to have two or more projects going at the same time. Juggling priority in our never-ending project queue is a new responsibility that comes from scaling your team.
Since our queue of projects is ginormous, adding yet another can throw people off — especially if you move it to the top. Therefore, I've taken to fully spelling out new Projects in mini Project Briefs — not as official as it sounds — usually only a few paragraphs long: an introduction to the feature, why it's important, and the scope. Actually writing it out helps prevent you from just shouting out every new idea that enters your head.
Here's the introduction I wrote for my Churn brief:
"Now that we have our new update out, we can eliminate poor video quality and other miscellaneous feature requests (for custom logos, big images, updated templates, etc.) from the churn discussion because now we offer everything they wanted. All those new features are working great and getting awesome customer feedback. However, we still need a better understanding of why our users cancel our service so that we can fight more effectively to reduce Carbonmade's churn rate."
That was followed by a full summary of what I wanted to build. The scope included the suggestion of a short survey asking our users — both free and paid — why they were canceling Carbonmade at the point of cancellation (very important). Was it because they were building their own website or did we not offer them enough space? Or was there a feature that we were still missing? People would answer the survey by clicking on the radio button that best corresponded to why they were canceling. They could then leave a few sentences in a form to go along with their selection. Not too complicated, but not overly simple — something we strive for.
All written up, I sent the email off to Dave and Jason to check out.
Middle of the Day: Chat over Coffee
Our conference room in our new office is still under construction, so Dave, Jason and I decided to walk down the street to Oro to grab some coffee and chat about what to work on next. It'd been a month or more since we last brainstormed because we've been heads down rolling out our new update.
They'd read my email earlier in the afternoon, so we began the discussion about whether we wanted to push this project to the top of our queue and how we wanted to implement it. We all agreed that we wanted to gather this data and that gathering data sooner rather than later was a good idea.
We discussed just how we wanted to implement the survey. Both Dave and Jason — to their credit — were not entirely stoked by the radio button survey approach. Both wanted to boil it down to a simple form field that the user would be presented with after clicking the cancellation button. Directing the user to type out their thoughts means that we'll get better data than simply letting them select an option, they argued. We may have to do more interpretation of the data, which means more work on our end, but the data will be better. We've all randomly clicked radio buttons on surveys just to get through the thing and this new approach would eliminate that problem as well.
We then argued a bit about whether we should present the form to both our free and paid users or just the paid users. Should we also ask users at the point of downgrade from the paid to free plan as well? We decided to take the Carbonmade approach of building the simplest solution first and iterating on it over time. We decided to roll it out for both free and paid users, but only at the point of cancellation — not the point of downgrading (for now). We could then expand on it if we were getting good data that we could act on.
End of the Day: Implementing our New Feature
A few hours later, we headed back to the office after discussing what we wanted to work on during the rest of 2010 — implementing our new comment form was only a small piece of our overall conversation. We filled Sigler in on what we had talked about, got his opinion on things, and then moved forward on knocking out the form by the end of the night.
Sigler got to work laying out and coding the HTML and CSS behind our Goodbye page. When he was done, Jason tied it in and we were live by that evening. We've already begun to sort through the data and it's really neat. Nearly everyone who cancels takes the time to write a sentence or two about why they've done so.
Here are a few of the more colorful ones:
- "Just playing with your rear end. I don't need a portfolio."
- "Had to remove portfolio images due to copyright issue... couldn't figure out how to change my profile to remove them...."
- "No longer need carbonmade. but it was a great start for me and helped me get a few jobs. thanks so much!!"
- "I'll create a new account with another e-mail and new portfolio, tks"
We're already able to take action based on these responses. Each response is tied to the person's former account, so we can look up their email address. We're able to email people — for example the person with the second comment — and explain to them how they could have removed their images. They may sign back up if we reach out to them and their problem is now resolved.
A good day at the office.