Should We Build This?

The hidden ask in "should we build this?"

Picture this: the CEO says, "Should we add CSV export to the dashboard? Customers keep asking." Your tech lead says, "We could probably get something in by month-end." The room moves on.

Six weeks later it ships. Along the way it ate one engineer for an extra sprint, broke pagination once in production, and required a real change to billing because exports count against the customer's data quota.

Nobody lied. The PM was asking "is this a good idea?" and the engineer was silently running a second question — "what does this actually take?" — that nobody put on the table. This chapter teaches you to read the second question out loud.

What "complexity" actually means to an engineer

Complexity is not lines of code. It's the shape of the work — meaning how many systems it touches, how many states it can land in, how many things break if it's wrong, and how much of it the engineer can't yet see.

A team I worked with shipped a complete design refresh — 4,200 lines across the app — in two days. The same week, they spent three weeks on a 30-line password-reset fix that touched the email service, the audit log, the rate limiter, and an old retry queue nobody remembered owning. Lines of code told you nothing. Shape told you everything.

When an engineer says "this is more complex than it looks," what they mean is: I can see edges of this problem you haven't seen yet, and I haven't finished counting them.

The five dimensions engineers are quietly weighing

Engineers don't name these out loud. They calibrate against all five when they react to a feature idea. Once you can name them, "this is harder than it looks" stops being a vibe and becomes a conversation with five entry points.

1. Integration — how many seams the work crosses

Each system the work touches — auth, payments, email, mobile, the data warehouse, the admin tool nobody remembers — is a seam (meaning a boundary where a bug can hide and where coordination work appears).

A "Verified email" badge next to the user's name. UI change, two days, right? In practice it had to know if the user verified (auth), update in real time (WebSockets), render on mobile (separate codebase, separate release cycle), and not break the CSV export (which needed to know about the new attribute). One badge, four teams, six weeks.

2. State — the new behaviors the system has to handle

Adding one option multiplies the valid system states the code has to behave correctly in.

"Add a Pause button to subscriptions." One new state? Until you list it: paused-during-trial, paused-with-pending-payment, paused-during-cancellation, paused-on-a-team-plan, paused-then-resumed-mid-month. Each is a behavior decision (does the customer get charged on resume? what's the proration?) and a test case. The "one" new state is really seven.

3. Scale — whether this works at 10×

A feature fine for the median user can collapse for the tail.

A "friends who like this" page works beautifully when most users have 50 friends. The enterprise account with 50,000 internal users hits it and the database gives up. The code didn't change. The data did.

4. Novelty — has anyone done this before?

Familiar work is fast. New work has unknown unknowns, and the estimate is fiction until somebody tries.

"Add SSO" in a SaaS that's already integrated three providers: two weeks, predictable. "Add SSO" in a product that's never touched it: 6–10 weeks, most of it spent discovering what they didn't know they didn't know. Same feature, different novelty, ~4× cost.

5. Reversibility — can we undo it without pain?

Some changes are one-way doors (meaning once you ship them, getting back is expensive or impossible).

Renaming a button is reversible — deploy again. Migrating 18 months of customer data to a new schema is not. "Rolling it back" means a second migration and probably a weekend. Engineers get more cautious as reversibility drops, even when the work itself looks straightforward.

Reading a feasibility check

Engineers rarely give flat yeses or flat nos. They give shaded answers. The shading is the signal, and the recurring shadings have specific meanings worth learning.

1. "It's possible" vs. "It's straightforward"

These sound similar and mean different things. "It's possible" means there's no architectural reason it can't be done — but the path isn't obvious. "It's straightforward" means it fits cleanly into how the system already works. The distance between them is often weeks.

Dialogue.
PM: "Can we let admins override the default tax rate per customer?"
Eng: "It's possible."
The engineer didn't say no. They said the work is doable but they're not yet seeing the clean path. Your cue: "what would make this straightforward, and what's in the way?"

2. "We could do that, but…"

The information lives entirely after the "but." Don't let the conversation move on until you've heard what comes next, and decided together whether it's a blocker, a tradeoff, or a preference.

Example. "We could let users export the full audit log… but we'd be streaming millions of rows out of the production DB, and that's the same DB serving the live app." The "but" is a real architectural risk worth designing around. If you'd nodded past it, you'd have learned about it at 2am during the first big customer's first export.

3. "Not in this sprint"

Sometimes a real capacity statement, sometimes a polite "I don't want to do this and I'm hoping you'll lose interest." The follow-up that distinguishes the two: "What would have to be true for it to fit in the next one?" A capacity answer leads to a swap conversation. A politeness answer leads to a different objection surfacing — which is the conversation you actually needed.

4. "We'd need to refactor X first"

Sometimes a real prerequisite. Sometimes the version of the work the engineer prefers. Both can be legitimate, but they're different conversations.

Useful follow-up: "If we did this without the refactor, what specifically would go wrong, and how soon?" A concrete answer ("the existing queue can't handle the new volume and would silently drop messages") means prerequisite. A hand-wavy answer ("it would be ugly," "we'd have to do it eventually anyway") means preference, and you can negotiate.

When (and how) to push back on a "no"

The most useful PM skill in this conversation is distinguishing hard constraints (facts about regulation, physics, or architecture) from preferences (legitimate engineering tastes).

Hard constraint: "We can't store payment data without PCI certification, which we don't have." That's not a negotiation. The right response is to find a different path — like a vendor that handles the card data so you don't store it.

Preference: "We'd want to clean up the old auth module first." A legitimate engineering instinct, but it's a request for scope, not a constraint. Weigh it against what else the team could ship in the same time, and decide together.

The mistake PMs make in both directions: treating hard constraints as preferences and trying to push through them (you'll lose, and damage trust), and treating preferences as hard constraints and quietly dropping good ideas (you'll under-ship).

None of these are challenges to the engineer's judgment. They're invitations to think out loud together — which is the real version of "should we build this?"

What changes when AI is in the loop

The question: How does AI change what's worth building?

What's changed. Time-to-prototype has collapsed. A clickable version of a feature that took an engineer a week to wire up can now exist in an afternoon — sometimes in an hour. Three things follow:

• Spike work and throwaway prototypes are genuinely cheap. "Let's just try it" is no longer a multi-week commitment, so you can run real experiments instead of arguing about hypotheticals in a doc.
• Categories of work that were "too small to bother" — internal tools, one-off scripts, custom reports — are now economically reasonable.
• The bar for "boring boilerplate" has moved. Code that used to anchor an estimate (CRUD pages, form wiring, simple endpoints) is increasingly assumed to be near-free.

Example. A team prototyped a new analytics dashboard in three hours using AI to scaffold the data fetching, charts, and layout. Then it took six more weeks to ship to customers. The three hours produced a demo. The six weeks were the integration with the billing tier (some charts only for paying plans), the responsive layout for tablet, the access control, three rounds of design review, and the analytics instrumentation so the team could tell if anyone was using it. AI saved most of the first three hours. It didn't touch most of the next six weeks.

What hasn't changed. The five dimensions of complexity from Section 3 are unaffected by AI:

• Integration is still hard. AI doesn't make your auth provider, your billing system, or your mobile release process simpler.
• State and edge cases still surprise you. The third state nobody thought about is still where the production bug lives.
• Scale and reliability are still earned, not generated. Code that works for one user is not code that works for a million.
• Reversibility decisions — schema changes, public API contracts, data model choices — still require human judgment, and getting them wrong is still expensive.
• And the most important one: deciding what to build is still about user value and business strategy, not whether the code is cheap to write.

What to watch for. The cheap-prototype era has its own failure modes, and PMs are well-placed to catch them.

1. The 80/20 trap

AI gets a feature to "looks done" extremely fast. The last 20% — error states, edge cases, real data, real load, accessibility, the thing your enterprise customer's weird config does — is where the actual complexity lives, and AI does not collapse that part. "We prototyped this in an afternoon" is not the same statement as "we can ship this in an afternoon."

2. Demo speed vs. ship speed

Ask which one your engineer is describing. The same words — "it works" — mean wildly different things in each.

3. Build pressure goes up, not down

When prototyping is cheap, everyone — leadership, sales, you — has more ideas they want to "just try." Discipline on what to actually ship matters more, not less. Otherwise your team ships ten half-finished features instead of three solid ones.

4. The hidden estimate moved to integration

If you ask "how long?" and the answer is mostly about hooking things up, plumbing data through, and matching existing patterns — that's the new bottleneck, and it's the part AI helps with the least.

AI lowers the cost of trying things. It doesn't lower the cost of shipping things, and it doesn't change which things are worth shipping. Treat those as separate questions and you'll keep your bearings.

PM Playbook — Questions to ask

The next time an engineer reacts to a feature idea, try these:

• Which of the five — integration, state, scale, novelty, reversibility — is doing the work in your head? — turns "it's complicated" into a conversation with five entry points
• Did you mean "it's possible" or "it's straightforward"? — make sure you know which one you actually heard
• Where's the surprise here? — invites the engineer to point at what they're least confident about
• What assumption are you making about how this will be used? — turns a feasibility argument into a scope conversation, where you have leverage
• What's the smallest version of this that would still be useful? — moves from yes/no to what/when
• Is this a hard constraint or a preference? — distinguishes regulatory/architectural facts from engineering tastes
• If we did this without the refactor, what specifically would go wrong, and how soon? — separates a real prerequisite from a preference dressed up as one
• Are we talking about demo speed or ship speed? — especially when AI is in the loop, the same words mean wildly different things

These eight questions alone will change which features get shipped, and which ones quietly disappear before they cost you a sprint.