The value of prioritized product tenets

Many years ago, as a freshly minted engineering manager at Amazon, I learned of the value the organization placed on prioritized product tenets at the concept phase of every product. Over the years, both in engineering and product, I have come to realize how valuable these tenets are, and how essential it is to get the entire organization, leadership down to engineering and XFN partner teams to rigorously debate and agree on these tenets early on in the program.

So what are prioritized product tenets?

There are two critical elements to good tenets - they are prioritized and they are product specific. Prioritizing tenets early on allows teams to make the right tradeoffs when the time comes, often deciding between what impacts one tenet versus another. Having them prioritized allows teams to make that call. Tenets are also product driven. While tenets can be used by XFN teams to drive their own set of goals and objectives for the program, the tenets themselves are product specific.

What makes a Tenet?

A tenet is very similar to the Objectives in an OKR. They are specific, explicitly clear and measurable. The way Amazon structured its product tenets followed a standard template that looked like below.

Product Tenets of Product XYZ

These are the prioritized product tenets for Product XYZ.

1. Product XYZ will launch at scale at an MSRP of $$ by Oct 31, 2022 in all markets where Organization Services are available in online and in retail.
2. Product XYZ will have a BOM+MVA of $$ or lower and will be BOM positive at launch.
3. Product XYZ will ship with feature A, feature B and feature C at launch. All new features and core experiences will need to be at CSAT of 5.5 (on a scale of 7) in internal dogfooding with n>100.
4. Product XYZ will have a customer rating of 4.0* or higher on (online retailer) within the first 60 days of launch.
5. Product XYZ “flagship feature” quality will be as good or better than Competitor A, Competitor B and Competitor C at launch.

As is evident, these tenets are very specific, have a timeline associated with each of them and do not leave much scope for interpretation.

Tenets are valuable when they are good. They can also be grossly misused and abused when not defined well. So two elements are critical to set good tenets. They need to be defined early in the program (concept phase) and they need to stand up to the test of time (time here being the entire product development lifecycle). Product concept Leadership reviews with poor tenets (if they make it that far past all the preflights) will result in poor and often short meetings. Without good tenets, the rest of the concept proposal becomes ripe for misinterpretation and significant impact to engineering and financial resources. How often have we been in reviews where much of the time is spent interpreting what a leader said the last time the team met?

Good Tenets vs. Bad Tenets

Here are some examples of good tenets vs. bad ones.

Example 1:
Good Tenet: Product XYZ will have a BOM+MVA of $$ or lower and will be BOM positive at launch.
Bad Tenet: Product XYZ will be profitable in its lifetime.
Why is it bad? The definition of profitable is so subjective based on who you ask and when that it is impossible to pin it down for years, if ever.

Example 2:
Good Tenet: Product XYZ will ship with feature A, feature B and feature C at launch. All new features and core experiences will need to be at CSAT of 5.5 (on a scale of 7) in internal dogfooding with n>100.
Bad Tenet: Product XYZ will support feature A, feature B at launch and feature C soon to follow.
Why is it bad? For many reasons, having a launch date for a target is critical to focus efforts. “Soon to follow” is nebulous. Also lacking a quality bar means kitchen sink experiences are acceptable.

Changing Tenets Midstream

This is often the most controversial aspect of tenets. In long duration programs and v1 programs, there is a lot of discovery that happens after the concept phase and this can significantly change what is possible within the technology, schedule and cost framework of the program. Additionally, competitor launches during product development can also impact programs.

There is a school of thought that says a mid-cycle evaluation of product tenets can help with the changing nature of technology product development. There is another that says that the product vision at the beginning of the program should drive tenets which then should not have to change in reaction to stimuli, internal or external.

Personally, I think good high-quality tenets created through rigorous debate and product reviews early on in the program with leadership alignment can weather any incoming storm, anticipated or otherwise. In many ways, this is why good tenets are so valuable.

Making Tradeoffs

Good tenets are priceless when the time comes to make hard decisions. Tradeoffs are always hard and not having good prioritized tenets makes it infinitely harder to make good decisions. By prioritizing tenets, we are placing a value to each of them, thereby articulating which ones are more important when it comes to decision making. All tenets are important and critical - but in the event that a team has to make a trade, the prioritization should be all it takes.

In conclusion, I think there is much to be gained for any product of any size to have high-quality prioritized, product tenets set at any early stage for the program. Good tenets are hard to pin down, especially given the stark and objective nature of the language it requires. But once set, they serve as the North Star for the program. They can be internalized by all the team members and XFN partners and used daily to make product choices at every stage of the program. With the team aligned on a single set of tenets, it helps drive a focused effort to a successful product outcome.