Product Data Interview: Audris Wong

This is part of our Product Data Interviews series, where we ask product managers across the industry the same set of questions about how they use data, what slows them down, and what helps them make better product decisions.

Audris Wong is an independent consultant at Snowpack Data, where she helps clients evaluate production ML models, understand what is working, and simplify deployment without sacrificing signal. Before Snowpack Data, she worked at The Browser Company, where her product work focused heavily on onboarding: when to roll out new features, when to pull them back, and how to run hypothesis tests on new experiences designed to help more users get value from the product.

Connect with Audris on LinkedIn.

1. What kind of product decisions are you personally responsible for in your day to day work?

At The Browser Company, a big part of my role was around the onboarding experience. Deciding when to roll out new features, when to pull them back, and running hypothesis tests on new experiences we were designing to improve how many users actually got value from the product and stuck around.

Now in the consulting work I do, I help clients evaluate their production ML models - specifically figuring out how effective those models actually are, which parts were worth keeping, and how to simplify deployment without sacrificing signal.

2. When you're evaluating whether something is working (or worth building), what signals matter most to you?

For figuring out if something is working, it really comes down to how it's performing against the metric we set out to move. For deciding if something's worth building, I try to be really intentional upfront. What is this feature actually designed to do? What does success look like? Once we have a clear answer to that, you can use it as a lens to evaluate how big the opportunity actually is and what the realistic upside is.

3. Walk me through a recent product decision you made that involved data. What did the process actually look like?

I start with answering the question "what do we actually expect to learn from this?". From there, I define what success and failure look like in concrete terms: if our hypothesis is right, what should we see in the data? If it's wrong, what would that look like? Then we make sure we're logging and tracking both the core metric we care about and any guardrail metrics that would tell us if something's going sideways.

During data collection, I check in regularly and I'm really careful about not drawing conclusions too early. Once we have enough confidence in the data, we build out a decision matrix and make a recommendation that factors in the opportunity cost of each path. Then it goes to stakeholders - engineering, product, leadership - for a final review.

4. How confident do you generally feel in the data available to you when making product decisions? What tends to increase or reduce that confidence?

Honestly, I have pretty limited trust in existing data to measure exactly what I need since that's just the reality of most setups. What increases my confidence is being really explicit upfront: defining exactly what we need to measure, setting up new tracking specifically for that purpose, and not relying on something that was built for a different reason.

I also try to explicitly outline where measurement might be off and what that would mean for the decision. Usually the risk of misalignment is smaller than it feels, but naming it out loud helps everyone calibrate.

5. What's the most frustrating or time-consuming part of getting the insights you need to make a decision?

Gaps in what's actually being tracked, and not being able to trust how things are defined. Without trust in logging, everything downstream in the decision process gets harder and slower.

6. How self-serve is data access for product managers at your company today?

Fairly self-serviceable. We use Claude via MCP and Amplitude, so I can get to most of what I need without having to go through an analyst for every question.

7. What's the hardest thing about turning data into action rather than just more dashboards or reports?

Getting enough context to move from "what happened" to "why did it happen" and "what do we do about it." The data tells you something changed; figuring out the meaning behind it and what that means for your next move is where the real work is.

8. Are there product metrics or definitions that people at the company regularly interpret differently?

Conversion metrics are a classic one. There's a lot of room for creativity in how you define the numerator, the denominator, the time window. Two people can look at "conversion" and be talking about completely different things. That ambiguity causes a lot of friction.

9. What's a surprising or overlooked source of product insight that you think more teams should pay attention to?

The opportunity cost of not making a decision. Teams spend so much time trying to get more certainty before acting, but if you frame the cost of inaction clearly, it really helps cut through analysis paralysis. Sometimes waiting is the most expensive option on the table.

10. What advice would you give another PM at a startup trying to make better product decisions with data?

Invest time in the basics. Get clear, shared definitions for the concepts that matter across your business, things like what counts as an active user, what activation means, what engagement looks like. It's not glamorous work, but the return on it is enormous.

When these things aren't nailed down, they can become blockers when you need to move fast and make a decision. Getting ahead of that early saves a lot of pain later.