Home / Tech Stacks For PM / Section 07: What Most PMs Get Wrong

PM Pitfalls

These are not engineering failures. They are specification failures. Each one has a consistent pattern and a consistent fix.

🔗

Approving API integrations without a cost model

▼

Most third-party APIs charge per call. PMs who approve integrations without modelling cost at expected traffic volumes create hidden long-term costs. The cost can scale dramatically with growth, and there is often no natural trigger to catch it until the invoice arrives.

Fix: Before any API integration is approved, ask for the cost per call, the expected call volume at launch and at 10× growth, and the cost ceiling at which the product needs an alternative. Document all three in the PRD.

📱

Treating mobile and web as the same surface

▼

PMs who plan a simultaneous web and mobile launch without accounting for app store review timelines will face a public web launch with the mobile feature still waiting approval. App store review can take 24 to 72 hours or longer for complex submissions.

Fix: In your release plan, separate web and mobile timelines. Ship web first where possible, and treat mobile deployment as a gated release dependent on app store approval.

♿

Listing accessibility without specifying the standard

▼

"Ensure the feature is accessible" is not an acceptance criterion. It is aspirational text that passes QA without being tested. Accessibility requirements that do not reference WCAG AA specifically will not be audited to that standard, and the product will fail when a compliance review or legal challenge occurs.

Fix: Include "WCAG 2.1 AA compliant" as a named acceptance criterion. Specify the testable items: keyboard navigability, colour contrast ratio, screen reader support, and alt text.

🧩

Describing microservices as reducing dependencies

▼

Microservices do not reduce dependencies. They decompose a monolith into a network of smaller, more manageable services, each with its own APIs and interfaces. The number of service-to-service connections typically increases, and dependency coordination complexity increases.

Fix: Frame microservices as increasing dependency management complexity, not reducing it. Plan for explicit dependency coordination between services.

⏱️

Applying a universal latency rule instead of a use-case budget

▼

A rule like "all API calls must respond in 300ms" sounds rigorous but is incorrect in practice. 300ms is too slow for a real-time trading feature and unnecessarily strict for a background data sync. A single threshold applied to all features produces wrong acceptance criteria for most of them.

Fix: Define a latency budget per feature category: Search and autocomplete under 200ms; Standard actions under 2 seconds; Real-time features under 100ms. Apply the right threshold to the right feature type.

🔒

Treating security as an engineering checklist rather than a PM requirement

▼

Security requirements that are not in the PRD will not be consistently built. Teams may assume security is "handled later," but production failures often result from missing input validation, XSS, SQL injection, and CSRF protections that were never explicitly specified.

Fix: Add a security requirements section to every feature spec: input validation, encryption in transit, XSS and injection prevention, and CSRF for state-changing actions.

🔄

Committing a sprint without checking service dependencies

▼

In microservices environments, a feature that touches multiple services requires alignment across those teams. PMs who commit features to sprints without confirming that all dependent services are available and aligned will face mid-sprint blockers that cannot be resolved within the sprint scope.

Fix: Before committing any feature to a sprint, ask which services it depends on and whether those teams have aligned capacity. Confirm dependencies during backlog refinement.

🚀

Launching without a feature flag or a documented rollback plan

▼

A launch without a feature flag means a rollback requires a full redeployment, which can take hours and risks introducing new issues. Without a rollback plan, teams may be forced to debug issues in production under pressure.

Fix: Every feature that affects a significant portion of users must include a feature flag and a rollback plan defined in the PRD before development begins.