Episode #23: Making Product Decisions with Limited Data with Austin Yang

Early-stage teams rarely have perfect data, unlimited research time, or enough traffic for every experiment to reach a clean result. In Episode 23, Austin Yang explains how customer conversations, product judgment, and disciplined testing can work together when certainty is limited.

What you'll learn

• How a sales background can lead naturally into product management

• Why Austin does not treat competitor visibility as the main risk of a public roadmap

• How to collect context through support and onboarding conversations

• When a team must make a decision without statistical significance

Start with the customer's problem, not the feature

Austin began his career in sales at a B2B technology company. Speaking directly with customers exposed him to their pain points and desired outcomes, and he became more interested in how solutions were chosen. At first, he assumed engineers generated the solutions and designers made them presentable. He later learned that product managers help determine priorities, direction, and which problems a team should solve.

His first company did not use the standard product manager title. A program management team performed work closer to product management by identifying customer needs, collaborating with designers and engineers, validating solutions, and considering outcomes for users and the business. A conversation with the company's chief product officer gave Austin a name for the discipline. He then contacted product people through LinkedIn and met some of them in Seattle to learn more.

The path matters because it shaped his product lens. Sales taught him to hear what customers were trying to accomplish instead of reducing a conversation to a requested feature. That same distinction appears throughout his approach to research and prioritization.

Use community access as a research advantage

At the time of the interview, Austin had recently joined Softr, a no-code app builder that lets people create applications using Airtable as a database. He was already familiar with no-code, product-led growth, and bottom-up software adoption from previous work, which made the transition smoother.

Softr's engaged community gives the product team direct access to people using the product. Austin can contact a power user in the community and receive detailed feedback. The host also asks about Softr's public roadmap. Austin does not view competitor visibility as the main risk. A roadmap item alone does not reveal whether it is current, how heavily it is funded, or whether the underlying judgment is right. Execution and learning still matter.

Austin's answer separates visibility from execution. Competitors can see an item without knowing its status, the team's investment, or whether the underlying judgment is correct. For him, publishing a roadmap does not remove the need to execute and learn.

Collect context in the flow of real work

Austin describes two recurring sources of customer context: live support chat and onboarding calls. When someone contacts support about a feature, the team can ask what they are building, what their use case is, and what a successful outcome would look like. Those questions move the conversation beyond the surface request.

Onboarding calls add direct observation. Customers can share their screens and show how they are building inside the product. This can reveal a mismatch between the customer's approach and the product's existing capabilities. In some cases, the requested feature already exists, but the customer has not found or understood it. That changes the product question from whether to build something new to whether discovery, guidance, or terminology needs improvement.

Austin also warns that employees at a no-code company are not average no-code users. Even without engineering backgrounds, they become power users and gain more technical understanding than many customers. Continued customer contact helps the team resist designing only for its own level of familiarity.

Decide how much confidence is enough

The team uses controlled experiments and compares control and variant groups when possible. However, a B2B company serving many smaller businesses may not always have the sample size needed for statistical significance. Waiting for perfect evidence can become its own poor decision, especially when the company is moving quickly.

Austin frames the challenge as deciding how much confidence is necessary for each choice. The team will not speak with every customer or fully map every use case before acting. Instead, it combines available data, customer conversations, the team's growth experience, and judgment. The practical task is to decide when that evidence is sufficient to move forward, then keep learning from what happens next.

His non-engineering background supports this approach. He focuses technical conversations on how implementation choices affect users, the business, and future product expansion while leaving engineering ownership with engineers. That creates informed collaboration without dictating the solution.

Listen to Episode 23 for Austin's full discussion of customer context, experimentation, technical collaboration, and the practical judgment required when early-stage evidence remains incomplete.