The Problem

You spec beautiful features. Engineering says "we can't do that—the database isn't designed for it" or "that would require a full infrastructure rewrite."

You feel blindsided. They should have told you earlier.

They did. You weren't listening.

The Trap

Most PMs treat technical constraints like legal disclaimers: something to acknowledge at the end of the PRD. "Yeah, yeah, database limitations, whatever."

This is backward. Technical constraints are part of the problem space. They're not blockers—they're part of the specification.

The Shift

Think of technical constraints as "what we can implement cost-effectively, given our current architecture."

A constraint isn't "we can't do this." It's "doing this requires either: (A) accepting this cost/time/complexity, or (B) choosing a different approach."

Good PMs understand the constraints and design product decisions within them. Great PMs understand constraints and advocate for changing them when the business value justifies it.

Actionable Steps

1. Ask Engineering: "What are our hard constraints?"

Not "can we do X?" but "what would we need to change to do X?"

Map it:

  • Database schema: What tables would we need to modify? How long? How much copy/verify?
  • API architecture: Can we change response times, payload sizes, endpoints?
  • Deployment: How often can we deploy? How do we manage breaking changes?
  • Scaling: What breaks at 10x traffic? 100x?
  • Integration points: Which external services are we tightly coupled to?

2. Integrate Constraints into PRD

Document it explicitly:

Technical Constraints for [Feature]
- Database: Current schema supports up to 10M records efficiently;
  scaling beyond requires sharding (2-week project)
- API: Current endpoint latency is 200ms; feature uses 3 calls,
  so worst-case user latency is 600ms
- Deployment: We deploy weekly; feature requires schema migration,
  so earliest launch is Week 2

This isn't pessimism—it's clarity.

3. Use Constraints to Negotiate Scope

When you see a constraint that blocks your vision:

  1. Can we reduce scope? (narrower MVP that doesn't hit constraint)
  2. Can we parallelize? (infra work + feature work simultaneous)
  3. Can we accept degraded performance? (launch with 500ms latency; optimize later)
  4. Is the infra improvement worth it? (business upside vs. time cost)

4. Document Decisions

"We chose approach B instead of A because A would require database sharding (2 weeks); B is slightly slower but ships in 1 week, and we can optimize later if needed."

Key Takeaways

  • Constraints aren't excuses—they're design inputs. The best PMs spec knowing the constraints, not in spite of them.
  • Technical debt becomes a feature constraint. If you have 3 weeks of accumulated tech debt, that's 3 weeks of constraint on what you can ship.
  • Communication prevents surprises. When engineering says "we can't" on launch day, you've failed to specify properly.