PublicBeta officially launched a month ago. But our V1 launch was nothing more than a marketing site. We didn't yet have a product.
In a traditional, lean startup way, the original launch was aimed at fully validating our idea and value proposition. "Launching" a startup with simply a landing page is probably the status quo these days.
But I didn't just want to validate the idea and the value proposition; I wanted to make sure that customers would actually pay for this.
After I had an insightful Clarity call with Dan Martell, I decided that the only way to gauge whether customers would pay for PublicBeta was to require a credit card upon registration.
In this case study, I'd like to share how we used this technique to validate our assumptions and also earned $4000 in revenue by selling a product that we didn't have.
The Start: A Landing Page
The initial landing page.
Our initial landing page was designed to do one thing: capture e-mail addresses that we can use as lead generation. The messaging was incredibly vague about what PublicBeta would actually be, but it was clear about one thing: entrepreneurship is tough and we wanted to help entrepreneurs.
In the two months preceding our V1 launch, we managed to acquire almost 2500 e-mail addresses. These were the top 3 sources (in order) of where the traffic (and signups) came from:
- Content marketing, which was mostly published on my personal blog. Here's the statistics of how this played out in the first month.
- In month 2, I listed PublicBeta on Betalist and we got another 300-odd e-mail signups within the first week of listing. We eventually tapped out at just over 400 signups from Betalist in total.
- I also released my book, Brandiing, which I supported by writing a few guest posts on other blogs. The TheNextWeb article specifically drove a lot of traffic and signups.
The fact that I had a pre-existing audience (15k+ followers on Twitter and my blog does about 10k uniques a month) definitely helped with the acquisition of these initial e-mail signups. That said, the traction we experienced on Betalist and the press we got on sites such as TNW (for my book) definitely pushed PublicBeta to an audience that was beyond my own. I don't have definitive figures on the split, but I'd ultimately estimate that about 50% of the 2500 e-mail signups came from or were referred by my pre-existing audience.
Next Steps: Learning From Past Mistakes
At this stage, it felt great that we had managed to acquire 2500 e-mail signups with no budget and by doing stuff that we would've done anyway (writing on my blog). But due to a past experience, simply having 2500 e-mail addresses wasn't enough validation.
In the last year, I worked on a side-project with friends of mine. Prior to the V1 launch, we had accumulated a mailing list of about 4000 subscribers who had registered and shown an interest (based off of an early, lead generation landing page and cool promotional video).
We launched and nobody came.
In the weeks following the launch, we acquired a few paying customers and maxed out at 19 active subscribers. This, however, hasn't been enough and we're in the process of selling the assets of the business.
So with PublicBeta, I wanted to avoid a repeat of those past mistakes - I wasn't willing to roll the dice to pick up another 19 paying customers out of 4000 who showed an interest.
That's basically a conversion rate of about 0.5% and I had to do better than that this time around.
There's no expense in giving away your email address.
The above scenario is probably due to society's fear of missing out. We are afraid of missing out on the next big thing (along with the prestige of being early adopters of this next big thing), so we register an interest in anything that looks like it could be cool in the future.
To us, there's no cost involved in giving our email address to a startup. If they eventually launch and email us, we can simply decide whether we want to commit to an ongoing relationship. If we don't commit, our only cost was the time we took to enter our email address.
This is exactly why email signups simply aren't accurate validations of your idea or value proposition; they don't represent any real commitment from a prospective customer to actually pay you in the future. In fact, any kind of free exchange is an useless, vanity metric unless there's an incredibly obvious route to moving from free to paid.
This is especially true when validating ideas. Pain is the only real validation.
This is why I pursued the ultimate validation: actual credit card details. If someone was willing to give me his credit card details and expected me to charge their card, I can be 99% certain of that revenue. That also means that the cost and the value of what I'm selling is mostly aligned, to the extent that people are willing to take a chance on it.
How We Did It
1. "Building" The Product (And Inventory)
Our initial value proposition was focused on producing and providing educational (video) content that would help entrepreneurs learn new skills and tricks. For this, we needed contributors who would be willing to share their knowledge and commit their time to work with us and produce the content.
One of the biggest areas of risk though was the production of the content, as it carried quite a hefty financial expense. To mitigate the financial risk, we needed to avoid actually producing any content (prior to proper validation of the idea).
So I tapped into my network, and asked friends whether they would be interested in teaching a course via PublicBeta. Knowing that time would also be one of the biggest barriers to a yes, we only had these entrepreneurs commit to working with us some time in the future (i.e. no concrete commitment or timeline). They, however, supported the idea (in principle) and we worked with them on the most minimum viable version of a course: a title and a description.
Having a title, description, and the support of the contributing entrepreneur meant that we had a product we could sell (if we were to produce it). For our initial V1, I had drummed up support from 40-odd entrepreneurs to teach courses on PublicBeta and this is what we started selling last month. (You can view our old library here.)
The important consideration here is that it is important to sell something that you can get, but don't yet have (for whatever reason). In our case, we didn't have the capital to risk in building this inventory up-front. You can't however go out there selling unicorns; you need to be realistically able to deliver on your commitment.
2. Technical Specs
When working on our initial marketing site, PublicBeta had no internal design or development resources and we had to outsource the work. The great thing about that was it forced us to focus the essentials.
We started this process with a very simple goal in mind: How little can be build? Or in other words, I like thinking about how lean we could fail?
Keeping this in mind, the V1 marketing site had only these pages:
- Homepage (explaining the main value proposition)
- Library (essential product details)
- Sign up + Sign Up Confirmation
- Vanilla informational pages (About Us, Terms & Conditions, Privacy Policy, etc.)
- Blog
We used WordPress. It's the easiest, cheapest, and fastest way to power up a marketing site.
The sign up process had two elements to it:
- Getting visitors to click any one of the various sign up buttons; and
- If they sign up, explain what had happened.
We used a combination of Recurly and Braintree for signup. The great thing about Recurly is they greatly reduce our PCI Compliance requirements compared to some other alternatives.
Behind-the-scenes (on signup), we then simply stored customers' personal and credit card details in Recurly's secure vault. To do this, you need to authorize a $0 transaction.
Note: We didn't actually charge customers any money at the time. We only wanted to make sure that we could charge them if we had the product ready.
If they were successful at signing up, they were then told that we were out of capacity and that we're not taking more users right away. We used a superficial queue mechanism to explain this to customers who had signed up.
We spent only $1000 on designing and developing this site. If we didn't get the validation or traction, we would only be losing that $1000 along with our time investment.
3. Communication
The communication during this process was pretty tricky. We wanted to avoid having to publicly tell people that we were running an extended validation test, because that would break the whole test.
If other people knew that we didn't have the content, they probably wouldn't sign up anymore. And that's why this was tricky: we ultimately relied on a bit of deception to validate the idea. This test would not have worked if we didn't use that deception.
I also think that it was important that we always had the intention to build the product and we weren't just testing an idea. If we could validate the idea, we would then invest the time & money in delivering on the promise.
We waited for a couple of days after launch (and after accumulating 30-odd paid signups), before we first started communicating with paid customers. At this point, we explained in detail what was going on and also apologized for deceiving them. I made it a point, though, to explain the risk areas (of our business model) and why this validation test helps us to mitigate that.
This strategy yielded great results:
- 71 Paid Signups
- 4 Angry Customers (who requested that their accounts are deleted)
- That makes up a 5.63% "churn"
Could we have been transparent about the fact that we did not yet have the inventory to sell?
No.
This validation test works on the premise that you are mimicking a real-life sales pitch. If a customer knows beforehand that they won't get the product subsequent to a successful signup, their considerations and motivations doesn't constitute an average sale.
This is then instead something akin to a pre-order or backing a project on Kickstarter. In both of these cases, you still get customers (very early adopters) and revenue, but you don't validate the biggest assumption: you can sell whatever you have under normal circumstances.
4. Customer Interviews
After we got the 30-odd signups, we felt that the idea was validated and that we could now proceed to the execution. In all honesty, I didn't have a clear threshold in terms of how many signups I needed to regard the idea as validated, but 30 signups represented about $1000 in Monthly Recurring Revenue (MRR) and seemed like a nice milestone (and threshold). I would've probably executed on the vision with only 10 signups too and I don't know if there's a right or wrong answer in terms of what your threshold should be.
Our first step was to start speaking to paid customers to prioritize and refine our road map.
We ended up doing interviews with about 25 of our paid customers, and these conversations were fascinating. We learnt so much about our customers: why they had initially signed up, and what they had hoped to get from PublicBeta in the future.
The great thing was that, what we learned from these conversations helped us to tweak our roadmap and we ultimately re-launched PublicBeta two weeks ago; a little different from what we initially planned. While our initial focus (and model) could have worked as well, the re-launch is definitely an optimization where we've prioritized the features that our paying customers wanted most.
5. Eventual Onboarding
A week before our re-launch, we contacted our paying customers to share our new roadmap and features. Since we had made changes to the roadmap (especially the fact that our educational content isn't ready yet), we gave all customers the option of opting-out, which meant that they would not get billed when we went live.
[caption id="attachment_1157530769" align="aligncenter" width="700"]
A real MVP: This is what PublicBeta looks like today[/caption]
When launch day came, we easily hit "start" on the monthly and annual subscriptions of our customers within Recurly. Since we had captured all of their details and authorized the credit cards, there was no hitch in going from passive signups to active, revenue-generating signups.
The Result
In the last month, we signed up about 70 customers for a total revenue of just over $4000. This also translates to approximately $2000 in Monthly Recurring Revenue (MRR). (The difference is due to the fact that we have a couple of customers on annual subscription plans.)
When we effectively re-launched PublicBeta last Monday, we were able to onboard 70-odd customers, and within a couple of minutes, had an additional $4000 in our bank account.
We also managed to prioritize our roadmap to avoid speculative expenses (the production of educational content that may or may not be valuable to our customers). These expenses required quite a big financial investment up-front, which means there's a definite financial risk there.
Takeaways & Learnings
Taking credit card details is the only way to really know whether someone is willing to pay you. Not even a verbal promise of "Yeah! I'd use that for $30" is enough. The sale is only done once you've charged a credit card.
We essentially had revenue on day one and $4000 more in the bank. That's money that we can use to further de-risk and accelerate our roadmap. Customers are always your best investors.
Doing interviews with customers that have actually paid you provides 10x the validity to the feedback. "Traditional" customer development ("get out of the building") will see you talking to prospective customers trying to figure out whether there is a problem that you could solve. But their feedback can be misleading, as they have no real vested interest in the consequence of that feedback. They don't have to pay you if you build something based on their misleading feedback. Doing customer development with someone that has given you their credit card details means getting feedback from someone with a shared interest.
It doesn't feel good to deceive prospective customers (or anyone for that matter). I didn't like this bit. Then again, is there really a big difference between this and in putting up a landing page to test a new idea? I don't know. I think if your intention is right (i.e. your heart is in the right place), then this deception is more of a white lie. (It's also important that never charged any cards; I think it would have been different if we charged the cards immediately.)
Regardless of how ethical (big or small) the deception is, it's tricky to communicate. Obviously being open and sincere about all the facts after the deception helps, but it also contradicts the very fact that you were deceitful.
Startups are about speed and access (to whatever they need to not fail on). Asking for credit card details is the quickest way to gain access to the real insight: can I sell my solution? The quicker you find answers to that question, the more risk you can mitigate. This buys you time to tweak your solution, or come up with a brand new idea; both of which increase your odds of building something people actually want.