Is your product becoming a house of cards?
A “framework” for communicating dependencies within your product experience.
TLDR: This ‘framework’ uses the metaphor of physical weight to help categorize parts of your product experience into three levels, each providing support for the next.
- The SYSTEM LEVEL is the foundation that enables customers to interact with your product as intended.
- The BASE PRODUCT EXPERIENCE is the main reason users are coming to your product, and this can be broken into two parts.
- EXTENDED is the level of localization or adding advanced functionality enabled by your BASE PRODUCT EXPERIENCE.
Creating new functions or localizing adds weight to your product. Adding ‘more’ when the foundation isn’t stable may cause the experience to collapse. Rather instead of adding value as intended, you may spend more time and effort to keep it running.
Context
I’ve spent the last three years designing global digital tools to be used in the agricultural industry. I have struggled to communicate the dependencies of features and how they relate to developing a cohesive product experience.
After many a meeting, I realized a pyramid “framework” to help illustrate the dependencies between features to ensure new functionalities contribute to a stable product experience.
Perhaps you have also been in conversations where it seems people are getting ahead of themselves. Hoping everything will “run” before you can get a product to “walk.” If so, read on!
This “framework” treats each new feature or function as if they each held weight. Each needing to be supported within your product experience or inevitably it will collapse.
The article below will introduce the three levels in what I have called the “product pyramid”– I welcome name suggestions.
Step 1: System-level
Some foundations need to be set to guarantee your users can engage with your product as intended, this SYSTEM LEVEL within the pyramid. This is the functionality and experience that enables your customers to interact with your product.
Incorrectly implementing this or skipping steps can lead to inevitable problems. Your product/experience collapsing for unclear reasons, or you may find your tracking data is unreliable down the road because the SYSTEM LEVEL experience was incomplete.
A few common examples.
• Sign-up / Login,
• Onboarding, customer support,
• Payment processes, edited account details
Step 2: Base Product Experience
The SYSTEM LEVEL supports the next-level BASE PRODUCT EXPERIENCE — I often refer to this as the ‘core functionality.’
The BASE PRODUCT EXPERIENCE is unique to each company and its context. It can help to split this level into two parts.
- Core Function(First-level experience)
This is the main reason users are coming to your product. - Supporting Function(Second-level experience).
This is what improves and supports your core function bring even more benefit to the base product experience.
These are the main reasons people are willing to sign up, use your tools, and recommend you to others.
Step 3: Variants | Extended
Once users can interact with your core functionality as intended, you can then make variations to the product experience.
The peak of the pyramid is the space reserved for adding additional benefits, making your product more valuable. Using the BASE PRODUCT EXPERIENCE, as the ‘baseline’ you can safely build from.
This is also where localizing a product based on local input or conditions fits very well. We need to build the BASE EXPERIENCE before you adapt it.
If we focus on the top without considering the supporting experience, the quicks ‘wins’ will often be short-term, with high churn, and even more work in the future.
How to identifying Variants | Extended functions?
Look out for features that are dependent on other functionality in order to work effectively, yet are adding additional value on top of the BASE PRODUCT EXPERIENCE.
“If we had X,Y, and Z we could enable ABC in a whole new way!”
At the very top of the pyramid can be the realm of ‘what if’, the ideas that could quickly send you down a rabbit hole if we first do not create the first two levels.
Two examples
I personally find examples very helpful so here are two I hope to help further clarify this “framework”. One from my experience in agriculture, and the second I will walk through the three steps looking at Miro a popular whiteboarding tool.
(1) My experience in agriculture.
Farming is a hyper-local practice. Which adds significant complexity when attempting to develop and scale a digital product. This is in part because what we build in one country, may or may not, work in the conditions of another.
By first defining a BASE PRODUCT EXPERIENCE, we can localize the tools to add crop calibrations and enable regional functionality. Making the tool even more valuable.
(2) Example using Miro
[Miro is “the online collaborative whiteboard platform to bring teams together, anytime, anywhere.”’
First step: SYSTEM LEVEL EXPERIENCE
— Sign up & Account creation
— Creating Whiteboard canvass
— Navigating between created boards
— Sharing boards with others.
Second step: BASE PRODUCT EXPERIENCE
A— Core function
The Whiteboarding canvas experience, and the overall experience of using the tool. This is the work environment for how to use the tool.
B— Supporting function
Collaborating with other colleagues within the tool, permissions and template files for customers to start with.
Third step: VARIANTS| EXTENDED level
Miroverse community for sharing customer-created templates.
Building the Miroverse without having the SYSTEM LEVEL l or BASE PRODUCT EXPERIENCE in place would eventually collapse. The Miroverse is enabled by having a core functionality that very works well. The customers then can find more benefits within the tool as a result.
To prevent building a house of cards, treat your features as if they each held weight. Each needs to be supported by either a system-level or base-level experience to prevent your product experience from collapsing.
Would this be helpful for you or improve communication in your teams? I welcome your thoughts and feedback.
