Cognitive principles for building products and prioritising roadmaps
This week, we go deeper into some fascinating aspects of product design and critically, how to go about figuring out what to build first.
We hope there are some useful things for you to take away!
Image: UX Collective
Applying cognitive principles and biases to building products
Designing brilliant product experiences is challenging but understanding and being able to apply principles from other disciplines can go a long way to making the leap from good to great. Psychology is one such field that has long influenced the tech industry. It's a fascinating area of product design and it can become quite easy to end up down a rabbit hole. So, we have summarised a few of the most interesting cognitive principles and biases.
1. Aesthetic-usability effect: Users have a tendency to perceive attractive products as easier to use. The lazy thing to conclude from this would be that when designing a digital product, you need to go all-in on the UI with all sorts of bells and whistles. It is probably not advisable to take this to its extreme though as there are diminishing returns to investing in design.
Instead, think about what's good enough - where is the rough tipping point where your design is visually pleasing enough to lend itself to being "easy to use"? Aim for that and crucially, know when to move on (user testing is your friend!).
2. Variable Reward: People find great pleasure in spontaneous rewards. In fact, the anticipation can be just as powerful as the reward itself. There is one man who exploited this brilliantly to invent one of the world's most ubiquitous smartphone gestures. Enter Loren Britcher: the former Twitter engineer and creator of the pull-to-refresh gesture. Do you ever recall mindlessly pulling down to refresh repeatedly on social media apps? This is the brain craving the dopamine hit from a new like, comment or funny meme in your timeline and not knowing what you are going to get or whether you are going to get anything at all only serves to heighten this experience.
Clearly, this idea can be used to create behaviours which may not be in the long-term interests of people. It goes without saying that companies and product teams have a responsibility to act in good faith.
3. Weber's Law: Users adapt better to small, incremental changes. One of the things that product teams always worry about is whether a new feature might detract from other areas of the product or tank key metrics. The latter is of particular concern for products that drive significant amounts of revenue where mistakes can mean millions in lost revenue.
There are a few ways to circumvent this:
- A/B test new features (this can be done even as far back as in the discovery phase via 'fake door' buttons or pages, for example)
- If A/B testing is not possible due to time to result or some other reason, you can roll out the feature to a small % of the user base and monitor results before you slowly scale up towards 100% over time
- If you are practising agile as intended, a large feature (or epic) should be delivered incrementally anyway and releases should be independent of each other. So, think about how to structure your releases in a way such that users are being educated or primed for future releases and in a way that maximises your learning before you roll out additional features.
4. IKEA Effect: People place a disproportionately high value on the fruits of their own labour (hence the reference to IKEA!). For those interested, here is more detail and a link to the often-quoted study where this was observed empirically.
This same principle can be applied in the digital realm. Are there ways in which you can give users some semblance of control so that they feel like they have 'created' or 'invested' in your product and therefore there is a perceived cost to churning or going elsewhere? Products that naturally lend themselves well to this are social media apps, note-taking or productivity apps where users have usually spent time curating a profile, knowledge or workflow but that's not to say this can't be applied to other categories!
Now's a good time to revisit how you prioritise
Prioritising the right things to go after has always been incredibly important for product teams but it is arguably more important now than it ever has been. So, we thought it would be useful to revisit some frameworks for organising your thoughts and making decisions methodically.
1. Impact/effort matrix: This is one of the most popular and straightforward ways to prioritise features or initiatives and works well when a product is early-stage and you are looking to do prioritisation with a wider group quickly. This technique can be used to leverage the wisdom of the crowd to get a relative sense of priorities before honing in on the high priority items identified with some of the other frameworks below.
2. Kano Model: The Kano Model is a framework that is solely customer focused and this is what makes it somewhat unique compared to the others on this list. The model is used to bucket features into three groups: 'basic', 'satisfiers' and 'delighters'.
- Basic: These are features are non-negotiables that customers simply expect your product to have. For example, anyone buying a laptop today would expect it to have a built-in webcam. If these features are lacking or fail to work as expected, it can quickly lead to immense dissatisfaction.
- Satisfiers: These are features that give customers a proportionate increase in satisfaction as you invest in them. For example, the better the processor a laptop has, the faster it will be when doing tasks. In other words, the more, the better with satisfaction increasing almost linearly.
- Delighters: These are things that elevate your product to the next level. They are usually features that customers don't even know they want but when they experience it, their satisfaction blows up exponentially. Face ID when it was launched on the iPhone is a good example of this.
What the Kano model also states is that, over time, features cascade down the groups: features that once delighted customers will eventually become performance features and then finally, basic features that customers simply come to expect.
3. RICE: This is an acronym for Reach, Impact, Confidence and Effort. Unlike the other frameworks on this list, this one is quantitative and encourages product teams to be more deliberate.
- Reach: How many customers will be impacted in a given time period? Is this a feature that 100,000 users are expected to interact with in the next quarter or only 10,000?
- Impact: This usually refers to a key metric such as sales or conversions. A scale can be used here: 3 for "massive impact, 2 for "high", 1 for "medium", 0.5 for "low" and 0.25 for "minimal".
- Confidence: It is important to factor in the level of confidence about all the estimates that you are making for reach, impact and effort. Here 100% is "high confidence", 80% is "medium", 50% is "low" and anything below this probably needs a rethink.
- Effort: This aims to capture the effort needed from all members of the team who will deliver this feature and is usually measured in terms of person-months (the work that one team member can do in a month). For example, if a project takes 3 weeks of planning, 2 weeks of design time and at least two months of one engineer's time, that could be an effort score of 4 person-months.
Once you have all these estimates, they can be plugged into the following formula:
Reach, Impact and Confidence are on the numerator because as they increase, the feature is more desirable (and so the RICE score should increase) whilst an increase in effort is in the denominator because as it increases, the feature becomes less desirable and the RICE score should decrease. Once you have calculated RICE scores for all features under consideration, you can compare the rankings and relative scores.
4. Cost of Delay: This approach blends together two different concepts that people often confuse: value and urgency. Value can be defined as the economic benefits of a particular course of action whilst urgency is how fast the value of a particular course of action declines with time (the quicker it declines, the more urgent it is). It is worth noting that something can be valuable but not urgent and vice versa.
Simply put, what Cost of Delay states is that for every day, week or month a product or feature is not out in the market, a company could be losing revenue. You can also think about this in terms of cost savings. For example, a new feature that automates part of an operations team's workflow might save 1 team member 5 hours a week, which translates to 1,000 hours a month for a 50-strong team. These 1,000 hours have an associated monetary value which can be worked out quite easily. Then, a business can make a call about whether they are willing to forgo this saving to pursue something else or not.
When you can calculate the anticipated lost revenue/cost savings per month or per quarter for each item on your product backlog, you arrive at a blended value of value and urgency - i.e. how big is the opportunity and what do we lose by doing releasing this 6 months down the line instead of getting this done in the next 2 months?
Regardless of which prioritisation approach you choose to use, it is important to always consider how any feature you are considering advances your product strategy and vision. Beware of advancing metrics for the sake of advancing metrics!