Episode #57: Running Product Experiments with Liz Pouya

Liz Pouya expected to work in medicine. She studied physiology and neurobiology, prepared for the MCAT, and helped start a medical device company with other students. That startup experience revealed an interest in entrepreneurship and opened a path beyond medical school. She entered technology through sales, first as a business development representative and then as an account executive.

Liz joined Chili Piper as an account executive, moved into customer success when the company's needs changed, and eventually saw an unowned opportunity around a premium product initiative. Drawing on her scientific habit of forming hypotheses and testing them, she wrote a job description, approached Chili Piper's co-founder and CEO, and proposed taking responsibility for the work. Her path through sales and customer success gave her direct knowledge of prospect goals, buying decisions, administrative frustrations, technical capabilities, and product gaps.

What you'll learn

• How scientific thinking can improve product hypotheses and evidence standards

• What micro experiments are and where small changes can produce meaningful gains

• How prototype tests reveal what users notice, ignore, or misunderstand

• Why iterative releases reduce the cost of a wrong product decision

• How consistent internal communication protects a product manager's time

Test behavior instead of relying on opinions

Liz's scientific education taught her to question whether one or two positive comments provide enough evidence for a decision. Sample size matters, as does understanding who participated in the research. Her earlier commercial roles added context that a product manager might otherwise need years to acquire. In sales, she heard what prospects wanted and why they bought. In customer success, she learned the product's technical limits and saw where administrators struggled with configuration.

At the time of the interview, Chili Piper was rebuilding its backend. Much of the effort involved reproducing existing functionality, which limited the team's capacity for playful growth experiments. The team still looked for quick improvements that would not disrupt the larger timeline. For high-level questions, it used moderated and unmoderated testing with a trusted group of administrators. UX researcher Taylor helped create multiple Figma prototypes, and the team watched what participants focused on, what they ignored, and which expected benefits failed to attract attention. Repeated rounds showed whether the team could clarify the concept or had missed the mark entirely.

The company also used A/B tests for onboarding flows, in-product language, and different paths through the application. These tests examined whether specific nudges changed behavior. Liz defines micro experimentation as making a very small change within an application or feature and measuring whether it creates a disproportionately useful result. The change may not generate a major go-to-market announcement or immediate revenue. It can still remove friction that affects daily use.

Navigation provides a clear example. If users take too long to reach a destination, the team can test a shorter route, expose something that was hidden, or adjust how choices are presented. Support and customer success feedback often reveals the starting point: users cannot find a setting, do not understand how it works, or expect one result and receive another. A micro experiment lets the team test a more accurate alignment between the interface and those expectations. Fewer support tickets and less pressure on customer success managers can serve as meaningful outcomes.

Ship smaller changes and communicate predictably

Liz warns product managers against becoming attached to one solution. Competitive research, customer conversations, and internal feedback can create confidence, but that confidence does not guarantee the finished product will match user expectations. Smaller MVPs and iterative releases produce evidence sooner. Customers receive improvements without waking up to a completely unfamiliar application, and the team can reverse or revise a weak decision before it consumes extensive resources.

Experimentation does not remove the coordination burden of product management. Liz speaks with marketing, customer success, leadership, design, engineering, and other stakeholders. Each group needs different information to do its job. She therefore treats communication itself as a system to design. If marketing receives an update in the same place and format each week, people know where to look and ask fewer repetitive questions. The same principle applies to customer success and leadership. Consistency creates time for deeper product work.

The most rewarding moments come when engineers, designers, customer success managers, and account managers share the same understanding of the problem, contribute in a common language, and leave with clear next steps. Keeping the persona and purpose visible prevents the team from building only because a technical task is available.

Liz also resists requests for a personal UI opinion. Whether she likes a color or layout is less important than whether it helps the user. Instead of turning preference into a product decision, she redirects the team toward questions about user context, expected behavior, and evidence.

Listen to the conversation

Hear Liz Pouya explain how Chili Piper tests prototypes, improves usability through small experiments, and aligns teams around customer problems.

Listen to the full episode.