Getting good feedback is one of the hardest parts of product work. You send a doc. You ask for thoughts and it’s usually met with silence or “Looks good to me.” You follow up for more and maybe one person responds or you get, “move the button in the flow to the top right”. Everyone else has “their own priorities.”
The problem usually isn’t that people don’t care. It’s that you’re asking them to do too much cognitive work. People respond to artifacts more than abstractions.
The Visualization Tax
When you describe an idea in words, even with clear requirements, you’re asking people to construct a mental model before they can react to it. That’s an expensive task if the person is even capable of doing it. It requires them to translate your description into something concrete, fill in the gaps you didn’t specify, and then form an opinion about this thing they’ve imagined. And that’s assuming that they had the right context to begin with.
Most people won’t do that work. Not because they’re lazy, but because they have their own problems to solve and you’re asking them to solve yours first.
But show someone a wireframe, and suddenly everyone has opinions. The signup flow feels clunky. That button is in the wrong place. Why does it ask for email twice? The reactions come faster because the majority of the cognitive work is already done. Using a wireframe isn’t a minor efficiency gain, it’s often the difference between getting feedback and getting nothing.
The GenAI Shift
I’ve seen this most clearly on problems that look trivial as written requirements and only reveal their complexity once something is built. A “unified user profile” shared between Product A and Product B sounds straightforward on paper. Even when the requirements are clear, it’s not a disagreement about wording, it’s about interpretation. Everyone imagined a slightly different version of how identity stitched across products, what happened when data conflicted, and which system was actually in charge.
Until there was something to look at, everyone assumed alignment. The moment there was a concrete flow to click through, the real questions surfaced: which fields are authoritative, which product owned the lifecycle, and what “unified” actually meant in practice. The problem wasn’t lack of documentation or specificity. It was that the hard parts became clearer once the idea was made visible.
Getting to a wireframe used to be expensive. Creating mockups that fit usually meant involving designers, waiting for cycles, or spending hours in Figma yourself. For most PMs, the economics didn’t work for early-stage ideas, so you defaulted to written specs, back of the napkin sketches, and hoped that would be enough to communicate the idea and for people to engage.
LLMs have changed that math. The PM who shows a rough prototype gets better feedback than the one who sends a polished PRD. Not because the prototype is better documented, but because it’s something people can see. And even better if it’s something they can interact with.
AI hasn’t changed the need for visuals, it’s just removed the excuse for not having them.
With your style guide, component library, and basic flows as context, you can generate working mockups or even functional prototypes in the time it used to take to write a requirements doc. This isn’t about replacing designers or killing the spec, it’s about having something concrete to react to before you’ve committed real resources.
I can describe that same completely new Unified User Profile page that spans Product A and Product B, attach our design system, and have something clickable in under 20 minutes. Not because it’s production-ready, but because it makes the tradeoffs visible early enough for people to engage with them. While the quality of the prototype is relevant, it’s not the most important thing. It’s often better to have an imperfect prototype because it gives people something to “shoot at.”
But don’t make things look too good, too early. If your prototype is pixel-perfect, like matching the brand colors, using real icons, and perfect spacing, people will assume the work is done and will typically be more hesitant to give you feedback. This is especially true for bigger changes. When the fidelity is too high, the feedback becomes more shallow and superficial. You’ll get comments on the hex codes or the phrasing of a sub-header because those are the only things left that look “changeable.” If you want deep feedback on the logic or the flow, keep the artifact slightly unpolished. Use wireframe mode. Use “ugly” placeholders. It signals that the idea is still fluid and that you’re actually looking for a partner in the build, not just an auditor to sign off on the finish.
If you’re communicating a backend change or dataflow, the prototype route won’t be the quick win. But the principle still holds. Before and after diagrams still beat a wall of text for high-level context.
Why Jira and Confluence Alone Don’t Work
You know the pattern: “I’ve documented the requirements in Confluence, please review and add comments.” Two weeks later, zero comments and 2 thumbs up.
Documentation still matters. Specs, PRDs, and Confluence pages are necessary for alignment, traceability, and decisions that need to outlive the conversation. They’re how work scales and how context survives turnover. But they’re a poor primary tool for generating feedback. Reading a doc is a sequential, high-effort task. Reacting to a concrete artifact is immediate. One is good for recording decisions; the other is good for challenging them. If you use docs as your main feedback surface, you’re asking people to do the hardest work at the least motivated moment.
The friction is too high because the tool is doing the wrong job at the wrong time. Open the document, context switch by reading through the executive summary and goals to level set, figure out where to leave relevant feedback, decide if you’re the right person for the feedback you’re leaving, write something coherent, constructive and useful. That’s a lot of steps for something that isn’t their top priority.
Compare this to: “Here’s a prototype, click through it, tell me what feels wrong.” The context lives in the spec, but the prototype means they don’t have to hold it all in their heads while reading. The feedback can be more immediate. They don’t need to remember your requirements while visualizing them or filling in the wireframes, they’re experiencing them. The more friction between your request and their response, the fewer responses you’ll get.
Before you bring it outside the team, test your engagement internally. Your PM colleagues are a low-stakes testing ground. They understand the feedback problem firsthand, so they’ll tell you if your context is muddy or your ask is unclear. Use them to refine before you spend social capital on the engineering lead or business stakeholder who have other priorities than helping you through the initial iteration steps.
The Abstraction Problem
There’s a spectrum of feedback requests, and most PMs are stuck in the wrong end of it. This isn’t because PMs are careless, but because abstractions feel safer than commitments.
At one end, you get requests that are too abstract: “What do you think about improving onboarding?” People stall because they’d have to define the problem, imagine possible solutions, and then evaluate those imagined solutions. That’s not feedback, that’s asking them to do the design work for you.
At the other end, you get over-specified descriptions without anything concrete to react to: “We’re adding a six-step onboarding wizard with progressive disclosure and GDPR compliance…” Now people are forced to simulate the system in their heads. Most won’t bother or just tell you it’s too complicated without understanding why it might have to be this way. The few who do will imagine something different from what you intended.
The failure mode in both cases is the same: disagreement is delayed. Everyone sounds aligned because the hard tradeoffs are still abstract.
The sweet spot is concrete enough to make the tradeoffs visible, but bounded enough to focus the conversation. “Here’s the onboarding flow. We think first-time users should reach their first success metric in under three minutes. Does this accomplish that?” Now people aren’t reacting to an idea, they’re reacting to something much more concrete and they can give you useful feedback earlier in the process.
If your feedback only shows up after implementation, it’s usually because the real tradeoffs were invisible when the decision was made.
Making It Work
Good feedback requests combine a few elements. Assuming you have something visual to show, the rest is mechanics:
- A clear assertion. Don’t just ask “what do you think?” State what you believe and invite people to challenge it. “We think this checkout flow will reduce drop-off by 15%” is more likely to generate response than “thoughts on checkout?” Assertions give people something to agree or disagree with.
- Bounded scope. “Is this flow intuitive?” is better than “any feedback?” Constraints make it easier to respond.
- The outcome you need. Tell people what decision you’re trying to make and when. “I need to decide by Friday whether to include social login” changes the dynamic from “optional input” to “your input matters for this decision.”
- A reason they should care. “You’ve seen more checkout flows fail than anyone here, does this one work?” lands better than a generic ask. You’re acknowledging why they specifically are worth asking, which makes responding feel less like a chore and more like being consulted. A little targeted flattery goes a long way. People tend to engage more when the ask is about their expertise, not just your need.
There’s also productive framing. When you present something as a draft you’re confident in, people feel comfortable poking holes. When you present it as ‘I’m not sure about this,’ they often don’t want to pile on. But ‘I’m stuck on this part, what am I missing?’ works differently. Most people genuinely want to help when given a clear opening. You’re not asking them to judge your work; you’re inviting them to solve a problem with you.
One more trick in case you’re dealing with a notoriously silent person or group. Try leaving something obviously wrong in the room. Not a functional bug, but a “low-stakes” error. This is usually a misspelled prominent header or a button that’s clearly the wrong color. It sounds counterintuitive, but people have a hard-wired compulsion to correct things. Once someone breaks the seal by pointing out the “obvious” mistake, the psychological barrier to critiquing the rest of the work vanishes. They’ve entered “correction mode,” and it’s much easier to transition them from “that word is spelled wrong” to “actually, this entire step in the flow feels redundant.” Give them a small win so they have the momentum to give you the hard truths.
The Shift
PMs who struggle to get feedback often assume the problem is other people’s priorities or engagement. Sometimes that’s true. More often, the problem is that disagreement has been postponed by abstraction.
When you ask people to react to ideas instead of more visual or interactive artifacts, you’re asking them to do the hardest work in their heads, on their own time, with no shared frame of reference. Silence and shallow agreement are predictable outcomes, not cultural failures.
Different artifacts support different cognitive modes. Documentation is how decisions scale and persist. Concrete representations are how opinions form and tradeoffs surface. If you use the wrong one at the wrong time, you shouldn’t be surprised when feedback arrives late, or not at all.
The question isn’t “How do I get people to engage with my ideas?” It’s “How do I make engaging with my ideas easier than ignoring them?”
Show the thing. State your bet. Make it easy to react.
