I spent the last two years in product discovery land, looking to see if tiny strands of ideas, industry hearsay, and the sheer chutzpah of ambition might coalesce into something that could one day be an actual thing.
These 24-months taught me more than the previous 16 years had. Here’s what I learned — just three to begin with.
(I will be conducting my education in public)
#1 At the discovery stage, the product management discipline requires you to be a working polymath.
There is industry, consumer, user, tech, UX, ML, competitor, software ecosystem, solution architecture, and even — legal research. Then there’s the modeling of usage and financials of a product that does not yet exist. Yes, that is absurd. But people who sign off budgets cannot do without it.
The above paragraph lists ten different disciplines. Of course, you wouldn’t be an expert at all. Or even one. A joke doing the rounds on Twitter is that a product manager is someone who cannot code and cannot design. The joke works because the premise is plausible.
But during the discovery phase the product manager must know enough to speak to actual experts without the experts having to dumb things down. And, knowledge of each individual domain should be enough to know which parts just cannot work, and if all the individual parts would work together at all. That’s a tall order.
Imagine you are designing an electronic medical record (EMR) system for pet owners, and not vets. There is a bewildering array of things to know.
The behaviour the EMR would replace is clinics mailing documents after a vet visit.
The user needs and the business case. Does this suck enough for a pet owner to sign-up for new software, perhaps even pay? Does it suck up enough for the clinics to buy licenses in bulk, and extend user licenses to pet owners?
Software ecosystem research. How many clinics use an EMR for their vets already? Which EMR solutions specifically? What is the market share situation among the top vendors? Do they have APIs? At the MVP stage, which is the one EMR you’d build a pet owner extension for? Fundamentally, do you base the design on extending a vet-focused EMR to pet owners? Or, do you build ground up?
User research. What is the primary purpose of an EMR for pet owners? Is it for the pet owner to have quick access to documents? Is it like a notepad? Is it for the vet to triage faster in an emergency? Is the endpoint always mobile? Is quick access to invoices an important use case? How many different clinics and doctors would a pet owner see over a dog’s lifetime? Is the portability of documents as big a deal as we think it is?
UI/UX research. What are the types of medical encounters? What is the subjective-objective-assessment-plan format? How is SOAP best visualised? How many kinds of lab reports are there? Is a timeline the best way to organise encounters and reports? Can a lab report be summarised with natural language processing (NLP) tech? What is the best way to trend vitals, such as weight?
Solution architecture research. What is the most likely search pattern on an EMR tool — would the pet owner search by vet name, by the type of encounter, or by the kind of lab report? Would a standard enterprise software search solution work? Or would you need to go beyond?
Business metric projections. For chains, could the vet influence more than vet services, such as merchandise (because vets are the most trusted source in pet care)? Is that ethical? How would that work in practice? Would the vet recommend actual products? Would it lead to loss of reputation, perhaps even trigger a public relations crisis? Would it be accretive to revenues? Should vet recommendations not be actual recommendations but polite nudges?
And finally this wealth of information must fit into a near narrative of user needs meeting business imperatives, and the twain must meet technical feasibility. And while there would be a dizzying array of Figma files, PRDs, and spreadsheets with projections and cost models — coherence is achieved possibly only in the mind of the product manager.
Which brings me to the next point.
#2 Stakeholders will be legion, but the idea in its entirety should reside within a single mind.
I have gone down a particular career path because I enjoy 34 open browser tabs, and like to believe my dilettantism equals multifaceted genius. But there are people who do a specific thing well, like UX or front-end development or NLP. All ninjas. But in the product discovery phase there isn’t a way for the ninjas to know how the heist will work, who rappels in when, and who breaks through the door.
Putting things on paper is great for consensus building; but there is always something lost, some disfigurement as the idea goes from one mind to another. If it passes through five minds it becomes the sort of Frankenstein AI-made art that no human would recognise as a product of a human mind. This is why “designed by committee” is an insult. That is why tech is forever in search of the full-stack engineer, the full-stack data scientist. That is why a movie is a lot more likely to suck than a book.
The end result of a product discovery exercise could be many epics, user stories, non-functional requirements, and wireframes — all exquisitely detailed. But it is still an idea. And an idea can be internally consistent only within a single mind, and if it does the cause of resonance with another mind is served. That is why the artsy kinds speak of authenticity. If a song gushes out of a well of real pain, there’s a better shot at striking a chord with the millions who would have suffered similarly. In the absence of a product in the field, gathering real user data, this is the best one can do.
Therefore, despite the impossibility of a single person combining working knowledge of six different areas, it does make sense to err on the side of a single product manager owning the whole canvas.
#3 You need cigar-chomping white beard psychoanalyst-level listening skills. Wise men and women have called it “active listening.” But that analogue is weak. What’s worse — it is inexact. Instead, a product manager in the discovery phase must think of themselves as a shrink, and the user in an interview as the patient on the couch. Whichever artefact you begin with, like a script or a questionnaire, is just to get your interlocutor talking. You are listening, very carefully, to the answers, of course. But the goal is to find out where it hurts. Even better, where it hurts real bad. The product researcher’s line of inquiry is neutral, empathetic, even charming — while circling around, moving the subject away from the polite and the banal to something that really bothers them.
Imagine the same pet EMR system. A user research conversation with a vet runs the risk of being limited to stuff you already know. The vet is talking to you because a market research company set them up, in exchange for a donation to a pet shelter. Such conversations default to the perfunctory. Your task is to establish that you have done your homework. That you are a serious person. That you grok a day in the life of the small clinic or the chain vet. And at some point, if one is hawk-eyed about possibilities of a genuine connection, you could be saying:
“But tell me more about how pet owners don’t stick to visit schedules?”
“Yes, sadly many of them do not understand that if they visit regularly there are a lot of issues we can catch early and actually extend the pet’s life.”
There, you have a specific tangible that could lead to real value (namely, additional months and years with someone you love).
The goal is to let you and your interlocutor arrive at these epiphanies.
When you speak to the next interviewee, the instinct is to validate the insight. There is an obvious case for seeking the warm glow of being proven right, but that should not be the only consideration driving the next interview. Instead, think of other genres of hurt. In fact, the product researcher needs to create a whole lexicon of pain.
Think of (at a minimum):
Helplessness. “I have no idea how much a procedure could cost.”
Panic. “My dog has been so quiet, it’s not like her at all.”
Sadness. “The vet we have had for all of my dog’s six years is moving.”
Rage. “I am sure I have been ripped off by this chain clinic.”
Irritation. “I was just filing a pet claim insurance, and the amount of item-by-item invoice reading I have had to do is not funny.”
The broader goal, just like in psychoanalysis, is to understand patterns of unconscious behaviour. It is possible to belabour and over dramatise the analogue of course. I would not go as far as to say “patterns of destructive behaviour” applies to product discovery. But the goal should be to understand how suboptimal things are, and if they really need to be. Maybe the workarounds the user has built around the current suboptimal thing make life more than tolerable. But there will be pockets, perhaps adjacencies, where dramatic improvements are possible. It isn’t the three-coffee-morning habit you are trying to fix, but the unwinding ritual after work that involves wine.
Like with all social interactions, the combined might of the heart and the mind must be summoned to rescue the conversation out of small talk land. Friction, change in tone, signs of life — that is what a good user interview is made of.
