Narratives are a powerful concept that make difficult concepts easy (and even fun, interesting) for us to understand. BUT they also come with some rish—risk from abstracting out important details and context that might diverge from facts. This happens quite a bit… 1/
2/ I want to talk about this in context of business because there's a lot going on where compelling narratives are taking hold, which sound like big problems or a lesson from business history but might hold us back collectively from finding solutions or understnading challenges.
3/ This is not a new problem and to be clear it isn't one to ascribe to malice. In fact it is most always a simple form of confirmation bias or "that just makes sense" combined with a bit of "if that's true it fits super well with a broader narrative." en.wikipedia.org/wiki/Confirmat…
4/ First example I came across professionally was "Microsoft uses undocumented APIs in the OS so its own Applications have an advantage". This was more than a narrative, but it was almost canon. In fact a book even existed along these lines.
5/ The use of such APIs fit in very well w/ idea that there was something inherently "unfair" about a company making both OS and Apps. This was a modern view of computing in the age of the first open OS, which happened to be MS-DOS :-)
6/ It also fit well in trying to "explain" that there must be some reason that MS Apps were starting to win in the market—that there was more there than just simply winning reviews and customers. QED, undocumented APIs. See also (2001) cambridge.org/core/journals/…
7/ This narrative stuck like glue and lasted ~decade. Only problemit wasn't the case. But proving absence of something can be tricky, except there's code. You could look at an app's code and see where it calls the OS. You can read all the reviews and talk to customers, too.
8/ Still it was and in many cases remains a powerful narrative. Powerful narratives without supporting evidence were even a key part of the antitrust (AT) efforts in tech. That's what motivated this thread. In AT a narrative is crafted by the winners which makes them interesting.
9/ Reading Sen. Klobuchar's book "Antitrust". At one point the excerpt below appears about both the AT&T case and the IBM case (so two narratives). The gist is that innovation was unleashed by antitrust structural releif. amazon.com/Antitrust-Taki…
10/ AT&T thiving came about because of the rise of wireless and changes in phone usage unrelated to the strucural relief entirely. In fact wireless was not even part of divestature. It was a last minute "who wants wireless"—the case was about long distance land lines.
11/ IBM did not take its eye off the ball of the PC that it invented. It simply didn't think a microprocessor was useful or powerful compared to mainframes. It believed the pundits who called (its own invention) PCs toys. Also it failed to see a pure play software market.
12/ Because the winners in AT create the narrative (no one believes the loser) and it is only natural & to their advantage to craft stories about how AT was successful, this became story. Here we are today 40 years later with a _fact_ that it was strucrural relief doing the work.
13/ Even if you don't believe an alternative view of causal relationships, that view and surrounding supporting facts are simply not part of any narrative. This matters because important debates are framed on those narrative (as the book does) and decisions are made.
14/ There are many of these narratives today that we're seeing become the new undocumented API canon. It does "amaze" me how often these are repeated or at least not looked at critically. While FB and Google with ads are the subject of many, so is Amazon.
15/ Two of my favorites are how Amazon subsidizes retail, depending on the time/narrative it is either AWS profits or something called "advertising" that makes it possible for Amazon to offer lower prices than other retailers.
16/ As with undocumented APIs proving something not done is difficult, but also in this case there's the public financials as well as 100 years of retail offer "evidence". One need only look at the financials. @benedictevans did that. ben-evans.com/benedictevans/…
17/ As far as "ads", without "ads" amazon would not be a profitable retailer. BUT, no retailers would be profitable without co-marketing, placement fees, coop ads, etc even if AMZN calls this "Advertising". All such "payments" from mfg to retailers have been typical for ~50 yrs.
18/ But there's an incredibly strong desire to provide a story as to why Amazon is successful that is more than just better execution and innovation in distribution (literally all retail is at the core), but some ~improper advantage. Now that feeds into AT and structural relief.
19/ One filter I have learned that helps with narratives is TIME. The closer a narrative is to events actually happening, the more likely it is that the true causaility and full context are lacking. It would take 10 years to fully understand IBMs miss oir ATTs gain.
20/ We might not know for a decade if Amazon was just the next innovative retailer to follow Sears, Macy's, GAP, Wal-Mart, etc. to be innovators followed by a challenging period. Retail has consistently done that.medium.learningbyshipping.com/amazon-4648bdf…
21/ Another filter is a second look at facts: timelines, company actions, and of course financials. Did AT action cause Microsoft to lose mobile? That's a favorite. The timelines, the 7 different tries starting in 2000 to build a phone, and biz model would not show that.
22/ Beyond antitrust but in all of the meta challenges facing tech today (from AI to privacy to just simply scale) narratives are an important part of the debate. It is both possible and desireable to disagree on the substance of a policy choice, but when it comes to narratives…
23/ …this thread is a call to be a good producer and consumer of narratives. When used effectively narratives abstract complex topics and make communication easier. When used with an agenda, narratives can obscure reality or even create paths to invalid solutions/actions. // END
• • •
Missing some Tweet in this thread? You can try to
force a refresh
What did a corporate network look like in 1994? Here are some slides I made in the summer of 1994 for the interns. MS had 35,000 PCs sending 12.2 million email messages a month. Also, MS had 23 mini computers and a mainframe with 3.2 terabytes of disk space. 1/
2/ Why is this so interesting? Because companies around the world were building out networks like this right when the Internet arrived. The Internet upended how to think about connectivity. A BigCo connected to the internet versus making its own Intranet.
3/ Many of us were incredibly excited by the opportunity the Internet brought us. Sitting in a hallway outside a the TCP/IP Dev Manager's office was Microsoft's FTP server. No demand gen. Spontaneous usage!
2/ The phrase "disruption" wasn't even around in 1994. In fact the original paper was months away before the language it created came to define the internet. (not yet "Innovator's Dilemma")
3/ When we first saw breadth of internet technologies all at once, it was still easy to dismiss for the reasons one can imagine. They didn't work as well, they were free, and so on.
I had to become an "evangelist" for the internet. I learned very valuable lessons very quickly.
Transforming from app/service to platform often (not always) involves adding extensibility (API) for other companies or customers to use. Using extensibility aside from solving a missing capability, is sticky and good for biz. Some patterns, traps, pitfalls & lessons 1/
2/ Most SaaS can be thought of as "mostly about data", "mostly about experience", or "mostly about an API", especially early. Over time most apps will naturally expand to be more of what it isn't, normal. To speed expansion and feature coverage, extensibility to the rescue.
3/ An app that is mostly about storing data will often expand to both ingest more data but to also display/report/synthesize data. Early on exposing an API that allows more data to be ingested or allows other tools to serve as front ends is natural.
Why were word processors $500+ in 1980s (~$1300 2021)? Aside from "seemed right" the packaging and contents were expensive. Here's a leading WP MultiMate. It came with several books, reference cards, keyboard templates, backup disks... The box is a fancy cloth storage box. 1/
2/ Companies were not just teaching their product but had to explain how a PC worked. The "Beginner's Guide" literally explained how a PC worked? Why, because often people were buying a PC to run one software product. How do floppies work?
3/ Products were enormously complex to use. It often took weeks to become kind of proficient. Mostly because usage meant learning essentially arbitrary keyboard "chords". MultiMate was famous for *stickers* you'd put on your keys (talk about commitment). (tough to find these!)
"Working Backwards" is a very good book for product leaders to read. It builds on 6 core Amazon principles AND tells the story of 4 key amazon projects. Written by @cbryar (12+) and @BillCarr89 (15+ yrs) of Amazon. 1/ smile.amazon.com/Working-Backwa…
2/ My normal caveat is that I tend to like books that tell the story and tools a company used but don't try too hard to tell you that you should do what they did or "use these tools". I'm hardcore about this because I think context, domain, and people make all the difference.
3/ I've seen far too often business leaders adopt the low-friction/readily adoptable part of such expressed lessons, and then get frustrated things don't work. I've even seen this happen when one part of Microsoft tried to lift parts of what another team did.