SMART External Touchpoints!

Given the frequency of interfaces product people have with the users, does it make any sense in working towards making those touchpoints smarter?

How often do you talk to your customers?

If one had popped this question a couple of decades earlier, the responses may have been unsurprisingly biased towards something like “as soon as a problem gets reported”. This was obviously true as for the service industry given how they dealt with specific projects targeting a specific outcome for their clients, but it was also true as for some product orgs.

Looks surprising given how product teams tend to function today isn’t it?

With many teams adhering to methods like continuous discovery suggesting that they keep their users engaged in dialogue towards bridging the gap between user expectations that could change dynamically & the product / features that the org. is building / planning to build.

“Continuous product discovery suggests that teams building the product, interface with the users at a regular cadence towards conducting a host of major / minor research activities in helping them reach a better level of understanding of user’s needs”

Doing so would help divert the org’s focus immediately towards what’s contextually relevant to users & more importantly define a purpose, making a strong case towards building something.

The iterative nature of continuous discovery methodologies as proposed by Teresa Torres, how it helps factor the VoM (voice of the market) in at a regular cadence & evolve the understanding product teams carry about their users leading to better features & products is possible only if the information being shared by the users was to possess a strong contextual relevance.

But as the world knows it, users are known to share a whole lot of stuff that they tend to perceive as important, more than half of which could end up being far from actionable. When some of that could be a narrative or a backstory that could help in building a behavioral understanding & arrive at the real motivations that are driving those expectations, most of it could end up getting classified as wishful thinking (if I had this right now my life would be much better).

When users are obligated to share detailed nuanced stuff about the problems they are facing, it is also believed to be directly proportional to the quality of questioning from the product teams over each of those interfaces. One could go on talking to the users at a regular cadence as stated under the “continuous discovery principles” but could still find oneself at odds with what’s termed actionable insight, let alone hitting a discovery block of semblance that seems good to be labeled “problems”.

As most tend to believe, one way around that situation is to try and use Gen-AI. But again beware, as you are employing an LLM which is just as good as the input (/ metadata) fed to it, which is, all content floating around the internet today.

Here’s a thought: Would it work well if product people put in some miniscule effort towards elevating the quality of inputs they obtain from those touchpoints?

How about this!?

A Product Ops PM is entitled to building internal tools targeted at improving productivity of teams over specific squadrons, realizes that there’s a high probability of them hitting success & pretty quick as well given the chances of them understanding each other pretty well. 
In many cases it is possible that the PM may themselves be a user. So, setting the bias aside & assuming the PM is well-aware of methods towards conquering that, there could be a great visible camaraderie between those teams & it could look like they are walking their way to success time after time over every release.

How is that even possible, you ask?

The answer lies in the quality of inputs handed to the PM which is directly proportional to the understanding users carry over the domain, the workflow, the problems, the need for solutions that could help them bump up that productivity.
So, may be a PM carrying nuanced understanding of a given domain would be far better off than someone who comes from plain vanilla Tech & has mastery over the art & craft of building generic products.

NOTE: This is in no way meant to be taken in as an indication towards considering the user’s inputs as final & planning towards building features / products based on just that. There’s a whole lot more that represents the gap between user input & a feature that’s good to hit the market, which is also often the difference between BLINDING & meagre adoption rates. And that includes but is not limited to underserved market needs, behavioral understanding, competitional landscape, product thinking, product sense, technology, innovation / differentiation.

---

BENEFITS of SMARTER TOUCHPOINTS

When working internally product people are so used to levelling up to the other team members, their workflow, the jargons, the lingo so as to be able to fit oneself in, to be able to empathize & understand them better targeting smoother & better collaboration.

If you analyze it, levelling up is a mandatory exercise for a PM, making it imperative that one spends enough time on it & is not alien territory at all. And in the process, it is only obvious that each of these internal team member learns a thing or two about product manager’s workflow which reflects in the manner which they disseminate information. One could see a gradual phase-wise improvement over the way sales / marketing / development / design teams communicate with a PM.

So, why isn’t allotting time & working towards elevating those user touchpoints & making them smarter a default option for any PM?

The answer simply lies in the RATIO - [EFFORT : PRODUCTIVITY].

Perhaps PMs may be of the opinion that it could end up being a futile waste of time & that may not altogether be false in some cases. But there are many markets, user groups across domains & contingents where this could fit in well & end up looking like a Godsend.

NO, this needn’t happen over a separately scheduled call altogether burdening the already burdened. One could think of this as an extension of the user onboarding exercise itself, spread out over a few odd sessions.

Firstly, here are a few benefits of making user touchpoints smart:

NOTE: Please remember! The whole idea of this exercise is never to minimize the interaction product teams tend to have with those users / user groups, but to OPTIMIZE it.

And, here’s a stepwise guide towards making those user touchpoints smart:

1. Empathizing

Even before a PM starts to think about the problems / pain / friction points, it becomes essential to approach the whole situation with a sense of empathy. But the case here is a little different given how empathy ought to be inborne as for the users themselves. It could also sound funny to a few ears when they think about “having empathy for oneself” but that’s the first step & that’s where it ought to start from. And it to be possible the users would have to begin thinking on these lines…

1.1 Get rid of the “I am merely a user” mentality

Most users may not have any cognizance of the problems they are facing because they don’t tend to think of it from a different standpoint. They don’t seem to have a choice & are made to believe that they have to live with. So they make peace with the situation eventually. It is imperative for PMs to pull users out of that mentality first.

1.2 Approach situations logically

Users tend to show polarity, in the sense that they either overthink everything or take it with a grain of salt sans thinking too deeply & that could include things bothering them deeply as well, blame that again on the “I’m merely a user” mentality. If users ought to get productive & smarter in terms of the info they share with PMs then they ought to learn to approach things logically questioning the status quo, sometimes over stuff that seems pretty obvious as well.

1.3 Explore root causes

It is very possible that users stop just as they stumble on a problem, but that again doesn’t augur well as for the ask here. Users ought to be able to dig in deeper into the causes behind those problems, conduct some sort of a root cause analysis (after-all they are the ones facing it first-hand) just so that they are able to see through one-leve deeper than the mere occurrence & frequency of those problems.

2. Story-telling

It helps if a PM is a natural story teller, but what about the users? How would it all spawn out if they are good storytellers? Would it be ok if users are stitching stories about their own workflows or would it be productive if they tend to stick to the point? Well. For users to get smart PMs ought to get more smarter & think about how easy it’d be for users to frame, remember & reproduce the whole problem without missing a beat if that happens to carry something of a backstory. For that to happen, these steps may be necessary:

2.1 Make notes about the problems

Users could meet F2F with the problem over a negligible instance of time over their regular day’s workflow, which could be easily forgettable given the insignificance of it all & tons of other issues they may have faced over an entire day. Making notes about the problems they are facing right then & there could augur well for them & also the PMs involved. Elaborating on the problem could then come naturally for most users.

2.2 Evolve the backstory

Given the one single sentence (/trigger) that a user may have written about stuff that they are facing, the need to round that up into a story could be crucial given the magnitude of the situation. That could work if the users take a minute or two & rethink the problem, its occurrence, frequency, context & of course the impact.

2.3 Test it on other users

It is possible that users could develop something that they perceive as a valid story given their experiences, but unless that’s run amongst their own community it may not be strong enough to carry forward. Sharing the story with a few of those fellow-users could help them understand how well it resonates with them, learning from & factring those experiences, evolving it thoroughly.

3. Jargons / Lingo

If the users are working at the back-offices, middle-offices of banks it is possible that they are pretty sound as technically / tehno-functionally & possess a command over the subject as well (although not to the level of an SME). But, that may not be true for all the users, which is why it becomes important to chart out plans to make them more aware, more accustomed to the jargons & the lingo so that the communication part smoothens itself out & totally falls in place.

3.1 Measure their comfort levels

Not everyone could be comfortable with everything. At times it is very possible that someone who is working on something day-in, day-out may not really be comfortable with it & but has been forced to make peace with it. And PMs don’t need to be educated on how costly assumptions could end up being. It becomes imperative to understand the comfort levels of the users first, which can be gauged periodically over conversations so as to chart out plans to upskill them as required.

3.2 Plan & conduct awareness campaigns

It is possible that users may be averse to lingo / jargons & some may also be of the opinion that it is a tough nut to crack. When dealing with such users it is important one remembers how they themselves took time to learn stuff & it wasn’t learnt in a day. Taking to building relevant content that could get the message across easily could also be the first step in conducting awareness campaigns. Merely throwing jargons on the users, even if it means one per day akin to the “word of the day” campaign by dictionary.com may turn out to be futile.

---