Leader Spotlight: Balancing creativity with scalable execution, with Adrienne Wang

---

Adrienne Wang is Head of Card Payments at BILL, an innovator in AP/AR automation and B2B payments. She began her career in financial services at Citadel, where she rose to Vice President of Derivative Operations. Adrienne later held product leadership roles at Northern Trust and Bank of America before moving into fintech, with roles at Viewpost, BILL, and Billtrust. Adrienne now leads the card payments business at BILL, where she’s focused on delivering innovative card-based solutions for SMBs.

In our conversation, Adrienne talks about how she’s learned to think creatively about products while also prioritizing scalable solutions. She discusses the major cultural differences between fintech and traditional finance companies, including speed, iteration, and the acceptance of failure. Adrienne also shares her process for determining whether a product is ready for commercialization.

---

Scaling fast and solving problems

You’ve had an exciting career journey that began in finance and operations. How did the pivot to product management come about? And, what skills did you find most helpful to make that jump?

Looking back, I’ve always been drawn to building, solving problems, and figuring out how things work. In high school, I took a design class where we had to build physical prototypes, but what really stood out to me was that we also had to think through how to bring them to market. That early experience taught me to approach challenges not just from a technical lens but from a broader systems and impact perspective.

That way of thinking stuck with me throughout my career. When I joined Citadel, many of the back-office processes were still manual. It worked when the fund was smaller, but as it scaled and the products became more complex, those systems started breaking down. They were inefficient and introduced operational risk.

To fix it, I worked with engineers to design and automate those workflows with scalability in mind. That experience made something click for me. I realized how much I enjoy building solutions that not only solve real problems but actually drive impact across the organization. That process of identifying bottlenecks, working cross-functionally, and delivering something that makes a difference was really energizing.

The skills that helped me transition into product management came from doing exactly that kind of work. My time in ops and finance gave me a strong foundation in breaking down complex systems and identifying root causes. Collaborating with engineering taught me how to think about scale and sustainability. Over time, I got better at translating business needs into technical requirements. I didn’t set out to become a PM, but looking back, I was already doing the job long before I had the title.

Although you went into that role with a lot of those foundational skills, did you find there were knowledge gaps? If so, how did you identify them and then upskill in those areas?

When I stepped into a more formal product leadership role, I knew I needed to up-skill in product design. Early in my career, the financial systems and operational workflows were targeted for internal stakeholders. The focus was on efficiency and accuracy rather than aesthetics, so my designs were practical, powerful, and robust, but not very elegant.

As I moved into product roles with external customers as the end user, I saw firsthand that usability and experience are just as critical as functionality. Powerful tools lose value if users can’t navigate them.

To bridge this, I immersed myself in UX best practices — learning from my partners in design and research to understand how to approach design, think about how to break down design challenges, and distill customer insights and feedback into functional and effective user flows.

There are probably many aspects of banking culture that are very structured compared to tech and fintech. Was that a big shift for you as you changed industries?

Absolutely. In financial services and especially in my role as an ops leader, the focus was on precision, whereas in fintech, the focus is on reimagining and simplifying complex workflows. I find that in my fintech roles, I take a more design-focused approach and leverage agile methodologies. This helps me take a more iterative approach to solving customer problems.

Fintech, and tech in general, also moves faster. There is a strong bias for action and acceptance of a test and learn approach. Teams move fast, test ideas, and adjust based on feedback and results. Structure matters, but there’s an understanding that not every detail will be perfect up front, and there’s a willingness to learn along the way. Also, failure in tech is viewed as a learning opportunity. In financial services, on the other hand, you want to avoid failure at all costs because it could result in losses or regulatory issues.

‘Constraints don’t squash innovation’

How does the way you lead or work with cross-functional teams differ in those environments?

Throughout my career, regardless of industry, the constant has always been a structured first-principles approach to problem-solving. No matter the role, I’ve always focused on breaking down what we are trying to solve for. When you understand those fundamentals, solutions arise naturally from them. If you don’t have a deep understanding of what the problem is, you won’t be effective in the solution you deliver.

Another key mindset that’s stuck with me centers around execution. Big ideas are great, but they only create an impact when they’re translated into action. I believe that innovation isn’t just about vision — it’s about making things work in the real world. That all ties back to understanding the details and underlying mechanics, and ensuring that there’s alignment across teams so that the execution is seamless.

Finally, collaboration has been a constant in my career. Whether it was working with the traders and broker dealers, or engineers, researchers, and designers, I’ve found that the best solutions come from strong collaboration and partnership. Being able to talk about the problem space and tackling it from all angles makes for a much more successful outcome.

That’s especially critical in product, because products don’t exist in isolation. At BILL, for example, we offer multiple payment solutions, and they all need to work together in a way that feels seamless to the customer. If they’re disconnected or inconsistent, we create friction and confusion. Collaboration is what ensures we build with clarity — not just in the backend, but in the actual customer experience.

You’ve spent a fair amount of your career in an industry that’s fairly regulated. From the standpoint of innovation, how did you work around that?

Constraints don’t squash innovation, they just force you to be creative in how you approach it. In highly regulated environments, compliance is often viewed as a blocker, but I think the most successful teams treat it as a design constraint. You work within it rather than around it.

The key for me has been talking early and often with the regulatory, legal, information security, and risk teams. They become your partners in thinking about the constraints and determining how to creatively approach them. In doing so, you understand where the potential blockers are and can flex on certain things to deliver something really innovative. I’ve been very lucky in my career to work with some great partners in that space who instead of just saying no, help me think around the compliance and different regulations.

The process of commercializing products

You mentioned that your early experience with prototypes is something you’ve carried with you. When you’re working on a new product, how do you know when it’s ready for commercialization?

It’s really a balancing act between business viability, the customer’s response, and operational readiness. First, I look at business signals. Are we hitting our key business objectives? Do we have early adoption in a pilot phase? Are there positive unit economics or a clear path to profitability? If we’re not seeing that traction or the cost structure doesn’t make sense, it’s often a sign that we need to refine our offering.

Second, customer response is critical. If we see strong engagement, retention, and repeat usage, we try to get feedback to determine if customers find value in the product and are willing to pay for it. There’s a lot of qualitative feedback there, too. If we have users who are excited and advocating for the product, we know we’re onto something.

The third is operational and functional readiness. This is where my background in operations differentiates me — I think about the ecosystem around the product as well. Do we have the right infrastructure in place to support scale? This includes technical scalability, compliance consideration, customer support readiness, and other internal teams like finance. If we have those pieces in place, then we’re ready to build bigger, but if not, we risk burdening our teams and, therefore, impacting the quality of our product.

Lastly, I look at the growth levers. Do we understand what’s driving adoption, for example, and how we can accelerate it if we test different channels, pricing models, or positioning strategies? Do we have a clear playbook for growth? With commercialization, it’s not enough to say we want to do it — we also need to have a logical path for execution.

What is your approach to de-risking the product launch, especially given your background in risk management and financial operations?

I usually think about product launch risk in three main areas: business risk, operational risk, and customer adoption risk.

On the business side, the key question is: Will this actually drive the impact we’re expecting? Early pilots or limited rollouts are a great way to test the assumptions behind the product. We look at usage patterns, feedback, and unit economics — are things trending the way we hoped? If not, it’s a chance to course-correct early.

Operationally, it’s about making sure we’re set up to scale and assessing if we have the infrastructure and processes to support scale. It’s important to stress test that. Go end to end and test for everything, not just the happy path. Make sure your teams and systems can handle things if they go wrong. The same goes for dependencies. If we have a critical integration with a partner, do we have all the contingencies in place?

And then there’s customer adoption, which is critical. We’re looking for early signs of sustainable engagement — things like retention, repeat usage, and even some organic adoption. That gives us a sense of whether the product is really resonating.

Overall, my goal is to manage the blast radius with phased rollouts, check in at key milestones, and try to catch risks early before scaling. It’s not about eliminating risk entirely — that’s not realistic. Rather, I want to manage it in a way that gives the product the best chance to succeed.

When you’re working to commercialize a product, does the process differ based on business size?

Definitely — enterprise and SMB operate in very different ways. I would categorize enterprise as more high touch, more customized, and long-term. These customers often have entrenched workflows and complex needs, and the sales cycle is much longer. There’s also a higher expectation for customization and integration. It’s a consultative process, you need to build deep relationships, understand their business inside and out, and show how your product fits into their broader workflows.

There’s usually significant work involved in mapping your product to their existing systems, which often means deeper integrations and tailored implementations. The upside is that once you’re in, the relationships are very sticky. But it takes real investment in sales, onboarding, and support to get there. Then, on an ongoing basis, you have to demonstrate value.

SMBs, on the other hand, are looking for solutions that are easy to adopt, self-service, and deliver immediate value. The focus is on simplicity, automation, and building for breadth rather than depth. SMBs are generally more open to adapting their processes to fit the product, which makes implementation faster and more scalable.

That said, SMBs also tend to churn more. Their needs can shift quickly, their businesses may not be as stable, and they’re often more price-sensitive. That makes it even more important to show value early and often and to build products that are intuitive, lightweight, and clearly solve a core problem.

Feedback loops with SMBs are tighter, it’s easier to collect feedback, and you can iterate quickly based on what you’re hearing. With enterprise, feedback is harder to generalize and often highly specific to the individual organization, which can make iteration more challenging.

That contrast is part of what makes product work so rewarding to me. I love the challenge of building for both — going deep and bespoke when needed, but also designing simple, scalable experiences that can support a wide range of users and use cases.