5 Ws and H of the Product Cycle

There’s something that we build during a product cycle that is even more important than any single release, and that is the team.

Note. This work originally appeared in the book One Strategy: Organization, Planning, and Decision Making co-authored with Marco Iansiti, published in November 2009. The post itself was originally authored in February 2008 for the internal Microsoft blog I maintained. Some minor edits were made for this version.

Even as we talk endlessly about shipping code, there’s something that we build during a product cycle that is even more important than any single release, and arguably more important to the company, and that is the team. Along with building the product, each release gives us an opportunity to build our team. Like building the product, building the team is something that is never “done” — building the team requires the same focus on the long term, consistency of purpose, and commitment to greatness that we normally ascribe to building out software. Product cycles allow us the chance to go through the whole “story” from beginning, through the middle, to the end. Like any good writer (or good actor in the theater) practice leads to perfection and so we should think about how we get better each and every performance. And like any good story, we should have a strong structure in place to tell the story.

So it might help if we treat a product cycle like a news story and think about the 5 Ws and an H. This structure is an appropriate way to think about the product cycle since we are after all creating a story, or narrative, for customers which they experience by purchasing out product (a great example of this can be seen in the current BusinessWeek article Building the Perfect Laptop, which also happens to be a good story about innovating with a plan and clarity). As I was reading this story I was reminded of the narratives we have been developing for Windows Live, IE 8, and Windows 7.

In future posts I hope to return to this metaphor but for now let’s have a brief look at these six components of a great product cycle:

• Who — It all starts with who we will build the product. The qualities of each person on the team brings and the values each member of the team represents. We want diversity of thought and background combined with a consistency of execution — maximizing the contribution of each and every member of the team. Who also starts with the tone and style of the senior leaders of the team. As we’ve talked about many times, the importance of our group managers in how they represent the best of the qualities we wish to have as a team and how they run the team is really paramount.
• What — Choosing what product to build is where the planning process guides us. I think it is fair to say that historically we have focused nearly all of our energy on this question. Most of the “fights” and “disagreements” happen over what we will build. Most of the tension happens over wanting to build more than we have. Of course what we build is insanely important, but I am also a believer in the role of the planning process to bring out a very solid set of ideas that we commit to. The idea of the planning process is to front load the “conflict” so we can execute smoothly, and more importantly so we can focus our execution on execution, which is itself super hard.
• Where — Certainly some could consider where to be the location of the team, but for me where represents the business proposition of “channel” (commonly referred to as “place” in the 4 P’s of product management or the marketing mix). Every product must meet the needs of different customers (individuals, enterprise, developers) who acquire the product through different channels (retail, OEM, solutions providers, VARs). As we develop a plan, it is keenly important that we clearly understand this aspect of the plan. This too is often thge source of tension and challenge. Microsoft has dedicated field and business folks for a plethora of channels and segments, and each one wants an entire offering for their area. Often this feels a bit like slicing up a pie, and more often if feels like our pie just isn’t big enough. So like all aspects of the product cycle, this is another one where front loading the discussion allows us to execute against a plan we know by definition is not perfect for everyone.
• Why — Why will customers like the product we will build? We need to know this of course when we start, but we also learn a lot along the way. They key thing we must establish at the start of a product cycle is a clear sense of purpose for the release. This is expressed in the vision, but more often than not when we tell the story of a product we will lead with why did we build this product. It is especially important when customers are satisfied with the product they have or at the other end of a spectrum when customers feel like there isn’t much of a reason for Microsoft to update (or customers to upgrade) to a new product. It is important that this be an emotional connection with customers and not just restate the features (what we built) as that does not reflect the context of skeptical customers.
• When — Clearly all product cycles have a schedule. Like many news stories, the when is pretty straight forward and I think the schedule is straight forward too. We pick a date and get into execution mode on the planning and the plan. Also like news stories, the place we don’t want to spend creative energy is on the date. I was recently on a mail thread with someone asking when will Windows 7 ship (someone who does need to know). In a pretty vicious while (TRUE) do {} loop I kept referring to the vision statement, but this person was convinced there is another schedule with extra buffer time hidden away. Believe me, that definitely isn’t the case!
• How — The processes and organization we use to build the product represent the how. Like Gilligan’s Island’s “and the rest”, how is often the forgotten aspect of a story. How is complicated and detailed. How requires domain knowledge. How isn’t often very fun to talk about. On the other hand, how can also be distilled down to an over-simplistic view that leaves out details just so the story can be told. Without a great understanding of how we will build the product, the other questions don’t matter. In fact, a great how can often make up for missing story elements. But missing the processes and organizations, the best you can hope for is a non-sustainable burst of success (a super creative idea that requires heroics to get out the door leaving a trail of bodies along the way, so to speak) — the essence of repeatable success is knowing how to build an organization, processes, and procedures.

That is why I believe when we RTM/RTO we certainly celebrate accomplishing what we set out to accomplish. But we have also shipped a version of our team. Teams are built release over release, just like software is built.

Building our team and working to improve how we build our services, browser, and Windows has been about trying to make sure we have a fantastic 5 W’s that our customers, partners, and the press (and bloggers) will care about, first and foremost. But focusing on the How is the real test of growing our team and growing our capabilities. I feel that without our deliberate efforts at improving how we build our software we will not ship a sustainable engineering organization. We are here for the long term and that means building an organization that has the skills and capabilities that go beyond any single product release.

My simple view is that if we can RTM a great team, then we will be able to take on even bigger challenges, harder technical problems, bolder competitors, and more sizeable business goals. Having the ideas and strategies to do those are necessary, but without an always improving team those ideas are just trees falling in a forest that no one hears.

Our team should feel super proud of the work we’ve done to develop the story behind the release and should feel very good about the progress we’ve made on improving how we engineer our products.

— Steven