As a dabbler in startup punditry (I've written a couple of books on startup positioning), I find Jerry's take very thought provoking.
The crux of the issue for me is what Dr Iain McGilchrist highlighted — we attend to the world in two very different ways. One mode of attention is a broad, open awareness to what's 'out there' and the other mode is a much more narrow focus on the parts and pieces.
For startups, when you look at the actual cases, many successful founders, almost by definition, had to stumble across their insight in some emergent fashion. They either experience some pain and set about solving it (Dropbox); see some opportunity on the horizon (OpenAI); or stumble onto some idea while working on something else (Slack).
If you want to do a startup, or your current idea isn't working, and you don't have that vision of emergent opportunity, then what do you do? "Just look for some emergent opportunity" isn't very compelling advice (even if it's probably the most accurate).
This is where the punditry emerges. You have to use your other mode of attention in an attempt to brute force some insight through narrow-focused analysis, and that analysis is inherently constrained to your (by definition) barren environment. That gives you the Lean Startup, customer development, etc etc. This far more analytical approach requires (a) intense discipline; (b) a lot of luck because you're starting from a point of no opportunity; (c) enough volume to actually do the interrogation of reality.
And it may not work because it's simply using the wrong mode of attention, anyway!
Nevertheless, frameworks that exist in this realm all sound reasonable because, on one level, they are: what else can you do but interrogate reality in some methodical way? But the question TFA raises (in my mind) is whether shaking the tree like this — IF you even can with appropriate discipline — reveals emergent opportunity for startups at a scale that's reflected in the broad outcome data, and the answer appears to be no.
Interestingly, the book The Heart of Innovation[1] tries to tackle this by going to the extreme. It's not about finding some clues in fast iteration or mapping out a canvas with a nice value prop, it's about finding 'authentic' demand that's so compelling it's something users can't not do. (The 'not not' concept is hard to explain but creates a much more rigorous bar for innovation IMO.)
That's their backward-looking observation for innovations that stick (and reflects most of the cases in the book), but they're still faced with the same dilemma of what to do if you aren't blessed with emergent opportunity.
In that case, their solution is to ramp up the analysis even harder, with 150-200 "Documented Primary Interactions" observations. I.e., brute force observations even harder. Some of the authors are part of a startup accelerator with an (apparently) high hit rate, so it's not just speculation.
All told, it's amazing that billions and billions of dollars are allocated to startups and so little is invested in studying innovation itself, especially given how slight the predominant frameworks are. Yet new ways of thinking exist (like McGilchrist, or the Heart of Innovation approach), so I wonder if frameworks for innovation are still in their absolute infancy, really, where the ones that succeed suffer the memetic curse: simple enough to travel; too simple to be effective.
But it is AI! Or, at least, it's been run through it. (Staccato sentences; Not X. Not Y. Z...) It's a shame for a personal reflection. It's hard to imagine what the (I'm guessing) Claude-isms add that improve what would otherwise have been a nice unmolested personal essay.
The most egregious bug/s I've encountered in recent years is the utterly cursed tab management in iOS Safari.
A couple of times a year it will just nuke all my open tabs (450-500) and present me with a delightful blank screen. Before that it will mislabel the active tab group on and off before giving up entirely.
Quick action on my part stops the destruction syncing & I usually end up recovering them on my Mac & then save them as a tab group.
But literally just an hour ago, iOS Safari looked like it nuked ALL MY TAB GROUPS. Ugh. They were gone; swiping right led to the "New tab group" screen. Frantic backing up and a restart later, and the tab groups are back, as though the phone was like "just kidding!". FML. So much for that backup plan.
UI bugs are one thing, but how is that level of data loss acceptable in a modern operating system? Boggles the mind.
(And don't get me started on the UI track wreck that is the iOS-inspired/inflicted bookmark management on macOS Safari, where all Mac UI conventions went out the window for some reason.)
I've used Time Machine for years with a cheap HD hanging off an old Airport Extreme, until today, incidentally.
MacOS had started warning that this approach won't be supported in the future. After upgrading to Tahoe, Time Machine kept saying backup failed, no matter what I did, despite the fact it should still work. Oh well, I'll just delete the old backup and create a new one.
I delete the old backup, click "Add Backup Disk...", select the backup disk, and get blocked with "[Drive] can only be used if it contains existing Time Machine backups for this Mac." It did! You broke them!
UGH.
I thought I'd get another year out of it. Apple in their wisdom has decided otherwise. Now I have no historical or ongoing backups.
I don't mean to be rude but this idea that there's some decisive, authoritative data vs. sketchy anecdotal claims kind of drives me up the wall.
What data would or could exist in this case beyond the hundreds of calls the author is apparently basing their observations on? That seems like a reasonable qualitative data set to me.
On the other hand, what you're asking for doesn't make much sense. Any push/pull strategy difference is going to change who takes a call in the first place. You're not doing a RCT on a random sampling of the population.
The point is simply that you're going to have a better time doing sales if your supply matches some pre-existing demand. You don't need a quantitative study to understand why that may well be the case.
It's the same reason that, despite being bombarded with advertisements, we don't all go out and buy 16 meals a day or 10 cars a year simply because someone tried to sell those things to us. We act when we have a need, and founders need to understand that as a physical reality when trying to sell their products.
Fellow OCD-ish charge watcher here. Has worked great for my aging iPhone.
What grinds my gears though is the AirPods. I have AirPods Pro that I want to last a long time, but out of the case the earbuds are always 'on' and drain battery relatively quickly (much faster than a phone left idle); put them in their case and they're almost always* charged to 100%. I want to be able to leave them out, off, and disconnected. I almost never need 100% battery in my day-to-day use and there's no replacing the batteries in them once they're worn out.
An 80% max charge limit would be great.
*They do offer 80% overnight charge protection, but that's irrelevant as I don't keep them plugged in overnight
Yeah, in this case, from memory, the spec author had a list of class names from a scraped HTML data set. He looked at the most common classes — nav, header, footer, and so on — and declared they should be made native elements.
Which would have been fine, except even the most obvious ones (header, footer) were given very idiosyncratic definitions, and others (article, section, aside) were seemingly thrown in at random.
This led to absurd examples where, as is still in the spec, a blog comment is an <article> and the comment's header is a <footer>. This of course undermined the original premise -- that these elements were just 'paving the cowpaths' of how people were authoring HTML, but the spec author would have none of it and shipped them all the same. And here we are. :)
A decade ago, in an act of extreme futility, I wrote a book about HTML5. I did the mailing list archaeological dig to discover the logic behind these and other new (at the time) elements. There really wasn’t any. The spec editor just made them up on a whim with very eccentric definitions. I found that very frustrating as I saw it as inflicting a whole array of meaningless choices on front end folks for years to come. A decade later, and folks are still earnestly trying to divine the wisdom of the spec. No need — there isn’t any. There’s no there there. I don’t blame the author for trying, but I do blame the spec author for a very silly rabbit hole that people are still falling down to this day.
That's really fascinating, thanks so much! I like the sound of your two cycle pitch approach -- kind of putting 'measure twice, cut once' into practice. And I admire your ability to wrangle a larger betting table & bring others into the pitching process!
> (Of course, we don't do Shape Up in exactly the way described in the book: rather than cargo-culting, we've tailored the process to fit our business, which is a very different business to Basecamp. Happy to offer more detail if anyone is interested.)
Sure, would love to hear more about your use of Shape Up. What have you found that has worked in your context that goes beyond the initial framework, for example? :)
Closest I can think of is destroying the village to save it, and I think that's very much the territory we're in here.