Combating Cognitive Bias
Here’s how my teams overcame cognitive bias, which happens to be a problem plaguing many teams across the world esp. while interfacing with users across various stages of building a product.
Data - lifeblood
Just a reminder that we’re now in 2023 and tons of things have changed in the last decade right from the way software products gets built, the way ideas get generated and how they move across through each of those stages refining and maturing over every silo. The role data plays over all of this can’t really be overlooked as it is the lifeblood, sans which one’d just be left with unwarranted complexity and mounting chaos induced in the name of processes.
Let’s consider a popular & common bottled soda drinks org. say, Pepsi.
There’s a place where it is produced, packed, bottled, sealed and then they are all transported across various distribution hubs vide a given city who then take up the responsibility of intern transporting a said quantity to each and every touchpoint accessible to all the users (customers in essence). Owing to inventory systems in place it’s not surprising that there would be a RE-ORDER function kicking-in at some stage as the quantity in stock drops below threshold levels as agreed upon between the owners of those storefronts & their distributors.
Now, let’s say, at some stage Pepsi launches a new flavored drink like for instance STING and needs to know very specific feedback regarding its appeal under various headers like say:
NOTE: these questions are certainly not going on the survey and that’s for sure.
Is the color of the drink appealing?
How is the taste?
What exactly would you want to see change over the taste?
How do you feel it is priced?
Where does this stand w.r.t other drinks by Pepsi?
Is the quantity to price justified?
What do you feel about the bottle design?
There could be no way to get to the bottom of all these questions in the first place, let alone some follow-up questions like for instance if a probe has to be initiated into question 3 there.
So, is there a solution to this?
They resort to some bit of customer interfacing they have when they get some complaints. The social media is another channel that’s used heavily to gain some insight, whilst popping those paid surveys from time to time which would naturally need some bit of extrapolation and may or may not always suffice.
But, the biggest talking point is - “the users could really be inaccessible”!
Data - blackhole…
When the inaccessibility forms one side of the story, the other side of it may look like an eternal void of a black hole where one seems to have all the access alright, but the deviation between whatever could be termed “relevant & valid data” and “the VOM (voice of the market)” could stretch to uncomfortable lengths, the maximum one could expect to reap at the end of the exercise would just be a faint / feeble representation of data.
Referring to the benefits / outcomes of “speaking a language the users comprehend” could often result in a clearer understanding of their motivations & help arrive at their pain points. Some commonly used techniques / tools across product teams are:
empathy map
user story mapping
focus groups
buy a feature
But not surprisingly, they do come with some pitfalls as well.
NOTE: For more information on the varied degree of bias the prioritization techniques could carry, do refer to this link:
But, if ever one has been involved in a product team and has had some practical exposure of these situations in any capacity over putting these above-mentioned tools / methods to use on a regular basis, one would know the importance of how “understanding the user’s language first” ought to precede everything else.
Data – unambiguous, clear & actionable
Look at the world around you today!
None of the product teams have ever stopped their work which is to build great lovable products given those data & ambiguity related problems being persistent all through, albeit to a varied degree in various pockets of the world.
So, how does that get done then?
It takes a lot of hard work, hours / days / weeks put into research activities, some even go so far as to pay and acquire the data as they don’t really have any other means of accessing it which applies to an org. like Pepsi we considered over our example at the beginning of the article.
Perhaps an outlandish thought for most people, but this worked wonders for my teams & had multiple perks targeted at the team’s relationship with the users.
It is most likely that you are catering to and talking to the same set of users over and over again across your (PLC) product life cycle and the host of products you are building, owing to which you would be talking to them at a regular cadence (Continuous Discovery activities), this thing could work like a charm.
Can you as a product person spend some time educating your users so as to get them to at least match up to your workflow to an extent, if not conversing with you spic-and-span using jargons and lingo?
The idea is not to minimize the time spent on the exercise but instead to optimize it for the quality of interaction & better the yields as much as possible.
What are the benefits?
Well! Plenty to miss out on. Some of them could be:
smart users could mean smarter requirements & access to smarter data
reduced cycle time to understand their true motivations
maintain continuity & not having to start all over from zero
better collaboration
rich relevance & improved quality of Q&A
users understanding internal processes to some extent & that could set expectations straight
Think of all the intros you would have to go over regressively time and again to build a sense of continuity. By the time you arrive at their actual pain points it could feel like a lifetime has passed in a normal scenario.
But, onboarding them onto what could be a well-thought-out framework could make the entire process better & faster.
NOTE: If it gets implemented & happens to work well, your user touch points could get smart enough & tuned to your thought process better providing information in a format you need.
WARNING: This process ought to function without discounting the other mandatory activities like research / discovery.
Scenario:
Here’s a simple analogy.
Think about when you have trouble in your body and plan to visit a general physician, as you don’t know the exact complication and seem to be unaware of whether it’s meant to be case for specialty or super-specialty doctors.
So, what’s the workflow?
You go up to the doctor and start with the complaint about say your stomachache (right in the middle of the stomach area to be precise) &
it started from (n) hours back after you had this (x) thing as a part of your meal (which was something of a deviation from your regular schedule)
prior to which it seemed inexistent
As opposed to you going there and just quoting:
“stomach pain” generally &
waiting for more follow up questions for the doctor to get to the specifics
Some may argue that this could lead to bias. Contrarian to that, I’d say:
it makes life simple as the physician could eliminate the other major diseases (for instance: acute lower stomachache intermittently “could” have something to do with the appendix)
follow up questions could be refined and directed well based on the confidence the physician has over his prognosis & examining the affected area &
matching it against the information that was provided to him (owing to the fact that he’d surely follow his protocols to ensure he’s heading the right way)
the area of trouble can be zeroed-in on much quicker
NOTE: It’s not altogether delusional to think that this method could lead to minimized time cycles over getting to the actual pain points. But, the focus ought to be on optimizing the conversation and the quality of inputs at the provider’s end.
Extending the scenario to a case where the same patient goes to another doctor, say he happens to be touring and is out of town. He has already been through some treatment and has had a first-hand experience of the diagnosis.
Naturally, he would be starting off from:
“I seem to have trouble with <exact area of the stomach> & I was treated for this previously as well via <this medication> and over the course of <this period> led to a recovery”
which could be nothing but actionable data in the true sense of the word
Back to the board:
Ok, let me clarify it once and for all now.
I’m not saying a user needs to be able to fill out the user story himself:
As a <> I want <> so that I can <>
Absolutely not.
But with a bit of time spent on training, one can get users to describe the whole situation a lot more clearly driving action faster as it’d help the PM / the Triad to get to an understanding faster than the conventional interviewing methods.
To avoid what could be mishaps over understanding it all, a PM could use a sequence diagram to depict all that workflow he is getting as an input from the users’ desks which could then be used to build some sort of a high-level summary just to reemphasize & discuss any missing elements / nuances, add them in there before taking to the next steps aimed towards solutioning.
For instance, here’s one depicting the workflow of an online shopping app.
The workflow in the diagram could act as a base for all further meetings, dialogues, discussions, considerations for all parties involved - internal & external teams, when editing them could be restricted to internal teams alone.
Having said that one can’t overlook the use of it as a canvas, where it could act as a reference material for all the other teams involved, not discounting the use of it as a quick sense building tool especially during new team members being onboarded and the need for a quick explanation as to where things stand now.
Conclusion
There could be many situations when the users and user community isn’t accessible for dialogue at all. But whenever that’s possible, anyone from the product team could bide some time from their schedules & apportion it over educating the users over the manner in which the interaction ought to take shape making it all the more productive for all of them involved.
To cross verify the story product teams could use a Sequence diagram over plotting all elements considered crucial to building the understanding which could be a template to edit & append features as needed at a later point in time.