Why Your Stakeholders Stop Telling You What They Actually Need

I’m not a couples therapist. I’m a Product Owner and business analyst. And when I first read Gottman’s work, I recognized something I’d been watching destroy projects for fifteen years.

The exact same pattern, in its professional form, is what makes stakeholders stop telling Product Owners the real problem.

What Gottman Actually Found

Gottman identified four destructive communication patterns he calls the Four Horsemen of the Apocalypse: criticism, contempt, defensiveness, and stonewalling. Of the four, contempt is the worst. In his research, it’s the single strongest statistical predictor of divorce, more predictive than frequency of arguments, financial stress, or physical infidelity.

The counterpart, the behavior that sustains strong relationships, is what Gottman calls accepting influence: the willingness to hear someone out, take their half-formed idea seriously, and negotiate rather than dominate.

Couples who accept influence stay together. Couples who default to contempt don’t.

There’s also a silent symptom worth knowing. When one partner stops sharing their plans and dreams, Gottman’s research shows that’s often a late-stage signal, repeated dismissals have taught them the other person isn’t a safe audience. Arguments still show communication. Silence doesn’t.

The Same Pattern Is Happening in Your Refinement Meeting

Here’s where it gets uncomfortable.

A stakeholder walks into your refinement with something vague. Their words are messy, incomplete, probably inconsistent. Maybe they say “we need a simple dashboard” or “customers are complaining about checkout, and also can we look at mobile?”

You have two paths.

Path one: “That’s not a proper user story.” “Come back when you have actual requirements.” A small sigh. An eye-roll at the vagueness. You paraphrase what they said into what you think they meant, fill in the gaps with your own assumptions, and send them on their way.

Path two: “Tell me more. Let me ask you some questions.”

The first path is the professional version of contempt. It’s small. It feels efficient. It even feels like good boundary-setting. But it has a predictable, compounding outcome.

Stakeholders stop bringing you real problems.

They bring you sanitized, pre-structured requests that hide what they actually need. They involve you later, after “they’ve already figured it out.” They go around you to someone who will listen, or to ChatGPT. Or worst, they stop trying altogether and quietly accept that the feature they needed isn’t going to happen.

The professional version of Gottman’s silence looks like this. The stakeholder who used to call you first now sends a finished brief that doesn’t quite match reality. The department that used to surface real problems now sends change requests for features that were decided elsewhere. The client who used to think out loud with you now forwards filtered requirements that solve the wrong problem.

You don’t get divorced. You get disinvited.

Vladimir’s Call

A few weeks ago my friend Vladimir called me. He’s a cameraman supervisor at a state TV station.

“Dejan, I need a simple app. A shift schedule. Nothing complicated, just a table, a few workers, who works when. Can you make that?”

I had two options.

Option one was to say: “Vladimir, that’s not a real brief. You don’t know what you want. Come back when you’ve thought it through.” That’s the professional version of “that’s stupid, you couldn’t do it anyway.” The conversation would have ended there. He’d have asked someone else, or quietly dropped it, and whatever he actually needed would never have been built.

Option two was to say: “Okay, tell me what you need.”

I chose the second. Ninety minutes later, from what started as a “simple app,” we had a functional specification with twelve sections, a priority algorithm, a displacement mechanism, weekend combination logic, and seven edge cases Vladimir didn’t know existed.

Vladimir wasn’t wrong to call it simple. He’s a cameraman, not a business analyst. The problem looked simple in his head. My job was to pull it out, ask the right questions, and turn it into something that could be built.

That’s the professional version of what Gottman calls accepting influence. Not dismissal. Not rewriting what someone said into what you wish they’d said. Preserving their actual words, asking the right questions, and structuring together.

The Concrete Rule That Turns Theory Into Practice

In the five-step framework I teach for backlog refinement, the second step has a specific, strict rule.

Paste the stakeholder’s exact words. Do not paraphrase. Do not clean up. Do not summarize.

This sounds small. It isn’t.

Every time you paraphrase what a stakeholder said, you smuggle in your own assumptions. You narrow their meaning to what you expected to hear. You lose the weird phrasing, the emotional emphasis, the word that didn’t quite fit, which is often the signal that something interesting is underneath.

When you preserve raw input and feed it back to AI with the instruction “ask clarifying questions, do not assume anything beyond what is stated”, you get back the 47 questions Vladimir didn’t know he needed to answer. You get back the edge cases. You get back the algorithm he never mentioned because it was implicit in his head.

Preservation before translation. It’s the professional form of Gottman’s rule: hear what was actually said before you respond to it.

The Signal That Should Concern You

If you manage a product, ask yourself three questions.

When was the last time a stakeholder called you with something they hadn’t thought through yet? When was the last time someone brought you a problem before they’d already decided on the solution? When was the last time a client rambled at you for twenty minutes about something vague?

If the answer is “not recently,” it’s worth considering whether they’ve learned you’re not a safe place to do that.

Arguments still show engagement. Sanitized briefs don’t.

What to Do in Your Next Refinement Meeting

Three specific moves you can make tomorrow.

1. Withhold the dismissive reaction for sixty seconds. When someone brings you a vague request, resist the urge to correct, reframe, or rush them into user-story format. Let them talk.
2. Capture the exact words. Whatever system you use, Jira, Azure DevOps, your notebook, paste the stakeholder’s raw phrasing first. Paraphrase later, clearly labeled as your interpretation.
3. Ask three clarifying questions before writing anything. Not “what’s the acceptance criteria.” Something like who is this for, what happens if we don’t build it, what does success look like in six weeks.

The work you’re doing in these three moves is the same work Gottman found sustains marriages. Take half-formed input seriously. Engage with what was actually said. Negotiate rather than dominate.

The Close (FIX for Stakeholders Stop Telling You)

Gottman’s most-quoted line, adapted for work: be the person your partner wants to tell their dreams to, because if you’re not, someone else will be.

The professional version is structurally identical.

Be the Product Owner your stakeholder wants to bring the messy, half-formed, barely-articulated real problem to. Because if you’re not, they’ll stop bringing them, to you or to anyone. And the project that would have worked gets quietly replaced by the one that was safe to mention.

Two ways to go deeper

Frequently Asked Questions

What is contempt in Gottman’s research?

Contempt is one of the “Four Horsemen” destructive communication patterns Dr. John Gottman identified through forty years of couples research. It includes eye-rolling, sarcasm, mocking, and moral superiority. It’s the single strongest statistical predictor of divorce, stronger than frequency of arguments, financial stress, or physical infidelity.

How does contempt apply to stakeholder communication in Agile?

The same pattern appears when Product Owners or business analysts dismiss half-formed stakeholder input as “not a proper requirement” or paraphrase it away. Over time, stakeholders learn that bringing raw, messy problems is unsafe, and they stop doing it. The real problem never reaches the person who could solve it, and the backlog fills with safe-but-wrong work.

What is Raw Request Capture in backlog refinement?

Raw Request Capture is the second step of the C.R.A.F.T. framework for AI-powered backlog refinement. The rule is to paste the stakeholder’s exact words, in quotation marks, without paraphrasing. This preserves original meaning and prevents the Product Owner from smuggling in assumptions that narrow the real requirement.

Why shouldn’t Product Owners paraphrase stakeholder requests?

Paraphrasing feels efficient but systematically strips information. Emphasis, unusual phrasing, and emotional tone often carry the signal that something important is underneath. When those get cleaned up into polished user-story language, the Product Owner’s assumptions replace the stakeholder’s intent, and the gap surfaces later as missed edge cases or wrong-feature builds.

What is the silent signal that a stakeholder has lost trust in a Product Owner?

When stakeholders stop bringing you raw, unfinished problems and start bringing you pre-structured requests with the solution already decided, that’s the professional parallel to Gottman’s silence. Arguments and debates show continued engagement. Polished, sanitized input usually means the stakeholder has stopped treating you as a safe space to think out loud.

What is the C.R.A.F.T. framework?

C.R.A.F.T. is a five-step framework for AI-powered backlog refinement: Context Injection, Raw Request Capture, Ask for Structure, Force Edge Cases, Test and Validate. It produces a sprint-ready user story with acceptance criteria, Gherkin scenarios, and an INVEST quality check in under ten minutes per story.