The line between product thinking and being difficult isn't the no

Every engineer who has worked with clients knows the moment. Someone describes what they want, you can already see what it will cost to build and maintain, and you have to say something. Most of the advice available at that point is about whether to object at all: pick your battles, don't be the difficult one, remember who's paying. Almost none of it is about the part that actually decides how the next six months go, which is the sentence that comes immediately after the objection.

I think that sentence is the whole job. Not the no. What follows it.

The industry has quietly agreed that this matters, and has almost nothing to say about how to do it. A systematic mapping of 44 studies found communication mentioned in 91% of them, ahead of teamwork at 68%, the most-cited soft skill in the field by a distance. A larger meta-analysis, 33 studies across 12 countries and over four thousand respondents, found teamwork and communication discussed more than any other soft-skill category. It also found something more awkward: most employers consider soft skills untrainable in the workplace, which makes them the critical hurdle for employment, and short-term pressure for technical skills means the need for them gets overlooked anyway. One study in that pool reported soft skills making up seven of the top eight most important skills for the job.

So the skill everyone ranks first is the one employers have decided can't be taught, and a 2026 review of the literature adds that nobody has a reliable way to measure it either. Assessing whether someone communicates well remains subjective in a way that testing programming ability is not. A skill that is universally demanded, considered untrainable, and effectively unmeasurable gets passed on as folklore, if it gets passed on at all.

The folklore is bad. "Push back when you need to" is not advice. Neither is "always come with a solution," which sounds sensible until you're in a room where you genuinely don't have one yet and you're being asked to commit.

Here is what I've found underneath most of these conversations. The person across the table is not describing a problem. They are describing a solution they have already picked, usually for good reasons, and the reasons are invisible to you.

Fred Brooks made the point in 1986 and it hasn't dated: the hardest single part of building a software system is deciding precisely what to build, and the most important function the builder performs for the client is the iterative extraction and refinement of the product requirements. He went further, arguing that the assumption you can specify a satisfactory system in advance and simply have it built is fundamentally wrong.

That same meta-analysis, thirty years of studies later, ranks requirements above development itself in importance. Two independent bodies of evidence, forty years apart, saying the hard part isn't the building.

If you take that seriously, the objection isn't an interruption of the work. It is the work. Which changes what you're doing when you push back. You're not defending your time or your architecture. You're doing requirements extraction under commercial pressure, in real time, with someone who thinks the requirements are already settled.

I worked on a job board where the client wanted every combination of filters to be indexable. Their reasoning was sound and evidence-based: they could see they got far more traction on pages Google could actually reach. What they asked for was that any filter combination which existed should have a page behind it. And they assumed this was automatic.

It isn't. What they were describing, once you unpack it, is a background job that watches for new postings, works out whether each one creates a filter combination that didn't previously exist, writes a page into the CMS, and reconciles all of that against a record of which URLs already exist so you don't duplicate or orphan anything. That is not a feature. It is a system, with its own state, its own failure modes, and its own permanent maintenance cost. It has to stay correct forever. And it sounds, when you say it out loud in a meeting, like one line item.

That gap is the thing. Not the client's carelessness, because they weren't careless. They described an outcome. Someone has to price the mechanism, and that someone is you.

We objected. The ask was out of scope, and more expensive to keep alive than it looked. What made that objection land was not that it was correct. Plenty of correct objections get absorbed and ignored. It landed because we said what it would cost in terms the client could act on, and we didn't stop talking.

What we came back with used something already in the system. We were running Elastic, and Elastic returns filters as aggregations, which means a filter only appears if there is at least one job behind it. The data already knew which combinations were real. We didn't need to generate anything or track anything, because the existence of the filter was the guarantee. Dynamic routes in Next.js, filters grouped by type, and the combinations ordered alphabetically so that two users arriving at the same result set by clicking things in a different order would land on the same URL rather than generating two pages of identical content.

That last detail is the one I'd point at. It isn't cleverness for its own sake. Two paths to one result set is a real duplication problem that you don't see until it's in production and your own pages are competing with each other. Working that out is what "still thinking about the problem" actually looks like from the outside.

The client accepted it. It delivered the requirement more completely than the original ask, because a generated page can fall out of sync and an aggregation cannot, and we had something in front of them to test in a fraction of the time the original approach would have taken.

The lesson I'd draw isn't "propose alternatives." It's narrower. Pushback has to be denominated in something the other person can spend. Scope and maintenance cost were currency that client understood, because they were paying for both. Had I argued elegance or architectural purity, I'd have been right and ignored.

The harder version is when the person asking doesn't sit on the other side of a contract.

On another project, a heavily animated site, the requirement was that the main background colour changed as you scrolled, driven by whichever component was entering the viewport. Easy to describe. Genuinely awkward to build, because you're detecting geometry against components whose height varies with their content, so the calculation shifts depending on what's inside each one.

It added nothing to the experience of using the site. It was pure brand. And the person who wanted it was internal to the agency, more senior than me, which meant the word "scope" was not available. You can tell a client something is out of scope. You cannot tell a colleague that. You can only tell them it won't work, and then you still have to sit next to them tomorrow.

Most writing about pushback assumes the client is the hard case. In my experience it's the reverse. Internal objections have no contract behind them, no change request, no commercial framing to hide inside. The cost of getting it wrong isn't a difficult email, it's a working relationship.

So the currency had to change. Effort was worthless as an argument, because he wasn't paying for my time in any way he could feel. Fragility wasn't. What I put to him was a question: would you rather have something that's broken, or something that's solid but slightly less impressive? I couldn't promise the full version wouldn't break. I said so. And a wow moment that breaks in front of users doesn't protect the brand it exists to serve, it damages it.

That reframed the decision as one only he could make, in the terms he actually cared about. He took it. We shipped it on desktop only.

Mobile was excluded and stayed excluded, and not as a consolation prize. On mobile the thing genuinely stopped working: text was disappearing against shifting backgrounds, which is a contrast and accessibility problem, and the viewport calculation was unreliable because iOS and Android handle browser chrome differently. Desktop-only wasn't a watered-down version of the feature. It was the line where the feature stopped being one.

It's still on the site. It still works, and it scales to new components. Nobody has complained. It is also still fragile, which is why it's documented. That's not a triumph, and I wouldn't dress it up as one. It's a contained cost that somebody wrote down, which is roughly the best outcome available when you lose the argument on the merits and win it on the shape.

Being difficult and thinking about the product look identical for about ten seconds. Both start with someone saying no to a thing that was already agreed in someone's head.

They diverge in what happens next. Obstruction ends the conversation. It hands back a closed door and treats the other person's problem as no longer yours. Product thinking keeps the conversation open, in language the other person can act on, and treats the outcome they were reaching for as still legitimate even when the mechanism they picked isn't.

You don't need the answer ready to be allowed to object. That's the part I'd most want to hand to someone earlier in their career, because it's the part that keeps people quiet when they can see exactly where a project is heading. You are allowed to say "this costs more than it looks and I don't think it's the cheapest way to get what you want."

What you're not allowed to do is leave it there, and the fix is smaller than people think. Two things have to be attached to the objection before you stop speaking. A direction, even a vague one: not the solution, just the shape of where you think the answer lives. And a date. "There's another way to get you the same outcome and I want to work it through properly. Give me until Thursday."

That's it. That's the entire difference between an obstacle and a partner, and it takes about four seconds to say.

It works because it changes what the no is. On its own, an objection is a verdict, and verdicts invite escalation: the client goes over your head, the stakeholder finds someone who'll say yes, the whole thing becomes a negotiation about authority rather than about the product. An objection with a direction and a date is a step in a process that's still running. Nobody escalates a process that's still running. You've bought yourself the thing you actually needed, which was not agreement but time to think, and you've bought it without asking anyone to trust you on faith.

The date is the load-bearing half. A direction without a deadline is how "we'll look at alternatives" becomes nothing, and everyone in the room has seen that happen enough times to discount it. A date makes it real, and it puts the cost on you rather than them, which is what makes it credible.

Then you have to turn up on Thursday. Not necessarily with a solution. Sometimes you come back and say the original approach is the only one and here's what it'll cost, and that's a fine outcome, because you've priced it honestly instead of building it resentfully. The commitment isn't to be right. It's to still be holding the problem.

So when you're mid-objection and genuinely unsure which side of the line you're on, the test isn't whether you're right. You probably are. It's whether you've given the person across from you something to do next, and a day on which it happens.