Spotify Product Manager (Junior Level) Interview Preparation Guide

Soft launch (aka limited market launch)

• Goals: validate product/market fit, basic stability, pricing and localization assumptions; softly test go-to-market.
• Participants: small real-user segment in one geography or channel.
• Duration: 2–8 weeks.
• Controls: region targeting, analytics, simple feature flags.
• When to choose: new region or commerce changes, low-risk feature.
• Expected outcome: discover localized UX issues, initial retention and conversion benchmarks.

Closed beta

• Goals: deep qualitative feedback, bug discovery, workflow validation.
• Participants: invited power users, internal staff, partners.
• Duration: 4–12 weeks.
• Controls: invite-only access, feature flags, opt-in cohorts, feedback channels.
• When to choose: significant UX changes, new core flows requiring usability feedback.
• Expected outcome: prioritized bug list, design fixes, validated hypotheses.

Public beta

• Goals: broader product stress test, metrics validation, messaging experiments.
• Participants: any willing users (opt-in), early adopters.
• Duration: 4–12 weeks.
• Controls: opt-in toggle, percentage rollouts, telemetry.
• When to choose: near-production feature that needs scale testing and marketing validation.
• Expected outcome: stabilized metrics (DAU, crash rate), marketing copy refinement.

Staged rollout

• Goals: minimize risk while scaling; monitor and halt on regressions.
• Participants: progressively larger user cohorts (1% → 100%).
• Duration: hours to weeks depending on sensitivity.
• Controls: progressive percentage flags, device/OS cohorts, kill-switch.
• When to choose: backend changes, performance-sensitive features.
• Expected outcome: safe full launch with rollback if issues detected.

General availability (GA)

• Goals: full release, marketing push, revenue/engagement targets.
• Participants: all users.
• Duration: ongoing.
• Controls: standard monitoring, feature flags for future experiments.
• When to choose: confident in stability, metrics, and support readiness.
• Expected outcome: measurable business impact (lift in conversion/retention) and operational handoff.

Choosing tiers: combine them—start closed beta for UX, public beta for scale, staged rollout to mitigate risk, then GA.

Direct answer

In the moment, I de-escalate with a short, calm acknowledgment rather than defending point by point in public, then move the substance to a private conversation quickly. I resolve it there before returning anything final to the public thread, and I preserve the relationship by treating the private follow-up as genuine curiosity about what they saw, not damage control.

Structured elaboration

In the moment. A short, non-defensive acknowledgment that doesn't concede a point you haven't verified. Don't litigate the technical substance in the public thread; a back-and-forth there tends to escalate, since both people end up performing for an audience instead of solving the actual problem. This can be as simple as one line said in the room, or one line posted back in the thread: "good flag, let me look into that and follow up."

Follow up privately, quickly. Same day if possible, to actually understand the concern in full, away from the public framing, which is often more compressed or more pointed than intended.

Resolve the substance there, then close the loop publicly. A short, factual update, what was found and what changed, so the thread doesn't stay hanging as an unresolved public criticism. In a pull-request context, that update is often best as a concrete follow-up comment on the same thread, showing the fix rather than re-litigating the tone.

Preserve the relationship. Treat the private conversation as genuine curiosity about what they saw, not a negotiation to get them to back down.

Worked example

A senior engineer left a pull-request comment, visible to the whole team, saying my approach "showed a lack of understanding of how the service handles concurrency" and suggesting my change would cause a race condition (two operations happening at the same time in a way that produces the wrong result depending on which one finishes first). In the thread, I replied briefly: "good flag, let me dig into the concurrency behavior and get back to you," rather than apologizing profusely or arguing my design was fine. I then messaged them directly and asked them to walk me through the specific race they were worried about.

They were right about a real edge case under high load, though the public phrasing read as a broader judgment about my competence than the actual, narrower issue. We worked through the fix together on a quick call. I then posted a follow-up comment on the same pull request: "Confirmed the race condition under concurrent writes, thanks for catching it. Fixed by adding the lock (a mechanism that only lets one operation touch the shared data at a time) around the update in commit X, added a test for the concurrent case." That comment did double duty: it closed the technical thread with a concrete fix and quietly reset the public record from "you don't understand this" to "a specific bug was found and fixed," without relitigating the original tone.

Trade-offs and pitfalls

Defending yourself point by point in the same public thread usually escalates rather than resolves, since both people end up performing for the audience instead of solving the problem. Going silent in public after being publicly challenged can read as agreement or avoidance, so a brief acknowledgment before moving it private still matters. And posting only a public fix without ever actually talking to the person leaves the relationship unrepaired even if the code got fixed.

Direct answer

A promise made in a sales conversation isn't automatically a commitment the roadmap has to honor, but it also isn't something to dismiss by pointing at process. The job is to find out quickly how big the ask actually is, then either fold it into already-planned work, offer something narrower that satisfies the intent, or explain clearly why it can't happen and what happens instead, rather than letting 'the process says no' be the whole answer.

Structured elaboration

1. Get the real scope fast

Find out exactly what was promised and how technically involved it is. A quick conversation with sales and a fast technical read often turns 'they promised a change' into either 'this is a config toggle' or 'this touches several systems,' and those two cases should be handled completely differently.

2. Route by size, honestly

Small, low-risk asks can go through a lightweight fast-track with the right owner's sign-off. Larger asks go through normal prioritization, with the customer commitment logged as one input among others, not an automatic override of everything else on the roadmap.

3. The urgent-and-risky variant: when the fix means a breaking contract change

Sometimes the promise is a customer-facing bug fix, and fixing it correctly requires a breaking API contract change that frontend and mobile integrations depend on. Other systems, like the mobile app, expect the API to hand back data in an exact, agreed shape (that agreed shape is the contract); changing that shape without warning breaks them, because their code is written to read the old shape and has no way to interpret the new one. Here the stakes shift: this isn't a process-bypass question anymore, it's a technical breakage risk question. The right move is to check who else depends on the contract, see whether the fix can ship as an additive, non-breaking change instead (meaning something new is added without touching what already works, so nothing that currently depends on the contract is disturbed), and if a break is genuinely unavoidable, version it and coordinate a migration window with every dependent integration before flipping it, rather than shipping it hot for one customer's benefit while breaking others silently.

4. The reverse-direction variant: when the roadmap deprioritizes something already promised

Sometimes there's no new promise to accommodate at all; instead, a roadmap shift deprioritizes a feature that was already promised to enterprise customers. Here the job isn't to accommodate a new ad hoc promise, it's to build a walk-back communication plan: get ahead of it with the account team before the customer notices the date has slipped, be specific about the new timeline or an alternative that addresses the underlying need, and give the customer-facing team language they can actually use, rather than leaving them to explain a surprise on their own.

5. Close the loop both ways

Tell the customer-facing team what was decided and why. Tell the team that owns the process whether the promise revealed a real gap worth fixing, such as a fast-track path that didn't exist yet, or a case where sales needs earlier visibility into technical constraints before a call.

Worked example

A rep promises a customer a small label change during a renewal call. A quick check shows it's a low-risk config change, so it ships that week through the lightweight path with the account owner's sign-off, and the exception gets logged. Contrast that with a case where a rep promises a fix to a data-export bug, and fixing it correctly means changing the shape of a public API response that a mobile app and two partner integrations depend on. Instead of pushing a fast fix, the team ships an additive new field alongside the old one, migrates the highest-risk integration first behind a feature flag (a toggle that turns the new behavior on for one group at a time, so it can be tested on a small slice before everyone gets it), and only removes the old field once every consumer has moved over, later than the customer originally hoped, but without breaking anyone else in the meantime. Separately, when a previously promised enterprise feature gets bumped by a roadmap shift, the team gives the account manager a specific revised date and a smaller interim capability to offer, so the customer hears a plan instead of discovering the slip on their own.

Trade-offs and pitfalls

• Using process purely as a shield, with no real attempt to find a legitimate fast path, damages trust with both sales and the customer for no real safety gain.
• Letting one ad hoc exception become the unwritten template invites every future promise to bypass prioritization; log exceptions and periodically check whether the process itself needs a documented fast lane instead.
• Treating a breaking-change fix as a normal prioritization question, rather than a dependency-risk question, is how a favor to one customer quietly breaks several others.
• Not looping back to ask why sales made a promise outside the guardrails in the first place means the same collision happens again on the next renewal call.

Direct answer
An API is a defined contract that lets one piece of software request functionality or data from another without knowing its internals, and the choice between REST, GraphQL, and gRPC shapes real product trade-offs in how the API evolves, performs, and feels to integrate with, not just a technical preference.

Structured elaboration

• REST: models the API as a set of resources accessed via standard HTTP verbs, with each endpoint typically returning a fixed response shape. Practical consequences: versioning is straightforward (path or header-based, as widely understood), caching works naturally with standard HTTP caching semantics since responses map cleanly to URLs, and it's broadly familiar to developers, lowering onboarding friction, but clients often over-fetch or under-fetch data relative to their exact needs since the response shape is fixed per endpoint.
• GraphQL: lets clients specify exactly which fields they need in a single query, often across what would be multiple REST calls. Practical consequences: reduces over-fetching and the number of round-trips for complex, nested data needs (valuable for mobile clients on constrained networks), but standard HTTP caching doesn't apply cleanly (most GraphQL traffic goes through a single endpoint via POST, requiring a different caching strategy), and it shifts real complexity to the server (query cost analysis to prevent expensive, poorly-formed client queries from overloading the backend). Versioning also works differently here: rather than shipping a new versioned endpoint, GraphQL typically evolves a single schema over time by adding new fields and marking old ones deprecated, which lets clients migrate at their own pace but requires disciplined schema governance so deprecated fields don't accumulate indefinitely.
• gRPC: a binary, contract-first protocol built for efficient service-to-service communication, typically not directly consumed by browser-based clients. Practical consequences: very low latency and efficient serialization, well suited to internal microservice communication or high-throughput client scenarios, but it requires generated client code from the service's defined contract (less flexible for ad-hoc, exploratory API consumption) and has weaker native support in web browsers. Versioning is tied directly to the protobuf contract: backward-compatible changes are typically made by adding new optional fields with new field numbers, while a genuinely breaking change requires a new service or package version, and clients must regenerate their stubs from the updated contract to pick up either kind of change, unlike REST's runtime-negotiable path or header versioning.

Worked example: a public-facing e-commerce order API with a broad, less sophisticated developer audience (small businesses integrating simple order creation and lookup) is well served by REST, since its familiarity and cacheability outweigh the modest over-fetching cost for simple resource access patterns. A mobile app's data layer aggregating a user's profile, recent orders, and personalized recommendations in a single screen load is well served by GraphQL, since it collapses what would be three or four separate REST calls into one request shaped exactly to the screen's data needs, reducing latency on a constrained mobile network.

Trade-offs and pitfalls
The most common mistake is choosing GraphQL primarily because it's newer or more flexible without accounting for the real backend complexity it introduces (query cost limiting, a different caching strategy), which can create more operational risk than the flexibility is worth for a simple API. The second common mistake is assuming the choice is permanent and irreversible; many platforms successfully offer REST and GraphQL as parallel interfaces over the same underlying services, serving each client type through whichever style fits its access pattern best.

Direct answer. Start from the capacity: derive what fits, define the one job the MVP (minimum viable product: the smallest product that tests the core idea) must prove, sort features with MoSCoW, and agree the cut order before work starts. Then explain cuts in terms of the goal, not preferences.

Capacity (illustrative: 2 engineers, 6 weeks). 2 x 6 = 12 person-weeks. Keep a 20% buffer (time held back for surprises): 12 x 0.2 = 2.4, leaving 9.6 person-weeks to plan.

MoSCoW (Must, Should, Could, Won't have this time; an approach from rapid application development, a style of building software in short cycles) with estimates, for a community app where people post and follow each other:

Musts total 8.0, plus the Should 1.5 gives 9.5, within 9.6. Coulds (2.0) are not in the committed plan; they only start if we are ahead. Check the Must share against the DSDM (Dynamic Systems Development Method) guideline. MoSCoW was created by Dai Clegg in 1994 for rapid application development and is used heavily in DSDM, whose published guidance is typically no more than 60% Must Have effort, measured against the planned effort for the timeframe (Won't items excluded), with around 20% Could Have effort as contingency. Planned effort here is 8.0 + 1.5 + 2.0 = 11.5 person-weeks, so Musts are 8.0 / 11.5 = 69.6%, Shoulds 13.0% and Coulds 17.4%. That is above the 60% guideline, so this plan is at the risky end: confidence that every Must lands is lower than DSDM recommends. (Against the whole 12 person-weeks the Musts are 67%, and against the 9.6 plannable weeks 83%, but neither is the basis the guideline uses.) The 2.4-week buffer is my own addition, not part of DSDM's rule, and it does not fix the ratio; the fix is to narrow Musts before the build starts, for example a simpler profile (1.0 instead of 1.5) and a chronological feed (1.5 instead of 2.0), which brings Musts to 7.0 of 10.5 planned (66.7%), closer to the guideline though still above it, and to keep the buffer for the surprises that remain.

What to cut first if it slips. Reverse order of value. Because the Coulds are not in the committed plan, the first cut is simply not starting them (notifications, then analytics beyond one launch event) and spending that time on the buffer. If the slip continues, cut comments next, keeping likes only. Musts are never cut; if even they slip, move the date or the launch audience, not quality of safety features like report and block.

Choosing in/out. I use a PR/FAQ (a press release and customer FAQ written as if launched). Write the headline first, for example: "Neighbours can now sign up, post, follow each other, see a feed and stay safe with report and block." If a feature is not needed to write that headline, it is not a Must; direct messages do not appear in it, so they are a Won't. Another way to cut is to serve one segment first. Suppose the app has moderators (volunteers who review reports), power users (who post daily) and casual users (who mostly read). Pick the segment whose need is sharpest, for example moderators, who need report and block to keep a new community safe, and give the others a clear later path.

Explaining cuts. Show the table and the rule: "This is what the first version must prove. Each cut buys the buffer that protects the date." Give the owner of each Won't a date to revisit.

My default communication style is clear, structured, and outcome-focused: I state the objective, current status, key risks/asks, and next steps. I adapt tone, detail, and format to fit the audience so conversations are efficient and action-oriented.

(a) Engineers — implementation risks:
Situation/Example: In a planning session for a new sync feature I said: “Goal: atomic sync across devices. Risk: conflict resolution at scale may add 4–6 weeks.”
Action: I switch to technical language, include architecture sketches, data volumes, and concrete failure modes. I invite engineers to propose mitigations and estimate effort.
Reason: Engineers need precise, actionable details to evaluate feasibility and trade-offs, so I use technical depth and collaborative problem-solving format.

(b) Executives — outcomes:
Situation/Example: During a quarterly review I presented product progress.
Action: I distilled to KPIs (DAU, retention lift, revenue impact), a one-slide summary, and two recommended decisions with trade-offs and cost/benefit.
Reason: Executives focus on strategic impact and decisions; concise, metric-driven summaries with recommended asks respect their time.

(c) Customers — product value:
Situation/Example: In customer interviews about onboarding I explained the feature and asked about pain points.
Action: I use simple, benefit-led language, tell stories/use cases, and validate with open questions. I share prototypes or walkthroughs and listen more than I talk.
Reason: Customers care about practical value and experience; empathetic tone and examples drive candid feedback.

Across all, I close with clear next steps and ownership so communication converts to action.

Direct answer

Write a changelog entry that states what changes, who is affected and the two dates (deprecation and shutdown), then a migration note that is a short before-and-after with a field mapping table and a "what to do by when" list. It is usable by a skimmer when the first line says whether they must act, the dates are exact, the change is shown as code, not described, and the detail is layered underneath.

Terms: a cursor is an opaque bookmark string the server returns with a page of results; you send it back to get the next page, instead of asking for "page 2". That is why a total count disappears: the server no longer numbers pages, it only knows where you left off. A changelog is a dated public log of changes to the API. Deprecating an endpoint means announcing it will be retired while it still works. Sunset is the date it stops working.

The changelog entry

2026-10-01  DEPRECATION  GET /v1/users will be removed on 2027-04-01

Action required if you call GET /v1/users. Use GET /v2/users instead.
Nothing changes for other endpoints.

- Deprecated: 2026-10-01. Still works, and now returns Deprecation and Sunset headers.
- Removed: 2027-04-01. After this date /v1/users returns 410 Gone.
- Why: v2 adds cursor pagination and fixes inconsistent field names.
- Migration guide: /docs/migrate-list-users

The migration note

Who is affected: anyone calling GET /v1/users. Check your logs for that path.

What to change, in three steps:

1. Change the URL from /v1/users to /v2/users.
2. Replace page numbers with the cursor (?limit=50&cursor=...).
3. Read the list from data instead of the top level.

Paging loop under v2 (Python):

import requests

cursor = None
users = []
while True:
    params = {"limit": 50}
    if cursor:
        params["cursor"] = cursor
    body = requests.get("https://api.example.com/v2/users", params=params,
                        headers={"Authorization": "Bearer KEY"}).json()
    users.extend(body["data"])
    cursor = body.get("next_cursor")
    if not cursor:
        break

Call 1 sends no cursor and returns 50 users plus next_cursor: "abc123"; call 2 sends cursor=abc123 and returns the next 50; the last page has no next_cursor, so the loop stops.

Before (v1):

{"users": [{"id": 7, "name": "Ana"}], "page": 1, "total": 240}

After (v2):

{"data": [{"id": "usr_7", "full_name": "Ana"}], "next_cursor": "abc123"}

Signals in the API itself. Headers are name-value lines sent with every response, so a program can read them without parsing prose. Starting on the deprecation date, v1 responses carry Deprecation: @1790812800 (the date 2026-10-01 as a Unix timestamp, the format RFC 9745 defines) and Sunset: Thu, 01 Apr 2027 00:00:00 GMT (RFC 8594). Programs can detect them, so warnings show up in client logs without anyone reading the changelog.

What makes it skimmable

• Lead with the action, then the reasons.
• Exact dates, not "soon" or "next quarter". 182 days separate the deprecation and removal here.
• Code and a table, not paragraphs. A reader can copy the new call.
• One task per step, in order, and each step is checkable.
• Say what does NOT change, so most readers can stop reading.
• Specific error after the sunset (410 Gone), the HTTP status meaning "this resource existed and was removed on purpose", so nobody is guessing.

Pitfalls

• Changing the type of id is the sneakiest break; call it out.
• Do not remove a field without a mapping row. Do not bury the dates in the last paragraph.
• Give the migration a support channel, and send the notice by email to key owners found in usage logs, since many will never read a changelog.

I build a senior PM talent pipeline and succession plan as a multi-stage, transparent program that combines objective assessment, deliberate development, and equity safeguards.

Stages

• Identify: talent review with managers + calibration against role rubric; include high-potential external hires.
• Develop: 12–18 month individualized development plans (IDPs) with milestones.
• Validate: stretch assignments and rotational experiences plus formal assessments.
• Promote/Backfill: readiness sign-off, transition plan, and bench hires.

Assessment criteria (role-specific rubric)

• Strategic thinking: portfolio roadmap quality, customer insights, market thesis
• Execution & influence: cross-functional delivery record, stakeholder outcomes
• Business impact: revenue/engagement metrics, trade-off decisions
• People leadership: mentoring, hiring, team health
• Judgment & scalability: handling ambiguity, scaling processes

Stretch assignments

• Leading a cross-product initiative or M&A integration
• Owning a high-visibility P&L or turnaround product
• Rotations into GTM, data science, or engineering leadership
• Acting as interim head for 3–6 months with measurable KPIs

Ensure diversity & fairness

• Use calibrated rubrics and blind components (e.g., anonymized work samples)
• Diverse interview and promotion panels; mandatory calibration meetings
• Track and report pipeline demographics and outcomes quarterly
• Sponsor underrepresented PMs with executive mentors and funded development
• Audit promotion decisions annually for bias and adjust promotion criteria

Measurement & governance

• KPIs: internal hire rate for senior PMs, time-to-fill, diversity of hires, promotion conversion, post-promotion success metrics
• Governance: HR+Product leadership quarterly reviews, 1:1s to adjust IDPs

This creates predictable, equitable advancement while ensuring promoted senior PMs have proven strategic impact, execution credibility, and the leadership skills to scale.

Objective: measure whether segment-specific price cuts in response to a competitor discount produce at least a 5% lift in revenue per user (RPU) for target segments, while limiting downside risk.

Design summary

• Segments: define segments by business logic (e.g., high-LTV shoppers, price-sensitive, new users). Run independent experiments per segment (or use blocked design with stratification).
• Randomization: stratified random assignment at user level (or account level) into Test (receive competitor-matched discount/price change) and Control (no change). Use hashing-based assignment to ensure stable exposure.
• Treatment exposure: single treatment variant per segment to avoid multiple comparison complexity.

Sample size (power) — formula and worked example

• For continuous primary metric (RPU), required per-group sample:
  n = 2 * (Z_{1-α/2} + Z_{1-β})^2 * σ^2 / Δ^2
  where Δ = absolute lift you want to detect, σ = SD of RPU, α=0.05, power=0.8 (β=0.2), Z_{1-α/2}=1.96, Z_{1-β}=0.84.
• Example: baseline mean RPU µ = $50, SD σ = $80 (estimate from past 90 days), 5% lift ⇒ Δ = 0.0550 = $2.50.
  Zsum = 1.96+0.84 = 2.80; n = 2(2.80)^2 * 80^2 / 2.5^2
  n ≈ 27.846400/6.25 ≈ 100,352/6.25 ≈ 16,056 users per arm.
• If your segment has lower SD or higher baseline, adjust. If metric is highly skewed, consider log-transform or use bootstrapped inference; compute sample sizes on transformed scale or for conversion uplift if more appropriate.

Duration

• Determine expected daily unique users per segment (traffic). Duration = ceil(n_per_arm * 2 / daily_visitors_in_segment). Add extra buffer (20%) for data loss and to observe downstream behavior (returns, refunds).
• Minimum duration: at least one full business cycle (e.g., 28 days) to cover weekly seasonality; recommended 4–8 weeks for robust revenue effects.

Metrics to monitor

• Primary: revenue per user (RPU) or revenue per active user over the observation window.
• Secondary: conversion rate, average order value (AOV), number of transactions per user, returns/refunds, gross margin impact.
• Safety & leading indicators: daily revenue delta vs control, cancellations, customer complaints/CS volume, coupon usage, repeat purchase rate (30/60/90d).
• Statistical approach: pre-register primary metric, use two-sided t-test or bootstrap CIs; adjust for multiple segments/tests (Bonferroni or Benjamini-Hochberg) or use hierarchical modeling to borrow strength.

Risk mitigation & guardrails

• Exposure caps: limit initial test exposure to a small % of the segment (e.g., 10%) and ramp to target (e.g., 10% → 30% → 50%) after manual checks.
• Automated safety stops:
  • Stop if short-term revenue per day for test falls > X% (e.g., 3–5%) below control for 3 consecutive days and statistically significant (p<0.01).
  • Stop if cancellations/refunds or CS volume exceed threshold.
• Profitability guardrail: monitor margin-adjusted revenue; don't optimize only for gross revenue if margin is negative.
• Holdback groups: keep an always-control holdout (e.g., 10% of segment) to measure market drift/competitor effects.
• Incremental rollout: start with a pilot (smaller sample) to validate instrumentation, then scale.
• Instrumentation & data quality: ensure event tracking, order attribution, and A/B assignment logging are validated before going live.
• Analysis plan & pre-registration: pre-specify metric definitions, aggregation window, winsorization, and missing data handling; lock analysis code.
• Customer experience: limit frequency of discount exposure (throttle), avoid showing price changes that surprise existing subscriptions; communicate pricing changes via FAQ/CS scripts.

Other considerations

• Multiple comparisons: if testing multiple segments or variants, prefer hierarchical Bayesian analysis or correct for family-wise error.
• Heterogeneous treatment effects: estimate and report uplift by subgroups (e.g., device, geography).
• Long-term effects: run post-experiment monitoring for churn and repeat purchases up to 90 days.

Concrete next steps for PM

1. Pull baseline RPU and SD per segment for sample-size precision.
2. Define exact treatment mechanics, discount amount, and UI treatment.
3. Implement stratified randomization and logging.
4. Pre-register analysis plan and guardrails with stakeholders.
5. Launch pilot, validate data, then ramp to full experiment.

In the moment, I would stop the blame loop and focus on the shared outcome. I would acknowledge the miss, ask for the facts, and clarify the handoff point that failed. By handoff, I mean the moment one team passes work to another with clear expectations.

I would say something like, "Let's separate what happened from who to blame. What was the requirement, what was the agreed due date, and what did each side believe was done?" If our requirements were unclear, I would own that and propose the next concrete step, such as a revised spec, a quick review, or a smaller interim deliverable so the project does not stall completely.

For the next milestone, I would prevent repeat issues by adding written acceptance criteria, a short handoff checklist, and a scheduled signoff before work starts. For example, if an API needed three required fields and one edge-case behavior, I would list those explicitly in the ticket and get both teams to confirm them before implementation. That lowers ambiguity and makes accountability much easier.