AMA: Former BILL Director, Product Management - Payments, Ruchi Aggarwal on Product Development Process

For betas, I start with clarity on the MVP and the segment it best serves. I choose customers with the strongest need- they feel the pain, are hungry to try an early solution, and willingly give feedback knowing it’s not fully polished. I also screen for operational or compliance risk. Once selected, I run tight loops through regular check-ins, metrics, and qualitative input so we can iterate quickly and validate the solution.

I triage scope changes based on impact: does the new info affect MVP success, expose a missed requirement, or can it wait post-launch? If it’s critical, I evaluate timeline impact and what we can de-scope or shrink to absorb it. If not, it goes to backlog. Once decided, I communicate early and clearly on what changed, why, and the trade-offs. This keeps iteration fast without losing control

Yes, Product Ops is critical, especially in FinTech where money movement is involved. I like to involve them end-to-end: pre-launch for requirements and operational risks, during development to validate scope changes, and before release through demos and readiness checks. Post-launch, they validate production behavior, surface issues, and help prioritize fixes. It’s a tight partnership that ensures smooth launches and a strong customer experience.

I use a simple filter: if the problem is deterministic, rules-based, and predictable, traditional software is better. AI shines when there’s lots of data, high variability, and many “it depends” scenarios where different users need different answers. I also check if we can reliably measure correctness i.e. AI must be evaluable. If the task benefits from pattern-matching, reasoning, or personalization at scale, it’s a strong candidate for AI.

For big launches, I run weekly “office hours” with support, Product Ops, engineering, and any ops partners (in FinTech, often legal/compliance). We review early metrics together, separate signal from noise, and pair that with qualitative feedback from the field. Actions may go to engineering, product, or ops (SOP updates). We keep this running for weeks or months until GA, and the insights feed directly into the roadmap and how we run the next cycle

I look at build/buy/partner based on where we are, what outcome we need, and speed to market. Usually one option is easy to eliminate upfront. Then I compare the remaining two on customer experience, cost, risk, and how much we’ve validated. If we know the space well and want full control, we build. If we need speed or expertise, we buy. If we’re entering a new area with high uncertainty, we partner until we learn enough to decide our long-term path.

The biggest misconception is believing AI will do everything for you- define the MVP, decide what to build, and evaluate itself. It won’t. You still need clear requirements, scope, and a definition of “good.” AI is powerful, but only when paired with strong product thinking. You have to guide it, structure the problem, and feed it the right context. Otherwise, it produces noise, not outcomes.