Strategy question
A senior customer executive demands a highly customized feature that would accelerate one account, but Decagon's Product and Engineering teams want to invest only in reusable platform capabilities. How would you decide whether to build bespoke, generalize now, or push back? Walk through your decision criteria, tradeoffs, and how you would preserve the executive relationship either way.
- Decagon
- 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
Whether you can resolve a bespoke-versus-platform tension with a senior stakeholder while protecting both the roadmap and the relationship.
How to approach it
- Get specific on what the executive is actually asking for and why, since the underlying need (faster resolution for a specific workflow) may be solvable without the exact customization requested.
- Check with Product and Engineering whether the request maps to an existing roadmap item or a genuinely reusable capability, since that changes the calculus from bespoke-versus-nothing to bespoke-versus-slightly-later-but-reusable.
- Weigh account value and relationship risk against platform cost explicitly, using real numbers where available, rather than deciding on executive pressure alone.
- Propose a middle path first: a configuration-based or scoped solution that meets the immediate need while the reusable capability is built on the normal roadmap timeline.
- If a middle path is not feasible and the decision is genuinely build-bespoke or push back, make the call transparently with Product and Engineering's input, not unilaterally.
- Preserve the executive relationship regardless of outcome by explaining the reasoning in terms of long-term product reliability for their own account, not just internal roadmap discipline.
What a strong answer includes
- Looks for a scoped middle path before accepting the binary bespoke-or-pushback framing the executive and internal teams are stuck in.
- Weighs account value against platform cost with real numbers, not deference to seniority alone.
- Frames the pushback, if needed, around the executive's own long-term interest, not just internal engineering discipline.
- Involves Product and Engineering in the final call rather than deciding unilaterally under executive pressure.
Common mistakes
- Caving to executive pressure without evaluating the platform cost and generalizability.
- Refusing outright without exploring a scoped or configuration-based middle path.
- Framing a pushback in a way that damages the executive relationship instead of protecting it.
Likely follow-up questions
- How would you handle it if the executive escalates above you after a pushback?
- What would you do if the middle path still requires more engineering time than is available this quarter?
- How would you validate the request is not actually already solvable with existing capability?
More strategy questions
- A Fortune 500 prospect believes in Decagon’s vision but is skeptical that an AI agent can safely automate complex support journeys across chat, voice, email, and SMS. How would you structure the pre-sales process from discovery through pilot to secure the technical win, convince the C-suite the rollout is worth the risk, and choose the narrow initial deployment scope that maximizes proof of value while minimizing implementation risk?Decagon · Strategy · Hard
- You inherit a newly signed enterprise account where support workflows are fragmented, requirements are unclear, and the VP of Support, Operations, and IT all want different things first. What roadmap would you set for the first 90 days, how would you prioritize which workflow to launch first, and what milestones would you use to keep the account moving toward a production go-live?Decagon · Strategy · Hard
- On flagship deployments, customers will ask for bespoke capabilities that could either stay custom or become part of Decagon’s core platform. What framework would you use to decide which requests to productize versus keep account-specific, and how would you balance customer impact, implementation cost, roadmap coherence, and reusability across future enterprise accounts?Decagon · Strategy · Hard
- After several flagship enterprise deployments, you notice each customer asks for different custom logic, integrations, and operating processes. How would you distinguish among (a) one-off account work, (b) reusable deployment playbooks, and (c) core product investments, and how would you feed those decisions into Product and Engineering so future deployments get faster without overfitting to a single customer?Decagon · Strategy · Hard
- A top bank wants to deploy a Decagon agent, but its security review blocks launch over data retention, data residency, and deployment constraints. As PM, how would you drive the decision process to unblock this customer while avoiding one-off work and turning the solution into reusable platform capabilities for future regulated enterprises?Decagon · Strategy · Hard
- Decagon can support enterprise deployments through native integrations, customer-built API/SDK integrations, or partner-built extensions. How would you prioritize which systems and deployment patterns to productize first? Walk through the decision framework you’d use, including customer demand, implementation cost, reusability across accounts, security/compliance blockers, and impact on time-to-launch.Decagon · Strategy · Hard
More questions from Decagon
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