Eight days. That’s how long it took Josh Pigford to build and launch the foundation of what, in six months, has turned in to a $14,000/month SaaS business.
In this guest post Intercom customer Josh Pigford, founder of Baremetrics, which provides SaaS analytics for Stripe, looks at why shipping small actually leads to going big. He suggests the idea that it takes months (or even years) to launch something profitable is bogus.
Start small
Shouldn’t you shoot for the proverbial stars and make a huge impact? Go big or go home, right? It turns out that’s actually a pretty short-sighted way to build a business. The longer you build in a bubble without customer feedback, the more likely you’re building the wrong product.
When you build in a bubble, slaving away on the next big thing (whether it’s a feature of your product or the product itself), by default you have to make a lot of assumptions. Assumptions about how users will interact with it. Assumptions about how much they’ll use it. Assumptions about whether they actually want to use it at all.
When you’re starting out, time spent on things that don’t have a meaningful impact on your business is detrimental. Often fatal. The key is to invest your time in the areas where you’ll get the biggest return.
Let’s look at a real world example of this.
Buying time, from $0 to $2K
Back in October 2013 I needed business metrics for a couple of SaaS products I had. Both used Stripe for payments, which gave me all of the raw data I needed to calculate things like MRR (monthly recurring revenue), LTV (lifetime value), monthly churn, ARR (annual run rate) and lots of other three-letter acronyms.
No solution out there could gather this data without significant setup, even then I had a hard time trusting the data, so I decided to build it myself.
Over the course of about eight days (spread across a month of juggling client work, two existing SaaS products and international travel), I built and launched the first version of Baremetrics.
That first version was raw. It didn’t do anywhere close to everything I felt like it really needed to do. There were a lot of manual processes that wouldn’t scale. The design was rough around the edges. But you know what? It didn’t matter.
That first incomplete, unscalable version got me to $2,000 in monthly recurring revenue in around eight weeks. But more importantly, it bought me time.
Getting paid to experiment
Launching small had two major benefits. First, it created an instant source of revenue. Second, it bought me time to learn how my customers actually wanted to use the product.
The nuance here is that the intersection of those two benefits is where the real value lay for me. It got me usage and feedback from paying customers. These weren’t users in a trial period or on a free plan. These were people looking to get actual value out of Baremetrics.
That’s the reason shipping fast and frequently is so critical. Until your product or feature is out in the wild, being used by real users, you’re building in a tunnel of assumptions.
You need empirical proof what you’re working on will pay off. And the only proof you’ll get is with usage.
Reduce the timeframe between building software and it being used by paying customers, and the speed at which you can grow your business will increase exponentially. This is what Marc Andreessen calls cycle time compression.
Launching small and fast
What does the process for launching fast and frequently actually look like? It’s really the same whether you’re launching the product itself or just launching features.
How to choose what’s next
You invariably will have a long list of potential features or ideas for your product. Picking what to work on next is often just a shot in the dark, but early on you need things that make big impacts. You’re always better off shooting for things that will have a 10–20% impact versus lots of small things that will only have a 1–2% impact.
For me, I needed to impact revenue, so that drove my decision making process directly towards the things I knew would provide the biggest boost in revenue.
Establish the minimum and ship it
After you pick what to work on next, establish the absolute bare minimum that’s needed to get it into production. What you need to test as quickly as possible is if anyone has even a remote desire to use this feature.
It won’t be perfect. It will lack polish. It will have bugs. It won’t do everything your customers expect it to. And that’s precisely where you want to be.
Ship it.
Monitor customer usage
Once you’ve shipped it, start monitoring usage. Do customers enable the feature? If you enable it, do some users want it turned off? Do they interact with it in any way? Do they share it? Does it increase login frequency?
Your user’s actions are what speak the loudest. You need to ask a slew of questions internally about the feature and measure if the actions of your customers moves the needle in the right direction for the metrics that matter to your business.
Iterate on what works
If it has a positive impact on your business, then iterate on the feature more. Start adding more polish, build out functionality…then keep measuring.
If it has a negative impact on your business, kill it and move on. There are too many things you can do to make a big impact on your business rather than forcing things your users don’t actually want or use.
Don’t be afraid to kill what doesn’t
It’s easy to get attached to something that you put dozens or hundreds of hours in to. But you have to detach yourself, realise it’s a sunk cost, and do what’s best for the business.
Remember, the key is to make the biggest impact possible in as little time as possible.
Commentaires