Engineering Said 'It's Complex.' You Nodded and Moved On.

It’s sprint planning. You present the next feature, the one sales has been asking for. The one that lit up your user interviews. Your tech lead squints at the screen, leans back, and says the word every PM dreads: “That’s… complex.”

A knot forms in your stomach. The whole room is looking at you. You don’t want to look like you don’t understand the tech. You don’t want to derail the meeting by asking “dumb” questions.

So you do what feels safe. You nod and say, “Okay, let’s park that for now and circle back.”

And just like that, a potentially game-changing feature dies, not with a bang, but with a vague agreement to talk later. It goes to the backlog graveyard, forever labeled with the tombstone: “Complex.”

This is a critical communication failure. “Complex” isn’t an answer. It’s a black box. Your job is not to accept the label, but to open the box with your engineering counterparts.

The Four Flavors of 'Complex'

When an engineer says something is complex, they rarely mean it's impossible. They're using a shorthand for a specific kind of problem. Your first task is to figure out which kind it is. "Complex" usually means one of four things:

1. High Uncertainty: “We’ve never integrated with an API like this. We don’t know what we don’t know. The docs look okay, but we could hit a wall on day three.”
2. High Interdependency: “This touches the billing system, the user permissions model, and the reporting export. A small change here could have cascading, unpredictable effects over there.”
3. High Effort: “There’s no magic to it. It’s just a mountain of tedious, manual work. We have to update 200 individual configuration files. It's a slog.”
4. Fragile Foundation: “The code in that part of the app is a decade old. Nobody who wrote it is still here. We’re afraid if we touch that one card, the whole house of cards will fall down.”

Each of these problems requires a completely different solution. A high-uncertainty problem needs a research spike. A high-interdependency problem needs careful system mapping. A high-effort problem needs ruthless scoping. A fragile-foundation problem needs a frank conversation about tech debt.

You can’t get to any of those solutions until you translate “complex” into its true meaning.

Five Questions to Open the Black Box

You don’t need a computer science degree to have a productive conversation. You just need a toolkit of clarifying questions. These aren't about challenging your engineers; they're about turning you into a problem-solving partner.

1. “Can we draw it on the whiteboard?” This is the single best way to cut through jargon. Ask them to sketch the system components, data flows, or user interactions. As they draw, you can point and ask, “So the user clicks here, and the data goes there? Which one of these arrows is the hard part?” It forces simplification and reveals the true source of the difficulty.

2. “What’s the single biggest risk here?” This question shifts the focus from effort to uncertainty. Is the risk technical (“The database might not handle the load”)? Is it a dependency (“We’re waiting on the API key from another team”)? Is it a user experience risk (“We’re not sure users will understand this”)? Once you name the biggest risk, you can design a small experiment to test it, instead of trying to build the whole thing at once.

3. “If we had to ship just 10% of the value next week, what would we build?” This is a classic scoping question, but it’s powerful. It forces the team to identify the absolute core of the feature. Often, 80% of the “complexity” lives in the 20% of the feature that constitutes edge cases and gold-plating. This question helps you find the simplest possible version that still delivers value and lets you learn from real users.

4. “Is this hard because of our code, or because of something outside our control?” This helps you distinguish between internal and external blockers. If the complexity comes from a third-party API or another team’s service, your job as a PM might be to manage that external relationship, get clearer requirements, or even find a different vendor. The solution might not be to write more code, but to make a phone call.

5. “Is this ‘complex-annoying’ or ‘complex-dangerous’?” This helps you gauge the type of risk. “Complex-annoying” is the high-effort slog. It’s predictable work that just takes time. “Complex-dangerous” is the fragile foundation, where a mistake could bring down the site. The former is a prioritization problem. The latter is a de-risking problem that might require dedicated time for refactoring before you even start the feature.

Your Job Is to Ask

These questions do more than just clarify technical details. They change your relationship with the engineering team. You stop being a feature requester and become a collaborative partner in shipping great software.

The next time you hear “that’s complex,” don’t nod and move on. Grab a whiteboard marker. The most valuable features aren't always the easiest to build, but they are the ones where you were brave enough to ask the next question.