EasyTechnical

53 practiced

Imagine you just joined Spotify as a PM on a new team. Outline a 30-60-90 day plan that covers stakeholder mapping, learning goals (product, data, users), early deliverables, and how you'd balance relationship-building with delivering measurable impact in your first quarter.

EasyBehavioral

42 practiced

Which Spotify product area or feature would you most like to own as a PM (examples: personalization/discovery, podcasts, creator tools, ads, Wrapped)? Describe the problem space, why it is strategically important to Spotify, the biggest risks, and how your experience positions you to lead that area.

MediumTechnical

37 practiced

Android premium conversions are materially lower than iOS conversions in multiple markets. As a PM, design an investigation plan: which datasets and segments you need, hypotheses to test (app UX, billing flows, pricing perception), experiments you'd run, and how you would present recommended fixes to execs.

Sample Answer

Requirements & goal:- Objective: diagnose why Android premium conversions << iOS across markets, and produce prioritized fixes that increase conversion and revenue without harming LTV.

Datasets & segments to pull:- Product analytics: funnel events (impression → click → plan page → start billing → success/failure) by platform, OS version, device model, carrier, market, acquisition channel, cohort, app version, locale, and experiment flag.- Billing logs: payment provider, error codes, decline reasons, retry attempts, tokenization rates.- Pricing/offer data: displayed prices, currency conversion, tax display, free trial vs discount offers by platform/market.- UX telemetry: time on screens, scrolls, abandon points, crash/restart rates, WebView vs native billing flows.- Customer data: account age, previous churn, payment method, past subscription attempts.- External data: Play Store reviews, payment method penetration by market, competitors’ pricing.

Key segments:- Market (low-conversion vs high-conversion)- New vs returning users- Acquisition source (organic, ad campaigns)- Device class (low-end vs flagship), Android OS versions- Payment method (card, carrier billing, Google Pay)

Hypotheses to test:1. Billing friction: Android payment integrations (Play Billing vs web) produce more failures or extra steps.2. Pricing perception: Prices show differently (currency/taxes) on Android causing sticker shock.3. UX discovery: Android UI funnels have different CTAs or content leading to lower intent.4. Technical instability: Higher crash/timeout rates on Android during billing.5. Audience mix: Android users in these markets have lower willingness-to-pay (WTP) or different payment method availability.

Experiments & analyses:- Analytics first: funnel-level conversion decomposition; compare failure rates and drop-off points per platform.- Billing log analysis: categorize failures; correlate failures with device/OS/payment method.- A/B tests: - Replace current Android billing flow with streamlined Play Billing flow or native IAP; measure conversion & error rates. - Price framing test: show localized price including taxes vs. price without taxes; trial vs discount messaging. - CTA and UX tweaks: primary CTA copy, one-tap purchase, reduced form fields; measure click-through and conversion. - Payment method experiments: prominently surface Google Pay / carrier billing in markets where used; measure uplift.- Qualitative: user interviews and usability testing for Android flows in target markets; support ticket analysis.- Canary rollout: for fixes that touch payments, rollout to a small % with close monitoring.

Success metrics:- Primary: premium conversion rate (view→purchase) uplift and revenue lift.- Secondary: payment failure rate, checkout time, refund/chargeback, CAC payback.

Presentation to execs:- One-slide TL;DR: problem statement, top 3 root causes, recommended fix with expected revenue uplift and confidence level.- Data story: funnel visualization highlighting where Android diverges, key metrics and sample size, and billing error breakdown.- Experiments plan: prioritized list (impact × confidence × effort), timelines, required teams (eng, payments, analytics, legal).- Risk & rollback plan: payment safety checks, monitoring dashboards, rollback thresholds.- Ask: concrete resources and go/no-go decision points.

Conclusion: prioritize quick wins (fix obvious billing errors, surface preferred payment methods, price framing) while running A/B tests for UX/billing changes; iterate using data and qualitative feedback.

MediumTechnical

40 practiced

Licensing costs for a major catalog have increased unexpectedly. As PM, how would you weigh product trade-offs (catalog availability, curated placements, feature investment), pricing strategies (regional price changes, bundling), and experiments to measure willingness-to-pay while minimizing churn and preserving relationships with labels and users?

Sample Answer

Clarify constraints and goals:- Immediate: absorb higher licensing cost without huge margin loss or churn.- Goals: preserve user experience and retention, maintain label relationships, and find sustainable revenue/UX trade-offs.- Constraints: contractual obligations with labels, regional price sensitivity, engineering effort/time.

Framework / approach:1. Triage short-term vs long-term moves (low-risk, quick; medium-risk experiments; strategic product changes).2. Quantify impact using scenarios (revenue, margin, churn, label relations score).3. Prioritize options by risk, speed, and stakeholder cost.

Short-term, low-friction actions (weeks):- Curated placements: reduce promotional placements for high-cost tracks/regions (soft throttle) rather than removing content—keeps catalog intact while lowering play/share of expensive content. Track engagement delta.- Regional price sensitivity analysis: use elasticity models and A/B tests (hold-out region) to evaluate small incremental price increases (e.g., +5-10%) where willingness-to-pay is highest.- Bundling offers: introduce or promote bundles (family, student, ad-free + podcast premium) with targeted discounts to increase ARPU without direct catalogue removals.

Medium-term experiments (1–3 months):- Willingness-to-pay experiments: randomized controlled trials with different price points, limited-time promotions, and value-add variants (exclusive playlists, early access). Metrics: conversion rate, churn over 90 days, LTV uplift.- Content-targeted paywalls: test opt-in premium access to exclusive/new releases vs broad availability; measure conversion and sentiment. Use labels as partners—offer revenue-sharing pilot to limit friction.

Product trade-offs and measurement:- Catalog availability vs curated placement: prefer availability but algorithmic deprioritization for costlier tracks. Measure listen-share by track cost bucket and user retention.- Feature investment: prioritize features that increase engagement/ARPU (personalized discovery, offline downloads) with smaller engineering cost first.- Pricing: prefer regional micro-adjustments and bundles over global price hikes to minimize backlash.

Stakeholder management (labels & users):- Proactive label negotiation: present data-driven pilots that can increase paid listens and revenue share; offer transparency and short-term guarantees or marketing support for pilot tracks.- User communication: frame changes as improved personalization and new bundles; avoid content removals messaging.- Legal/finance: ensure compliance with contracts before experiments.

Guardrails & metrics:- Primary metrics: net revenue, ARPU, 30/90-day churn, LTV, label revenue share impact.- Safety thresholds: stop any change if 30-day churn increases > X% or NPS drops materially.- Rollout plan: small randomized experiments → escalate successful variants regionally → global.

Expected outcome:- Short-term: mitigate cost pressure via placement and bundling, limited regional price tests.- Medium-term: data-backed pricing/product changes that preserve catalog, strengthen label partnerships via revenue-sharing pilots, and raise sustainable ARPU with controlled churn.

HardTechnical

44 practiced

Spotify leadership proposes centralizing certain global features, reducing squad autonomy for those areas. As a senior PM responsible for guiding the transition, design a change-management plan that minimizes disruption, explains who to involve, metrics to track during the migration, and criteria for which capabilities should remain decentralized versus centralized.

Sample Answer

Situation: Spotify leadership wants to centralize global features (e.g., recommendations, account billing flows) that today are owned by multiple squads. As senior PM, I must lead the transition while preserving velocity and product quality.

Plan (phased, low-risk):1. Clarify objectives & scope — define what “centralized” means, success metrics, and timeline. Prioritize capabilities by value and risk.2. Pilot & validate — pick 1–2 non-critical but common capabilities (e.g., global A/B testing infra) and run a 2–3 month pilot with volunteer squads.3. Gradual migration with co-ownership — for each capability, introduce a Central Capability Team (CCT) that owns platform-level design and SLAs while local squads retain product decisions during transition.4. Migration playbooks — provide API contracts, data contracts, runbooks, rollback plans, and dedicated migration sprints.5. Communication & training — weekly stakeholder syncs, office hours, technical workshops, and explicit RACI for each capability.6. Feedback loops — retrospective after each migration batch; adjust governance.

Who to involve:- Exec sponsor (for funding & mandate)- CCT (engineers, tech lead, PM, UX)- Affected product squads (product leads, eng, QA)- Data & analytics, infra, legal (GDPR/billing), biz ops- Developer experience & tooling

Metrics to track (before/during/after):- Customer impact: error rates, latency, feature adoption, NPS changes- Delivery health: lead time, deployment frequency, rollback rate- Squad health: cycle time, number of open tech-debt tickets, satisfaction survey- Business: revenue impact, retention uplift for features affected- Migration KPIs: % clients migrated, time per migration, incidents per migration

Decision criteria: centralize if- High cross-product reuse (>=3 squads) and duplication cost is high- Needs strict global consistency (billing, legal, finance)- Economies of scale improve performance/cost materially- Complexity of decentralization causes user-facing bugs or inconsistent UX

Keep decentralized if- Fast iteration is critical for competitive differentiation- Capability is tightly coupled to product-level strategy or local market needs- Localization or experimentation needs exceed what a central team can support quickly- Ownership by squad enables faster learning cycles and direct user feedback

Trade-offs & governance:- Define SLAs, escalation paths, and a lightweight Product Council to approve centralization proposals.- Accept short-term velocity dip; mitigate with buffer capacity and compensated resources in CCT.- Use metrics and pilot outcomes to re-evaluate: if centralization harms velocity or growth, consider hybrid or federated models.

Outcome: a measurable, reversible migration approach that balances global consistency and local autonomy while preserving squad delivery and user experience.

Why Spotify Specifically Questions

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Unlock Full Question Bank