Your inbox is full. Slack is piling up. Client messages need a response yesterday. Typing thoughtful replies to all of it takes hours you don't have.

Wispr Flow turns your voice into clean, professional text you can send the moment you stop talking. Speak like you would to a colleague — tangents and all — and get polished output. Emails, Slack, LinkedIn, WhatsApp, whatever's open.

89% of messages sent with zero edits. Used by teams at OpenAI, Vercel, and Clay. Works on Mac, Windows, and iPhone.

Try Wispr Flow free

Most Product Managers have a refinement session they would rather forget.

The one where you walked in with something you had been thinking about for weeks, something you believed in, something you had researched and shaped and were genuinely excited about, and the room received it with the particular silence that means the team is figuring out how to tell you it is not going to work. Or worse, the session where the pushback started immediately, before you had even finished explaining, and the next hour was a slow and uncomfortable negotiation between your conviction and their scepticism.

If you dread those meetings, you are in good company. And if you have been treating that dread as an unavoidable feature of the PM role, I want to suggest that it is actually a signal: not that refinement is inherently adversarial, but that something in how the process is being run can be improved.

The eight principles below are not a guide to winning arguments with your engineering team. They are a guide to creating the conditions under which those arguments rarely need to happen in the first place, and to navigating them constructively when they do.

Let us dive in.

Before we get into the specific actions, it is worth being honest about where refinement friction usually comes from.

Engineers are not, as a rule, resistant to new work because they are lazy or obstructive. They are resistant when they feel that a significant challenge has been dropped on them without adequate context, without genuine involvement in shaping it, and without recognition of the real complexity it involves. That resistance is not irrational. It is a reasonable response to feeling like a delivery mechanism rather than a thinking partner.

The refinement sessions that go badly almost always have their root cause somewhere earlier in the process, in a gap between how the PM developed the idea and how much of that development the team was part of. Fixing the session itself is possible, and the principles below address that. But the deeper fix is upstream, in how ideas move from initial thinking to team conversation.

With that in mind:

The first response to a challenging proposal is almost never the considered response.

When you present something that is genuinely difficult, something that will require significant engineering effort, a meaningful architectural change, or a departure from how things have been done before, the immediate reaction from the team is often one of resistance. This is not evidence that the idea is wrong. It is evidence that the idea is hard, and that the team is processing the implications in real time, without the weeks of context and consideration that you have had.

The mistake is to treat that initial reaction as a final verdict. A PM who becomes defensive or discouraged the moment the room pushes back is a PM who will either retreat from good ideas prematurely or dig into a confrontational dynamic that makes the subsequent conversation much harder.

The more effective approach is to hold your position calmly while genuinely acknowledging the concern. You are not dismissing the difficulty. You are asking for the space to work through it together, which is what the refinement session is for. Sometimes what looks like resistance at the start of a conversation looks like problem-solving by the end of it, if the PM can stay steady long enough to get there.

Give the team time to process. Not every objection needs an immediate response. Some of the best refinement conversations happen after a short break, or in the follow-up session the week after, when the initial shock has settled and people have had time to think.

This is the principle that, if applied consistently, reduces the need for all the others.

The refinement session that goes badly is almost always one where the team is encountering the idea for the first time under delivery pressure, in a context where they are being asked to commit to work they have not had the chance to think about. The surprise, the complexity, the lack of prior context: all of these combine to produce exactly the kind of defensive, resistant response that makes the session feel like a battle.

The refinement session that goes well is almost always one where the team has been part of the thinking before it arrived in the room. Where the engineers were consulted during the ideation phase and had the opportunity to flag technical concerns early, when those concerns could still shape the proposal rather than threaten it. Where the designers contributed to the concept before it was fully formed. Where the conversation in the session is about refinement and commitment, not about whether to do the thing at all.

Getting there requires a habit change: sharing early thinking with the team before it is finished, rather than presenting finished thinking for the team to receive. This feels uncomfortable for many PMs, because early thinking is incomplete and uncertain, and presenting it exposes that uncertainty. But that exposure is precisely what makes the subsequent conversation better. The team is not reacting to a fait accompli. They are contributing to something that is still being shaped, which is a very different and much more productive dynamic.

There is an important distinction between an opinion and an analysis, and refinement sessions often conflate the two.

An engineer who says "this will take forever" or "this is never going to work" is expressing a view. That view may be correct, and it deserves to be taken seriously. But it is not, by itself, a basis for abandoning or substantially revising a well-considered proposal. It is the beginning of a conversation that needs to go deeper.

The appropriate response is to ask what is driving the assessment. Not in a challenging or dismissive way, but in a genuinely curious one: what specifically makes this difficult? What is the technical constraint that creates the complexity? Is the difficulty in the approach being envisioned, or in the problem itself? Could a different technical approach change the picture?

This line of questioning serves two purposes simultaneously. It forces the conversation to move from opinion to analysis, which is where productive problem-solving happens. And it frequently reveals that the perceived difficulty is more tractable than the initial reaction suggested, either because there is a simpler approach the team had not yet considered, or because the scope can be adjusted in ways that reduce the complexity without compromising the core value.

You should, of course, be prepared to bring your own evidence to the conversation. The data that validates the user problem, the research that supports the strategic rationale, the metrics that justify the investment: these are the foundations of your credibility in the room. If the team is going to be asked to do difficult things, they deserve to understand clearly why those things are worth the difficulty.

The single most useful tool in a difficult refinement conversation is also the simplest one.

Ask why. Then ask why again. Then ask why again after that.

This is not a rhetorical technique for exposing the weakness of the team's objections. It is a genuine attempt to understand the nature of the difficulty, because the stated objection is often not the real one. An engineer who says a feature is too complex may be pointing at a specific architectural constraint that the PM is not aware of. An engineer who says a timeline is unrealistic may be accounting for dependencies that are not visible in the product brief. An engineer who says something will not work may have tried something similar in a previous context and learned something important from the failure.

The why questions surface that context. And more often than is initially apparent, the process of articulating a concern out loud, of being asked to explain it step by step rather than simply assert it, produces insights that neither the PM nor the engineer had before the conversation. Problems that seemed intractable when stated as a general objection reveal specific and addressable components when walked through carefully.

This is one of the reasons that the best refinement sessions feel more like collaborative problem-solving than like negotiations. The PM's job in those sessions is not to defend a position against attack. It is to understand the engineering reality well enough to make good decisions about scope, approach, and priority, and the why questions are the primary tool for building that understanding.

Engineers are better at solving problems when they understand why the problems matter. This sounds obvious, but the operational implication is one that many PMs underinvest in.

When a proposal meets resistance, the PM's instinct is often to defend the proposal itself: to argue for its technical feasibility, to push back on the effort estimates, to negotiate the scope. What is often more effective is to step back and make the case for why the problem being solved is genuinely important.

The feature that seems like an arbitrary addition from the engineering team's vantage point looks very different when the PM explains the specific user pain it addresses, the customer feedback that identified it as a priority, the competitive gap it closes, or the strategic objective it serves. The difficulty does not change, but the motivation to work through that difficulty changes significantly.

Leadership support is also worth naming explicitly when it exists. Not as a threat or an appeal to authority, but as a piece of context that signals the organisation's commitment to the work. A difficult initiative that has genuine executive sponsorship is a different proposition from one that feels like a PM's personal preference. Sharing that context honestly is not political maneuvering. It is helping the team understand the full picture.

If the idea fits the product's mission, is supported by real evidence, and aligns with the strategic direction the organisation is committed to, say all of those things clearly and specifically. The team deserves to know why they are being asked to do hard things, and that knowledge makes the hard things more worthwhile.

One source of refinement friction that rarely gets named is the blank canvas problem.

When a PM presents a user need or a strategic objective without any proposed direction for how it might be addressed, the engineering team is being asked to generate solutions under time pressure, in a group setting, without the weeks of context the PM has been living in. That is not a creative brief. It is a stressful improvisation exercise, and the outputs it produces reflect that.

Coming to refinement with a rough proposed approach, clearly labelled as a starting point rather than a finished specification, changes the dynamic significantly. The team now has something concrete to react to, which is a much easier cognitive task than generating ideas from nothing. Their pushback becomes more specific and more useful. The conversation moves faster, because everyone is orienting around the same artifact rather than trying to build a shared picture from a verbal description alone.

The proposal does not need to be technically sophisticated. A rough user journey, a simple flow diagram, or a written description of the intended experience is enough to give the conversation a foundation. The PM's job is not to specify the solution; it is to give the team enough of a starting point that their expertise has something genuine to work with. The distinction between presenting a direction and dictating an implementation is significant, and maintaining it clearly is what keeps this principle from sliding into micromanagement.

There are situations where, having done everything above, genuine disagreement remains. The PM has shared the context, asked the questions, understood the objections, and still believes the work should proceed. The team remains unconvinced.

In those situations, the PM does ultimately have the authority to make the call. It is your responsibility to decide what the product needs, and a team's reluctance, even sincere and well-reasoned reluctance, does not automatically override that responsibility.

It is also an option that should be used as infrequently as possible and with clear awareness of what it costs.

The team that is directed to do work they have argued against will do that work. They will do it less enthusiastically, with less creative investment in finding the best approach, and with a degree of damage to the collaborative relationship that takes time to repair. The PM who uses authority regularly to override team judgment will eventually find that the team stops offering genuine judgment, because experience has taught them that it does not change the outcome.

Before reaching for the authority card, there is usually one more move worth trying: find the smallest version of the idea that can be tested with minimal engineering effort. An MVP that proves the concept, that demonstrates the value to real users with a fraction of the investment the full feature would require, is often enough to shift the team's view. And if it is not enough to prove the value, it was probably not enough to justify the full investment either.

When you do use it, be transparent about the fact that you are using it, acknowledge the team's concerns honestly, and commit to revisiting the decision if the evidence supports doing so.

Refinement sessions frequently end with a version of consensus that turns out, in the following days, not to have been consensus at all.

The team nodded. The PM felt the room was aligned. Two days later, the ticket is being built in a way that does not match what the PM thought was agreed, or the engineer working on it has a different understanding of the scope than the one the PM left the session with. This is not dishonesty on anyone's part. It is the predictable result of a session that ended without making the agreement explicit.

Before closing any refinement session, take five minutes to state aloud what has been decided. What is in scope and what is explicitly out of scope for this iteration. What the acceptance criteria are. What open questions remain and who owns resolving them by when. What the next step is and who is responsible for it.

Then ask the room whether that matches their understanding.

This small discipline surfaces misalignments while the team is still in the room, when they are cheap to resolve, rather than three days into a sprint, when they are expensive. It also creates a shared reference point for the work that follows, which reduces the number of mid-sprint clarification conversations that interrupt delivery and quietly erode trust in the planning process.

The five minutes it takes is one of the highest-return investments available in any meeting.

The refinement session is not, at its core, a negotiation between what the PM wants to build and what the engineering team is willing to build. It is a collaborative process for translating a product intention into a shared technical understanding of what will be built and how.

When it works well, both sides leave with more than they came in with. The PM has a more realistic understanding of the complexity and the constraints. The engineering team has a clearer understanding of the user problem and the strategic rationale. The proposal has been improved by the combination of product thinking and engineering expertise, and the team is genuinely committed to the work because they helped shape it.

Getting to that outcome consistently requires the PM to invest in the process before the session, to bring genuine curiosity rather than defended positions into the room, and to trust that an engineering team that understands why something matters will almost always find a way to build it.

The sessions you dread are usually the ones where that trust has not yet been established. Building it is slower than winning an argument. It is also considerably more durable.

A question worth sitting with: in your most difficult refinement sessions, how much of the friction was created in the session itself, and how much was created by what happened before it?

The honest answer to that question is usually the most useful guide to where the process needs to change.