This section covers the technical knowledge product managers need to work effectively with engineering teams. The goal is productive collaboration and informed decision-making, not deep technical expertise.
Web applications follow a standard request flow:
User → Client (browser/app) → API → Server → Database
| Component | Description | PM Relevance |
|---|
| Client | Browser or mobile app | Changes require app updates and store review |
| API | Interface between client and server | Determines what data is available |
| Server | Processes requests | Changes can be deployed immediately |
| Database | Stores data | Structure affects query performance |
Feature scoping considerations:
- Client-only changes: Require app store approval (1-7 days)
- Server-only changes: Can deploy instantly to all users
- Full-stack changes: Require coordination across teams
API (Application Programming Interface) defines how software components communicate.
| HTTP Method | Purpose | Example |
|---|
| GET | Read data | Retrieve user profile |
| POST | Create data | Submit new order |
| PUT/PATCH | Update data | Modify settings |
| DELETE | Remove data | Delete account |
| Status Code | Meaning | Typical Cause |
|---|
| 200 | Success | Request completed |
| 400 | Client error | Invalid request format |
| 401 | Unauthorized | Authentication required |
| 404 | Not found | Resource does not exist |
| 500 | Server error | Internal system failure |
| Type | Examples | Use Case | Trade-offs |
|---|
| SQL (Relational) | PostgreSQL, MySQL | Complex queries, data integrity | Strict schema, slower writes |
| NoSQL (Document) | MongoDB, DynamoDB | Flexible schema, high scale | Limited query complexity |
| NoSQL (Key-Value) | Redis, Memcached | Caching, session storage | Simple data structures only |
Caching stores frequently-accessed data closer to the user to reduce latency.
| Cache Location | Latency | Use Case |
|---|
| Browser cache | Under 1ms | Static assets (images, CSS) |
| CDN | 10-50ms | Content delivery |
| Application cache | 1-10ms | Database query results |
| Database cache | 5-20ms | Query optimization |
Cache invalidation consideration: Cached data can become stale. Profile updates may not appear immediately due to caching.
| Type | Behavior | Example | User Experience |
|---|
| Synchronous | Wait for completion | Login authentication | Loading spinner |
| Asynchronous | Return immediately | Video upload | "Processing" status |
Asynchronous operations require:
- Status tracking
- Failure handling
- User notification system
| Instead of | Use |
|---|
| "How long will this take?" | "Can you help me understand the complexity for prioritization?" |
| "The competitor has this feature" | "Users need X. Competitor Y solved it this way. What approach works best for us?" |
| "We need this by Friday" | "Here's why Friday matters. Is that achievable? What would we need to cut?" |
| Behavior | Description |
|---|
| Clear problem statements | Define the problem, not the solution |
| Context | Explain why this matters, who is affected, what happens if delayed |
| Honesty about uncertainty | Acknowledge unknowns rather than false confidence |
| Respect for expertise | Allow engineers to propose technical solutions |
| Commitment follow-through | Deliver on promises, communicate changes immediately |
| Behavior | Impact |
|---|
| Mid-sprint requirement changes | Disrupts planning, erodes trust |
| Ignoring technical concerns | Creates technical debt, reduces credibility |
| Treating engineers as implementers | Reduces engagement and solution quality |
| Making assumptions about effort | Leads to unrealistic commitments |
Platform PMs build products for developers. The user base has different expectations and behaviors.
| Metric | Target | Why It Matters |
|---|
| Time to first API call | Under 30 minutes | Measures onboarding quality |
| Documentation completeness | 100% endpoint coverage | Reduces support burden |
| Error message clarity | Actionable in 95% of cases | Enables self-service debugging |
| SDK quality | Under 5 open critical bugs | Affects developer productivity |
| Factor | Description | Impact |
|---|
| Backward compatibility | Changes must not break existing integrations | Requires versioning strategy |
| Versioning | Support multiple API versions simultaneously | Maintenance overhead |
| Deprecation | Advance notice before removing functionality | Typically 6-12 months |
| Migration support | Tools and documentation for version upgrades | Reduces customer friction |
Platform PM shipping velocity is typically slower than consumer PM due to backward compatibility requirements.
Technical debt is accumulated shortcuts that increase future development cost.
| Signal | Description |
|---|
| Slow feature delivery | Simple features take weeks instead of days |
| Recurring bugs | Same issues appear repeatedly |
| Engineer frustration | Team avoids certain codebase areas |
| System fragility | Changes in one area break others |
| Responsibility | Action |
|---|
| Advocate for allocation | Reserve 15-20% of sprint capacity |
| Understand trade-offs | Know which shortcuts are appropriate |
| Balance priorities | Weigh new features against stability |
| Communicate impact | Translate technical debt to business terms |
Response structure:
- Problem framing: Provide context and goals, not implementation details
- Collaboration: Let engineers propose approaches
- Constraint awareness: Understand technical limitations before committing
- Knowledge gaps: Ask questions rather than make assumptions
Response framework:
| Level | Description |
|---|
| Required | Understand system architecture, technical vocabulary, read documentation |
| Not required | Write production code, deep language/framework expertise, make low-level technical decisions |
STAR format example:
- Situation: Need for notifications system
- Task: Choose build vs. buy approach
- Action: Analyzed current volume (low), projected growth (18+ months to justify build), integration effort (2 weeks vs 3 months)
- Result: Used third-party service, shipped faster, learned requirements, built custom system later with better specifications
| Method | Description | Benefit |
|---|
| Engineer conversations | Ask about system design decisions | Context and relationships |
| Architecture documentation | Read existing system docs | Foundation knowledge |
| On-call shadowing | Observe incident response | Understand failure modes |
| Personal projects | Build simple applications | Experience development constraints |
| Company | PM Technical Bar | Notes |
|---|
| Stripe | High | Read code, review API designs, opinions on DX |
| Google | Split role | PM focuses on what/why; TPM handles execution |
| Amazon | Moderate | Strategic tech understanding; SDMs handle implementation |
| Meta | Moderate-High | Read internal wikis, understand performance implications |
| Startups | Variable | Smaller teams require broader knowledge |
| Factor | Consumer PM | Platform PM |
|---|
| User tolerance | Moderate | Low (developers switch quickly) |
| Documentation priority | Secondary | Core product component |
| Breaking changes | Fix and iterate | Months of deprecation notice |
| Success metrics | Standard analytics | Inferred from API patterns, surveys |
| Customer segments | Relatively uniform | Individual developers vs. enterprises |