Why you should build in public
And how to launch your beta MVP product.
Deciding the day our beta web-app was “ready” to be launched was one of the toughest decisions I’ve had to make as a founder.
In April, my team and I launched the first version of Penny to the world.
In August, we launched our v2 website.
And in September, we launched our v2 product.
And in between April and now, we’ve had 20+ tech releases, and are constantly iterating on the product.
Sooooo much goes into launching a web-app. And the second you put that beautiful thing you created out into the world, you are immediately inviting criticism. You see these exciting launch videos on social and everyone cheesin’ hard. But what you must know is it really looks like this:
This beautiful thing you’ve been working on is not nearly done. Not even close. But building in a bubble doesn’t allow you to get real, raw feedback. You can’t possible learn if people are going to find your product, use your product, or open their wallets for your product, unless you PUT IT OUT THERE.
Of course, the thing has gotta work. People need to be able to get immediate value from your product.
I am a big proponent of building in public and iterating as you go so you can build what the user *actually* wants and not be blinded by lower conversion numbers that didn’t match your controlled pilot.
That doesn’t make it easy to do in real life.
My tips & learnings:
- MVP = must verify path forward (the real definition of mvp is minimum viable product) — what things are you trying to prove out? what are you trying to get answered? build for that. you will never have as many features as you want on day 1, but you must be able to verify and prioritize what is next based on what you put out there.
- Solve bugs quickly — no one wants to use a site that doesn’t work. We use honeybadger to detect errors and trello to manage weekly sprints.
- Test, test, test — As a founder you better be testing every possible flow in your app. Only you have the vision for your product. You can’t expect your team or your engineers to know the full test script, and catch everything. Use browserstack to quickly check different devices/screensizes.
- Auto-feedback — Build embedded usage analytics and feedback points into your product — so you don’t need to rely on user interviews to learn about your customer journey and drop-off points. This is the best thing we did. It took us longer to build our MVP because of this, but being able to see themes from the backend in real time saves you a TON of time. Btw, your users are busy and feedback surveys are a waste — 1% response rates.
- Embrace your first canceled subscription — it feels like someone stabbing you in the heart. The emotional attachment to your product is one you just can’t untangle from. Lean into it and learn from it! Your product is not for everyone (well, at least on day 1 it shouldn’t be!)
- Breathe and wait for the themes to emerge — when you hear that 1 person couldn’t find the profile page, don’t redesign immediately. Wait for things to become a theme. My rule was 4 weeks & 4 times. If more than 4 people said it in the first month, then we explored it.
- You only launch once — plan for it. Launch social media campaigns 2–3 months prior to start building momentum behind your product (we didn’t do this long enough) and have a place for people to sign-up to an email list to be notified when you are live. Don’t wait too long to launch while you are gathering a waitlist though, people will forget about you!
- Invest in a staging/testing environment — that mimics your production site as closely as possible!!!!!! WHY —well, a couple weeks into our beta launch (back in April) we realized that we needed to add a consent field to the sign-up page for our automated emails to get sent out. UGH. How did we miss this. BASICS. Well, in our testing environment, we didn’t replicate the API for the automated emails. Big miss. The hundreds of people that were signing up weren’t getting the full Penny love or receiving their custom money insights. OOF. Don’t cut corners on the set-up. The infrastructure and processes are everything (think GA,SEO,APIs). You’ll seriously appreciate the upfront work when you’re product evolves.
Today, we have almost 2,000 users in our site. Those 2,000 users got to meet Penny in her infancy. And we thank them sooo much for their patience with the drop-downs that didn’t work properly in mobile and those handful of calculators that errored out when they entered symbols into the fields. 😭
You’ll never be perfect. You’ll screw up a million times. Some people will tell you the product isn’t good enough. Some people won’t get what you are trying to build long term. Some people will push you to build for everyone and everryyythiinng. Stick with the plan. Build for your target customer (be specific). Communicate humbly with your users. And listen to your customer, she is the boss.
Tell everyone you are in beta. Tell everyone you are building something from scratch. Tell everyone you are early stages.…and have a little fun with it — no way you will get everything right on day 1.
Our early users are the greatest gift in the world. We’ve learned A TON from seeing these women interact in our site, and feel confident that the v2 product we built truly provides value, and is *actually* ready for prime time! Version 3, 4, 5, 6, 7 will be even better than we originally imagined.
You gotta believe and embrace the feedback, even if its harsh.
My company is Penny Finance, an early stage startup that is taking on the wealth gap. We want every woman who doesn’t have a financial mentor to have Penny. You can follow us here.
