4 ms·
Yeah, there is something about this startup model I don't quite like. To be upfront, I am not arguing what the word startup means - the society is free to assig
by ozataman 14y ago
Yeah, there is something about this startup model I don't quite like. To be upfront, I am not arguing what the word startup means - the society is free to assign to it any meaning it wants and what Paul describes here is a clear, specific meaning that's as good as any.
What makes me uneasy is the model itself and what it implies for the entrepreneur. To me, it makes the most sense for the VCs and other investors who manage a portfolio and can accept to fail in 90%+ of their decisions while still getting massive returns from the remaining 10% that succeed (Maybe I'm even understating the split here). But it's awful for the entrepreneur. They manage portfolios of one and surely, nobody sets out to fail! It's an awful feeling and no matter how much you say "I've learned a ton!", you still waste a big part of your life while also surviving under intense stress.
There is no one model, no clear right/wrong here and clearly Paul's model does work over large numbers of cases, judging from the Googles, Apples, Dropboxes of the world.
I personally favor a more grounded approach where you start with a strong industry background/knowledge or at least a set of skills that make you and your team special. The more diverse your team, the better, as you'll make connections between possible/untapped solutions and your domain's problems. Then you set out to solve a problem you've noticed (with a clear business model and path to initial traction based on your industry intuition and upfront customer discussions) and seek customer interaction as early as possible. If you're in IT, you're in luck as you can often get to your MVP early and you should try to get customers FAST.
Doing this with limited exposure to the VC game, in my mind, teaches your company to live within constraints and minimize your burn rate while making the most out of every member of your team. You can also take a little more time evolving your product, devoting your energy to the science (as opposed to fund-raising, etc.) and discovering unique value propositions. You also have the freedom to pivot as you need and perhaps even spend lots of time with your initial clients (and maybe be a consulting firm for a while) to learn. There may then be a point where you are much better informed about your business and want to go the VC route to transition to Paul's growth mindset. Apple started in a garage with family loans (if memory serves right) and got funded after it was already selling its prototypes and had traction. This formula, of course, would never work for a crappy team, but then no formula does.
Now if you happen to be working on the next Google, then it really is moot trying to achieve a disciplined organization upfront or taking it slow or spending time with initial clients or [fill in the blanks here]. You've found a gold mine and you're essentially pillaging it - who cares if you're inefficient. But less than 1% of smart entrepreneurs out there will end up finding that gold mine and somehow I would hate to be in the 99%. I would prefer a strategy that increases my chances of initial traction, possibly slows me down a litte, but gives me the mental leeway to discover a true niche and possibly a scalable product later on. The book "Nail It then Scale It" comes to mind.
Maybe this is what Paul means all along, but I can't help thinking that the "weekly growth targets" would paralyze many of the newcomer entrepreneurs out there with its singular mindset and make them blind to the intricacies of the problem they are actually trying to solve.
- caf 14y agoIt's not so much "who cares if you're inefficient" - if you really have found that goldmine then you have to tear into it quickly, because if you slow down to get that extra efficiency then a faster, less efficient competitor will dig it out from under you.
- ozataman 14y agoRight, that's a better wat to put what I intended to convey implicitly.