3 ms·
Interesting writeup! Thanks for sharing. >Seems easy right - it's a CLI - just document every option and you're done in half a day. That's what I thought too.
by mtlynch 7y ago
Interesting writeup! Thanks for sharing.
>Seems easy right - it's a CLI - just document every option and you're done in half a day. That's what I thought too.
>But then you realise that each individual option is its own thing that requires thought to explain, and crucially, interacts with all other options. It's not enough to explain it in isolation. You need to tie everything together. You need examples. You realise from doing all this that there's a simpler way to name or combine options, you go back and make that change and have to update all the examples, explanations, etc.
You question whether your MVP at that stage was viable, but when I read this, I wondered whether it was actually minimum. Is it possible that you added too many options and your MVP would have been easier to ship if it had been more limited in scope?
>The product did not look like something anyone would want to pay for
One pitfall to look out for is that you probably can't accurately predict what customers pay for until you talk to a real customer. Maybe things like aesthetics that seem important wouldn't actually be important to a customer if your product solves their problem. A designer gave you feedback, and they no doubt have valid expertise, but they're also not your customer.
I had the experience of shipping too late last year:
https://mtlynch.io/shipping-too-late/ https://mtlynch.io/shipping-too-late/
tl;dr of my takeaways:
* Even if you've been warned about startup pitfalls a million times, sometimes you just have to make the same mistake to learn it.
* The goal of the MVP should be to get something in the customer's hands ASAP so you can hear their feedback. If you focus on polish and design, you might be polishing something that nobody wants.
* Question whether your "must haves" are actually just ways of delaying scary conversations with customers.
- davnicwil 7y agoThanks! And thanks for the link, I'll give that a read. On the 'get it in front of a customer' thing - I agree and struggled with this decision a bit after I'd made it as a result. Probably the best way to validate you're building the wrong thing, or it's not ready yet, is hearing 'no' and hopefully why. Super interesting factor in this case though is that basically I am the customer - it's really a product I'm building because I want it to exist. I asked myself the question, would I honestly pay for this right now? The answer was no. So at least for customer number one, me, I did kind of have that answer. Maybe cheating a bit though :-)
- gspetr 7y agoYep, the good old "build it and they'll come" trap for the naive engineer that I've stepped into myself. Thankfully, having read Rob Walling's book now I know that marketing comes before code: https://news.ycombinator.com/user?id=rwalling https://news.ycombinator.com/user?id=rwalling It's a bit dated now, but most of the advice is still relevant to solo engineers looking to turn solo founders.
- mtlynch 7y agoI like that book too! I wish I had read it before shipping that first MVP. My notes: https://mtlynch.io/book-reports/start-small-stay-small/ https://mtlynch.io/book-reports/start-small-stay-small/
- davnicwil 7y agoFollow up to my other comment, read your post and it's extremely entertaining - found myself laughing at (you can probably guess) the estimates part and a lot of the other stuff in there I know so well I felt almost as though you were writing my own thoughts better than I could :-) Very cool to hear from other bootstrappers / solo founders like yourself talking about things they've done, successes yes but also failures and lessons, and that was also my aim with this post. I feel like it's a pretty small niche within the much larger overall 'startup' world.
- mtlynch 7y agoOh, thanks! I'm glad you liked it.