I’m Not a Doctor
Paul dropped a great analogy today when he compared product managers to doctors.
I love a good analogy, and this one is gold, at least when applied to sustaining a product.
Plus, it’s funny when you inject a little Hollywood into it.

Not sure which one of us is which
When you’re not feeling well, you go to a doctor and explain what hurts. When you use a product, you tell the product manager what doesn’t work for you. If you like the way a product works, you don’t usually call up the PM and to say how awesome it is. Just like you don’t call up your doctor to say you’re feeling fine.
Not never, but not often.
Coincidentally, both medicine and tech have bugs and enhancements.
I’ve discussed cyberchondria, a.k.a. Internet doctoring, and user feedback generally includes a how-to component, especially with design concerns. The more people read up on symptoms and prescription drugs, the more apt they are to diagnose and treat themselves; similarly, the more people use software, the more likely they are to diagnose and fix bugs and enhancements.
It’s in our natures to solve problems ourselves.
Let’s take a break to make it clear that I am not comparing myself to a doctor in education or experience or importance, just extending the analogy.
Back to the analogy. Getting to the basis for requirements is similar to finding underlying conditions that could exist beyond outward symptoms. Users may say they need a specific enhancement, but without knowing what drives the need, it’s tough to make a call on the right way to meet the underlying requirement. Just like treating a persistent cough.
I suppose you could draw a parallel between beta-testing and drug trials too.
Finally, you have to trust your doctor to make good calls on your behalf. That’s the job, right? Same with product management, or at least it should be the same.
One place where the analogy breaks down is that products aren’t always singularly tailored to one user, like diagnoses are to individual patients. Sure, bugs could affect all your users, and enhancements could benefit them all too. But there are lots of cases when a change or fix for you could bork up things for others.
Extending the analogy, I guess developers would be surgeons, i.e. they’re called in to fix what ails the product or to enhance it. I have a mental image of Rich and Anthony in surgical masks typing away, dimly lit by the glow of a monitor. That’s Paul and me up in the observation room, eating Junior Mints.
Or you could cast our little team in your favorite episode of Scrubs or any other of the many shows and movies about medicine. It’s a little funny.
Anyway, Paul’s a smart guy, and this is a solid analogy.
Apologies to any real medical professionals or who were offended by it.
Find the comments.
Possibly Related Posts
- Do Users Want Innovation?
- On Product Management
- Inertia and Separation Anxiety Drive Design
- So, What Do You Do?
- Twitter’s #fixreplies Boo-Boo
-
chet
-
tardate
-
chet
-
Jake
-
Jake
-
chet
-
Jake
-
mpbennett
-
Jake
-
chet
-
Jake
-
chet
-
Jake



