Axioms and Anchors

A Lightweight Framework to Enforce Product Focus

This was originally posted on Axioms.io. The principal author is Dieter Shirley, Senior Engineer and Architect at Axiom Zen, previously Head of Development at Atimi Software and Senior Software Engineer at Apple Inc.

The greatest products are those that have clear and well-articulated benefits for their users.

Keeping those benefits in mind allows decision-makers to maintain product focus. Each and every decision that is made, each and every feature that is suggested, must map directly to the core essence of what the product endeavors to achieve.

“Clear and well-articulated” is a relative term: In a perfect dictatorship, The Big Vision can exist inside the heads of the leaders so long as they can effectively weigh in on every detail. In most companies, however, each person owns their own responsibilities, and makes their own decisions on how to move forward to some degree.

In a low-hierarchy, decentralized structure, important decisions are very often made at the periphery of the organization, meaning it’s more important than ever to keep everyone on the same page. In such a structure, “clear and well-articulated” often means written down, with buy-in by everyone. (Literally “on the same page”!)

When I worked for Apple, we used the term “Tent Poles” when referring to the features in a product that deserve special mention and drive adoption. At Axiom Zen, we built upon that concept and have developed a framework around “Axioms and Anchors” that reflects our unique approach.

The word “axiom” means something that is accepted as a fundamental truth; the Axioms we select to direct a product release are those truths we believe are fundamental to its success.

Every product or major release should have a small (but non-zero!) number of Axioms which define what makes the release interesting, unusual and great. The ideal number is two or three: Without a couple of Axioms, the application risks being perceived as pointless or “me-too”; with too many, the product (and the message) is not focused.

Axioms are aspirational, but no product will succeed without also being realistic. “Anchors” is the term we use to refer to various considerations that are to be taken into account, without driving product direction. Anchors represent the grounding realities we need to address. Most products share some default Anchors (listed below), but many have additional constraints specific to that release that need to influence the overall design. Axioms and Anchors are rarely individual features, and often represent ideals that touch every aspect of the software.

Common Anchors:

• Table Stakes — Features that would be conspicuous by their absence (like a spell-checker in a word processor)
• Revenue — Features required to fund the product or business, could be ads or direct payment. Note that if the particular channel or method of attaining revenue is resource-intensive or strongly differentiating it might be better categorized as an Axiom. Or perhaps it should be reconsidered entirely!
• Visibility — Systems for tracking our own success and failure. Analytics, performance-benchmarking, and crash reporting are examples.

The goal of defining Axioms and Anchors is enforcing product focus. Each and every item on the feature list must directly address one (or more) of the Axioms or Anchors. If they don’t, they are wasting valuable energy that should be used to improve the core product. Put ’em in the back-log!

Remember, your product is a small part of your customer’s life, and they will choose a short-list of attributes to describe it — to themselves as well as to their friends and social networks. If you don’t enforce clear attributes when building the product, you may not like the ones your users choose after you ship!

If you enjoyed this, please tap the recommend button below.

We’d love to hear from you: @AxiomZenTeam or info[at]axiomzen.co