Previously on the series, I covered aspects of product discovery that intrigued this fresh-off-the-boat PM. To recap, my goal was to build a pet care EMR, aimed at the owner as the primary user, and the vet as the secondary user. The one paying for the development of such an EMR would be the chain vet clinic. The chain clinic’s goal is to replicate the personal touch of the local vet - the much loved family doctor for the dog and cat.
The app is aimed at the American market. This third, and final edition, begins where part II ended.
In the manner of serialised fiction we kick off with bullet #7
#7 Read the sacred texts, but be wary of reading too much
One book I’d recommend is Cindy Alvarez’s Lean Customer Development. Alvarez explains how to get the most out of user conversations, and the need for a practiced, habitual objectivity. There is a temptation to validate the first thesis that registers, to give the mind some rest in all subsequent conversations, and hear only what you want to hear. This instinct must be fought.
If there is one book you read, let it be Lean Customer Development. The book is ridiculously practical.
Alongside Alvarez, there is one more. Teressa Torres’ Continuous Discovery Habits is an essential part of the PM canon, and the rare text that dives into the discovery part of product development. Personally, what I gathered from the book is that the team’s shared understanding of the goal must always be rooted in real users. The drift towards an inward-looking group that cares little beyond building what has been deemed important by diktat or even consensus should be resisted.
Beyond two titles focused on the PM craft, the necessary skills devolve down into the constituents of product discovery — UX, competitor, tech ecosystem, consumer, and regulatory research.
Second in line is an enormous subset of product discovery — the software development knowledge one needs to converse with engineers in the team. For someone not segueing from a dev role, there are a ton of things to build familiarity with, from broad disciplines such as enterprise architecture, system design, integration patterns, public APIs to irreducible concepts such as “eventual consistency”, app crash rates, and app load times. There is no dearth of books and YCombinator threads on these individual subjects. But the titles are far removed from product discovery, which is how it should be.
In every age, there exists a corporate function that began life with the goal of generating ideas that lead to business value, but through drift (and not design) ended up being the wellspring of needless words. In an earlier era it was consulting in its various forms. In the present day there is real risk product management will go that route. I’d be wary of reading too much.
Where the goal is to build in the real world, a bit of literature is useful, but beyond a point (and the point appears earlier than you’d think) the stuff goes rogue and feeds on itself. Tarantino’s movies are all about movies. The risk with the ever expanding universe of PM influencers is that ideas about product discovery could become ideas from the literature on product discovery. This is wrong. Movies and products should be about those whose reference point is real life.
Think Anthony Bourdain, who, among many literary accomplishments, wrote for the New Yorker. He also said:
I only became happy — in fact, intensely satisfied — as a dishwasher at a restaurant in Provincetown in Cape Cod, my first job. I was a shy, goofy, awkward teenager. But in this blue collar, factory-like environment, there was no blurred line, no grey area, no philosophical question to fret over. Dishes had to go in the washer and come out taintless
Be like Anthony Bourdain, not Quentin Tarantino.
#8 The style of leadership is more Mike Brearley than Sachin Tendulkar
For those from outside South Asia, Mike Brearley was an English cricket captain known for being an exemplar of a captain. Sachin Tendulkar was the batting wunderkind. He became captain too. But that is not what he was known for; is not the legacy that endures.
Mike Brearley made his debut at 34, did not score a single century in 39 tests, and finished his career with a batting average of 22. He led a team of superstars who dwelled in realms of skill the captain knew he would never enter. One such superstar, David Gower, had a batting average of 44 and scored 18 centuries. But the captain flourished anyway, contributing as captain.
In the discovery phase, technical virtuosity is not necessarily a virtue in the PM. This might be hard for the kind of person who wants to be PM. School was a long time ago. You don’t need to always be out-thinking and out-knowing everybody in the room.
Explain the boundaries to each superstar, and how their craft must enmesh with those of other superstars. Then proceed to conspicuously get out of the way.
Personally, I have found that the approach of knowing the user and business goal with high precision is the proper job of the PM. With that done, step aside, and allow the drummer a solo.
An illustration follows:
An aspect of pet health care is knowing the lineage of the dog, and the medical history along family lines. That informs diagnosis. That informs triage in situations where time is paramount.
Now, this particular aspect of the owner-focused EMR we are building is uniquely challenging. I use the word “unique” with care. In this context, it is descriptive, as the word was meant to be. It is not a superlative.
You see the vet clinic’s EMR we are piggybacking on through APIs does not have that feature. It is not a case of information being made accessible to the owner through an API. It is about bringing new information into the EMR ambit. It is about increasing the information points the vet has for triangulation.
This is different.
In fact, the broader point here is that the situation does not just concern our client. The issue is not about the particular chain vet clinic’s EMR, but runs into the nature of EMRs, or what EMRs have been historically.
The raison d'être of EMR, as a category, is “increasing accessibility of information generated as a matter of course in regular clinical interactions.”
With this, we are nudging the systems towards generating more information.
To be clear, the vet inquiring about the pet’s family history is standard. The owner being a ready with detailed answer — less so. Often, this is for good reason, namely that the information is simply not there. The dog might be a rescue adopted well past puppyhood. Sometimes, it takes too much effort to track down those who might know. Sometimes the circumstances are as messy as they are with matters of human lineage.
The task for the EMR designer is to render the “lineage” object unavoidably salient. Lineage should be at part with “encounters”, “reports”, “vitals” as a top level domain in the information architecture. The nudge should be towards reminding the owner that dog’s breeding history and the parents medical history from both sides can affect outcome in a medical event. This goal manifests in more ways than one - from reminders, to how the lineage screen itself is designed, its salience from the default view, and its position in the hierarchy.
This is where the job of the PM ends. Now it is upto the UX person to hash out the rest. You aren’t the UX Tendulkar, you are the PM Brearley. Get used to it.
#9 Politics is not a distraction, politics is the PM’s job.
“Politics” is the label given to the inescapable reality that sincerely held positions on matters of significance are based on little more than:
“It gets the job done AND it does not hurt me personally to hold that position.”
This isn’t going to change.
Platforms, technologies, frameworks, ideas, fads, FUDs, three-letter-acronyms, vendors, tools, budgets, timelines, the left or right tine on the fork — could be backed by words. Thousands of them, in fact. They could be backed by something more evil than words — numbers, which carry the promise of certitude and precision. But that’s just the paperwork.
Things happen because somebody’s position on a real or imagined status ascension ladder improves a wee bit by that particular decision. Things happen because individuals or groups are in a cohort that rises up and down the status ascension ladder together. These in a cohort act in concert, and in opposition to other cohorts. Often, the status ascension goal that defined the cohort is long forgotten, and what moves choices is pure tribalism.
The PM’s job is to figure out what those cohorts are, what status universe they think they inhabit, the next rung on the ladder, and the choice that helps them move one step up. Then build it into the plan.
If the price is microservices, or AI, so be it. Jane Goodall did not change her higher primates, you will not either.
