Background
It’s 11:42 p.m., and Priya still hasn’t closed her laptop. Her team shipped a clinical dashboard three weeks ago, and the pilot feedback is trickling in from two hospitals. Most of it is fine, honestly — a few nurses even said it saved them time. But one comment, buried in a form with forty other responses, just says: “clunky.”
That’s the one she can’t stop reading.
They hate it. I should’ve caught this in usability testing. Maybe I’m just not cut out for this job.
If you’ve ever managed a product in healthcare, you know exactly what that spiral feels like, and you probably know it doesn’t stay contained to one bad night. The stakes here are different from consumer software — a confusing workflow doesn’t just annoy someone; it can slow a nurse down mid-shift or bury a lab value where nobody sees it in time. So the pressure sits differently in your chest. One offhand comment turns into a referendum on whether you’re good at your job at all. Figuring out how to change negative thought patterns isn’t some optional self-care add-on for people in this field — it’s closer to a survival skill, quietly baked into the job description nobody wrote down.
Why This Job in Particular Gets Under Your Skin
Healthcare PMs answer to a strange mix of masters: clinicians who don’t have five extra minutes, compliance officers who don’t tolerate gray areas, and patients they’ll usually never meet but whose outcomes are somehow riding on a decision made in a Tuesday sprint planning meeting. Add in procurement cycles that drag for a year, IT departments that move at their own pace, and regulatory review boards that can freeze a launch indefinitely, and you end up with a job that hands out very few clean wins — and a lot of ambiguous, half-finished feedback loops to sit with.
Aaron Beck’s early work on cognitive therapy described how, especially under sustained stress, people default to distorted shortcuts in how they read situations — catastrophizing, mind-reading, jumping from one data point to a sweeping conclusion (Beck, 1979). That’s more or less exactly what’s happening to Priya. One word from one nurse becomes proof that she’s failing, when really it’s just one word from one nurse.
Fictional Use Cases
Daniel and the Launch That Wasn’t Actually a Failure
Here’s another one. Daniel — not his real name, because he isn’t real, but you probably know someone like him — led a team building a medication adherence feature for a remote monitoring platform. Eight months of work. Two weeks after launch, adoption sat at 12%, nowhere near the 40% target they’d promised leadership.
His first reaction wasn’t measured. We wasted eight months. Leadership’s going to lose confidence in me. This is going straight into my performance review.
He nearly fired off an apologetic email to his VP that same night. He didn’t, though — he waited until morning, and instead of hitting send, he did something almost embarrassingly simple: wrote the thought down on paper, then next to it wrote what actually happened. What had actually happened turned out to be more complicated than “we failed.” The low adoption number had exposed a real gap in how patients understood their own medication schedules, and that finding ended up reshaping the whole roadmap for the year.
This is basically what cognitive restructuring looks like in practice — you take the automatic thought out of your head, put it somewhere you can actually look at it, and check it against the evidence instead of just believing it because it showed up first. Research on this technique has found it measurably reduces the grip that negative or anxious thoughts have once they’re named and examined rather than just felt (Hofmann et al., 2012). Daniel didn’t wake up feeling great about the numbers. But he sent a different email than the one he’d drafted at midnight — one with three concrete hypotheses in it, not an apology.
Marisol and the Slow Erosion of Trying
There’s a slower, quieter version of this problem too, and it shows up in the long, grinding projects healthcare product work is full of — interoperability standards, EHR integrations, multi-year FDA pathways. When wins take that long to arrive, you’re exposed to a lot of small losses along the way: a delayed API from a hospital partner, a compliance reviewer who says no for the third time in a row.
Martin Seligman’s research on learned helplessness found something worth sitting with — after enough uncontrollable setbacks, people often stop trying even once they regain a real shot at changing the outcome (Seligman, 1972). Marisol, another composite of PMs I’ve heard about secondhand, led interoperability work for a hospital referral system. After her third rejected integration proposal, something in her just gave up a little. No point pitching anything ambitious — it always gets shot down anyway. She started submitting smaller, safer asks, even in cases where she genuinely believed the bolder version would help patients more.
What snapped her out of it wasn’t a pep talk. It was her manager, almost in passing, pointing out that the three rejections had come from three completely different causes — a budget freeze, a staffing shortage, an actual technical concern — not some pattern about her judgment. Separating what happened from what it supposedly meant about her turned out to matter more than any amount of encouragement.
What Actually Helps, Day to Day
None of this sticks after one good conversation. It’s more like a habit you have to keep rebuilding.
One thing that helps: treating the artifact and yourself as two separate things. “Clunky” is a comment about a dropdown menu, not about Priya as a product manager — but you have to say that to yourself out loud, or write it down, because your brain won’t do it automatically.
Another: paying attention to the base rate instead of the loudest voice in the room. One critical comment out of forty is a data point, not a verdict — and healthcare PMs, trained to spot risk everywhere, are often the worst at applying that same skepticism to a single piece of harsh feedback.
There’s also something to be said for treating institutional delay as information rather than an insult. A proposal getting rejected in a heavily regulated environment usually says more about the institution’s constraints than about the quality of your thinking. People who explain their setbacks this way — as specific and situational rather than as evidence of some personal flaw — tend to hold up better over the long run, with less burnout across repeated stressors (Maddi, 2005).
And honestly, something as small as a two-minute end-of-day habit helps more than it should: write one sentence about what happened, and a separate sentence about what it means. “The pilot hospital paused testing” is what happened. “I’m failing at this” is a meaning your brain tacked on afterward, uninvited, and you’re allowed to reject it.
Back to Priya
Priya never did “solve” the clunky comment that night — she just closed the laptop, eventually, and slept badly. The next morning, though, she pulled the entire feedback report instead of the one line that had ruined her evening. Thirty-one of forty comments were positive. The clunky one turned out to reference a single dropdown that took two days to fix.
Healthcare product management is never going to hand out clean, unambiguous wins — that’s just the nature of building things where getting it wrong shows up in patient outcomes, not just a churn dashboard. Learning how to change negative thought patterns doesn’t mean pretending the stakes are smaller than they are. It means making sure the story running through your head after a hard day is the accurate one — not just the one that got there first and shouted the loudest.
The FACT Framework: A 4-Step Reset for Negative Thinking
When a difficult piece of feedback lands, it can be surprisingly easy to move from what happened to what you think it says about you. The FACT framework offers a simple way to interrupt that process.
F — Find the automatic thought
First, identify the thought that appeared immediately after the event.
Don’t soften it. Write down exactly what your mind said.
Example:
“The nurses think the product is clunky, so I’ve failed as a product manager.”
The important part is recognising that this is a thought, not necessarily a fact.
A — Assess the evidence
Now separate what you actually know from what you’re assuming.
Ask:
- What objectively happened?
- What evidence supports my interpretation?
- What evidence contradicts it?
- Am I generalising from one person’s experience?
- Am I predicting something that hasn’t happened yet?
- What would I say if a colleague were in this situation?
For Priya, the fact might be:
“One nurse described one part of the product as clunky.”
The interpretation was:
“The users hate the product, and I’m bad at my job.”
Those are very different statements.
C — Create a more accurate interpretation
The goal isn’t to replace a negative thought with an unrealistically positive one.
Instead, create a balanced interpretation that fits the evidence.
Instead of:
“The product has failed.”
Try:
“The feedback has identified a usability problem that we need to investigate.”
Instead of:
“Leadership has lost confidence in me.”
Try:
“The adoption target wasn’t met. I need to understand why and decide what we can change.”
This shift matters because it moves you from self-judgement to problem-solving.
T — Turn the thought into an action
Finally, ask:
“What is the next useful thing I can do?”
For example:
| Automatic thought | Evidence-based interpretation | Next action |
| “Users hate the product.” | One workflow received negative feedback. | Review the wider feedback and usability data. |
| “I’ve failed.” | Adoption is below target. | Identify the barriers to adoption and test hypotheses. |
| “This will damage my career.” | The project has encountered a setback. | Prepare a clear explanation and recovery plan. |
| “There’s no point trying again.” | Previous proposals failed for different reasons. | Identify which constraints have changed and revisit the viable options. |
The aim isn’t to eliminate difficult thoughts. It’s to prevent an automatic thought from becoming an automatic decision.
A two-minute version for busy healthcare teams
You don’t need a therapy session every time something goes wrong. At the end of a difficult meeting, feedback session, or product review, ask yourself four questions:
- What happened?
Write the observable fact. - What did I tell myself it meant?
Write the interpretation. - What does the evidence actually tell me?
Look beyond the loudest or most negative piece of information. - What is one useful action I can take next?
Turn reflection into action.
For healthcare professionals working in high-stakes environments, this distinction can be particularly valuable. A setback is information. It doesn’t automatically have to become a judgement about your competence, your team, or your future.
References
- Beck, A. T. (1979). Cognitive therapy and the emotional disorders. International Universities Press.
- Hofmann, S. G., Asnaani, A., Vonk, I. J. J., Sawyer, A. T., & Fang, A. (2012). The efficacy of cognitive behavioral therapy: A review of meta-analyses. Cognitive Therapy and Research, 36(5), 427–440. https://doi.org/10.1007/s10608-012-9476-1
- Maddi, S. R. (2005). On hardiness and other pathways to resilience. American Psychologist, 60(3), 261–262. https://doi.org/10.1037/0003-066X.60.3.261