Inclusivity in business analysis - On older people and surnames
Dad, VUCA, Oma, and my surname
Reflection on Building Product for Older Adults
I visited my great-aunt again this mid-month, and I observed how she preferred something done a certain way, a characteristic that I’ve noticed a lot in older adults. Seriously, having good observation skills is a must for any business analyst worth their salt.
It’s this particular example. While on the way to the church, my Oma reminded me to tell her to turn off the phone as soon as we were approaching the church.
I asked her why she didn’t just turn the silence mode on. She refused because she thought it was difficult; she’d rather turn off the phone completely to avoid accidents with the phone ringing during the Mass.
This provides a smooth segue to another example. This example is about my dad. He didn’t understand why my job as a senior product manager (my old job) existed. He thought that once the apps were launched, that was it.
“No,” I told him. I then explained that the apps needed to be maintained and improved because you couldn’t just ship them and be done with it. There would be more features baked in, seasonal marketing campaigns, and so on.
In short, his prime was in an era of the waterfall project management. How many OS versions had he experienced, and how frequent were the upgrades? Probably every few years for the complete upgrade - we’re talking about Windows 95, 98, and XP here.
Modern software deployment nowadays follows Agile methodology, where the releases come so often because of the iterative, cyclical approach. Rather than releasing a major version upgrade every two years, the development window is shortened to two weeks, in a unit called ‘sprint’.
The principles of Agile prescribe the solution backlog to be built incrementally and iteratively. You may have heard the jargon ‘move fast, break things’ from the tech startups. The idea is to manage VUCA (Volatility, Uncertainty, Complexity, and Ambiguity). What was considered relevant and the game-changer two years ago when the project commenced might be more likely obsolete now, hence it’s recommended to break down the solution into ‘tranches’ that can be released every so often.
‘Deferred to the last responsible moment’ becomes key as we don’t want too many assumptions. Therefore, product management becomes more agile, and all sorts of disciplines evolve with this methodology in mind.
However, this culture gap is not socialised well. Users are expected to accept whatever versions and policies the software companies have. Having a new button on the homepage, a new user flow “for a better experience”, or a new KYC flow to stay compliant might not be received well by the elderly folks or those with more long-term stability in mind.
Come to think of it, doesn’t fast fashion also evolve rapidly very recently?
(Mentally kicking myself for letting go of my late Grandma’s sweater - the knitwear quality back then was insanely higher, my amateur self in fashion could even tell the difference)
To put it simply, old: less iterative, more predictable, more stable, put your best work out for once; and new: more iterative, ever-changing, and the time to improve is near in the next release.
From experience, the forced upgrade of the app from the company I worked at didn’t come out very often. Still, we’re talking about every few months in frequency rather than years. My dad still has a hard time understanding the rush. He doesn’t get why, for instance, his banking app no longer works in his old phone. It’s a constant uphill battle: as the hardware becomes more advanced, the software versions follow.
(I still keep an iPad 2. You don’t need to ask whether it’s still usable - it can’t even connect to my home wi-fi.)
This kind of rapid development sometimes doesn’t make any sense to me: the iPad isn’t broken. It can still play music and show videos, preserving the ancient versions of the remaining apps offline. It’s an antique when the world around it marches forward.
I remember my team were planning seriously for a forced upgrade time horizon.
Building for the merchants (a touchpoint for sale, or Point of Sale / POS), the last thing we wanted was disrupting their business through a forced upgrade pop-up that interrupted their transactions.
A random note: I used to be able to see the Gherkin from vlogs or films, but now I spoke in a conference held in the building near it.
Life surely turned out interestingly.
Cultural sensitivity - Surnames
I don’t have a surname in the sense of I don’t have a family name.
My dad’s ethnicity doesn’t have a culture of giving a surname to the descendants. I think in the past, the Dutch settlers imposed the rule of having a surname - very European, and as a result, the Surinamese people from Java island still keep the practice of having a first name and a surname, while the Javanese in Java largely don’t.
An Indonesian photo ID card doesn’t have two separate name columns. Neither does its passport, only a full name column.
A seasoned Indonesian product manager knows that for creating an onboarding page, they only need one field: the full name. A British product manager, however, will create a requirement of at least two fields: the first and the last name.
A Chinese, Japanese, or South Korean product manager designing products for their countrymen may want to put the surname column first.
It’s impressive how practising business analysis makes you more attuned towards cultural viewpoints.
What you can take away . . .
From my piece of reflection in this post, it’s worth approaching a different way of doing things with curiosity rather than a challenging mindset.
We may have been raised culturally to think a certain way. Our behaviours are the products of our environment, after all. But when we interact with other people, it’s not always about a zero-sum game, my way or the highway.
Sometimes, winning the argument means losing the people, doesn’t it?
Until next time,
