Ah yes this discussion. As always, I will chime in saying what I always say.
While it's true that you need to begin the iteration process with real customers sooner rather than later, you still have to actually build something for them to use. This is still going to be very hard work.
Yes, don't build features nobody has asked for yet, but do completely deliver on at least one core feature that actually makes people want more. Also, if you're a small team, and you crank out sub-par and not very well understood foundations, you're running the very real risk of having it all fall apart from underneath you when the first thing goes wrong. Again, don't go full k8s if you don't need to, but it's still very important to have a solid grasp on every aspect of your system.
You can't just skip the hard parts and get to the money printer. Or maybe you can, in which case, consider me jealous!
And when the hype curve gets ahead of your development speed, the internet can be very cruel.
There's a fine line between an MVP and chumming the waters.
Stealth Mode is meant to give you some buffer against competitors who agree with the kernel of your idea and want to copy it. If the idea is obvious, someone else might beat you to market while you're faffing about. If there is no danger of a competitor having the same idea, then customers might not 'get it' either, at which point waiting has cost you a fortune.
I can agree with that for the most part. The only point I don't exactly agree on is putting too much weight on being first to market.
Like you said, being first to market comes with the burden of having to educate the market about what the offering even is, whereas having competition means the market exists already and you won't have to do (as much of) this work.
In the end, there are plenty of examples of best-in-market beating first-to-market, and vice versa. And here we are trying to predict the weather :p
I'm not a big fan of first to market myself, but it does seem to get some people to pay attention, so I'm not afraid of dangling that carrot if it suits me.
Feedback is important. It's not the only thing that's important, but it's important. Sitting on a bunch of dark code means you won't get any feedback, and when you do get it, it won't be usable (too late to reverse course).
I've recently started thinking of businesses in similar terms to core game loops. Deep in the guts of every successful business there is one (or more) loops that keep the rest going. When I next try something i'll start with the loop.
> When it finally catches up, that bear can take many forms. Running out of money, losing interest, burning out, partners falling out, family or life situations changing, markets shifting and opportunities disappearing… That bear is running out of time.
It’s funny because I read many books and HN posts until I launched 7 years ago, and I was prepared for all situations (including downs) and all went well.
But no-one had told me that one. Fortunately, my startup is my longest streak in a single employment (2.5 max for the other ones, I’m missing recognition in the real world), but now I feel it’s time to enquire how one jumps out of this.
- Intermediaries like Corum Group only accept to help you sell if you are worth 6-30m€ (I’m around there, but, being sole owner, it’s hard to prove a valuation),
- When selling a startup, there are always provision clauses that a lot of liabilities will remain with you. Which defeats the role of an LLC (or equivalent in Europe).
So it’s hard to sell or jump ships.
This is just food for thoughts for the wannabe-entrepreneurs here — but by all means, that was my best professional experience and I had immensely more recognition naked in front of a market than in companies where the boss wouldn’t even coach me into improving myself, apart from “be the best of the team and we may promote you – 9 month later — maybe.”
But also, don't. The world is chock-full of unstable, insecure, incomplete apps, services and technologies. Our desire to be first to market, or to practice extreme continuous improvement via rapid iteration and rapid feedback creates motivations which, in some ways, are antithetical to the moral imperative we as engineers should all feel. That of creating technology that is secure, private and stable. We don't need another password breach, we don't need another growth metric driven app the belies the privacy invasions that power that growth metric.
I think you are right, but when you take your time how do you beat the company that just Zooms through, ignoring security, privacy, and stability, eats the entire market share, and leaves the secure, private, and stable apps to fight over scraps?
I think a major consideration is building what matters. Clearly, evidenced by Zooms continued dominance in spite of these scandals, these privacy issues aren’t breaking to customers.
While obviously not moral, the current environment seems to reward “get big fast, then take a breath to clean up the mess before other catch up”, by then the damage to many has already been done, but your company is huge and ate the rest.
Internet is a Kondratieff cycle: It’s a long economic cycle. 40+ years.
- At the beginning, you innovate, and there are 100 car manufacturers in your city (Lyon, France) and every employee can build a car from A to Z.
- Then you mature. You need to build the petrol station in every corner of the city, and put pollution everywhere especially on cathedrals (and passwords spill all over the place). Employees have a scope and become replaceable, but at least it’s a skill that _can_ be taught at school so you build schools to output a nation’s worth of engineers, not PhDs.
- Then it concentrates. You still make more and more cars every year, but legal requirements rise and less than a dozen manufacturers per continent make it, it is extremely capital-intensive and return on investment is around the interest rate. Employees have a mundane job, there is even a job description, which would be an insult to most of the previous generation.
- Then global warming comes and you need to remove petrol stations and cheat on tests to prove that you comply to regulatory emissions.
Startups are at phase 2. Regulatory burden is so immense that the only way to comply to SOCs/PII/Health/GDPR requirements is to build inside of AWS. The job is becoming 1. either work for Atlasssian or Amazon 2. or be independent and built a toy inside their containers, with pre-approved APIs that insurances cover you for.
Your comment is a sign that we’re entering phase 3: It’s hard to launch a startup and comply by the correct security and redundancy requirements, the talent has to be great, funding is absolutely necessary to have enough lawyers and designers, it’s capital intensive but still has excellent potential growth.
But soon, launching a startup will be as hard as launching a clothing brand: You’ll need support from stars to get famous, advertising power of the soap industry, and you’ll only make 4% above market rate.
> worrying about scalability before having a single user
While you don’t want to do something really dumb that’s hard to get out of from day 1, I can’t agree more. Last year I was asked to help with an open source medical devices project for Covid, and when the guy writing the infrastructure said he had a microservices design in place I took that as a queue to exit the project. They hadn’t even validated that people needed what they thought they should build, and here was a guy about to do a ton of work for scale that likely never came.
I'd much rather see these sorts of posts as flow charts, with lots of If/Then functions along the way. For example:
- Are you entering a regulated market with unbendable safety standards? If yes, take time to get it right. If not, proceed faster.
- Do you need to hit the next milestone fast to get more money. If so, launch rapidly with what you've got. If not, consider taking more time to get it right
Individual anecdotes are often charming and sometimes inspiring. But with so many decision points, a series of "succeed like me" single-example posts, all with different messages, start to blur.
I prefer the middle ground: do some planning and optimization so I don’t release a freaking PWA monster into the world, then have to stall later while I figure out how to maintain the darn thing.
The point of the article is that stalling later, when you have a better idea or what people want (and maybe some revenue, maybe?) is better than stalling now, when you have no customers.
Launching something that clearly nobody will use because it can't do anything is clearly a waste of time still, but if you have something that people will use despite its flaws, maybe it's time to launch.
It's an argument that makes total sense until you see how peers implement that idea.
The fact is we have coworkers who want to appear high brow but not put in the work. So they will espouse a deep belief but then use it to do something else entirely. Or nothing at all.
Stalling, YAGNI, are extremely powerful tools. Maybe not explosives level of power, but perhaps cutting torch. You can get yourself into a lot of trouble with a torch if you do things in the wrong order or skip steps. (Not a welder, but I recently watch Alex Steele, Youtube blacksmith, and his then-partner make the same mistake twice in three weeks - heating a 3 piece assembly with a torch to get pieces 1 and 2 apart/together, could not remove piece 3 afterward due to the heat - expensive teachable moment the first time, but they needed a refresher)
The Fine Art of Stalling is figuring out which Irreversible Decisions you can safely put off until later, when there is more information, and which things you require now regardless of reversibility. You don't stall on Reversible Decisions you need soon. You make them cheap.
Got a bike shed to paint? Budget for five coats of paint in as many colors, pick one at random, and then move the fuck on. Your real job is determining which concrete contractor is certified to lay the base for your nuclear reactor, when you need it laid, the lead time each candidate needs to start the work, and any buffer you want to build in. If that means you don't need to know for another year, then let's keep an eye on those contractors' finances, turnover, and lawsuits, and look at the next thorn in our side, like the shipping company we're using that keeps screwing up.
To quote the splash page I put up for my own project[0] a few days ago:
> Until sometime last year I'd been coding socii in the open because I bought into the MVP (minimal viable product) hoopla the tech community spouts. As a result, no one used it because it lacked features people expected or wanted. Turns out, if something is too minimal it ends up not being viable and well, no one will use your product.
The real reason is the drive traffic to their site. You must be new to this. Apparently this is "the" way to drive traffic / growth now, i.e. by writing these sort of short blog posts now. It's the "growth hacking" way. I have a product in the Chinese market so I haven't really used these kinds of marketing techniques. Maybe someone else can chip in how well these methods work in driving traffic and subsequently conversions, I'm genuinely curious as well
While it's true that you need to begin the iteration process with real customers sooner rather than later, you still have to actually build something for them to use. This is still going to be very hard work.
Yes, don't build features nobody has asked for yet, but do completely deliver on at least one core feature that actually makes people want more. Also, if you're a small team, and you crank out sub-par and not very well understood foundations, you're running the very real risk of having it all fall apart from underneath you when the first thing goes wrong. Again, don't go full k8s if you don't need to, but it's still very important to have a solid grasp on every aspect of your system.
You can't just skip the hard parts and get to the money printer. Or maybe you can, in which case, consider me jealous!