Technical Understanding interview questions
Technical Understanding questions a Product manager can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A customer asks whether your product “has an API”, and the sales engineer forwards the question to you.
What is the customer actually asking, and what do you need in order to answer?
The strongest answer: They want another system to use our product without a person clicking: which operations are exposed, how they authenticate, what the limits are, and whether it is documented and supported
Why it works: Exactly — for a customer, “an API” means documented, authenticated, supported operations with limits, not the existence of endpoints.
- An API is a supported product.
- Which operations are exposed?
- How do they authenticate?
- Documented, versioned, rate limited.
A customer asks for “read-only users”. In refinement the engineers start talking about authentication and authorization as two separate things.
What is the difference, and which one is this ask?
The strongest answer: Authentication is proving who you are — login, SSO, a second factor. Authorization is what that identity may do. Read-only users is authorization: a role, plus the rule for every action
Why it works: Exactly — and the work is the rules: every screen, export, API call and notification has to know what a read-only user may do.
- Authentication: who you are.
- Authorization: what you may do.
- Read-only is a role.
- Decide the rule per action.
The tech lead asks for a full sprint of “tech debt work” and lists nine items, none of which a user would notice.
How do you decide?
The strongest answer: Ask what each item buys in terms we can both see — which changes get faster, which incidents stop, which risk goes away — then fund the ones the next bet depends on and schedule the rest
Why it works: Right — debt is not one thing. Ranked by what it unblocks, most lists split into “needed for the next bet” and “would be nice”.
- Ask what each item buys.
- Faster changes? Fewer incidents?
- Fund what the next bet needs.
- Schedule the rest, visibly.
You ask for “one more field” on the customer record. Engineering comes back with two weeks.
What is behind that number, and how do you respond?
The strongest answer: Adding a column is cheap; the cost is around it — filling it in for existing records, the reports and integrations that read the table, and doing it without locking a table users are hitting
Why it works: Right — ask what the two weeks is made of. There is often a thinner slice: new records only, or a default that avoids the backfill.
- The column is cheap; the data is not.
- Ask about backfill and readers.
- Ask what locks in production.
- Look for a thinner slice.
You are writing the PRD for a feature that lets users upload documents and share them with people outside the company.
What goes in it besides the flows?
The strongest answer: Who may see and share what, what we store and for how long, whether links expire, what the audit log records, what happens to the files when an account is deleted, and who reviews it
Why it works: Right — permissions, retention, expiry, audit and deletion are product decisions with user-visible consequences, and they are cheapest before the build.
- Decide the rules in the PRD.
- Who may see and share?
- How long do we keep it?
- Log it, expire it, delete it.
A large European prospect asks, in the security review, whether their data can stay in the EU. Sales has already told them it probably can.
How do you handle it?
The strongest answer: Find out before promising: where data sits today, where backups and logs go, which sub-processors touch it, and what a real EU deployment would cost — then answer with what is true now
Why it works: Right — residency covers every copy: primary, replicas, backups, logs, analytics and every vendor in the path. Answer with facts, then scope the gap.
- Residency covers every copy.
- Check backups, logs, replicas.
- List the sub-processors.
- Never confirm before you verify.
Buying a vendor for a core part of your product would save two quarters of build, and the demo was excellent.
What do you check before you sign?
The strongest answer: What happens when it fails or raises the price, whether we can get our data out and what leaving costs, who touches our customers’ data, their incident record, and the price at ten times today’s volume
Why it works: Right — the questions that matter are the year-three ones: exit, data, price at scale, and what we do on the day they have an outage.
- Buy the exit, not the demo.
- Can we get our data out?
- Price it at ten times volume.
- Ask who touches customer data.
You ask for per-team permissions. The architect says it cannot be done without reworking how the product stores ownership, and that it is a multi-quarter job.
You are not an engineer. How do you engage with that?
The strongest answer: Take the constraint seriously and get specific: what exactly blocks it, what a narrower version would cost, what else the rework unlocks, and what we offer customers meanwhile — then decide together, openly
Why it works: Right — a PM does not overrule an architecture claim, they make the trade-off legible: the cost, what it unlocks, the thinner slice, and who decides.
- Take the constraint seriously.
- Ask what exactly blocks it.
- Price the slice and the rework.
- Decide together, in the open.
How do you fund platform work without a fake leverage multiple?
The strongest answer: Name the jobs it unblocks this year and the tax teams will pay — I do not write “10× leverage”
Why it works: Exactly. Jobs and tax. 10×, starve-to-incident, and no-user platforms are three failures.
- Jobs this year + the tax.
- No 10× leverage slogan.
- Do not starve until incident.
- Keep a user in the sentence.