Bears on the KulikThe most successful product development projects are focused. Rarely do things go well for projects that try to do everything, meet every demand, support every scenario. This applies to building cars, skis, buildings, shampoo, as well as software.

I learned this the hard way. I’ve personally helped build products & technologies that did a lot of things “ok”. I’ve also been deeply involved in projects where we tried to build things without really understanding who we were building it for. I’ll be the first to admit that while DCOM is interesting and cool, we (I) didn’t _really_ understand who the customer was when we built it. It’s a classic “build it and they will come” project and in the end it was overly complex and underutilized.

One of the things that convinced me that I should give up my perfect job in running the Windows Home Server business and take a huge risk in joining the Windows Phone team was a strong commitment to clear prioritization & principles. When the Windows mobile organization was “reset” back in late 2008 it was clear that the new leadership had learned many of the same lessons I had learned and were deeply committed to not repeating history. In talking with Terry Myerson, Joe Belfiore, Henry Sanders, J Allard, and others I felt the passion for changing our game. I heard phrases like

“We will do a few things, and do them really, really well.” 

“If you write a list write it in priority order.” 

“Focus on the end user.”

“Don’t show our organizational boundaries to customers.”

Many people were pleasantly surprised with the user experience for Windows Phone 7 Series we showed off two weeks ago in Spain. I heard & saw comments to the effect of “Wow, this is not typical of Microsoft!”.

How did we do that? What’s the secret? 

I’ll tell you: It’s being able to say “no”. It’s being able to get an entire organization setup to be able to not just say what they are going to build, but what they are not going to build.

A mentor of mine once taught me a trick to managing any sort of project. He used the “5Ps” as a framework:

  • Purpose: Why do we exist? Why are we in business? Where do we want to be in the future.
  • Principles: What are the non-negotiable rules and key strategies?
  • Priorities: What’s the framework for tradeoffs?
  • Plan: How are we going to stage and tackle solving the problems?
  • People: Who’s accountable for every key part of the plan?

It’s gratifying to see how this kind of framework can pay off. The readers of this blog will be in a position over the next few months to tell us if it’s paid off for the Windows Phone developer experience as it has for the user experience.

The developer experience team started with our purpose:

Our purpose is to harness the energy, talent, and attention of developers and designers with a platform and ecosystem that delivers on the developer experience end to end; that, combined with the phone’s end-user experience, results in a winning virtuous cycle.

We then wrote down a set of principles. Tenets or rules we would live by as we did our daily work. Frankly, I am not comfortable sharing all of our principles because I think they disclose too much of our long term strategy, and I’m not keen on letting our competitors know that. But I can tell you a few:

  • Every decision we make must be made mindful of the effect on end-users.
  • We will do a few things and do them very, very well; we are better off not having a capability than doing it poorly. There are always future versions.
  • No API will be created or documented without a clear use case; “build it and they will come” APIs almost always do nothing but create bad legacy.
  • We will build on the shoulders of giants; where possible integrate instead of create.
  • We will strive to not show our organizational boundaries to developers.

The most critical tool you can give small independent teams of creative people is a list of clear priorities. Such a list lets people make independent decisions rapidly knowing that they can justify those decisions later on.

To illustrate this I’ll call out something another mentor of mine taught me about leadership:  “90% of the decisions don’t matter; real success comes in being able to identify the 10% that do and focus on them.”

For the Windows Phone developer experience we had several things to prioritize.  For example, we prioritized the developer segments we would target:

  1. Consumer Developer - Pro Devs who build products that are sold directly or given out for free to general public end-users.
  2. Non-Pro Developer - Non-Pro Developers building products for academic/personal use.
  3. In-ROM Developer - Pro Devs who build products & technologies that are sold to mobile operators or device manufacturers.
  4. Enterprise Developer –Pro Devs who build apps & technologies that are sold to corporate clients and businesses.
  5. IT Developer - Pro Devs who build apps & technologies that are only for use by their own corporation.

It may be pedantic, but it’s important to call out that the way you read a prioritized list like this is top down.  Priority 1 is higher priority than priority 3, but that does not mean priority 3 isn’t important. It’s also worth calling out that prioritization is temporal.  Over time (e.g. for subsequent releases) it is perfectly fine to change priorities.  We did this with Windows Home Server.  For the initial release the scenario priorities were:

  1. Backup
  2. Centralized Storage
  3. Remote Access
  4. Entertainment

For Power Pack 2 the priorities were adjusted:

  1. Remote Access
  2. Entertainment
  3. Backup
  4. Centralized Storage

For Windows Phone, we fully expect to adjust priorities in future releases.

Creating this list within the context of the overall Windows Phone strategy was fairly easy. Getting people to understand it and live it was harder. But once it was understood individuals, feature crews, and other groups could use this list to more easily identify which decisions & issues were in the 90% bucket and which were in the 10% bucket.

Continuing the example (and this is just one example meant to be illustrative) a feature crew deciding where to invest their time/resources could easily make tradeoffs.

“We know we can’t do both Feature A and Feature B because we can only do one of them really, really well. Feature A is something most useful to Enterprise Developers. Feature B is most useful to Consumer Developers. The decision to do Feature B is easy because we are supposed to prioritize Consumer Developers higher.”

The feature crew could make this decision independently of “management oversight” because the framework was clear. There was no need for seeking approval.

I don’t know of any secret to dealing with the “10%” bucket. It’s just hard work. But at least the noise is removed.

We had similar prioritizations for areas such as app types, technologies, scenarios, etc… This proved super helpful and really helped us to be able to say “no” as well as focus on was really important.

The plan was relatively easy to create. First we knew the overall top-down schedule for Windows Phone itself so that provided boundaries. We also knew there would be a MIX conference this spring. This gave us a great forcing function. Invite thousands of people to a big event and you better get your sh** together. By the way this is another trick another mentor of mine taught me:  Events are great forcing functions for engineering teams.

Last, but not least, in the 5Ps framework is the people. One of the things that I’m most proud of, and most excited to see the real results of, in building Windows Phone 7 Series is how we’ve aligned an incredibly diverse set of people from across all of Microsoft to build the product. From the Xbox folks to the people in Developer Division. To people in Windows Live, Exchange, Windows, Office, and DPE.

My intent in writing this tome was to re-cap how we’re changing our game based on organizing and structuring our work in extremely focused ways. It starts with “end-user is king” and it’s not just about the phone user experience, but about the core changes we’re making to the phone ecosystem. Those changes are only possible through being extremely disciplined about principles and priorities.

Hopefully as we get closer to being able to show you all the details this will provide useful context and insights. My next post will be about the definition of “application”… I’ll try not to make it so long. :-)