Testing Assumptions and Building Product Team Trust with David Mark Siegel | Episode #73

David Mark Siegel's approach to product management began with social psychology research at Stanford. His work required forming a hypothesis, testing it, accepting when it was wrong, and using the result to design a better study. He later applied the same discipline while managing educational video game projects at LeapFrog, where research with children and parents showed how inexperienced technology users interacted with a product.

Those experiences taught him to separate personal opinion from evidence. Instead of asking which idea he likes, he asks which customer problem matters, what behavior would validate a proposed solution, and what qualitative detail explains the result. That mindset has helped him work across educational technology, financial technology, and commercial aviation data without claiming expertise on arrival.

What you'll learn

• How to test the riskiest assumption instead of defending a preferred idea

• Why messaging should fit a priority customer segment rather than everyone

• How a PM can learn a new domain by building trust from the team outward

• What empowered engineering ownership requires from product leadership

• Why proactive product work begins before anyone requests a strategic plan

Test the problem, message, and assumption

Siegel uses experimentation to replace his expectations with evidence. In psychology research and product studies, the useful question was not what he expected to work. It was what worked for the intended group and what the details revealed about why. Metrics can show a result, but interviews, questionnaire responses, and observed behavior can provide the nuance needed when a team is still locating a product's core value.

His messaging research sharpened this lesson. Two people can take different meanings from the same message because its effect depends on the recipient's orientation. A product message does not need to appeal to every audience. It needs to communicate the intended value to the segment whose problem the team has chosen to solve. Success requires clarity about the target, the problem, and the evidence that would demonstrate the intended response.

For PMs, this creates a practical sequence: define the priority user, identify the riskiest belief about that user's problem or response, and choose a test that can disconfirm the belief. Then examine both the primary measure and what participants did and said. The goal is to improve the next decision, not prove the original idea correct.

Build domain knowledge through relationships

Siegel moved among industries by carrying transferable product skills while deliberately learning the missing domain knowledge. When entering an organization, he starts with the immediate team. He asks developers and designers how work has been going, what frustrates them, what they would change, and how they prefer to collaborate. This provides operational context while beginning to earn trust.

He then works with domain experts and colleagues in customer support and sales. These partners can explain terminology, recurring customer needs, and the history behind current decisions. Siegel also sees the PM as a filter for unstructured requests from experts or executives. Organizing that input helps engineers stay focused without separating them from valuable knowledge.

The next step is direct customer contact. In specialized fields such as financial services or commercial aviation, customers may be reluctant to educate someone unfamiliar with their work. Siegel builds enough credibility to ask specific questions about a recent feature, observe how it fits the customer's workflow, and understand why one airport or business operates differently from another. He describes a target progression for his first 30 days: earn trust within the team, learn from internal experts, begin direct customer conversations, and start shaping a strategic plan.

Pair customer evidence with team ownership

For Siegel, a strong PM combines customer understanding, data, strategy, technical awareness, design judgment, and collaboration. The purpose is to solve important customer problems while helping the business succeed. That requires communicating evidence clearly enough that developers and leaders understand why a decision was made.

Empowerment depends on a real division of responsibility. The PM explains the problem and what the product should achieve, while engineers own how to build the solution. This works when the PM and engineering lead trust each other's decisions, align on strategic goals, and support each other. The team also needs to believe the product vision. Skepticism may signal a weak case, resistance created by prior experiences, or concerns that have not been heard. A PM has to investigate those conditions rather than simply repeat the vision.

Siegel also argues that product managers should not wait for permission to think strategically. They can study the customer journey, look for gaps and underserved segments, apply frameworks, and identify where a focused change could create leverage. Proactivity means developing an evidence-based perspective on what could improve for customers and the business.

Listen to the full conversation: Episode #73 audio.

Siegel's method gives PMs a practical approach: test beliefs against user behavior, learn unfamiliar contexts through trusted relationships, and give teams enough evidence and autonomy to solve the selected problem.