It’s no secret that I have been writing a book — Running Lean. While this blog is a near-realtime account of my lessons learned applying Customer Development and Lean Startup techniques, the book benefits from retrospective learning, reordering, and refining of steps for a more optimal workflow. If I could do it all over again, this is the workflow I would use, and in fact, that’s exactly what I am doing with my next startup: USERcycle, where I am putting “Running Lean” through its paces.
Why Another Startup?
In the course of building my last product (CloudFire), I learned a hard lesson that is not stressed nearly enough in the current body of Customer Development/Lean Startup knowledge:
You must start building and testing a significant path to customers from day 1.
Like pricing, too many startups defer this to later. If you follow a Customer Discovery process, it’s possible to interview 30–50 people, get a strong must-have problem signal, build an MVP, refine the first user experience, even get some happy paying customers, and still hit a wall because you can’t effectively reach more customers after that.
In my case, my target customers were busy moms with young kids. Therein lay both the opportunity and challenge. The fact that moms were so busy was the reason why CloudFire would be a compelling alternative, BUT it required them to try something new and different, which was difficult because they were so busy.
There were some early warning signs that I chose to ignore. For instance, setting up early customer interviews was painful — there were long lag times before an appointment was confirmed, last-minute cancellations, etc. I put these concerns aside because it was my first time practicing customer discovery, and I didn’t have anything to benchmark against. The interviews themselves were very encouraging. I got lots of strong and genuine problem resonance and a willingness to pay, which carried me forward. I also knew early on that SEO/SEM would not be viable channels here because moms don’t wake up one morning and decide to search for a photo-sharing solution. Many have been using their current solution for years, which they learned about from friends.
This reminded me a bit of the case-study Drew Houston shared on Dropbox — A lot of their users didn’t know they had a problem until they tried the service. In my case, getting them to try the service at all was a hard chasm to overcome. Around that time, a few professional photographers also contacted me about CloudFire, which started another round of customer discovery that we ran in parallel. This time around, calls were easier to schedule, and we learned that wedding photographers had the biggest pain. It dawned on me after a few interviews that wedding photographers would not only make for easier customers but were also a potential distribution channel for future moms.
If you can’t get to them when they are busy with kids, get to them before the kids.
While most existing services were selling to photographers, we would help the photographers sell more effectively to their clients. That is how CloudFire Pro was born.
But this is not why I am doing another startup. I had started building CloudFire for myself, then pivoted to moms, and now to wedding photographers. I am NOT that into photography and don’t feel like the best person to carry this torch forward.
I found myself having more passion for the solution than the problem, which is a problem.
Around this time, I started exploring a product idea around a set of recurring problems I had experienced while building CloudFire. I witnessed others face the same problems in the workshops I taught. There seemed to be something here that prompted me to do a customer discovery cycle. To date, I have interviewed over 50 companies and have decided to move forward on USERcycle. Because it is quite different from my existing business, it was cleanest to pursue this as a new company for several reasons.
What happens to CloudFire?
The service is still active, and I am currently entertaining one of two alternatives — finding the right person to drive the product forward or selling the business. The second is currently more likely.
What is USERcycle?
I announced USERcycle over a month ago. My first attempt to describe it was as a “Highrise (CRM) for web apps.” That description didn’t survive the first round of customer interviews (which is what they are for).
USERcycle is built around solving a set of problems when moving users through a product’s adoption lifecycle. It is a synthesis of my work with Lean Startups, Kathy Sierra’s work on Creating Passionate Users, Josh Porter’s work on the Usage Lifecycle, and many others.
USERcycle is a lifecycle marketing software that helps companies turn their users into passionate customers. It specifically lets you target your users in real time based on how they behave with your product.
Building a Significant Channel to Customers from Day 1
When running lean, the first thing that matters is validating you have a problem worth solving. To me, finding a problem worth solving is finding something customers want and are willing to pay for. I have refined the gating criteria for Problem/Solution fit to now also test for a significant path to customers early.
I particularly liked USERcycle because it addresses problems I care about and also potentially targets the same people I reach on this blog. But before committing myself full-time, I wanted to test this hypothesis.
I did this by benchmarking how quickly I could get through the Problem/Solution fit stage against my last product. I put up a very basic teaser page and invited people on my blog to sign-up for customer interviews. I got over 200 responses as a result of that post, and while it took me six weeks to interview 30 moms with CloudFire, I was able to interview 40 companies in 2 weeks. If I had the stamina to do full-day interviews, I would have been able to do this in a week. My apologies to those I wasn’t able to get to. I have refined my customer interview process to where I test sets of hypotheses in batches. The first batch is over, and I am currently regrouping for the second batch.
The interviews themselves had a 90% must-have and pricing fit. They helped me re-prioritize the top 3 problems, better define the initial customer, and gave me the green light I needed.
The next step to channel building is starting a “Problem” blog. While I will continue documenting how I am building my business here, the USERcycle blog will be about the business itself. I will specifically cover techniques for tracking and increasing engagement with users. The blog just went live with the first post yesterday: Lifecycle Marketing and Building Successful Products.
Next Steps
I’m all in. I believe I have a strong problem worth solving and have attracted a great roster of advisors (all of who should be familiar to readers of this blog). The next step is getting the MVP launched, which I am braving on my own at the moment.
Starting a co-founder search
I get asked a lot about my perspective on co-founders. I am not against them and actually started my last company with co-founders. They were the wrong ones, though, and I have been running my company for the last seven years as a single-founder company with some help along the way. Running a Lean Startup (or any startup) as a single founder is not easy, and it’s forced me to come up with a set of work hacks along the way, which I covered in a post earlier.
Finding a co-founder has been likened to a marriage, and like a marriage, it can be the best or the worst thing to happen. I am certainly open to a co-founder for USERcycle and had actually started working with someone that would have been a great match — unfortunately, the timing was wrong.
I am not particular about location (at least not initially) and am looking for a builder (technical co-founder) that gets Lean Startup, Rails, and USERcycle. A lot has been written on the topic of co-founders lately. If I have anything worthwhile to add, I’ll do so in a future post.
The necessary prerequisite, I believe, for finding the right co-founder is establishing some history of working together first. Even people you’ve known for a long time can make for bad co-founders, as I found.
If anyone out there is interested in exploring working together on USERcycle, I’m up for it: ash@usercycle.com.