Surely if I know the answers to these questions, but still fail over and over again, these answers aren’t that useful. 🤷♀️
So what’s a better question to ask? 🤔
💬 I often get Q’s like these:
How did you get your first customers for WIP? How did you grow BetaList’s traffic? Etc.
Makers are looking to reverse-engineer success. I see it everywhere.
I don’t think it works that way and the answers to those questions are mostly useless. 💥
Surely if I know the answers to these questions, but still fail over and over again, these answers aren’t that useful. 🤷♀️
So what’s a better question to ask? 🤔
🧠 This is known as survivorship bias.
Focusing on what survived, while ignoring what made it survive in the first place.
What makes @WIP, @BetaList, and to some extent @AllStartupJobs succeed where my countless other attempts failed?
What separates a failed product 👎 from a successful product 👍?
It’s like Steve Jobs said “I’ll know it when I see it.” 👀
Same is true when we make products. We don’t know upfront what will work. But once we see an inkling of a product that does have potential, it’s not that hard to spot.
👌 The right idea will pull you forwards.
👌 The right product will attract people wanting to use it. People will give feedback without you asking for it.
👌 The right product will give you the confidence to ship something embarrassing, because you know despite all its shortcoming it’s useful.
More from Startups
There are a *lot* of software shops in the world that would far rather have one more technical dependency than they'd like to pay for one of their 20 engineers to become the company's SPOF expert on the joys of e.g. HTTP file uploads, CSV parsing bugs, PDF generation, etc.
Every year at MicroConf I get surprised-not-surprised by the number of people I meet who are running "Does one thing reasonably well, ranks well for it, pulls down a full-time dev salary" out of a fun side project which obviates a frequent 1~5 engineer-day sprint horizontally.
"Who is the prototypical client here?"
A consulting shop delivering a $X00k engagement for an internal system, a SaaS company doing something custom for a large client or internally facing or deeply non-core to their business, etc.
(I feel like many of these businesses are good answers to the "how would you monetize OSS to make it sustainable?" fashion, since they often wrap a core OSS offering in the assorted infrastructure which makes it easily consumable.)
"But don't the customers get subscription fatigue?"
I think subscription fatigue is far more reported by people who are embarrassed to charge money for software than it is experienced by for-profit businesses, who don't seem to have gotten pay-biweekly-for-services fatigue.
On a serious note, it's interesting to observe that you can build a decent business charging $20 - $50 per month for something that any good developer can set up. This is one of those micro-saas sweet spots between "easy for me to build" and "tedious for others to build"
— Jon Yongfook (@yongfook) September 5, 2019
Every year at MicroConf I get surprised-not-surprised by the number of people I meet who are running "Does one thing reasonably well, ranks well for it, pulls down a full-time dev salary" out of a fun side project which obviates a frequent 1~5 engineer-day sprint horizontally.
"Who is the prototypical client here?"
A consulting shop delivering a $X00k engagement for an internal system, a SaaS company doing something custom for a large client or internally facing or deeply non-core to their business, etc.
(I feel like many of these businesses are good answers to the "how would you monetize OSS to make it sustainable?" fashion, since they often wrap a core OSS offering in the assorted infrastructure which makes it easily consumable.)
"But don't the customers get subscription fatigue?"
I think subscription fatigue is far more reported by people who are embarrassed to charge money for software than it is experienced by for-profit businesses, who don't seem to have gotten pay-biweekly-for-services fatigue.
