AMA: BILL Director Product Management, Advaita Nigudkar on Product Development Process

Engineering plays a huge role in initiative planning, not in deciding what we build, but in shaping how we build it and what’s feasible. I involve them early in problem definition, sizing, and technical discovery. Some of the most elegant solutions I’ve seen have come from engineers who were part of the conversation before a solution was locked in. As a PM, I own the why and what — the priorities, the customer needs, the business goals. But I see the how as a space for collaboration. I’ll come i ...Read More

I work closely with engineering managers, designers, and engineers as a core triad, each of us brings a different lens: PMs focus on the why and what, design on the user experience, and engineering on the how and scalability. The best outcomes happen when we’re aligned from problem definition through delivery. With Engineering Managers, it’s about joint ownership of team planning, sequencing, and balancing tech vs. product priorities. With design, I stay closely looped in from early research thr ...Read More

This is a classic product tension, building fast and building the right things. The way I balance shipping on time with market insight is by separating strategic prioritization from tactical execution — and creating space for both. Use dual-track planning: At BILL, we run 2-week sprints, but roadmap decisions aren’t made in 2-week increments. I work in parallel tracks: one focused on near-term delivery, the other on discovery and market validation. That way, the sprint team can move with clarity ...Read More

Setting clear expectations between development and leadership is one of the most important parts of my role as a PM. I see myself as the bridge — translating strategy into execution and execution back into strategy. A few things I consistently do: Upfront alignment on scope and goals: Before we start building, I make sure there’s shared clarity on what problem we’re solving, what success looks like, and what we’re not doing. This helps avoid surprises later. Shared timelines with context: I don’ ...Read More

I believe it's important to bring the development team in early — not just on the what, but on the why and how we’ll measure success. Success metrics shouldn’t be an afterthought. If we’re asking engineers to invest time and energy into building something, we need to be aligned upfront on how we’ll know if it’s working. That means having conversations early in the product discovery or planning phase about: What outcomes we’re trying to drive (business or customer impact) How we’ll measure them ( ...Read More

I involve engineering and design right from the start, not just at execution. When we’re defining the problem space, I like to bring the team in to align on: Who are the customers? What are their pain points? How are we solving those? What data do we have (qual, quant, comp) to validate that this is a real problem? This helps build context early and creates shared ownership from the start. I also pull in engineering for early brainstorming. Some of the most creative and efficient solutions I’ve ...Read More

I genuinely believe that great product management is largely domain-agnostic. If you’ve built strong PM fundamentals — customer discovery, problem definition, roadmap prioritization, data-driven decision-making, and cross-functional execution — you can flex those muscles across industries. The core craft doesn’t change, even if the context does. That said, some roles do have a steeper learning curve — especially deeply technical or domain-specific areas like identity, core infrastructure, risk/f ...Read More