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.
4/ There are two reactions to disruption:
1. This is never going to work and worrying about it is dumb and here's why... 2. This is entirely obvious and failing to change everything is dumb and here's why...
5/ It seems so silly but that is literally what happened to me as I demonstrated the internet to some of the biggest names in technology, entertainment, communications, and across all of Microsoft.
Meetings were all about idiots--except which ones?
6/ As one example, I found myself constantly making this (simplified) table of "superior" Microsoft technologies versus the web technologies that were just coming into existence--the ones I was demonstrating on my MacBook Duo.
7/ One view of this table was "that's idiotic...all those things on the right are toys". The other view of the table was "we're screwed, everything on the left is "all wrong'"
Then came the economics and business people...
8/ Who pays for all this stuff? Who maintains the code? How much does it sell for? Who are the sales and support people? Who is going to pay for connectivity?
And on and on...
9/ Many of you might have experienced this dynamic, perhaps even at these extremes (internet, cloud, mobile, ML, etc.)
Most likely you also faced this looking up an increasingly skeptical management chain.
There are two challenges in this situation....
10/ First, no matter what ends up happening someone always said it would. No matter what course of action you take, the whole time people are going to be reminding you "told you so". Every time the internet had a hiccup or we won a deal with old tech, we were wrong.
11/ Second, at the same time disruption takes time...a lot of time. Even if everything you believe will happen does happen, there's a very good chance it will take a decade or more. And that whole time you'll be wrong. That makes change incredibly difficult.
12/ And one other thing, not everything is disruption. In fact even defining what disruption is turns out to only work in hindsight. Was it the internet? Was it the browser? Was it HTTPS? Advertising?
Which technology matters when is a huge part of this.
13/ Everyone is going to face a moment where they are either saying "nope this isn't a big deal" or "OMG this is the biggest deal ever". But everyone is yelling "this is disruption" ... "this is existential"
It is one of the most difficult situations to face in technology.
14/ In the next installment of …rdcoresoftware.learningbyshipping.com we'll look at what it was like to demonstrate the Internet to those that were not sure if it mattered or not. Join in and subscribe. It is fun. I think there are lots of lessons in the story. //END
PS/ By the way, this whole story was also detailed at the time in BusinessWeek Magazine in 1996. I'll be talking about that because there are even lessons in how the way events are reported influences how the team thinks about what is happening.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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.
2/ From the earliest days the company was uniquely focused on a breadth product line, and only on software. Those were both unique compared to single-product companies or to the vertically integrated likes of IBM captured by this classic video (c. 1981).
3/ As technical assistant I was there to help with product reviews and serve as a form of connective tissue or glue between product groups executing on Bill's vision. In 1993 Microsoft just launched the 'year of Office' and had started the pivot from apps to the suite.
A topic I end up talking about quite a bit is how org structures evolve. In today's "Hardcore Software" I discuss origins of Microsoft's two main cultures--Systems and Apps. "018. Microsoft’s Two Bountiful Gardens" in Hardcore Software on @SubstackInc…rdcoresoftware.learningbyshipping.com/p/018-microsof… 1/
2/ Mike Maples Sr (then head of all World Wide Products) explained the origin of each culture using a folksy story about "two bountiful" gardens at Microsoft. Apps was 58% of revenue but Systems was top of the food chain, so to speak.
3/ Many are familiar with this image of different tech company org charts. It always drove me bonkers because I felt it did little to understand how or why companies are structured like they are and presumes it is just lunacy. Yes, I get it was to be funny.