Strategy question
One large customer wants a custom capability that would help them launch quickly, but it does not yet fit Sierra's core platform. How would you decide whether to build a customer-specific solution, create a configurable enterprise feature, or say no? What decision criteria would you use, and how would expected revenue, reuse across accounts, implementation cost, and long-term product complexity factor in?
- Sierra
- Strategy
- Hard
Practice this question out loud. An AI interviewer asks it, follows up like a real interviewer would, and scores your answer. Type or speak.
Start a mock interview on this question · Mock interview from a job description
What this question tests
Tests the three-way decision between a bespoke customer solution, a configurable enterprise feature, or declining, weighing revenue, reuse, and complexity.
How to approach it
- Quantify the customer's launch value and urgency, since a fast-launch need pushes toward a quicker bespoke or configurable path over a full platform build.
- Assess reuse across accounts by checking if similar requests have surfaced elsewhere, even informally, not just from this one customer.
- Estimate long-term product complexity cost for each option, since a bespoke fix adds maintenance debt while a configurable feature adds permanent surface area.
- If reuse is likely and complexity is manageable, build a configurable enterprise feature, scoped minimally to hit the timeline.
- If reuse is unlikely but revenue justifies it, take the bespoke path but cap and document it clearly as scoped debt.
- If reuse is unlikely and revenue does not justify the complexity cost, say no and offer a partial workaround or services alternative.
What a strong answer includes
- Uses revenue, reuse, and long-term complexity together as explicit decision inputs, not a single dominant factor.
- Treats declining as a real option with an alternative offered, not an implicit last resort.
- Scopes the configurable feature minimally to respect both the timeline and the long-term complexity concern.
Common mistakes
- Defaulting to 'yes, build it' without weighing long-term complexity cost.
- Never considering decline as an option even when reuse and revenue are both weak.
Likely follow-up questions
- How would you validate reuse potential before committing to a configurable feature?
- What would you do if this customer's revenue alone is enough to justify a bespoke build?
More strategy questions
- Sierra uses outcome-based pricing. How would you design and defend that model?Sierra · Strategy · Hard
- How would you handle a Sierra agent giving a customer wrong information that costs the client money?Sierra · Strategy · Hard
- How should Sierra compete with Decagon and incumbent CX vendors like Zendesk?Sierra · Strategy · Hard
- Traffic is growing, p95 agent latency is degrading, and GTM is asking for faster delivery of customer-specific features. As PM for Infrastructure, how would you decide what to do in the next quarter: performance work, reliability hardening, cost optimization, or platform investments that unblock product teams? Walk through the framework, inputs, and tradeoffs you would use to make and defend that prioritization.Sierra · Strategy · Hard
- You have separate 30-minute meetings with a CIO and an engineering lead at the same prospect. How would you change the demo, proof points, and objections you address for each audience while keeping the core product story consistent?Sierra · Strategy · Medium
- Three enterprise customers request similar capabilities, but each wants different workflow details. How would you decide whether to build a one-off feature, create a reusable platform capability, or advise a process workaround instead, and what criteria would drive the roadmap decision?Sierra · Strategy · Hard
More questions from Sierra
Learn the skill behind it
Chapters of the AI PM course that teach what this question tests.
- Chapter 4: Discovering and Sizing AI Opportunities
- Chapter 9: Measuring AI Product Economics
- Chapter 14: Interviewing for AI PM Roles