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.
I love your take, but I had a hard time getting through the article because “science of entrepreneurship” already feels like a contradiction in terms to me. Each startup is a product of its unique time and context. There are huge swings in fortune based on seemingly subtle factors that are not necessarily under the control of the founder but need to recognized and can force the whole vision, approach, or even the problem statement itself to shift wildly overnight. This happens over and over again, and so creating a successful startup is more akin to bull riding than any formulaic process.
Because entrepreneurship and markets overall are at the center of so many disparate human contexts, I just don’t think the scientific method is particularly applicable. I also think the minute you try to generalize between startups the fidelity of understanding the factors of success fall off exponentially. The most common failure mode—almost by definition—is failing to recognize that some seemingly good idea or pattern that worked in many other businesses just does not work in this particular context for whatever reason. This is why entrepreneurs that are too focused on theory and not enough on the details of their particular space tend to fail.
To me, The Lean Startup is useful food for thought, and can be useful in surprising ways (even in bigger companies), but the generalized ideas and statements are of very little value without a keen sense of applicability in context. Any “science” of entrepreneurship would basically be combining the systemic chaos of macroeconomics less the precision of standard financial metrics plus all the human factors of psychology. Fascinating to think about, but I doubt the best pundits and theorists would themselves make good entrepreneurs.
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.
What else is a shame is claiming that some single language feature supports a foregone conclusion that the writing's been 'molested'. It's hard to imagine what a constructive comment this could've been with the minimum of effort to know that the author has written this way consistently since at least 2021, before the first public release of ChatGPT.
It's also hard to imagine how difficult you must enjoy being, when you could have offered a kind clarification but instead dove into some obituary style takedown.
Author here, it’s all me. I ran it through Claude before publishing to spot check me on grammar/typos and it caught a few syntax things, but this is just my writing style.
Here’s a satire piece I wrote in the summer of 2021. Tonally very different but you can pick up on my voice between it and my essay yesterday: https://samhenri.gold/blog/20210803-localhost/
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.)
Very often I'll close a tab, realize I need to open it again for some reason, long press on the + button and it just isn't there. I feel like re-opening a closed tab fails more than it works.
Also sometimes the back button will just freeze or not take you back. So I try hitting it again, it takes me 2 steps back in my history (this is fine), then I press forward and it takes me to the end of history, so I hit back again and it takes me 2 steps back. And the page I actually wanted to go back to is just gone from my history. I know there's a lot of whacky JS messing with history that happens on web apps, but it will often happen on HN when the article I clicked on is a plain text blog with minimal JS and definitely not altering the history state.
Edit: This literally just happened to me after writing this comment, with the post about turso database. I clicked the HN comments, clicked the post link (to github), read for a bit and clicked back. And the comments page is just not in my history.
I also don’t understand the back button at all on Safari iOS, I think one version it just stopped doing its one task correctly. It’s messing with my mental model of how I arrived at each tab. Currently:
Safari iOS: Be on a page, tap hold a link, click Open in new tab, go to new tab. The Back button should be grayed out and isn’t, and clicking it closes the tab.
Chrome iOS: Be on a page, tap hold a link, click Open in new tab, go to new tab. Back button correctly grayed out as the tab has nowhere to go back to.
If you have a window with only one tab in it, and drag that tab to another window to merge them, the window disappears and they merge... right? Nope, if you look in your Windows menu, you now have a phantom window with no tabs in it that you have to reveal and close manually.
Randomly when I go to close a tab it will say "you have 2 tabs selected, do you want to close both". I didn't even know selecting multiple tabs was a feature, so OK maybe I had held down shift while switching tabs at some point? Nope, switching tabs (to deselect any tabs) doesn't change it, it still thinks I have some phantom tab selected somewhere.
And there are even more macOS Safari bugs. One is that history search won't work; you'll can type in the search bar but it won't filter the list. At least a few years old. Another bug I've been getting for a few years is that sometimes I'll launch Safari and some tabs will be blanked out, often pinned tabs. No URL in the bar, no back button, the site is just gone and only a blank tab remains.
Another one is text input. Type a long enough piece of text in a website's text box and eventually it'll get messed up, or your text will be partly duplicated, or the box will be half-broken and you need to copy your text, refresh the page and paste it back before continuing.
Bookmarks sync is still an unreliable train wreck. Sometimes they'll be moved out of folders and into the bookmarks menu. Sometimes they're gone and you've lost them, which has never happened in any other browser.
And of course, Safari is the only modern browser where I still get infrequent browser crashes (not tab crashes). Something rarer on Chrome and Firefox than a lottery win.
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.
Arq Backup works great on Mac. It has a lot of smart features like only backing up on certain networks, only backing up when external power is connected, etc. You can backup either locally or remote (encrypted then uploaded to your preferred cloud provider, I used BackBlaze B2).
If you prefer free and open source, you can try Vorta (based on Borg Backup which I can also vouch for).
So "push" and "pull" as English verbs are basically opposite; and he's describing them as opposites in the previous post. But in this post he describes "push" this way:
> We are taught to do “discovery” to find their “pain points” and “problems.” So we waterboard potential customers with a series of questions to try to understand their current state... then try to surface their problems + pain points
And PULL this way:
> What are you trying to accomplish right now, or this quarter? Why this project now, vs. all the others you could prioritize? What options have you considered or tried, and what do you feel like is lacking with your existing options?
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.
Your comment hits on a broader tension I see a lot, not just here but in business strategy in general. It's the divide between compelling, experience-based narratives and empirical evidence. I think both are essential.
The author has presented a fantastic and intuitive narrative with the "BUYER-PULL" model. Your analogy is spot-on: you can't sell 16 meals a day to someone who only needs three. The qualitative insight is powerful.
My request for data comes from the next step. How do we know this narrative is not just a "just-so story"? How much does this effect matter on the margin? In the complex world of B2B sales, where needs aren't always as clear as hunger, can "push" tactics sometimes be effective at helping a buyer crystallize a latent need?
Asking for metrics like close rates isn't meant to demand an impossible standard of scientific proof. Instead, it's an attempt to test the boundaries of this framework and understand its real-world impact. Great insights often come from quantifying the effects of a powerful story.
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
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.
The ill-fated XHTML 2.0 was where the academics with actual interest in the semantic meanings of tags got too busy trying to cardinalize their semantic meanings. My understanding was that HTML5 "imported" some of the tag names but never had an interest in the intended semantic meanings as that was part of the schism that killed XHTML 2.0 and was something HTML5 wanted to avoid entirely for pragmatic reasons.
Under that understanding I think you can probably still find interesting semantic versions of these tags in the XHTML 2.0 mailing lists and schism discussions. They aren't relevant to HTML's present, but might be interesting for someone truly curious about the path not taken in semantic HTML (the path unlikely at this point to ever be taken).
I was curious so I compared the list of element tags between HTML 4.0 and XHTML 2.0, excluding the XForms module. Excluding XForms tags from XHTML 2.0, the former has 91 tags, reduced to 67 in the latter.
AFAICT, XHTML 2.0 reorganized tags into modules, yes, but didn't actually try to expand the set of semantic tags, except for XForms--the XForms module looks really complex. And those module groupings were more concerned with functionality, not content semantics, per se.
As far as I recall, that "final" draft of the XHTML 2.0 that W3 posted is "post-schism" just to get something out to compete with the growing momentum of HTML5 and kick the semantic can down the road again to XHTML 3.0 (after most of the damage of the schism was already done). I recall early XHTML 2 drafts had at least article, aside, section, hgroup, and others. I don't know where you would track down such drafts other than combing ancient mailing list archives.
Section and article makes sense as "parts of a book". However, unlike HTML, article is always hierarchy bellow section, it is actually bellow paragraphs. This schema is common in legal texts in many languages, I don't know if this is the case in EUA.
The hgroup elements also seems to be related to this.
My reasoning has always been that an article is a separable entity, which can do without the given context. (E.g., you can share it, or you can present multiple of them in varying order.) So a document may have sections, which may include articles, which in turn include sections, like the table of contents, a section of images, etc. So there's no distinctive hierarchy to them, as each may contain the other. (Mind that this is somewhat different from the use of articles in legal documents, which are integral elements of that document and lose meaning, if provided out of context.)
While any such interpretation is somewhat funny in the context of the parent comment, it may still turn out useful. E.g., if we were to scrape any content from an existing site in order to reintegrate it for a relaunch or a similar purpose.
And, as we're at it, a div is really just a technical means for applying something to a group of elements (e.g., in it's a original use, an attribute for centered text presentation), think of it as blocks in programming. Nothing semantic to see here, keep calm and carry on…
BTW, thanks for mentioning the hgroup, which is often overlooked, but really makes sense, when combining headings and subheadings, which are to be understood as a single item (like the head of an article, yes, an article in the common sense).
The actual specification of article and section elements in HTML is pretty much what you said.
My issue with them is not with their roles, but with their names. And, from the article and from OP, it seems I'm not the only one. I think "region" as it is used by WAI-ARIA would be a better name. Also something like "contentinfo" instead of "footer". And "complementary" instead of "aside"...
> E.g., if we were to scrape any content from an existing site in order to reintegrate it for a relaunch or a similar purpose.
The spec call this "outline".
Related to divs. I find ironic that making pages with tables were frowned upon 20 years ago, yet it is hot again now, but we are calling them "grids".
They say, the lack of usage of hgroups is due the lack of support by screen readers. Another common use case is <h1>Chapter 1</h1><h2>Foobar</h2>.
Regarding the table irony, see also the common use of table, table-row, and table-cell display styles for anything but actual tables. ("If I'm using divs, it's fine!") :-)
(Tables should even be more accessible, since there is <th>, both in <thead> and with `scope="row"` for table rows.)
Something, I've been guilty of (sometimes) for emulating hgroup: <h1>Heading<br /><small>Subhead</small></h1>.
In both cases article means something like "an atom of content". In legalese each statement is a separate article, in other context an entire book can be an article.
Heh, that's a little surprising. I never paid too much attention to the HTML5 element bikeshedding; I always assumed it was (like html) cribbed from sgml/docbook - but simplified (rather than randomly dumbed down).
So normally I'd probably go look at something like:
However - tfa was a lot more interesting and pragmatic - giving good advice on accessibility ; something that is actually worthwhile and not just silly bikeshedding...
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. :)
This has been a thought that has been kind of recurring for me the last few weeks.
I think the problem of bad architectural decisions has been understated, possibly since the dawn of computing.
An example of greatness is HTTP and SMTP. I'd argue most cases don't even need HTTP/2 or HTTP/3 -- getting rid of all the tracking/bloatware on the modern internet would deliver more value for the end-customer but that's not the direction we're going in. The industry has boomerang'd back to nearly static sites (I think there was progress made, IMO SSR is a local maximum), so honestly HTTP/1 is often good enough.
An example of sadness might be Bluetooth. Every time I sit down to look at some docs that involve it (mobile, otherwise) I am horrified anew.
Bad standards basically set the entire industry back person-decades.
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.
[1] Excellent overview here: https://commoncog.com/the-heart-of-innovation-why-startups-f...
reply