Jan 31, 2022·edited Jan 31, 2022Liked by Steven Sinofsky
Another great post. These are fantastic.
As an ex-Amazonian, one of the things that sticks out for me is the huge disappointment you all set up for yourself because of the focus on what Notes did, and not your customers.
This is precisely why within Amazon, it is, at the very least, considered bad form to even talk about competitors when you're advocating why to do something or not. No one, least of all JeffB@, wants to hear it.
In this article, as before, you cite Notes as a driver for what you needed to do, rather than the customers you wanted to serve, though you do talk about acting like you were still serving hobbyists instead of enterprise customers. That said, it is the case that when you're chasing taillights, what first-mover competitors were able to sell is a useful second-level proxy for what customers want. But it's only a starting point.
I noticed in 1991, when Melinda asked me to sit in on a review of Symantec GreatWorks for the Mac, that people from Office and the Works team - who hadn't shipped yet - kept saying, "Oooh we have to have that" and other talk that would threaten their impending shipping dates if they acted upon it... not because the customers needed these features in Works 1.0, but because a competitor had them. There were a dozen people there performing a forensic examination of that product to extract must-have features. This dynamic seemed pervasive. Heck, I was there only because we at Pixelite had a quick implementation of WordArt that could be used to compete with PowerUp!'s consumer desktop publishing package for Publisher 1.0. We were told that was the reason they did the deal with us.
I admired this competitor focus at the time. I grew suspicious of it as I matured.
In general, in loops for candidates from MSFT for AMZN, we always pressed hard on customer obsession, to make sure that it was the core driver, rather than competitor obsession, the latter which we tended to see in mid-level people from MSFT far too often.
I may be misreading you here. You do talk a lot about steering the company towards obsessing about listening to LORGs more, etc. You also talk about it as a struggle. Maybe reading this into it, but it seems like it was a deep struggle.
I knew it was time to retire when I had to explain that for the 1000th time, gift someone with the MMM, etc.
"Cutting is shipping". Brilliant way to summarize it. Succint.
There's no right and wrong. Being competitive serves Microsoft well because in most every category there was competition. Where it fails is when categories span the org structure as Notes did. Microsoft had a super tough time with that.
I think similarly, being customer-centric works super well when you're expanding retail and focused on customer service as a differentiator of selling commodity products. It has not worked as well on the highly competitive innovation categories like phones, tablets, tv sticks, health bands, etc. where the products are not differentiated and struggle even with in-house placement. IMO.
Makes sense. Then why not honor Conway's Law and re-org to remove this problem and meet the competitive threat, I won\der? No org chart is sacrosanct. Was MSFT just reticent to do this?
There are many dimensions to your question. One part is an innovator's dilemma sort of thing where all sides are making money and having some success and the thing that spans existing products creates a potential competitive issue, but also ambivalence. Another part is that despite the notable failures, Microsoft had some meaningful successes with these cross product team efforts. Early Apps/Windows versions and Visual Basic for Apps are two examples. To me this example highlights the fundamental dissonance between the server teams' ethic of iterating with the IT customer, damn the timeline, and Office's ethic of making a plan to ship and sticking to it. This is a fundamental part of the issues surrounding the transition to LORG focus that Steven talks about. Another part of this example is the teams having wildly different execution paradigms which made understanding the true state of the code in real-time extremely difficult,
Another great post. These are fantastic.
As an ex-Amazonian, one of the things that sticks out for me is the huge disappointment you all set up for yourself because of the focus on what Notes did, and not your customers.
This is precisely why within Amazon, it is, at the very least, considered bad form to even talk about competitors when you're advocating why to do something or not. No one, least of all JeffB@, wants to hear it.
In this article, as before, you cite Notes as a driver for what you needed to do, rather than the customers you wanted to serve, though you do talk about acting like you were still serving hobbyists instead of enterprise customers. That said, it is the case that when you're chasing taillights, what first-mover competitors were able to sell is a useful second-level proxy for what customers want. But it's only a starting point.
I noticed in 1991, when Melinda asked me to sit in on a review of Symantec GreatWorks for the Mac, that people from Office and the Works team - who hadn't shipped yet - kept saying, "Oooh we have to have that" and other talk that would threaten their impending shipping dates if they acted upon it... not because the customers needed these features in Works 1.0, but because a competitor had them. There were a dozen people there performing a forensic examination of that product to extract must-have features. This dynamic seemed pervasive. Heck, I was there only because we at Pixelite had a quick implementation of WordArt that could be used to compete with PowerUp!'s consumer desktop publishing package for Publisher 1.0. We were told that was the reason they did the deal with us.
I admired this competitor focus at the time. I grew suspicious of it as I matured.
In general, in loops for candidates from MSFT for AMZN, we always pressed hard on customer obsession, to make sure that it was the core driver, rather than competitor obsession, the latter which we tended to see in mid-level people from MSFT far too often.
I may be misreading you here. You do talk a lot about steering the company towards obsessing about listening to LORGs more, etc. You also talk about it as a struggle. Maybe reading this into it, but it seems like it was a deep struggle.
I knew it was time to retire when I had to explain that for the 1000th time, gift someone with the MMM, etc.
"Cutting is shipping". Brilliant way to summarize it. Succint.
There's no right and wrong. Being competitive serves Microsoft well because in most every category there was competition. Where it fails is when categories span the org structure as Notes did. Microsoft had a super tough time with that.
I think similarly, being customer-centric works super well when you're expanding retail and focused on customer service as a differentiator of selling commodity products. It has not worked as well on the highly competitive innovation categories like phones, tablets, tv sticks, health bands, etc. where the products are not differentiated and struggle even with in-house placement. IMO.
Makes sense. Then why not honor Conway's Law and re-org to remove this problem and meet the competitive threat, I won\der? No org chart is sacrosanct. Was MSFT just reticent to do this?
There are many dimensions to your question. One part is an innovator's dilemma sort of thing where all sides are making money and having some success and the thing that spans existing products creates a potential competitive issue, but also ambivalence. Another part is that despite the notable failures, Microsoft had some meaningful successes with these cross product team efforts. Early Apps/Windows versions and Visual Basic for Apps are two examples. To me this example highlights the fundamental dissonance between the server teams' ethic of iterating with the IT customer, damn the timeline, and Office's ethic of making a plan to ship and sticking to it. This is a fundamental part of the issues surrounding the transition to LORG focus that Steven talks about. Another part of this example is the teams having wildly different execution paradigms which made understanding the true state of the code in real-time extremely difficult,