The 6Ps is a useful framework for tackling problems and crafting durable solutions. The 6Ps are Premise, Purpose, Principles, Priorities, People and Plan.
J Allard introduced this approach at Microsoft in the 90s. His framework didn’t include Premise, so it was called the 5Ps. J’s conjecture was that any successful project eventually lands on the 5Ps—and the best projects do it up front.
I use this framework all the time, and not just at work. Whenever I’m crafting a plan I think about the 6Ps. The 6Ps work for big things like shipping game consoles to little things like organizing your garage. They work for organizations, for projects and for life goals. The most important Ps are also the hardest to get right: purpose and principles.
Here’s a quick example to make it real.
The Garage
Premise: The garage is a disaster. There’s no room for the car, and it’s hard to find the things we use.
Purpose: Permanently park the car in the garage while making it easy to find the garden tools.
Principles
- Minimalist: Embrace living with less. Be willing to throw stuff out that we never use.
- Organize for Efficiency: Put the things we use regularly where they’re easiest to find.
- Low-cost: Do the work ourselves—or get the kids to do it!
- Enduring: Assume we’ll acquire new stuff that needs to be integrated into the solution, but without losing space to park the car.
Priorities:
- Parking the car in the garage
- Access to garden supplies
- Getting rid of stuff we don’t use
- Cost efficiency
People: Me (Directly Responsible Individual), spouse (Involved), kids (Assigned)
Plan: If we haven’t used garage item in 5 years, donate or toss. Spend May weekends cleaning. Spend June organizing. Park the car in the garage permanently no later than July 4.
For a small project, you can see that the 6Ps fit on a page. For a large project, the first four Ps should still fit within a page or two, but People and Plan can vary depending on the scope of the project.
Premise
The Premise defines the Why. The Premise describes the current state, the lay of the land and why the issue is worth solving. The Premise includes the problem statement, but also provides background and context. Defining the Premise first is important because there may be multiple solutions, so it can be worth reminding yourself of the context periodically. Ensure your team and/or customers agree the Premise is well defined before moving on to the Purpose.
Purpose
The Purpose defines the Goal. The Purpose is short and simple, no more than a few sentences. It’s the north star, the deliverable and the mantra for the team. It can be the mission statement, and like a good mission statement, it should be easy to remember—although it’s often challenging to formulate. The Purpose informs your team, your stakeholders, and your customers about the reason you have a Plan. Examples:
Project/Product/Company | Purpose |
Google Chrome | Provide users with a fast, simple, and secure web browsing experience |
NASA’s Gemini program | Demonstrate the ability to orbit and maneuver manned spacecraft, rendezvous and dock with other spacecraft, and practice reentry and landing methods |
Original Star Wars film | Create a new kind of science fiction movie that is broadly appealing, pushes the boundaries of filmmaking technology, and promotes values such as courage and the struggle with tyranny |
Sonos company | Fill every home with music |
Principles
The Principles define what’s truly important for success—and what’s not. Principles create guardrails for the project. Principles are sacrosanct. Principles help the team make quick and durable decisions. Principles define how the team will act. Principles create a shared consciousness within the team that allows the project to continue even if leadership changes. When the Plan needs to change, Principles help ensure that the Plan still addresses the Premise. When new people join the project, Principles are the most important thing for them to internalize. Principles are sometimes called tenets or core values.
Principles often involve deep discussion with stakeholders and customers. For example, should the product be high price and high quality but lower market share (principle: high quality), or should the product be lower price/quality but larger market share (principle: broad reach).
Principles are often adjectives or descriptive nouns. They can be single words or short phrases. Sometimes principles may conflict (see Priorities). A list of some potential principles appears below. All of these are valid, but they’re presented as inverse pairs to highlight the tradeoffs that come with good principles.
- High Quantity/High Quality
- Unfiltered/Curated
- Inclusive/Exclusive
- Experimental/Long Lasting
- Open/Closed
- Safe/Exciting
- Transparent/Protected
- Innovative/Comfortable
- Simple/Powerful
- Inexpensive/Boutique
- Minimalist/Full featured
When you think of popular products, projects and even successful people, you can often derive the guiding principles that led to their success:
Product/Project/Person | Principles |
iPod | Minimalist, portable, integrated |
Apollo space missions | Innovation, risk-taking, collaboration |
Disneyland | Storytelling, immersion, family-friendly |
Twitter/X | Conciseness, openness, real-time communication |
New York Times games | Approachable, rewarding, curated, short time well spent |
Dalai Lama | Compassion, non-violence, universal responsibility, inner peace |
Principles are important to get right because everything else is informed by the principles. Projects can struggle when principles are unwritten and develop organically over time. Ideal projects discuss and define principles early, then communicate them broadly.
Priorities
The Priorities define the important deliverables and the important customers. Priorities define how to make tradeoffs between conflicting principles. Priorities help control scope. Priorities can define the order in which things are done. Priorities can also indicate what’s not important (non-goals). Having clear Principles and Priorities enables teams to rapidly make decisions themselves. Prioritization is temporal and may change over the course of the project, but when priorities change they should be re-communicated to the team.
People
People includes everyone involved in the project. People includes ownership and accountability. The RACI model (responsible/approver/consulted/informed) is one useful framework for considering people for larger projects. The People component might also include roles that still need to be hired. People and Plan are usually closely related and often considered in tandem.
Plan
The Plan is the What. In the real world, people gravitate toward creating the plan first, but in the 6Ps framework the Plan is last. The Plan is informed by everything above. The Plan can change as long as it fulfills the Purpose, Principles and Priorities. The Plan includes milestones, dates, deliverables, and forcing functions such as conferences/events. The Plan can be complex and involve multiple approaches, but many other frameworks are available to help with this aspect.
More Examples
Original Xbox Console
Premise: Microsoft owns the office (“A computer on every desk”), but hasn’t made headway in the living room.
Purpose: Gain a competitive market share in the living room with an entertainment hub for gaming
Principles
- Bet on broadband: embrace multiplayer gaming and social connection
- Power and performance: smooth and immersive gameplay
- Developer friendly: easy to port from PC, great tools, APIs, docs
- Safe and secure: level the playing field; limit hacking, limit cheating
- Leverage existing investments: NT kernel, Win32, DirectX, Visual Studio
Priorities
- First party developers
- Third party developers, ranked by potential game sales
- Ship the console first, Xbox Live second
People: Build a team of experts from the gaming industry and from within Microsoft. Establish relationships with chip and hardware manufacturers to create a strong supply chain.
Plan: Ship a gaming console to compete with Sony and Nintendo. Ship a broadband multiplayer gaming service with secure networking.
C++ Language
Premise: There’s no programming language (circa 1980) that provides the performance of C combined with the abstractions of object oriented programming and generics.
Purpose: Deliver a general-purpose programming language with a bias towards systems development that supports data abstraction, OOP, and generic programming.
Principles
- Practical: useful, mainstream, easy to adopt
- Efficient: low-level control of system resources
- Zero overhead: you don’t pay for what you don’t use
- Compatible: a superset of C
- Portable: works across a wide range of platforms
- Object oriented: support reusable modular code with encapsulation, polymorphism and inheritance
- Flexible: support multiple programming paradigms (functional, OOP, generics)
Priorities
Features
- Encapsulation and inheritance (C with Classes)
- Polymorphism (virtual functions, function overloading)
- Generics: templates and exception handling
Customers
- Bell Labs
- AT&T
- Universities
People: Bjarne Stroustrup and other Bell Labs contributors
Plan: Build C with Classes and go from there
References
J Allard’s original model: The 5Ps: Achieving Focus in Any Endeavor
Robbie Bach’s simplified model: Learning the 3P Strategy Framework