System design questions for product managers are more common than most candidates expect. Top companies like Google, Meta, or OpenAI use them now to test your ability as a PM to think at a systems level, reason through technical trade-offs, and connect architectural decisions back to product goals.
This is a rather different bar from what engineers usually face and may seem tricky. But with the right preparation, you can walk into these interviews with a clear framework, a strong sense of what interviewers are looking for, and enough practice to answer confidently.
In this guide, you'll find a breakdown of which companies ask PMs system design questions and why, commonly reported questions with full worked answers, a PM-specific answer framework, and a prep plan to get you ready.
- Overview
- 3 system design questions for product managers (with full answers)
- How to answer system design questions as a PM
- More system design questions for product managers
- How to prepare
Click here to practice 1-on-1 with ex-FAANG PM interviewers
1. Overview ↑
1.1 What is a system design interview for product managers?
A system design interview is typically 45-60 minutes long and begins with a broad prompt, like "Design Instagram.” You’re expected to generate a high-level design, showing the different required system components. You then need to describe how they're connected, and any trade-offs in your approach.
The goal of the interview is to test how well you design scalable, maintainable systems that can function in a massive, fast-paced environment. Building a technically sound solution is key, but equally as important is your ability to consider business needs, user experience, and internal resources.
For engineers, that means whiteboarding distributed architectures, debating database trade-offs, and getting graded on implementation depth. For product managers, the bar is different. Interviewers want to see that you can:
- Scope a problem intelligently
- Identify the key components
- Reason through trade-offs
- Connect your technical decisions back to product goals
One distinction worth making early: system design questions are not the same as product design questions.
Product design questions (like "design a phone for the elderly") test user empathy and UX thinking. But system design questions (like "design the backend for a ride-matching service") test architectural reasoning. Some questions blend both, and when they do, the interviewer will typically signal which lens they want.
For candidates who want to build a stronger technical foundation before working through the questions below, our system design interview guide covers the underlying concepts in detail.
1.2 Which companies ask system design questions to product managers?
System design questions for PMs are concentrated in two types of companies:
- FAANG+ (primarily for PM-T roles, but increasingly at senior PM levels too)
- Developer-focused companies, where they appear even for standard PM roles
Your system design interview(s) might take place in person at the company headquarters or virtually. If you interview in person, you might be asked to draw out your design on a whiteboard, but most candidates use an online drawing tool such as Excalidraw.
Knowing which bucket your target company falls into shapes how hard you need to prepare. Let's look quickly at how each company approaches the topic.
1.2.1 FAANG+
This is the most consistent. Technical rounds for PM and PM-T roles regularly include system design or algorithm design questions. Candidates report questions like "How would you design a messaging app?" and "How would you design a file-sharing system?"
Google has a reputation for having some of the highest standards when it comes to technical capabilities, which makes their system design rounds especially tricky. Some candidates have even reported receiving a system design question that proved to be intentionally unsolvable. However, this is rarely the case.
Amazon
Amazon includes system design as a standard component of PM-T interviews. For standard PM roles, dedicated system design rounds are less common, but technical depth is expected at senior levels and can surface in behavioral and product rounds.
According to Amazon’s official guide, you can expect at least one 45-minute system design interview as part of your interview loop. The goal of this round is to test how well you can design scalable, maintainable systems that can function in Amazon’s massive, fast-paced environment.
Meta
Meta doesn't have a standalone system design round for standard PM roles, but technical fluency comes up in product execution rounds. For PM-T roles, technical depth is assessed more directly.
OpenAI
OpenAI typically asks AI-first system design questions in PM interviews. Candidates report questions like "design a system that enables a large language model to handle multiple questions in a single thread."
1.2.2 Developer-focused and infrastructure companies
Developer-focused companies are those whose primary customers are engineers and technical teams. They sell APIs, data infrastructure, cloud services, and developer tools rather than consumer products.
There are two main types of developer-focused companies worth distinguishing here.
- API and infrastructure companies like Stripe, GitHub, and Twilio. These companies build products that developers integrate directly.
- Enterprise platform companies like Oracle and NVIDIA. They operate at a different scale and with different user bases, but system-level thinking is equally central to the PM role.
Because PMs at these companies build products that developers integrate directly into their own systems, they're expected to understand the architecture underneath in a way that PMs at consumer companies typically aren't.
This matters because system design questions show up at these companies even for standard PM roles, not just PM-T roles. The questions are often framed as trade-offs or API design discussions rather than open-ended architecture problems, but the underlying expectation is the same: that you can engage credibly with an engineering team on technical decisions.
1.2.3 PM-T roles specifically
Regardless of company, if the role has "technical" in the title, treat system design as near-certain prep. Our technical PM interview questions guide covers a more comprehensive picture of what PM-T interviews involve. System design is one component of a broader technical assessment that also includes technical explainer questions, estimation, and algorithm design.
2. 3 System design questions for product managers (with sample answers) ↑
The questions below are among the most commonly reported by PM and PM-T candidates across FAANG+ and developer-focused companies. Each answer uses the 4-step framework explained in Section 3. If you want to understand the reasoning behind the structure first, start there and come back.
We recommend attempting each question yourself first, then checking your answer against the sample to find gaps in your approach. These answers are calibrated for PMs, not engineers. So they’re lighter on implementation detail, heavier on trade-off reasoning and product tie-back.
- How would you design a notification system for a mobile app?
- How would you design Uber's ride-matching system?
- How would you design the API for a payments product?
2.1 How would you design a notification system for a mobile app? ↑
This is one of the most commonly reported system design questions for PMs across Google, Amazon, and Meta.
It's a strong starting question because the scope is manageable, the trade-offs are clear, and it rewards candidates who think about the user experience alongside the architecture.
Example answer outline: "Design a notification system for a mobile app."
1. Ask clarifying questions
- Scope: What types of notifications are we supporting? Push, in-app, email, SMS, or all of the above? For this walkthrough: push and in-app only. Email, SMS, and rich media are out of scope.
- Functional requirements:
- Deliver notifications triggered by user actions (transactional: order shipped, new message received)
- Deliver notifications triggered by marketing campaigns (promotional: weekly digest, special offers)
- Support user preference controls: opt out of notification types, set quiet hours (e.g., no notifications between 10pm and 8am in local timezone)
- Non-functional requirements:
- Scale: 100 million daily active users
- Latency: transactional notifications must deliver within 2 seconds; promotional notifications can be batched and delayed
- Reliability: no silent drops — every notification that should be sent must either arrive or be logged as failed
2. Design high-level
- Event producers: upstream services that trigger notifications — order service fires an event when a package ships, messaging service fires one on new message received, marketing service fires one for a campaign
- Notification service: receives incoming events, queries user preferences, decides whether to send, and routes to the right delivery channel
- Message queue: sits between the notification service and the delivery workers; buffers traffic spikes so a flash sale triggering 5 million order notifications doesn't overwhelm the workers
- Delivery workers: consume from the queue and dispatch to the device — iOS through Apple's APNs, Android through Google's FCM
- User preference store: queried by the notification service before every delivery decision; at 100M DAU this lookup happens millions of times per minute, so read speed is critical
Key metrics: delivery latency (transactional under 2 seconds) and delivery reliability (no silent drops).
3. Drill down on your design
- Async delivery vs. sync:
- Synchronous: order service waits for notification delivery before returning. Simple, but tightly coupled — if the notification service is slow or down, order confirmations slow down too.
- Asynchronous (recommended): order service fires an event and moves on immediately. Notification system processes independently. Workers acknowledge messages before removal from queue to guarantee delivery.
- Trade-off: async adds acknowledgment complexity, but at 100M DAU the reliability gain far outweighs it.
- Key-value store for user preferences:
- Relational database works at lower scale but becomes a bottleneck at millions of lookups per minute.
- Key-value store (e.g., Redis or DynamoDB) keyed on user ID gives sub-millisecond reads and scales horizontally.
- Trade-off: complex preference logic (timezone conversion for quiet hours) moves into the application layer rather than the database.
- Fan-out for high-follower accounts:
- A single event from a celebrity account may trigger notifications to 10 million followers. Processing this naively at send time creates a massive burst.
- Pre-compute and cache fan-out lists for high-follower accounts so delivery can be spread over time.
- Trade-off: some staleness — a user who recently unfollowed may receive one notification before the cache refreshes.
4. Bring it all together
Here, tie technical decisions to earlier stated product goals and success metrics:
- Separate transactional and promotional notifications into a fast path and a batched path respectively
- Architecture: event producers → notification service (preference lookup) → message queue → delivery workers → APNs/FCM
- Transactional notifications hit the fast path and deliver within 2 seconds even under peak load
- Promotional notifications go through the batched path, which is more cost-efficient and doesn't compete with transactional traffic
- User preference controls and timezone-aware quiet hours are enforced at the notification service layer, before any event reaches the queue
2.2 How would you design Uber's ride-matching system? ↑
This is a commonly reported question for PM-T candidates at companies with marketplace or logistics products. Interviewers use it to test whether you can take a large, open-ended scope and narrow it intelligently. They also want to see whether you can reason through the technical decisions that underpin a core product metric, which in Uber's case is rider wait time.
Example answer outline: "Design Uber's ride-matching system."
1. Ask clarifying questions
- Scope: Focus on the matching component only — how a rider request gets paired with an available driver. Surge pricing, driver incentives, navigation, and payments are out of scope.
- Functional requirements:
- Accept a rider's trip request with pickup location
- Find available nearby drivers in real time
- Select the best match and notify both rider and driver
- Non-functional requirements:
- Scale: millions of trips per day globally; thousands of match requests per second at peak
- Latency: rider receives a driver assignment within 3 to 5 seconds of requesting
- Reliability: no dropped match requests; driver location updates must be processed continuously in real time
2. Design high-level
- Rider request service: receives trip requests from the rider app, validates them (authenticated user, valid pickup address), and passes to the matching engine
- Driver location service: ingests a continuous stream of GPS updates from all active driver apps; maintains a current view of every driver's location and availability; write-heavy, as active drivers send updates every few seconds
- Geospatial index: allows the matching engine to query "all available drivers within 2km of this rider" in milliseconds, rather than scanning every active driver globally
- Matching engine: queries the geospatial index, ranks nearby available drivers using matching signals (proximity, acceptance rate), and selects the best candidate
- Trip service: creates the trip record once the driver accepts, sends confirmation to both rider and driver, and hands off to navigation and payment systems
Key metrics: match latency (under 5 seconds), match quality (low rider wait time, low driver dead miles), and reliability (no dropped requests).
3. Drill down on your design
- Geospatial indexing — geohashing vs. quadtrees:
- Naive approach: scan all active drivers globally and compute distance for each. Too slow at scale with hundreds of thousands of active drivers.
- Geohashing: divides the world map into a grid of cells, each with a short alphanumeric code. Drivers are indexed by their current cell. A trip request queries the rider's cell and adjacent cells.
- Quadtrees: more precise results in areas of uneven driver density, but more complex to implement and maintain.
- Recommendation: start with geohashing — fast, simple, horizontally scalable. Quadtrees are an optimization for later.
- Matching algorithm — nearest available driver:
- Simplest strategy: match the closest available driver. Optimizes for rider wait time, which is the dominant metric for a consumer ride-hailing product.
- More sophisticated: weight multiple signals (driver heading, historical acceptance rates, driver rating). Better match quality but adds compute latency to every decision.
- Recommendation: nearest-driver-first to start, with additional signals added incrementally as the system matures.
- Concurrency — optimistic concurrency control:
- Problem: multiple matching engine instances run in parallel at peak. Two instances could simultaneously select the same driver for two different riders.
- Distributed locking: prevents conflicts but adds latency overhead to every single match decision.
- Optimistic concurrency (recommended): allow the conflict, detect it at assignment, re-match the losing rider. Re-matching typically takes under a second.
- Trade-off: occasional re-match is a far better outcome than slowing every match with locking overhead.
4. Bring it all together
Tie key technical decisions to earlier stated product goals:
- Architecture: rider request service → matching engine (queries geospatial index) → trip service; driver location service feeds the geospatial index continuously in the background
- Every design decision is downstream of one product insight: rider wait time is the metric that matters most
- Geohashing gives low-latency spatial lookups; nearest-driver-first keeps the matching decision fast; optimistic concurrency avoids locking overhead
- A logistics product optimizing for route efficiency over wait time would make different choices at every one of these decision points — the architecture follows from the product goal
2.3 How would you design the API for a payments product? ↑
This is a commonly reported question for PM candidates at Stripe and similar developer-focused companies. Interviewers use it to assess whether you understand what makes an API good to build on. Not just technically sound, but reliable and easy for developers to integrate correctly.
Unlike the previous two questions, there's no full system architecture to sketch. The focus is on design decisions and their downstream consequences.
Example answer outline: "Design the API for a payments product."
1. Ask clarifying questions
- Scope: Focus on card payment processing — a charge API. Bank transfers, wallets, international payments, and fraud detection are out of scope.
- Users: Developers integrating the API into their own products. The API needs to be clear, predictable, and hard to misuse.
- Functional requirements:
- Create a charge against a payment method
- Retrieve the status of a charge
- Initiate a refund against a prior charge
- Non-functional requirements:
- Reliability: a double charge is a critical failure; idempotency is a first-class concern
- Scale: thousands of requests per second at peak
- Developer experience: errors must be specific enough that developers can take action and surface useful messages to their users
2. Design high-level
The core API surface:
- POST /v1/charges: creates a charge against a payment method
- GET /v1/charges/{charge_id}: retrieves the status of a specific charge
- POST /v1/refunds: initiates a refund against a prior charge
Key design decisions embedded in this structure:
- Versioning (/v1/): future breaking changes can be released as /v2/ without disrupting existing integrations
- Resource-based URLs: charges and refunds as nouns, not verbs like /processPayment — makes the API predictable and intuitive
- Stable resource IDs: each charge has an ID that can be used to retrieve its current state, essential for debugging and async flows
3. Drill down on your design
- Synchronous vs. asynchronous responses:
- Synchronous: waits for the payment processor to confirm and returns success or failure immediately. Simple to integrate, but response time is coupled to the processor's, which can spike under load.
- Asynchronous: returns pending immediately and delivers the result via webhook when processing completes. Decouples latency but requires developers to build webhook handling and manage pending state.
- Recommendation: synchronous with a timeout as the default, webhooks as a reliability fallback for network failures and processor delays.
- Idempotency keys:
- Problem: network failures mean a developer may send the same POST /v1/charges request twice without knowing if the first succeeded. A naive retry results in a double charge.
- Solution: developers generate a unique key per charge attempt and include it in the request header. If the server sees the same key twice, it returns the result of the first request rather than processing a new charge.
- Trade-off: server must persist recent request results and look them up on each incoming request — storage and lookup overhead that is non-negotiable given the cost of double charges.
- Error design:
- Flat error code (payment_failed): simple to implement, but developers can only show generic failure messages to users.
- Specific decline codes (card_declined, insufficient_funds, expired_card): lets developers surface actionable messages and retry intelligently (don't retry an expired card; retry insufficient funds later).
- Trade-off: granular codes expose more about the processor's internal logic, creating potential liability concerns.
- Recommendation: specific codes for developer-actionable scenarios, generic codes for sensitive or ambiguous failures.
4. Bring it all together
- Scope: card charge API, developer-facing, thousands of requests per second, idempotency as a first-class requirement
- API surface: POST /v1/charges, GET /v1/charges/{id}, POST /v1/refunds
- Key decisions: synchronous responses with webhook fallback, idempotency keys to prevent double charges, structured error codes for developer-actionable failures
- Every decision is downstream of one product goal: make it as easy as possible for developers to integrate payments reliably — the API design is the product
3. How to answer system design questions as a PM ↑
Now that you've seen what strong answers look like in practice, it's worth understanding the framework behind them.
The 4-step method below is what structures each of the answers above. It's adapted from IGotAnOffer's system design framework, but calibrated specifically for PMs, so it’s lighter on implementation detail, heavier on trade-off reasoning and connecting technical decisions back to the product.
Here is a more detailed walk-through of this answer structure from Ramprasad (ex-Meta engineer and interview coach), with additional information on what to cover in each step as a PM:
4-Step System Design Answer Framework: Walk-through
System design questions for product managers are deliberately open-ended. When an interviewer asks you to "design a notification system" or "design a ride-matching service," they're not expecting a complete, production-ready answer. The question is intentionally broad. Your job is to make it specific.
Think of it this way: the interviewer's responsibility is to give you a vague, complex prompt. Your responsibility is to simplify it into something you can actually work through in 45 minutes.
Here's how to do that in four steps.
Step 1: Clarify scope and requirements
This is the first thing interviewers evaluate, and it's where PMs often stand out. Before drawing anything, ask questions. What is the system's primary goal? Who are the users and at what scale? What constraints matter most: latency, reliability, cost?
In practical terms, you're defining two things:
- Functional requirements (what the system needs to do)
- Non-functional requirements (how well it needs to do it)
Don't worry about getting these perfectly right. The goal is to reach an agreement with your interviewer on scope before you start designing. When in doubt, ask directly: "What are the most important requirements for you?"
Step 2: Sketch the high-level design
Next is the high-level design. High-level design for 90% of the products will be the same:
- Client-side, which gives you the information
- Server-side, which is collecting the information
- Storage layer, which stores the information
Think about your write path and your read paths. Now use your non-functional requirements: at what cadence it is coming through at high frequency, and how much distribution is coming through will determine what kind of storage layer you pick.
Map out the main components and how data flows between them. Name one or two metrics the system needs to optimize for. These will guide your trade-off decisions in the next step. Keep it at the skeleton level for now. Details come later.
Step 3: Drill into trade-offs
This is the heart of a PM system design answer, and where most candidates fall short. For each major design decision, explain what each one costs and what it buys, in terms that connect back to the product.
SQL vs. NoSQL. Synchronous vs. asynchronous. Caching vs. always querying the database.
The interviewer is evaluating whether you understand the implications of each choice. One of the ways to show this is by framing trade-offs in product terms.
For example, you can say "Choosing eventual consistency here means we accept some staleness, which is fine for a content feed but would be a problem for a payments system". This is what separates strong PM answers from generic ones.
Step 4: Bring it back to the product
In the final few minutes, check your design against the requirements you established in Step 1. Have you met the functional and non-functional goals? Are there obvious bottlenecks or failure modes worth flagging?
More importantly, tie your key design decisions back to the product goal. This is the step engineers often skip and the one that most clearly signals PM thinking. A two-sentence summary is enough to land it:
"Because we prioritized low latency and async delivery, the system can handle peak load without degrading the user experience, which was the core reliability requirement we started with."
A note on depth. PMs are not expected to go as deep as engineers. If the interviewer wants more technical detail, they'll ask. The goal is to showcase systems thinking and technical credibility.
To help you make sure you cover the right information in your answer, check out our system design interview cheatsheet prepared by coach Mark (ex-Google EM and interview coach).
4. More system design questions for product managers ↑
The questions below give you a broader bank to practice with. Before diving in, it's worth knowing the four types of system design questions you're likely to face as a PM, since each calls for a slightly different approach.
4.1 Types of system design questions
- Design a full product or system. This is the most common type. You're asked to design something end-to-end like a messaging app or a streaming service. The scope is intentionally large, and part of the exercise is narrowing it down intelligently before you start designing.
- Design a feature or component. This is more targeted. You're asked to design one piece of a larger system like a notification service, a rate limiter, or a search autocomplete. These questions test whether you can reason about a specific technical challenge without losing sight of how it fits into the broader product.
- Design an algorithm. This appears primarily at Google for PM-T roles. Rather than asking about architecture, these questions ask how a system would make decisions. The interviewer wants structured thinking, not code. For a worked example of this type, see the Disney+ algorithm question in our technical PM interview guide.
- Technical trade-off and API design questions. These are most common at developer-focused companies and tend to be the most conversational type. Instead of a full system, you're asked to reason about a specific technical decision, i.e., which database, which API design pattern, how to handle a particular constraint, etc.
4.2 System design question bank for PMs
Design a full product or system
- Design a real-time messaging system (e.g., Slack or WhatsApp)
- Design a social media feed (e.g., Twitter/X or Instagram)
- Design a video streaming service (e.g., Netflix or YouTube)
- Design a collaborative document editor (e.g., Google Docs)
- Design a food delivery platform (e.g., DoorDash or Uber Eats)
- Design a file-sharing system (e.g., Google Drive or Dropbox)
- Design an e-commerce checkout system
Design a feature or component
- Design a search autocomplete feature
- Design a rate-limiting system for an API
- Design a URL shortening service
- Design a payment processing flow
- Design a real-time leaderboard
- Design a content moderation system
Design an algorithm
- Design an algorithm for an elevator system
- Design an algorithm for a self-driving car
- Design a recommendation algorithm for a content feed
- Design a fraud detection algorithm for a payments product
Technical trade-off and API design questions
- How would you most efficiently store large images in a database?
- What technologies would you use to build a live-stream video service?
- A feature needs to sync user data in real-time across devices. Walk through your approach
- How would you design the API for a developer-facing analytics product?
- When would you use a message queue versus a direct database write?
5. How to prepare for system design questions as a PM ↑
As you can see from the complex questions above, there is a lot of ground to cover when it comes to PM system design interview preparation. So it’s best to take a systematic approach to make the most of your practice time.
Below, you’ll find a prep plan with links to free resources.
5.1 Learn the concepts
There is a base level of knowledge required to be able to speak intelligently about system design. You don't need to know EVERYTHING about sharding, load balancing, queues, etc.
However, you will need to understand the high-level function of typical system components. You'll also want to know how these components relate to each other, and any relevant industry standards or major trade-offs.
To help you get the foundational knowledge you need, take a look at our 9-part deep dive on system design concepts. Click on the topic to go directly to the article you need.
- Network protocols and proxies
- Databases
- Latency, throughput, and availability
- Load balancing
- Leader election algorithms
- Caching
- Sharding
- Polling, SSE, and WebSockets
- Queues and pub-sub
5.2 Study the company you're applying to
If you already have a system design interview scheduled at a specific company, take the time to familiarize yourself with how its entire interview process works.
You also want to know if they have specific requirements for their system design interviews in particular. For example:
- Google system design interviewers prefer that candidates refrain from using specific products (e.g., certain databases, load balancers, etc.). Instead, they require candidates to build from scratch. This is to make sure they know how these components work, rather than resorting to a product that takes care of certain aspects like sharding.
- Meta, on the other hand, might give you the option to choose between a system design and product architecture/design interview. Meta system design interviews are focused on large-scale distributed systems, while product design is for user-facing products, i.e., APIs, data modeling, etc.
Before you prep, research your specific target. Check Glassdoor for recent PM and PM-T candidate reports at that company.
Read your target company's engineering blog to understand what kinds of technical problems they're actually working on. This gives you useful context for which question types are most likely and what product considerations matter to that specific company.
Your system design round is just one of the many topics you'll cover as a PM candidate. Know where it fits into the bigger picture by familiarizing yourself with the entire interview process. Here are relevant IGotAnOffer company PM guides to get you started:
- Google product manager interview guide
- Amazon product manager interview guide
- Meta product manager interview guide
- Microsoft product manager interview guide
- Apple product manager interview guide
- Netflix product manager interview guide
- NVIDIA product manager interview guide
- OpenAI product manager interview guide
- Oracle product manager interview guide
- Stripe product manager interview guide
- Coinbase product manager interview guide
- DoorDash product manager interview guide
- TikTok product manager interview guide
- General product manager interview process guide
For a detailed overview of what PM-T interviews involve beyond system design, see our technical PM interview guide.
5.3 Practice by yourself
A great way to start practicing is to interview yourself out loud. This may sound strange, but it will significantly improve the way you communicate your answers during an interview.
Use a piece of paper and a pen to simulate a whiteboard session, or use a whiteboard if you have one. There are also online whiteboarding tools like Excalidraw, Visual Paradigm, or Sketchboard.me, which are particularly useful for practicing for virtual interviews.
Play the role of both the candidate and the interviewer, asking questions and answering them, just like two people would in an interview. Trust us, it works.
5.4 Practice with peers
Once you've done some individual practice, we strongly recommend that you practice with someone else interviewing you.
If you have friends or peers who can do mock interviews with you, that's an option worth trying. It’s free, but be warned, you may come up against the following problems:
- It’s hard to know if the feedback you get is accurate
- They’re unlikely to have insider knowledge of interviews at your target company
- On peer platforms, people often waste your time by not showing up
For those reasons, many candidates skip peer mock interviews and go straight to mock interviews with an expert.
5.5 Practice with ex-interviewers
In our experience, practicing real interviews with experts who can give you company-specific feedback makes a huge difference.
Find a system design interview coach so you can:
- Test yourself under real interview conditions
- Get accurate feedback from a real expert
- Build your confidence
- Get company-specific insights
- Save time by focusing your preparation
Landing a job at a big tech company often results in a $50,000 per year or more increase in total compensation. In our experience, three or four coaching sessions worth ~$500 make a significant difference in your ability to land the job. That’s an ROI of 100x.
