The Minimum Viable Product Constitution: How to Document Core Product Principles and Best Practices

Last week I published an article about why organizations should consider creating and implementing product constitutions as a means of communicating best practices and defining processes for things like conflict resolution, roadmap prioritization, and making major product decisions across an organization---and in turn, how a constitution could reduce friction, confusion, and ambiguity by increasing transparency and accountability across teams.As a follow up, today’s post is all about how to go about establishing a basic product constitution that can grow as your organization grows.

[bd_table]In This Article:

• The Minimum Viable Product Constitution
• Terminology
• Charter
• Membership
• Fundamental Principles
• Product Decision Process
• Escalation Paths for Conflict Resolution
• Amendments

[/bd_table]

The Minimum Viable Product Constitution

If done well, establishing a product constitution, or set of guiding principles and documented product management processes and procedures, will ensure that your organization’s approach to building products will outlive any single employee or product lifecycle--they may even outlast one of the few creatures left after a nuclear attack.The depth, specificity, and format of your product constitution will likely depend on factors like the headcount of your organization, the number of products in your portfolio, and possibly even the stage of your company. A well-rounded product constitution should convey core product principles by clearly outlining things like key business objectives, leadership and organizational structure, major stakeholders, processes for conflict resolution and major decisions etc. But your first version does not need to be that extensive; a bare bones product constitution could be as simple as a running list of best practices for product development that are specific to your organization.However, if you want to draft a “minimum viable product constitution” that can grow and adapt with your organization, you’ll want to cover several sections including terminology, charter, membership, fundamental principles, decision making, conflict escalation paths, and amendments.Also, a quick note on length: strive to keep each section as brief as possible while still addressing likely situations. This document should serve as a guide, and if you want people to keep using it, you absolutely must keep it manageable. As a friendly reminder, you’re not laying down the law for a government and its people; and as reference, the United States Constitution is the “shortest written Constitution of any major government in the world” at 4,400 words. Just sayin’.

Terminology

This section of the should define any key terms that are used throughout the document, especially those that may be ambiguous or uncommon. The terminology section is all about clarity and setting the stage for a common understanding. The Beatles and Elon Musk agree on this point: the words you use matter, so define them before someone else defines them for you.

“Her name was Magill, and she called herself Lil, but everyone knew her as Nancy.” -Rocky Racoon, The Beatles

yes! it really does hurt communication RT @collision: .@elonmusk on the spread of unnecessary acronyms inside SpaceX pic.twitter.com/pbONEozz4l

— dave johnson (@davejohnson) May 25, 2015

(Another reference)

[Epilogue: In spite of Musk’s admonishment, the list of acronyms remains significant. Maybe establishing acceptable terminology up front would have helped?]

Charter

What are the goals and objectives of your product constitution and what is the context in which it will be used? For example, will it be used by the product leadership team to make high level product decisions? To establish overarching success evaluation criteria? To resolve cross-functional disputes? Define the context and boundaries.This is also a good time to be explicit about the charter of the team that will be using the document. Very often, organizations are lackluster at explicitly connecting high level corporate strategy with tactical execution. The group that is beholden to the product constitution should have this as part of their charter; they should not be a strategy-only group, they should also be the guardians of that corporate strategy and how it plays out in the trenches of the company.Steven Haines provides another type of process that may benefit from this charter: lifecycle product portfolio management, which according to Haines is the “ongoing, multi-dimensional, multiphase, decision-making methodology that allows a business to achieve strategic, market, financial and operational balance across each and every product in an organization, across all life cycle phases.”In that case, your product constitution fills the role of product portfolio management, linking the corporate mission and vision and cascading the output of the strategic planning process throughout the organization. It ensures strategic alignment. Haines concludes, ““[M]any companies do not adequately consider the connection between top-level strategy and lower-level execution.”Finally, Haines also makes the case for a cross-functional product review board which is a “senior level, overarching decision-making governing body, guiding and prioritizing product investments for existing products, products in development and product projects in various planning phases.” This is the group who should be tasked with making decisions that cut across products and functional areas of the organization, using funding and staffing levels as their key levers for setting direction and effectively implementing decisions. In order to be effective, they must have a sense of what is really happening within the operational teams. Therefore, they need to be in close contact with the operational teams, and should meet frequently enough to keep the pulse of the work and oversee overall progress.

Membership

Explicitly define who will be using the constitution, and in what context. Is the team one which can live up to the charter, and vice versa? Does this team have the authority and power to enforce the charter? If not, fix that misalignment by either changing the charter or rejiggering the membership makeup. Your product constitution will turn into a worthless pile of pixels if team members are toothless and gummy.Since specific people will come and go, it’s wise not to include people’s names in the constitution, but rather identify them by title or role. Be as specific as possible. “EVP of Product” is better than “Whoever is Leading the Product Organization” or “The Bobs.” If you have five Vice Presidents of Engineering, be explicit: which one of the five? All five? Does membership rotate?Membership will most likely consist of a cross-functional team, with representatives from each core corporate function. [bd_table]For example:

• Product Management
• Product Development
• Research & Development
• Engineering
• IT
• Marketing
• Product Marketing

• Sales
• Finance
• Operations
• Client Services
• Technical Support
• Legal / Regulatory
• Manufacturing

[/bd_table]In The Product Manager’s Desk Reference, Steven Haines suggests creating three levels of membership: Dedicated Core Team, Associate or Extended Team, and Advisory Members.

• 1. “Dedicated Core Team members bring one member per functional organization, authorized to make commitments on behalf of their function to the product team. These members are accountable for meeting the agreed-upon goals for their functional area.”
• 2. “Associate or Extended Team members are part-time... members. They are usually subordinates of Dedicated Core Team members and may be dedicated to a particular product or product project. They are not permitted to make final commitment on behalf of their function.”
• 3. “Advisory members are those who are called in to participate on an as-needed basis because they represent their organizations to many different product teams. Organizations like Legal, Regulatory, PR, Training are examples of Advisory members.”

Or, you could use a RACI matrix to further define roles and responsibilities. Who is Responsible or Accountable for what decisions? Who will be Consulted? And who needs to be Informed of the proceedings?

Fundamental Principles

Fundamental principles are the articles that define what an organization believes in. They may be as generic or specific as you like. This section effectively lays out core concepts which you want to institutionalize.[bd_table]Subjects might include:

• Core business focus
• Customer and Market focus
• Development approach
• Distribution channels
• End-of-life process
• Financial goals and financial ratios
• Go-to-market strategy
• High-level Marketing mix
• Loss-leaders
• Market Segmentation
• New Product Development

• New Product Introduction
• Personas
• Primary and secondary target audiences
• Product Business Cases
• Product or Feature Feasibility Assessments
• Profitability & profit margin
• Release cycles and release timing
• Strategic Planning cycles
• Strategic Product Planning
• Target Market
• Timing and Scheduling of Annual Key Events

[/bd_table]

Product Decision Process

There are a lot of ways to make decisions. Let’s assume, for the sake of this post, that we want to have a methodical, repeatable, transparent process. Let’s further assume that we want decisions to be largely driven by data and metrics, and let’s keep assuming that we have access to that data in real- or near-real-time.Now comes the fun part, defining a model which will enable the team to prioritize the issues and which can be used to both make decisions and resolve disputes. Creating a model that everyone can get behind is usually the most difficult part of the process, and it is through the process of creating one that the true “values” of the organization should become apparent. For example, are criteria related to sales and profitability weighted more heavily than those related to innovation or charting a visionary, envelope-busting course? Once there is a model in place, it becomes a more data driven (and constructive) discussion.For the purposes of your product constitution, you’ll likely want to decide whether to codify a very specific model for prioritization (including particular criteria and their relative weights) or to focus on outlining structured “guides” for teams to use as a foundation. There is a very strong argument to be made for including details and criteria in this document. Point #1, it increases transparency because the specifics are written out for everyone within the organization to see. Point #2, it increases consistency and accountability because once written into the Constitution, the criteria cannot be easily changed or manipulated. They can be changed, but not capriciously.Going back to Mr. Haines’ and The Product Manager’s Desk Reference, the list below contains a few types of portfolio-level decisions you need to be able to handle.[bd_table]Portfolio-level product decisions to prepare for:[line_list]

• Should products in development be cancelled?
• Should a mature product be revived?
• Should we focus on investments to increase market share?
• Should we invest in a more diverse set of products so that we minimize our exposure to risk in a given product category?
• Should we invest in improving the product’s name recognition in a limited geography?
• Should we invest in cost-cutting for a product line?
• Should we invest in other marketing mix elements, new distribution channels, or more advertising or promotion?
• Should some products be discontinued?
• (And on and on and on and on. And on. Etc.)

[/line_list][/bd_table]Carefully consider the metrics and criteria needed to support these types of decisions.

Escalation Paths for Conflict Resolution

If product teams have problems, what’s the escalation path? Who needs to be involved in resolving issues that impact multiple teams? What should you try before escalating the issue? What types of issues fall into this team’s purview? Spell it out. Teams will then understand just how much they are expected to resolve on their own before bringing their problems to the so-called adults.

Amendments

Finally, you must identify a way to keep the document current. Establish a process for updating it that is flexible enough to allow compelling updates, yet not so open that it can lead to manipulation or abuse of power.

Does your organization or team follow a set of guiding principles for product development? How does your system work?