The Hedonic Treadmill
As a product person you'd be well aware of problems stemming out of inconsistent / polarized emotions defying a consistent pattern gets on your wick, here's one possible way out...
Analyze the countries in the world that boast of an impeccable HAPPINESS INDEX and one is still bound to find a sizeable section of people who are of the opinion that they would be much happier if they also had access to some (x) in their lives which they currently aren’t in possession of. For ex: Residents of Switzerland could yearn for beaches just like the residents of the Nordic countries could yearn for tropical weather.
But another point of realization is how those wants are just but temporary given the startling speed at which all of those expectations could overturn. In reality this seems to be a perfect & fair representation of the larger section of the world & their expectations which is only but human as there could literally be no end to one’s wants.
Someone who doesn’t have a CAR & yearns for it today, would only yearn for a bigger one with better features they think is beneficial to them in some way (which could largely be delusional as well). The common factor is the “YEARNING” bit and there seems to be no end it to it especially for us as humans although that could be dictated by many paradigms ranging from personal / internal to social / external motivations.
Looking at this from the product managers’ lens, the same scenario could fit in well to represent motivations of users who happen to be using a given product.
And as someone who is building a product blaming the users for carrying & changing those expectations is a big NO-NO, for that just happens to be the very lifeblood of organizations envisaging & commissioning product-ops because if contentment was hit early, it may have thwarted / halted that progress bringing product organizations to a total standstill. That’s essentially what’s referred to as the Hedonic Treadmill.
Definition:
“The hedonic treadmill is the idea that an individual's level of happiness, after rising or falling in response to positive or negative life events, ultimately tends to move back toward where it was prior to these experiences”
[Source: Psychology Today]
But here are a few interesting questions now:
Given the motivations fueled by the hedonic treadmill how does one measure happiness levels to a fair degree of accuracy?
Can one think beyond pinning on lagging indicators / metrics so to arrive at those happiness levels unambiguously?
How often does one go about measuring it?
Would it suffice if it is measured once immediately post release?
There have been many instances of product teams identifying & using vanity metrics like DAU tying it to growth and labeling it as NSM (North Star Metric). But if you pop a question like “are a majority of my existing users HAPPY with the product offering?” that could indicate something else entirely.
“All said and done you are building features, products for the users / user groups and if you aren’t tracking their happiness over every release and over a regular cadence thereof it is as good as building for nobody”
“Wouldn’t it be great it one could track that happiness score by hitting the users up for some feedback much earlier in the PLC preferably post discussing the strategy over a 1:1 discussion?” But that’s wishful thinking .
For a good reason that the users may not even perceive the strategy as it was meant to be, and just supposing the users did, it could still prove to be a horrendous idea dragging users into a product strategy discussion.
And more importantly what would you ask?
If things were as simple as popping a question like “are you happy with the strategy / direction we are heading over our initiatives / upcoming feature / product release?” the world would have been a much better place.
One way to get around this issue is to collect feedback and keep doing that continuously on a regular cadence (or say irregular cadence depending on the phase of the PLC) over a variety of parameters that matter over what could be termed CONTINUOUS FEEDBACK.
Just as much as the HEDONIC TREADMILL which could be perceived as an endless loop of ever-changing expectations of the users, here’s something of a process loop to factor it in & lead to establishing the happiness levels:
1. Pre-Strategy
Prior to formulating the strategy, the activity carrying a predominant intersection with the users / user groups is the Research & Discovery phase. When one is mostly interested to gather as much information as one can so as to establish a basis for a problem area here, the one thing that could make the users happy is if the questions thus popped had more than enough relevance to the problems.
Arriving the happiness quotient could be down to these questions:
Would you say there is anything missing & you could add to make your workflow better & more productive?
How much of a hindrance is this problem (x) given your current workflow?
2. Strategy
As strategy talks of areas to focus on NOW & what’s not, it ought to boil down to the fitment in terms of hitting the right problem area(s). Strategy formulation could depend on the ability of the PMs, how well they apply product sense & find a balance in terms of fitting in all into product thinking / big picture thinking.
Quite naturally the users would be happy if the strategy & the initiatives thereof resonate well with their own perception of the problem areas.
If you’d have to pick one of them as “THE problem” what would you say that is as of now?
Do the opportunities listed have rich relevance to the users given their current workflow?
Does the proposed solution course circle back to eliminating the problem completely in an elegant fashion?
3. Roadmap
As the first step in deploying the strategy, it has to roll into a roadmap with EPICs. When those EPICs placed farther away in time could still simply represent opportunities, the ones that are prime and to do addressed NOW ought to carry enough clarity for every team involved in terms of their own outputs / deliverables whilst also possessing the necessary amount of clarity over how it all adds up to business outcomes as any member from any team may have to interface with the users.
It could be an absolute delight for the users to see how each of the touchpoints that they happen to interface with over the course of the PLC seem to have total clarity on what’s required whilst exhibiting a solid alignment in terms of the user’s needs, which could be emphasized over questions like:
Are the users excited to learn of the upcoming features & releases thereof as seen in the external roadmaps?
Do the users spot any kind of confusion while interacting with any of the team members in the org.?
Have the users already moved / planning to move to some other competitor’s product to smoothen out a part of their workflow?
What’s the value add they see in adopting to the competitor’s product?
4. Backlog
Prior to kicking-off the build phase, the backlog which could be a lengthy list of user stories prioritized according to the relevance to problems could be a single source of truth for all the Design & Tech teams involved, going LEAN & heading via the MVP (Minimum Viable Product) route so as to gun for MLP (Minimum Loveable Product) has proven to be far more beneficial & delightful for the users as well given how they could feel like an integral part of the whole product envisioning, building & testing process with a practical window to notice how feedback is received & factored in.
Some questions that could help determine delight here in this phase are:
Are users happy about the order & manner in which the solutions are shaping up?
Do users resonate with the Design, UI & UX parts of it?
Do those MVP tests still point to some kind of friction somewhere over the workflow?
Does the MVP pass with flying colors?
5. Features
At this phase the feature that the teams have been working on iteratively running into those “IDEATE – BUILD – TEST – LEARN” cycles ought to have taken proper shape carrying a pretty high chance of adoption if built via the LEAN / MVP route. When that is bound to obviously delight the users if you ask them right after the release. The trick would be to give it some weeks of time and then pop those question.
A few weeks into using the latest feature / product release, these metrics could help you determine the happiness quotient:
NSM (North Star Metric)
C-SAT Score
NPS Score
But having said that the ONE question that can help spill the beans here is:
If this product / feature were to be discontinued right here and now, how do you think it would impact your workflow & hamper your productivity?
Do remember:
Collecting feedback from the users ought to be your GOTO as a product person & that ought to go beyond merely asking them questions post the build phase as pertaining to the UI / UX over those moderated / unmoderated tests.
Sometimes (and am sure the whole product community agrees with me here) talking to users has also helped discern factoids that were not just enough to negate a hypothesis but point out how frail an entire strategy was. And error corrections at that stage don’t prove to be all that costly (although there’s some money burnt) as opposed to staring down the barrel of anonymity having to deal with mounds of sunk cost / piles of tech debt.