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 it’s paces.

Why Another Startup?

In the course of building my last product (CloudFire), I learnt a hard lesson that is not stressed nearly enough in the current body of Customer Development/Lean Startup knowledge:

You need to start building and testing a significant path to customers from day 1.

Like pricing, too many startups defer this to later. If you simply follow a Customer Discovery process, it’s possible to interview 30–50 people, get a strong must-have problem signal, build an MVP, refine 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 lied 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 were 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 be 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 learnt 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 to future moms.

If you can’t get to them when they are busy with kids, get to them before 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 really 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 in the course of building CloudFire. I witnessed others face the same problems in the workshops I taught. There seemed to be something here which 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 a number of 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 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 a 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 6 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 to document how I am building my business here, the USERcycle blog will be about the business itself where 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.

If you like what you see, please consider subscribing.

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.

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 7 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 as a post earlier.

Finding a co-founder has been likened to 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 starting 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 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.