Core Concepts
The Full Stack: What Each Layer Means for Product Decisions
Each layer has different ownership, different risk, and different PM implications. Know which layer a feature lives in before writing the spec.
Description
The interface rendered in a browser (React, Angular, Vue) or native mobile app (iOS, Android) or cross-platform framework (React Native, Flutter). Each has different release cycles, performance constraints, and QA scope.
PM implication
Web deploys instantly. Mobile requires app store approval, which can take 24 to 72 hours. This affects release planning and incident response timelines.
Description
APIs define what data the frontend can request and what the backend will return. Responses are not always JSON. They can be HTML, XML, binary files, or GraphQL payloads depending on the API type and use case.
PM implication
API design decisions affect performance, cost, and flexibility. When you spec a feature that needs external data, you are specifying an API integration with real cost and latency consequences.
Description
The server-side code that handles requests, applies rules, manages user sessions, and coordinates between services. This is where authentication (who are you?) and authorisation (what are you allowed to do?) live.
PM implication
Most security requirements are backend requirements. When you write acceptance criteria for login, permissions, or role-based access, you are writing backend requirements.
Description
Databases (SQL, NoSQL), caches, and data warehouses. Data residency rules (where data physically lives) are enforced here. GDPR and HIPAA compliance decisions start at this layer.
PM implication
If your product serves EU users, data residency is a PRD requirement. If you handle health data, encryption at rest is a PRD requirement. These belong in your spec, not in an engineering post-mortem.
Frontend vs Backend: Where Features Live
Frontend is everything the user directly interacts with. Backend is everything that processes, stores, and serves the data the frontend displays. PMs need to know which side a feature lives on because it determines release speed, testing scope, and performance targets. A frontend change deploys in hours; a backend data migration can take weeks and requires rollback plans.
Description
Web frontends (React, Angular) deploy on demand through a browser. Native mobile apps (iOS, Android) must pass app store review before reaching users, which can take 24 to 72 hours. Cross-platform frameworks like React Native and Flutter write once and deploy to both, but with trade-offs in native performance.
As a PM, this means...
Mobile release cycles are longer. A critical bug fix on mobile cannot go live in minutes the way a web hotfix can. Your release plan and incident response playbook must account for this gap. Always ask: is this a web feature, a mobile feature, or both? The answer changes your timeline.
Description
State is the data your application holds in memory while a user is active: the items in their cart, their current step in an onboarding flow, the contents of an unsaved form. Poor state management causes users to lose progress, see stale data, or experience inconsistent UI. Features like shopping carts, real-time updates, and undo/redo all depend on state being correctly managed.
As a PM, this means...
When you spec a multi-step feature, you are implicitly specifying state requirements. Define what happens if a user refreshes mid-flow, navigates away and returns, or loses connectivity. These are PM decisions, not engineering edge cases to figure out later.
Description
Page load time directly affects conversion and retention. A page that takes 3 seconds to load loses a significant share of users before they see the content. Performance targets are not aspirational; they are product requirements that belong in a PRD with defined acceptance criteria and measurable thresholds.
As a PM, this means...
Define your performance requirement in the spec. A reasonable starting point: interactive in under 2 seconds on a mobile connection. Any new page or feature should have a load time acceptance criterion. If engineering ships something that does not meet it, that is a bug, not a discussion.
Common mistake
Treating load time as a nice-to-have rather than a hard acceptance criterion. Without a defined threshold in the PRD, "slow" is subjective and untestable.
Description
WCAG (Web Content Accessibility Guidelines) defines three conformance levels: A, AA, and AAA. Most regulatory frameworks, including the EU Accessibility Act and ADA standards in the US, require WCAG AA compliance. Failing to meet it creates legal risk and excludes a significant percentage of users from your product.
As a PM, this means...
WCAG AA must appear in your acceptance criteria for every user-facing feature. That means sufficient colour contrast, keyboard navigability, screen reader support, and alt text for images. Include it in the definition of done. If your team does not test for it before shipping, it will not be compliant when audited.
Description
Authentication answers: who are you? It verifies identity through credentials, tokens, or biometrics. Authorisation answers: what are you allowed to do? It controls which actions or data a verified user can access. OAuth is an authorisation protocol that lets users grant limited access without sharing credentials. SSO (Single Sign-On) lets users authenticate once across multiple products.
As a PM, this means...
When you spec a role-based permission system, you are specifying authorisation. A user story like "As an admin, I can view all team reports but a member cannot" is an authorisation requirement. Write it as a user story with clear role definitions and test it explicitly in acceptance criteria.
Description
When a browser or app requests data from a server, the response format depends on the API type and the use case. JSON is common for data APIs. HTML is returned by server-rendered pages. XML is still used in enterprise integrations and payment systems. Binary formats are used for files and media. GraphQL can return custom-shaped JSON payloads.
As a PM, this means...
When integrating with a third-party API, ask what format it returns and whether your frontend can consume it directly. Mismatched formats require transformation work that adds engineering time and potential failure points. Include the expected format in your API integration requirements.
APIs and Integrations: The Contracts That Connect Everything
APIs are agreements between systems about how data is exchanged. Every feature that touches a third-party service, uses data from another internal team, or triggers an event in another product is an API integration. PMs who understand APIs can write specs that include cost models, latency budgets, error handling requirements, and rate limit thresholds. PMs who do not will approve features that break under load.
Description
REST (Representational State Transfer) uses standard HTTP endpoints. It is the most common API type. GraphQL lets the frontend request exactly the fields it needs, avoiding over-fetching of data and improving mobile performance. gRPC is a high-performance protocol used for internal service-to-service communication, particularly where low latency is critical.
As a PM, this means...
GraphQL is particularly valuable for mobile products where bandwidth is constrained: the frontend requests only the data it needs, which reduces payload size. gRPC is rarely something you spec directly, but knowing it exists helps you understand why your engineering team structures internal services the way they do.
Description
A standard API requires your app to ask the server whether something changed (polling). A webhook reverses this: the server notifies your app the moment an event occurs. Payment confirmations, notification triggers, and CI/CD pipelines all use webhooks. Specifying real-time integration features requires understanding whether a webhook is available from the third-party service.
As a PM, this means...
When a user needs to be notified the instant their payment processes or their order ships, that is a webhook scenario. Before specifying real-time updates, ask engineering: does this third party provide a webhook, or will we need to poll? Polling at scale is expensive and unreliable. The answer changes your feature design.
Description
Rate limits cap how many API requests your product can make within a defined window, typically per second, per minute, or per day. Hitting a rate limit causes failed requests, degraded UX, or service outages. Rate limits also create unexpected cost escalation: many APIs charge overage fees when limits are exceeded.
As a PM, this means...
Before approving any API integration, ask engineering for the rate limit, the current projected call volume, and what happens when the limit is hit. Document the acceptable threshold in your PRD. If the product is expected to grow, include a plan for what happens when usage approaches the limit. This belongs in the spec, not in a post-incident review.
Description
APIs use semantic versioning (v1, v2) to signal the scope of changes. A major version change (v1 to v2) often breaks existing integrations. Deprecation means the old version has a sunset date after which it stops working. A PM who is unaware of versioning will miss deprecation notices and ship a broken experience to users.
As a PM, this means...
Track the API versions your product depends on. When a third-party announces a version change or deprecation, that creates backlog work. Prioritise migration before the sunset date and communicate the deadline to engineering well in advance. Include API dependencies in your technical risk register for each sprint.
Description
A synchronous API call makes the user wait until the server responds before the next action is available. An asynchronous call lets the app continue while the server processes in the background, with the result delivered later. The distinction directly determines whether you need a loading spinner, a pending state, a progress bar, or a completion notification in your UX design.
As a PM, this means...
When you spec a feature that involves a third-party call (payment, email, export, AI generation), ask: is this synchronous or asynchronous? A synchronous payment means the user waits on the checkout screen. An asynchronous one means you show a pending state and confirm later. Both are valid. Each requires a different UX design and a different error handling flow.
Description
Latency is the time between a user action and the product's response. There is no universal threshold. Acceptable latency varies significantly by use case and user expectation. A rigid rule like "all API calls must respond in 300ms" will be too strict for some scenarios and dangerously loose for others.
Latency by context
Search autocomplete: aim under 200ms. Standard page loads: under 1 second is a good target. Background data sync: 1 to 2 seconds may be acceptable. Real-time features such as trading, gaming, or voice: under 100ms is typically required. Define your latency budget per feature category, not as a global rule.
| Use Case | Target Latency | PM Implication |
|---|---|---|
| Search autocomplete | Under 200ms | Any slower and users perceive a lag. Include in acceptance criteria. |
| Standard page or screen load | Under 1 second | Critical for conversion. Measure with real devices on a mobile connection. |
| Form submission or standard action | Under 2 seconds | Users accept a short wait if there is visible progress feedback. |
| Background data sync | 1–2 seconds acceptable | No user-visible wait. Show a subtle loading indicator, not a blocking spinner. |
| Real-time features (trading, gaming, voice) | Under 100ms | Architecture must be purpose-built for low latency. Standard infrastructure will not meet this. |
System Design Basics: The Structural Decisions That Constrain Everything Else
System design decisions determine how fast your product can scale, how quickly it can go live, and how resilient the product is to failures. These are not purely engineering concerns. A PM who does not understand scalability, failure modes, and architecture will set unrealistic timelines, approve features that are not ready, and be unable to participate in reliability conversations with engineering leadership.
Description
Vertical scaling adds more power to a single machine (more CPU, more RAM). It is faster to implement but has a ceiling and creates a single point of failure. Horizontal scaling adds more machines to share the load. It is more resilient but requires stateless architecture and more coordination between services.
As a PM, this means...
Your decision is: what is your availability target and what is your budget? If you are planning a product launch or a seasonal event like Black Friday, you need to know your scaling approach before the event, not during it. Include scaling requirements in launch planning as a hard dependency, not an engineering afterthought.
Description
A CDN (Content Delivery Network) stores copies of your static content, such as images, CSS, and JavaScript, on servers distributed around the world. When a user requests a page, the content is served from the nearest location rather than from a central server. This dramatically reduces load time for international users and decreases the load on your origin server.
As a PM, this means...
If you are specifying an international launch or a product with significant media content, CDN use is a performance requirement, not an optional infrastructure decision. Include "content served via CDN" in your non-functional requirements when the audience is geographically distributed.
Description
A monolith is a single, unified codebase. It is faster to start building and easier to understand early on, but becomes harder to scale and deploy independently as it grows. Microservices separate the product into independent services that can be deployed individually. This enables teams to ship independently but increases the number of service integrations to manage and the coordination required across teams.
As a PM, this means...
Microservices allow teams to deploy independently but require you to track which services a feature depends on before committing to a sprint. A feature that touches three microservices has three times the integration risk of one that touches a single service. Ask engineering which services your feature depends on at the start of planning, not at the start of the sprint.
Description
A message queue holds tasks and processes them one by one or in batches. When a user places an order, a message goes into a queue to be processed by the fulfilment system. Queues decouple actions from their processing, enabling reliable async workflows. Systems like Kafka, RabbitMQ, and AWS SQS are common implementations.
As a PM, this means...
Any feature involving notifications, order processing, data exports, or async workflows likely uses a queue. When you spec these features, include the retry logic (what happens if a task fails?), the failure handling (what does the user see if a queued action does not complete?), and the expected processing time in your acceptance criteria.
Description
A feature flag is a configuration switch that enables or disables a feature without deploying new code. PMs use feature flags to release to a percentage of users first (canary release), run A/B tests without engineering involvement, roll back instantly if something breaks, and give different user segments different experiences.
As a PM, this means...
For any risky or large feature launch, request a feature flag in the PRD as a launch requirement. Without it, a rollback requires a full redeployment, which can take hours. With it, you can turn the feature off in seconds. Feature flags are risk management tools, not engineering conveniences.
Description
An SLO (Service Level Objective) is your internal reliability target: the uptime percentage or latency threshold your team commits to meeting. An SLA (Service Level Agreement) is the customer-facing promise, often with financial penalties if broken. An SLI (Service Level Indicator) is the actual measurement used to track whether you are meeting the SLO.
As a PM, this means...
PMs own the SLO decision. Setting it at 99.9% uptime rather than 99.99% means accepting roughly 8.7 hours of downtime per year in exchange for significantly less reliability engineering investment. That trade-off is a product decision, not an engineering one. It determines how much reliability work gets prioritised against new features in every planning cycle.
GDPR
Requires user data from EU users to be processed and stored within the EU. Data residency is an architectural requirement that must appear in your PRD before engineering begins, not after a legal review flags it.
HIPAA
Requires healthcare data to be encrypted at rest and in transit. If your product handles any protected health information, encryption is not optional and must be specified as a hard acceptance criterion in every relevant feature.
PII Handling
Personally identifiable information (names, emails, addresses) requires explicit handling rules: where it is stored, who can access it, how long it is retained, and how it is deleted on user request. Define these in the data model section of your PRD.
Right to Erasure
GDPR grants users the right to request deletion of their data. This is a product feature, not a database operation. Spec it explicitly: what data gets deleted, what is retained for legal compliance, and how is the user notified when deletion is complete?