Context
As one of Income Discovery's key clients, Company A requested the development of a new API — driven specifically by the needs of their top advisor. The project had a 3-month development timeline and a clear tension: Company A wanted something custom, but the right solution was to champion the generic API with minimal extensions.
The key to launching this project is to deeply understand the top advisor's use case, why the current API experience isn't fulfilling their needs, and what workarounds they are currently using to fill those gaps. A complete understanding of the generic API and its functionality is equally essential — it's the only way to compare the differences and determine how to close the gap.
Assumptions
- The top advisor at Company A may not represent typical use cases
- I can discuss Company A's requirements with other Income Discovery employees and stakeholders
- The project is focused on API development — Company A handles integration and front-end UX changes
- API integration points remain the same as the current API
- Customizations will not negatively impact other Income Discovery clients
- API customizations for Company A will not be available to other customers
- The new API will be backward-compatible
- Company A is a medium-to-large company with a full complement of roles, including Legal and Compliance
Questions for Company A's Product Team
Empathy, curiosity, and strategic thinking are the tools for guiding Company A toward the generic API. I've grouped questions into two tiers — Priority 1 questions are critical; Priority 2 questions deepen discovery but can be answered through other channels or follow-up.
- Scope: Are UI or UX changes part of this project? Does the 3-month timeline cover the full end-to-end integration and testing, or just the API build?
- The advisor's problem: What specific challenges is the top advisor facing? What are their business objectives? How are these different from other advisors?
- Success metrics: What does success look like for the advisor? For Company A, if different?
- Urgency: Is there a hard deadline, business event, or trigger driving the delivery window?
- Current workarounds: Are there existing solutions or workarounds? Do they work? What's the cost of continuing to use them?
- MVP: Is there a minimum viable product that could be delivered sooner? What are the top priorities?
- Scope of users: Is this API solely for the top advisor, or will it extend to others? If more advisors will use it, what are their common needs?
- Tech changes: Are there changes in Company A's stack or infrastructure the new API needs to account for?
- Known future enhancements: Are there future features already known but not part of the core requirements?
- Constraints: Are there technology constraints or preferences that differ from the current API?
- Volume: What is the expected API volume? How many users, how often?
- If there is work in progress on the existing API, should it continue — and how are the two prioritized?
- What are the advisor's performance, reliability, and scalability expectations?
- What are the load expectations and performance metrics?
- What are the data security and compliance requirements?
- Are there existing tools they want to integrate that the current API can't support?
- Are there new internal or external data sources that need to be accessed?
- What does the transition from old to new API look like?
Stakeholders at Company A
A complete picture of Company A's requirements extends beyond the product team. I'd engage both primary and secondary stakeholders — primary are essential, secondary are important but not blockers.
Primary
Advisors (B2B Users)
Meet with the top advisor to understand current usage and pain points. Also meet other advisors using the current API — having a benchmark point of comparison is how you separate the top advisor's specific preferences from real product gaps.
Engineering Team
Capacity, velocity, expertise, and bottlenecks. Discuss technical feasibility, trade-offs, API versioning, documentation, REST vs. GraphQL structure, rate limiting, and support requirements.
Security and Compliance
Ensure the API adheres to security standards and regulatory requirements. Understand how testing and production validation will be performed.
Customer Support
Gain insight into common support requests — often the clearest signal of where the current API is falling short.
Secondary
End Users (Retirees)
In a B2B2C model the true "customer" is often the end user, not the advisor. Will the new API, as articulated by the advisor, actually meet their needs?
UX / Product Design
Input on the advisor's user journey and design expectations to ensure a seamless downstream experience.
Data Science / Analytics
Data requirements, analytics, and reporting needs.
Business Analysts
Additional context on the advisor's workflow, pain points, and business requirements.
Sales and Account Executives
How the API is being sold, what competitors are offering, and how the product is perceived in the market.
Internal Preparation
I'd approach internal preparation in phases, each building toward a complete picture of what's feasible, what's risky, and what the right MVP actually is.
Discovery
- Review past requirements docs, release notes, and current backlog for Company A and generic API users
- Assess analytics for patterns — are other clients hitting the same walls?
- Understand how success is measured and whether this release uses the same metrics
Technical Evaluation
- Assess feasibility of meeting requirements within the 3-month timeline
- Review past API tickets for performance, usage, and customization requests
- Confirm versioning approach and documentation release timing
- Discuss documentation automation with technical writers
Prioritization and OKRs
- Identify MVP enhancements to generic API based on customer feedback and research
- Define post-MVP features ranked by user impact vs. engineering effort
- Develop talking points that align the MVP direction with Company A's stated goals
- Define KPIs: user satisfaction, adoption rate, performance improvements
Stakeholder Alignment
- Engage senior leadership on project goals and priorities
- Check with Sales and Support whether Company A's requests mirror other client requests
Risk Assessment
- Identify technical, resource, and timeline risks with mitigation strategies
- Address API governance and downstream impact of customizations
- Determine rollout approach: pilot, scaled, opt-in
Resource Allocation
- Assess engineering availability and cross-team dependencies
- Evaluate downstream impact of any generic API customizations on other clients
Go-to-Market and Support
- Define communication plan for updates, progress, and feedback loops
- Prepare Customer Success for post-launch support and iteration cadence
Conclusion
Influencing Company A toward the generic API requires a deep understanding of the advisor's current experience and where it's actually falling short. In practice, clients don't usually need the custom thing they asked for — they need their actual problem solved.
The generic path, framed correctly, is the better outcome for both sides: faster to ship, easier to maintain, and lower risk for Company A. Getting there requires doing enough discovery to close the gap between what they asked for and what already exists — and making that path feel like their idea.