I started building HelloHailey in public (TheMVPSprint.com) last November, and launched in January. Today, 600 teammates across dozens of teams use it every day.
My last company was backed by YC and raised ~$3 million (not a successful outcome), but this time I'm going the bootstrapped Indie Hacker route as a solo founder.
I'd love to hear your feedback - about the product, home page, messaging, or anything else. Installation only takes a few minutes if you want to try it out!
For companies where innovation previously sprouted from in-person watercooler conversations, replicating that after a sudden shift to remote work is a real challenge. Their entire DNA needs to change.
Certainly they could do it, but it's far easier for an "always was remote" company than for a newly remote company. Remote-first is in Doist's DNA.
I'd love to hear any feedback you have on my MVP process (or my solution). I haven't started building yet, but I hope to have an early prototype ready in just a few weeks.
The "launch with 100 free members" strategy worked extremely well to avoid the classic "chicken and egg" problem. It's hard to quantify, but it set the tone for the community with friendly, intelligent, and experienced people.
As a new member, that led to an amazing first-time user experience where I got high-quality answers to every question I posted.
And now I'm motivated to help out other members just as the first members helped me.
Launch revenue is great, but it won't survive unless it gets this right ^^
Thanks so much for sharing your experience, Tim :) I'm really glad that you like the tone (for which I can obviously thank the members). I still have a lot to learn, but excited about what's next for sure!
It's not entirely clear to me why gig-workers would choose to receive compensation via equity (at least from the contents of this article).
For a W-2 employee, it's appealing to have a share price locked in - when Amazon is worth 3x what it was when an employee started, the value of their stock comp goes up 3x.
Will gig workers similarly see some sort of locked in share price to really see the value from this sort of structure?
Definitely a good question! Short answer - I have a strong idea, but nothing concrete yet.
I've started this whole journey with a problem-first mindset.
In the first 2 articles, I chose a problem and a niche:
As a remote product or engineering leader in tech, it's hard for my team to develop personal connections with teammates distributed across time zones.
Over the next 2 weeks I'll set my product vision and share specific requirements for an MVP. I'll scope an MVP that I can build in a month or less.
The landing page today is vague - I was hoping the problem and potential outcomes would resonate with potential users, with the goal of collecting and qualifying early waitlist sign-ups.
So far I've had 50-60+ signups, but hard to say how serious they are.
If you have such a low price with a land and expand strategy, sell your subscription only on a yearly basis and provide a long trial of 60-90 days or more so there is enough time for asymptomatic incubation and infection to coworkers.
The fewer options you provide for subscription, the better. You want your B2B customers to have a simple yes/no decision process.
Thanks for the thoughts! I agree, and was thinking something along these lines as well.
I'm leaning towards having a permanent free tier with a low seat limit.
On billing, I'll definitely have an annual subscription option. From interviews I found that, in some cases, team leads will have to file expense reports and doing it monthly would be too tedious.
I'll have to think through offering quarterly and semi-annual plans. My gut feel is that it'd be too much complexity to have 3-4 options.
Consider also a "true-up" model where buyers can exceed their user quota on your platform until their subscription is set to renew. Then perhaps you can catch the big multi-team renewals due to inertia, as well as catching back-pay for the months they were over subscribed?
I second this. Instead of billing retroactively, consider just not billing for the extra seats during that period. Maybe notify the user that they've entered a grace period for this billing cycle, but starting next cycle they can expect to get charged for the extra seats.
The usual flaw with trying to make a bundle selling better mouse traps is that there is less demand than expected for said mouse traps. And the creator's idea of what is desired seldom matches the consumer's.
This is why the important thing is getting an MVP into the hands of users, then iterating.
I agree that there's nothing wrong with spending a week or two developing an MVP first.
I don't plan on spending more than 3-4 weeks building an MVP, which I'll start within 2 weeks.
An advantage that my current approach gives me is a few dozen low-commitment (but qualified) waitlist users that have shown some initial interest.
I obviously have some close friends that will try it out with their teams. But going distribution-first allows me to easily expand beyond that close circle to a more unbiased group of people.
I started building HelloHailey in public (TheMVPSprint.com) last November, and launched in January. Today, 600 teammates across dozens of teams use it every day.
My last company was backed by YC and raised ~$3 million (not a successful outcome), but this time I'm going the bootstrapped Indie Hacker route as a solo founder.
I'd love to hear your feedback - about the product, home page, messaging, or anything else. Installation only takes a few minutes if you want to try it out!