PM interview prep
Difficult questions a Senior PM might face in this case study, and how to answer them.
Risk/revenue matrix
Use this to justify prioritisation. Phase 0 comes first because it's high risk AND blocks revenue.
| Item | Risk if skipped | Revenue impact | Effort | Priority |
|---|---|---|---|---|
| Phase 0: Multitenancy (RLS) | Critical — GDPR fines, breach, lawsuits | Blocker — enterprise deals rejected without it | Medium (4-12 weeks) | 1 — Must do first |
| Phase 1: Scope definition | Medium — scope creep, support burden | High — defines what we can sell | Low (2-3 weeks) | 2 — Do immediately after |
| Phase 2: Versioning | High — breaking changes break clients | High — client retention depends on stability | Medium (4-6 weeks) | 3 — Before scaling |
| Phase 3: File drop (S3/SFTP) | Low — simplest option | High — works for most clients | Low (2-4 weeks) | 4 — First delivery mechanism |
| Phase 3: API access | Low — nice to have | Medium — some clients want real-time | Medium (4-6 weeks) | 5 — After file drop works |
| Phase 3: Data share (Snowflake/BigQuery) | Low — premium option | Medium — enterprise upsell | Medium (4-6 weeks) | 6 — Premium tier |
| Phase 3: Embedded dashboards | Low — alternative to raw data | Low — clients asking for raw data, not dashboards | High (8-12 weeks) | 7 — Only if demand |
| Phase 4: Governance | Medium — compliance gaps | Indirect — retention, trust | Ongoing | Continuous — starts with Phase 0 |
| Phase 5: Productise (pricing, packaging) | Low — can do manually first | High — turns cost centre into revenue | Medium | 8 — Once delivery works |
The 2x2 view
HIGH REVENUE IMPACT
│
┌─────────────────────┼─────────────────────┐
│ │ │
│ Phase 1 (Scope) │ PHASE 0 (RLS) │
│ Phase 2 (Version) │ ← DO THIS FIRST │
│ File drop │ │
│ │ │
LOW ─────┼─────────────────────┼─────────────────────┼───── HIGH
RISK │ │ │ RISK
│ │ │
│ Dashboards │ (nothing here │
│ Data share │ ideally) │
│ API access │ │
│ │ │
└─────────────────────┼─────────────────────┘
│
LOW REVENUE IMPACT
Reading this: Phase 0 is top-right (high risk if skipped, high revenue impact). That's why it's priority 1. Dashboards are bottom-left (low risk, low revenue for this brief) — do last or not at all.
Phase 0 — PM-level questions
These test prioritisation, stakeholder management, and business thinking — not technical knowledge.
| Question | What they're testing | How to answer |
|---|---|---|
| Engineering says Phase 0 will take 6 months. Sales promised the client 3. What do you do? | Stakeholder management, negotiation, managing expectations | Reset with sales and client immediately. Explain what's possible, offer interim solutions (manual extract for now, automated later). Never promise what you can't deliver — own the conversation early |
| How do you prioritise Phase 0 against 5 other features clients are screaming for? | Prioritisation frameworks, saying no, communicating trade-offs | Phase 0 is a blocker — nothing else ships securely without it. Frame it as unblocking everything else, not competing with it. Use a risk/revenue matrix to show why it comes first |
| The CEO asks "why are we spending engineering time on something clients don't see?" | Executive communication, selling internal work, business case articulation | "They don't see it, but they'll reject us without it. Enterprise clients require security evidence. And if we skip it, one breach costs us £17M+ in fines and every client's trust" |
| Legal says we need multitenancy. Engineering says it's not their top priority. How do you resolve it? | Cross-functional influence without authority | Align on the risk first. Bring engineering into the legal conversation. Make it their problem too, not a mandate from above. Find scope they can commit to |
| A client threatens to leave if they don't get data export in 4 weeks. Phase 0 alone takes 6. What's your move? | Crisis management, creative problem-solving, knowing when to say no | Be honest: "We can do a secure manual extract now, or wait 6 weeks for automated. We won't ship something insecure." Offer the interim, protect the relationship, don't cave on safety |
| How do you measure success for Phase 0? It has no direct revenue. | Defining metrics for enabling/foundational work | Pen test pass rate. Time to answer security questionnaires. Number of enterprise deals unblocked. Reduction in manual extract requests. These are leading indicators of revenue |
| You've shipped Phase 0. How do you know it actually works? | Defining "done," acceptance criteria, validation | Automated isolation tests pass. External pen test passes. Can fill out client security questionnaire with evidence. First secure export delivered without incident |
| The sales team keeps promising custom data fields. How do you handle scope creep? | Product discipline, managing commercial pressure | Define what's in the standard product vs custom. Custom is quoted separately. Sales needs a pricing framework, not a blank cheque. Work with commercial to create it |
| What's your 12-month roadmap for this data product? Walk me through it. | Strategic thinking, sequencing, phased delivery | Phase 0 (multitenancy): months 1-2. Phase 1 (scope definition): month 3. Phase 2 (versioning): months 4-5. Phase 3 (delivery mechanism): months 6-7. Phase 4 (governance): ongoing. Phase 5 (productise): months 8-12 |
| You have to cut scope. What do you drop from Phase 0 and why? | Trade-off decisions, understanding what's truly essential | Keep: RLS on export tables, pen test, automated tests. Cut: full database coverage (do export tables only), fancy monitoring (basic logging is enough for MVP). Secure the exit path first |
| How do you get buy-in from engineering when they'd rather build features? | Influence, storytelling, making the case | Show the cost of not doing it: blocked deals, breach risk, fines. Show the benefit: once done, we can sell to every enterprise client. Make it a "build once, unlock many" story |
| A competitor launches a data export feature next month. Does that change your plan? | Competitive response, staying focused vs reacting | Not fundamentally. We don't rush and ship something insecure because a competitor moved. We might accelerate, but we don't skip Phase 0. Speed without safety is a liability |
Phase 1 — scope questions
How do you support different client requirements without building custom code for each?
| Layer | What it covers | How it's handled |
|---|---|---|
| Standard scope | The 80% that most clients need (repairs, properties, compliance, work orders) | Built once, available to all. This IS the product |
| Configuration | Delivery schedule, file format, destination, which tables they want from the standard set | Config per client — no code, just a settings row |
| Custom fields/tables | The 20% where one client has a unique ask | Quoted separately, funded by that client, or "no" |
The product discipline: You're NOT trying to support every requirement. You define what's IN the product (standard scope), what's OUT (custom or "not available"), and price the difference.
What the client sees: settings page
┌─────────────────────────────────────────────────────────────┐
│ PLENTIFIC › Settings › Data Export │
├─────────────────────────────────────────────────────────────┤
│ │
│ Destination │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Type: [Amazon S3 ▼] │ │
│ │ Bucket: [nhg-data-imports] │ │
│ │ Path: [/plentific/daily/] │ │
│ │ Credentials: [••••••••••••] [Update] │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Schedule │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Frequency: [Daily ▼] │ │
│ │ Time: [02:00 UTC ▼] │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Data included │
│ ☑ Repairs │
│ ☑ Properties │
│ ☑ Compliance records │
│ ☐ Work orders (coming soon) │
│ │
│ [Save changes] │
│ │
├─────────────────────────────────────────────────────────────┤
│ Recent exports │
│ ┌──────────────┬──────────┬─────────┬─────────────────┐ │
│ │ Date │ Status │ Rows │ File size │ │
│ ├──────────────┼──────────┼─────────┼─────────────────┤ │
│ │ 14 Sep 02:00 │ ✓ Done │ 48,291 │ 12.4 MB │ │
│ │ 13 Sep 02:00 │ ✓ Done │ 48,105 │ 12.3 MB │ │
│ │ 12 Sep 02:00 │ ✓ Done │ 47,892 │ 12.1 MB │ │
│ └──────────────┴──────────┴─────────┴─────────────────┘ │
│ │
│ [Trigger manual export] [View all history] │
│ │
└─────────────────────────────────────────────────────────────┘
Client-facing API
We build this. It's NOT the existing Plentific API — it's a small, new API specifically for the data export product.
| Endpoint | What client uses it for |
|---|---|
GET /exports/latest |
"Did my export run? What's the status?" |
GET /exports/history |
"Show me exports from this month" |
POST /exports/trigger |
"I need a re-export now, don't wait for 2am" |
PUT /config/destination |
"We changed our S3 bucket" |
GET /config |
"Show me my current settings" |
Phase 0 — technical questions
You need to understand these, but don't get lost in the detail. Know enough to be credible, focus on decisions.
| Question | How to answer |
|---|---|
| What is multitenancy? | One system, many clients, each sees only their own data. Not separate databases per client |
| Why can't we just filter in queries? | Human error — one missed WHERE clause = data breach. RLS enforces it at database level, no exceptions |
| How long will Phase 0 take? | Depends on current state. Need to audit first. If tenant IDs exist: 4-6 weeks. If gaps: 8-12 weeks |
| What's the risk of not doing it? | GDPR fines (£17.5M or 4% turnover), client lawsuits, contract termination, reputation destroyed |
| What if tenant IDs don't exist on some tables? | Then we have a data problem first. Need to backfill or restructure. This is why we audit before estimating |
| What about reference/lookup tables shared across clients? | Those don't contain client data — they're fine to share. Example: a list of repair categories. But anything with client-specific records needs isolation |
| What about historical data that was never tagged with tenant? | Risky. Options: backfill if possible, exclude from exports if not, or accept that old data can't be exported safely |
| How do you test multitenancy without using production data? | Create test tenants with synthetic data, run queries as each tenant, verify isolation. Also: security team does pen testing |
| Can you guarantee zero data leakage? | No one can guarantee zero. But RLS is the industry standard, and we'll have automated tests + pen testing + monitoring. That's the defensible position |
| What are automated tests for multitenancy? | Create test data for Tenant A and B. Query as Tenant A. Assert: you see ONLY Tenant A's data, zero rows from B. Run on every deploy |
| What is pen testing? | Security experts try to break your system — find ways to access data they shouldn't. External pen test is more credible to clients |
| Is RLS industry standard? | Yes. Used by Salesforce, AWS, most modern B2B SaaS. Built into PostgreSQL, SQL Server, Oracle, Snowflake |
Common PM traps
What NOT to do in the interview:
| Trap | What good looks like |
|---|---|
| Getting lost in technical details | Know enough to be credible, but focus on decisions, trade-offs, outcomes |
| Saying "engineering decides that" | You own the WHAT and WHY. Engineering owns HOW. You can't abdicate the decision |
| No clear prioritisation logic | Have a framework: risk, revenue, effort, dependencies |
| Can't articulate the business case | "It enables revenue and protects us from fines" — simple, clear |
| No plan for stakeholder conflict | Show you can navigate competing priorities |
| Promising what you can't deliver | Be honest about constraints. Offer alternatives. Don't cave to pressure |
| Treating security as optional | Phase 0 is not negotiable. You can scope it, but you can't skip it |
The killer question (be ready)
"If multitenancy is so critical, why hasn't it been done already?"
How to answer:
"Probably because manual extracts worked for the clients they had, and the security risk wasn't visible until enterprise clients started asking hard questions. That's normal — you don't build infrastructure until you need it. Now they need it."