The project to prevent price-point apocalypse at Microsoft
In 2004, after wrapping up my coding project for Microsoft Research, a friend from Berkeley was now a director at Microsoft and hiring for a position quite unlike anything I’d done before, in a part of the company that couldn’t be more different from the product groups or research. It was a product manager / business analyst consultant role for a special project on the operations side of the company.
Bracing for the asteroid called Vista
Bear with me, as the root problem here needs explanation. It’s not really about the products or services themselves, or the end-users, and yet, it’s vital.
During this time, 2004, 2005, 2006, leading up to a mammoth Office upgrade cycle and the much-unloved Windows Vista, consumers would not have noticed, but from an internal operations perspective, the combinatorial complexity of Microsoft’s offerings was exploding.
Every year, there were many new products, to be sure. And then there were new versions and variations of each these products for different platforms and languages and market segments. But wait, there’s more!
For each of these, there were many different programs you could license them through, targeting different types of enterprises large and small, public and private sector, different durations and levels of commitment. And then, there were the licensing agreements themselves, and all the agreements and approvals and business processes around every stage of them (sounds riveting, I know…)
Then there was an entire enterprise sales pipeline built around this with an army of internal operations managers and field sales in offices in every region of the world, creating sales quotations, managing promotions and discounts and all the different contingencies for everything that could go wrong or each permission that needed to be granted by anyone at every step of each business process. Who knew that simplify buying software - sorry, licensing software and support services - could be so complex?
Microsoft was bracing for the explosion in its own product offerings, four million price points, when the next Windows/Office update wave hits. Despite all the financial success Microsoft was having, there was a vague sense of doom, as if there were this asteroid called Vista that might be on a collision course with Earth, but it was still very far away.
The corporate IT organization was scrambling to keep the systems running, systems that were vital for the company to actually book revenue. They were stuck using tools built when the company was smaller, and the offerings simpler. Documentation and training resources were outdated. Microsoft was relying on the passing of oral history for operational competence.
There was not yet a tool that provided a comprehensive customer-oriented view of the license position they were paying for, and the supporting information had to be assembled in clumsy fashion from multiple sources. And now, the Sarbanes-Oxley Act of 2002 inspired by the Enron financial scandal had imposed all kinds of new accounting requirements on top of it all that would have a ripple effect through the whole stack.
Even the internal process to determine a single “price point” for a product offering was surprisingly complex, and the number of these price points, based on the combinatorial complexity of Microsoft’s offerings, kept going up, and up, and up. Soon, it would exceed the number of rows in Excel, and Excel supported over a million rows. (Wait, they were using Excel?) Yes! Eating their own dog food, as the saying goes. Excel price sheets were embedded in business processes that couldn’t be disrupted. Microsoft needed to upgrade its airplane cockpit with paid customers on board, in flight.
Joining WWLP: Worldwide Licensing and Pricing
I took a job in a surprisingly large group I’d never heard of called Worldwide Licensing and Pricing, to dive into this problem space. My director-level boss was an old friend from Berkeley, ambitious, successful, brimming with confidence. I thought the problem sounded like fun, not intimidating at all.
My job was more than half meetings; I was often meeting with VPs. Steve Ballmer’s name kept coming up. I’d felt I’d arrived, in a sense, but I also felt like a fish out of water, because I was an experienced software engineer in a corner of the organization where I was as almost as far removed from engineering as you could get. This gave me a unique perspective that was hard for people other than my manager to understand. I came in knowing little about the organization, but knowing so much about technology that I sensed that some people found me intimidating. One person who had to use Excel to validate the commutative property for multiplication struck me as one of those people. I sometimes felt an uncanny need to downplay my own technical expertise at Microsoft, because this group did not hire me to code. They hired me to help Microsoft come up with a big picture strategy to solve this big and important problem.
My first mission: Go figure out how pricing works
My consulting gig started as an internal corporate research project. I got carte blanche to go around the company and reach out to folks and survey the landscape of any tool or business process that had anything to do with pricing. There were many other consultants and planners in the mix, be they from consulting companies or FTEs, who were working on v.Next of this or that internal tool to meet the biggest short-term needs for this or that org. This was going to be fun.
It was like the parable of the blind people and the elephant. Nobody had the whole picture… The execs had a big picture, but didn’t have the bandwidth to dive into this or that tool or data model four levels down in their own organizations, let alone the outdated tools and data models and ad-hoc workarounds in the other orgs they didn’t run. There were issues with bad or missing data and process constraints everywhere. Ambiguities and limitations in the tools and the data were causing errors and friction and missed opportunities downstream, and costing the company real money.
Planning to fix everything, while fixing nothing
By the end of the first month on this role I had surveyed the landscape and come up with an initial strategy for the short, medium and long term. Meanwhile, momentum was building in the mid-levels of management to do something big about this obviously big problem. With my manager’s encouragement, an effort was spinning up to pitch the top executives to fund a hiring spree to address the root problems head-on. I worked hard on the pitch with the people who were in charge of pricing policy, strategy, etc. for all of Microsoft.
Because of the huge scale of the problem, the scale of the “big fix” was also large, and expensive, and thus needed a strong business case. Various managers started hiring consultants to help make the case to hire even more consultants to solve the problem. Soon, it was a beehive of activity, with competing consultant teams, each attempting to flood the zone with their own. I’d never seen so many people come on board so quickly.
Microsoft was ramping up. The more we climbed up this ramp, the longer and steeper it seemed.
Too many cooks in the kitchen
With so many consultants, there were all kinds of kickoffs and scoping meetings and the like. Soon it felt like half my job consisted of perfecting executive pitches to keep the funding going so we could continue to attack the big problem, but because such a large number of people came on board, it was in a way, distracting us from the problem we were trying to focus on. There were too many cooks in the kitchen.
Despite efforts to forge a shared team identity, the consultants were funded by different organizations with different managers and varying priorities. Most weren’t fully allocated to this project. Some were simultaneously responsible for improving tools that might be put out to pasture because they were a workaround for a business process we were trying to fix. Those consultants had a perverse incentive to maintain the status quo while also trying to change it. I was actually one of them, but my attitude was, I was happy to talk myself out of part or all of my current job if it made sense for the organization, and then maybe go join the team to architect the fix, having been steeped in this planning and ideation phase. If I had to roll off and get some other job, so be it.
What I thought we should do
My proposed strategy was to do a few things at once: First, complete the incremental updates to all these tools already underway. Then, in parallel, survey the landscape of tools and business processes. Start figuring out what data standards are in place now, what the gaps and needs are, and spin up some kind of systemic solution. That much was already aligned with the path of least resistance.
Unfortunately (but understandably!) most of the original internal tool developers were long gone, and folks were so busy working around the current limits they couldn’t give you the time of day on their calendar for two weeks out. The project was set up to elicit the info we needed in a piecemeal, plodding fashion.
My instinct was to go much further, much faster. I thought, enough word-smithing PowerPoint decks asking for more resources to solve the problem, let’s get real right now. We’ve got a ton of consultants floating around already.
How many tools are there in all, 50? 80? Let’s send out a broad survey and get a complete list, collect piles of docs and contacts. Let’s obtain and read the actual source code for these tools, why is everyone pretending we can’t do that, how hard can it be, they’re all homemade tools in VB or C#, and we’re Microsoft. Then let’s get in a room with some subject matter experts and information architects and take a stab at a more generalized product data model that completely spans the space of all the offerings we have now, plus all the ones we might want in the future.
I was thinking we could devise some formalized system, build a unit-testable API around that, and piece by piece, update by update, incrementally install new plumbing to hook up the tools to some common infrastructure that spoke the same product language. Some tools, we’d rewrite immediately, and some stopgap solutions would fade away. As a developer, my instinct was, just give me access to some code and data to play with and I’ll show you what I mean, come on, put me in, coach!
But for month after month, it seemed to me that dozens of pricey consultants (including me) spent most of their time talking about what we all might do, how we might do it, how much it would cost, when it could happen and all of these other things that all preceded the actual core effort that it seemed to me we would obviously need in the end, and all that stuff seemed on some level superfluous if the executive team just trusted us to solve the problem, and if they don’t, why are we here and what’s their plan B? The clock was ticking fast towards price-point apocalypse.
What we actually did
With enthusiasm I joined the sub-team aiming to build consensus around creating a formal representation of the company’s existing business rules to prep for the big re-architecture project, which had provisional executive support, and we invited a company to demo their rule capture tools and teach us the best practices. All this was just for requirements gathering.
With all this talk and so little action, I was tempted to code something/anything, myself, but that wasn’t my job, and there never seemed to be sufficient consensus on next steps, with so many divisions of the company in the mix at once. It always seemed like the actual work of generating the final requirements was moving at a snail’s pace; from there we’d have endless rounds of formal reviews and signoffs, which seemed to confuse process with progress. But while there were many smart people having many smart conversations every day, trying to think long term, it felt like we were in a sort of ever-widening spiral of analysis paralysis, increasing in scope, budget and overhead.
The Home & Entertainment unit, the Xbox people, had understandably lost patience and faith in any kind of “boil the ocean in one go” solution, and they had gone off on their own and started a new, SAP-based solution for just their own pressing needs. I was skeptical of their approach, but I wasn’t even on their project. Microsoft was starting to feel like a federation of fiefdoms.
My instinct was that the 4 million price points was a sign that the pricing model itself was inherently too complex and would come to be seen as a liability by prospective corporate customers.
Enough BDUF
The project was sputtering as I rolled off. Microsoft somehow coped with its own internal limitations, and managed to launch the next wave of products, I’m sure with many headaches along the way.
In hindsight, this project was something of a case study in the limitations of the extreme Big Design Up Front (BDUF) approach that pervaded Microsoft’s culture in that era. That culture grew out of necessity in a world of shrink-wrapped software where bugs are super expensive after you ship, but that didn’t really apply to our internal IT problem.
If Lewis and Clark had insisted on mapping, planning and scheduling each leg of their entire 1804 expedition across the American West in advance they would never have crossed the Mississippi River. There’s only so much planning you can do when there are too many unknowns.
The “Extreme BDUF” culture I experienced on this “Atlas” project at Microsoft was the polar opposite of “bias to action”. It was a forced serialization of thought processes that ensued from a near-obsession with the “waterfall” process of stepwise planning: Don’t you dare code so much as a demo before checking every box in this list of process steps. But by the time you’ve documented how you fully understand the problem, it may have changed. And by the time you’ve devised the perfect solution, it may now be too late.
Let me be clear that it’s not the “Big Design” part of BDUF that I saw as the problem on this project. Holistic planning, long-term thinking, and documentation are all good things. The issue is the “Up Front” part. This mentality first manifests as the unwillingness to explore early actions while planning is underway. Small requests get deferred to a “grand plan” that will solve everything. The grand plan then gets bigger, longer, more expensive and sucks all the oxygen from small, early actions that could otherwise have catalyzed a tight positive feedback loop of simultaneous discovery and forward progress. When a project consists entirely of planners and managers, how can that happen?
Projects are hugely diverse, and no one approach fits all. If you want to fly a helicopter on Mars, you definitely should do big design up front!
Rolling off, while Microsoft rolled on
Back on the product side, Google Docs appeared months after I rolled off this project, in 2006. Google Docs threatened the hegemony of Microsoft Word, and its hottest feature was collaborative editing, like I had dreamed up back in the early 90s at Microsoft.
Meanwhile, Windows Mobile was just treading water and blowing bubbles in the swimming pool in the years before the iPhone’s big splash. From the outside, Microsoft demonstrated no discernible ambition in the entire mobile space during this period. I just couldn’t believe it, year after year after year of tiny incremental upgrades to a platform I found to be so terrible in daily use it was actually fortunate for the Windows brand that it wasn’t more popular.
During this period, despite all the big money flowing around, a dry rot was silently spreading underneath the gloss of good MSFT earnings reports, a rot whose full structural impact was yet to be felt. There were too many layers of management with too many egos, too inward of a focus, too much zero-sum thinking, too cautious an approach for such a dynamic industry.
Hugely successful companies can experience a sort of addiction to their existing revenue streams. At Microsoft during this era, it felt like anything that remotely threatened Office or Windows got knee-capped, and anything that didn’t boost them got ignored. Threat perception was too-often internally directed at other Microsoft groups. The biggest real threats were not internal, they were the external ones that were still unknown, but could have been predicted, and should have been assumed.
With one foot stuck in the past, it’s hard to take a bold leap into the future. But the future is always coming, and often disruptive. The bold visionary leap was Steve Jobs’ signature move. Meanwhile, Microsoft under the leadership of a very different Steve, Ballmer, seemed to be spinning in circles, one foot stuck in the past and the other just kicking the immediate competition down to the ground. With record profits, a lot of hard questions just never got asked.