This post is about how to achieve focus in any endeavor you embark on. That endeavor could be a software development project, a job search, or a phase in your life. I have personally found the tool I describe here (“The 5Ps”) useful both small projects (e.g. prepping for a VC demo/presentation) as well as large scale projects such as the Windows Phone 7 Application Platform.
(Update: April 6, 2012 – I updated this post with minor cleanup and edits.)
The most successful projects are focused. Rarely do things go well for teams that try to do everything, meet every demand, support every scenario. This applies to building cars, making shampoo, as well as software development.
I learned this the hard way. I’ve personally helped build some great products & technologies. I’ve also been involved in some stinkers. I’ll be the first to admit that while DCOM is (was?) interesting and cool, we (I) didn’t really understand who the customer was. It was a classic “build it and they will come” project and in the end the technology was overly complex and unsuccessful.
In that project, and others, the team did not have a framework that enabled us to focus our energies.
Back in late 2008, 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 commitment to clear prioritization & principles by the new leadership. In talking with Terry Myerson, Joe Belfiore, Henry Sanders, J Allard, and others I felt the passion for taking a focused approach. 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.”
While the long term success of Windows Phone 7 is yet to be determined, anyone who’s used it will tell you “Wow! It really is a great product!”.
How did we do that? What’s the secret?
The key is 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.
The 5 Ps : Purpose, Principles, Priorities, Plan, and People
In ancient times I worked for J Allard while we were building Microsoft’s Internet Information Server (IIS). J taught me tool that helps projects be focused: the “5Ps”:
- Purpose: Why do we exist? Why are we in business? Where do we want to be in the future? What will we deliver?
- Principles: What are the non-negotiable rules and key strategies? How will we act?
- Priorities: What’s the framework for tradeoffs?
- Plan: How are we going to stage and tackle solving the problems? What are the known dates & forcing functions on the calendar?
- People: Who’s accountable for every key part of the plan?
I cover each of these Ps below. To illustrate each I use how we used them within the WP7 Developer Experience team. The extracts below are taken from a planning document that was shared and referenced by the entire team during planning as well as execution.
Your purpose answers one or more of the following questions:
- Why do we exist?
- Why are we in business?
- Where do we want to be in the future?
- What will we deliver?
For the Windows Phone 7 developer experience our purpose was:
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.
When you write down your purpose try to be a concise as possible. I actually think the example above is too long, but for a largish project like WP7 it worked fine.
Here’s another example to illustrate: Today I helped my daughter write her plan for an internship she wants this summer. I taught her the 5 Ps and for her “Purpose” she wrote:
To get real experience with and learn about the medical science.
You may already have a “Purpose” for your project. Some people call it a “Mission”.
The principles you agree on will enable everyone involved to know how to behave throughout the endeavor. They are laws that shall be followed by everyone involved.
- What are the non-negotiable rules and key strategies?
- How will we act?
- How will we treat others?
As with our purpose, we wrote down a set of principles for “wp7dev”; tenets or rules we would live by as we did our daily work:
- 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.
Call them mantras if you want. A good leader will continually re-enforce these principles (by leading by example and through written & oral communications) with the team.
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.”
(I’ve subsequently written an entire post titled “90% of the decisions you make don’t matter”).
For the Windows Phone developer experience we had several things to prioritize. For example, we prioritized the developer segments we would target:
- Consumer Developer - Pro Devs who build products that are sold directly or given out for free to general public end-users.
- Non-Pro Developer – Non-Pro Developers building products for academic/personal use.
- In-ROM Developer - Pro Devs who build products & technologies that are sold to mobile operators or device manufacturers.
- Enterprise Developer –Pro Devs who build apps & technologies that are sold to corporate clients and businesses.
- 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 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.
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 to seek 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, geographies, scenarios, etc… This proved super helpful and really helped us to be able to say “no” as well as focus on was really important.
A little aside on enabling teams to be able to say “no” – if you are a leader, you have to be disciplined at saying “no” too. But you also have to use the principles & priorities of the project to not put the people you are leading in a position where they continually have to say “no” to you. Don’t be the kind of leader that is continually asking the team to do new things mid-way through the plan. Which is a great lead-in to…
The plan is your top-down schedule. It describes how you are going to stage and tackle solving the problems. In the framework of the 5 Ps the plan should be “top-down” and not “bottom-up”; a detailed bottom-up schedule should be used to determine whether work should be cut (using your principles & prioritization as a guide) or scoped back or (never happens) added.
A top-down schedule starts with a end-date. They are best visualized as a timeline that starts with today and ends with whatever point in time the endeavor you are embarking on is “done”. For Windows Phone 7 the end-date was “Launch in the Fall of 2010”. The start-date was May 2009.
The top-down schedule should include all “known” dates. Things that are immutable like holidays and conferences should be included. These are things you know you will have to work around and I’m always stunned when I see people haven’t put them on the timeline.
The plan should also include important milestones. For example, for my daughter’s summer internship, we agreed she should have a “mid-summer” check-in where she would meet with her boss.
For WP7 the top-down schedule was relatively easy to create. We knew the overall top-down schedule for Windows Phone itself so that provided boundaries. We also knew there would be a MIX conference in the spring of 2010. 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 to get their sh** together.
Last, but not least, in the 5Ps framework is the people. Writing down who is responsible for what (and as importantly, not responsible for what) will help you make sure everyone knows who’s accountable for every key part of the plan.
There are tons of frameworks/tools for helping people understand roles & responsibilities. At Microsoft I used a bunch of these. They can all be made to work, as long as you don’t over-do it (just like you should not over-do the 5 Ps). To illustrate how to think through the people part of the 5 Ps, I’ll use RACI:
- Responsible – The individual(s) who do the work to achieve the deliverable.
- Approver – The one (and only one!) person who is ultimately answerable for the correct and thorough completion of the deliverable. (I don’t like using “Accountable” for this because accountable is an overloaded word and I want everyone to “feel” accountable).
- Consulted – Those whose opinions are sought; generally via two-way communication.
- Informed – Those who are neither responsible, accountable, or consulted; but told.
Use whatever tool you want, but you do need to explicitly write down the names of individuals for each part of your plan. Avoid naming groups such as partners; if I can’t identify a person I usually view that as a red-flag and something that needs to be followed up on.
It is really helpful (and I’ve found it liberating) to also write down explicitly who’s NOT accountable. The “Informed” bucket is great for this. If Sally is responsible for widget A and widget A has no dependencies with widget B Sally will actually find it liberating if she knows the people responsible for widget B don’t expect or want her opinion or help.
I’ve applied the 5 Ps many times for personal and professional projects of all sizes. I find it a really useful framework when getting started and people who’ve worked for me have told me that it has helped them focus and be successful. Hopefully you’ll find it valuable as well.
But remember: The 5 Ps is just a tool. There other tools you can use to achieve similar ends. Like all tools don’t over-use them.
Related posts on focus and decision making: