Measurable Experiments for Better Mobile Buying Journeys | Episode #19 with Ashima Goyal

Ashima Goyal's path into product management joined technology with a desire to see its business impact over time. She studied computer science, began her career as a technology consultant, and completed an MBA before moving into product. Consulting exposed her to varied projects, but she wanted to remain close enough to a product to see whether a recommendation actually changed outcomes.

At Carvana, Ashima owns the pre-purchase portion of the direct-to-consumer mobile experience. That scope includes what a customer encounters when opening the app, exploring inventory, searching, viewing vehicle details, and deciding which car may fit. She works with web product counterparts, mobile engineering, design, analytics, and marketing to improve that journey.

What you'll learn

• Why Ashima treats measurability as a prerequisite for a consumer launch

• How business outcomes and granular behavior data reveal different parts of an experiment

• When qualitative research can prevent costly design, engineering, and analytics rework

• Why solving the customer pain point remains the high-level definition of product success

• How deliberate written communication can complement fast Slack or Teams discussions

Designing experiments around the full journey

Ashima's analytics background informs a straightforward philosophy: do not launch a customer-facing change if the team cannot measure it. Without instrumentation, a feature can sit in the product while the team remains unsure whether it helps, harms, or has no effect. Measurement therefore needs to be planned before release, not added as an afterthought.

A business metrics dashboard can show whether an experiment affects the outcomes the company tracks. Product analytics adds a more detailed view of behavior. Ashima asks whether a change creates friction for one group, removes it for another, or produces a problem the team did not anticipate. In a consumer app, the sequence of interactions can be observed at a fine level, making it possible to reconstruct a customer's path rather than stopping at a top-line conversion number.

That distinction matters because an overall result can conceal uneven effects. A change may improve one metric while making an important step harder for a particular segment. The PM's job is to define the intended improvement, instrument the relevant interactions, and examine the result deeply enough to understand the customer story behind the aggregate.

Research before expensive implementation

Quantitative data becomes especially valuable after an experiment reaches customers, but it is not the only way Ashima reduces uncertainty. When a team has identified a pain point and developed several possible solutions, she works closely with design to decide which ideas deserve further investment.

A problem can be addressed in many ways, and a team should not assume its first interpretation is the best one. For a consequential or unfamiliar feature, a user study can expose confusion and support iteration before engineers build the experience. That early feedback can save development time and avoid unnecessary product analytics work on a poorly informed concept.

Ashima is careful not to prescribe formal research for every small release. The amount of discovery should reflect the uncertainty and type of feature. When confidence is low, however, qualitative learning provides an efficient checkpoint. After the concept is refined and implemented, quantitative experimentation can determine how it performs across the larger customer base.

Her high-level definition of product success keeps both methods aligned: did the team actually solve the customer's pain point? Business metrics, product metrics, and technical health metrics provide distinct signals, but they should all support a clearer judgment about whether the flow helps customers make the decision they came to make.

Context switching and durable communication

Ashima describes PM work as satisfying and challenging for the same reason: the role touches many responsibilities. A typical day can include retrieving the result of an older experiment, preparing a leadership presentation, explaining a priority, clarifying requirements for engineering, and attending meetings. The PM must switch contexts quickly while still giving focused, concise answers.

She also changed how she communicates product work. Fast chat tools are useful, but a channel post can disappear in the stream and may not create enough space for detailed questions. Ashima now uses email more deliberately when she needs to lay out her thinking, explain a launch, or invite a broader written discussion. She pairs that durable format with Slack messages or direct communication because different colleagues consume information differently.

The principle mirrors her approach to customer segments: one channel will not serve every audience equally. Product communication works better when the format matches the depth of the topic and the habits of the people who need to respond.

Listen to the full episode for Ashima's complete discussion of mobile experimentation, mixed-method validation, product success, and communication.