David Meyer on Product Management, Customer Curiosity and Building Teams

David Meyer trained in civil and nuclear engineering before joining Plumtree Software. He moved from quality assurance into engineering, then into product when a colleague he had frequently criticised recommended him for the job. He had initially thought engineering was too important to leave, but discovered how much he enjoyed product.

In quality assurance, Meyer began investigating defects in another engineer’s code. After the engineer blocked his access to source control, Meyer took the issue to the CEO, who dismissed the engineer and asked Meyer to write the code. Looking back, Meyer admits that criticising a job he had never done was easier than doing it.

Meyer regards not knowing what is supposedly impossible as an advantage when it encourages curiosity. Harry Stebbings gives his own example: he might have quit earlier had he known how long building an audience would take. Both see a willingness to pursue a problem without fully appreciating the obstacles as potentially useful.

Meyer says an unhappy customer can be more useful to meet than a satisfied one: a concrete problem creates an opportunity to understand and reframe the work. He starts by asking enough questions to understand the person’s job, the steps they take and the outcome they actually want, rather than treating every requested step as essential.

Customer interviews are hard because questions can lead the witness. Meyer asks colleagues to observe and give him feedback and says the goal is truth-seeking, not confirmation. Even an apparently open question may steer the answer, so he tries to explore alternatives instead of simply presenting a demonstration and talking at the customer.

He distinguishes one customer from the collective customer. A product team should understand what an individual needs to accomplish, then test whether that need is common. Copying a single customer’s prescribed feature can overfit the product and neglect the wider market.

Product managers must balance customers, sales, engineering and finance, whose priorities conflict. Meyer jokes that a successful PM can leave everyone dissatisfied: sales may see too much long-term work, while engineering may see too much deal chasing. The role is less a miniature CEO than a person finding workable compromises and moving toward a vision without running out of resources.

For people considering a product role, Meyer looks for evidence that they already cannot stop doing the work, even without the title. An engineer who challenges requirements or a sales engineer who persistently pushes for customers’ needs may be practising product management. He asks candidates where they made an impact and probes how it related to product value.

Databricks changed a stated value from being data-driven to being truth-seeking, Meyer says, because data can be selected to support almost any argument. Metrics should reveal blind spots and prompt questions, not become goals in themselves. If evidence disproves the original assumptions, the right response can be to revise the target.

A one-person startup can adjust hypotheses continually; a large organisation must account for the people and systems organised around a target. Even so, Meyer argues an existential error should not be allowed to persist merely because goals are annual. He prizes speed of learning rather than shipping speed alone, including experiments that may be discarded.

Meyer admits to compulsively checking dashboards whose green records do not lead him to act. He sees a larger waste when people manually compile numbers nobody uses. A useful metric should lead to a decision and reflect the vision; he acknowledges that every metric can be gamed.

Usage, such as daily or weekly active users, can be harder to game because a person is giving a product their scarce time. Meyer cautions that usage does not by itself prove a viable revenue model. Stebbings compares subscriber totals with more meaningful signals such as how much of an episode listeners finish or whether they recommend it.

Meyer describes product management as often thankless: the PM is a roadie rather than the rock star. He values curiosity, persistence and demonstrable impact, and warns against assuming that work at a rapidly growing company caused its growth. A feature can appear successful simply because it was placed in front of an already expanding audience.

Asked whether PMs are worse on average than in the past, Meyer says he cannot know but suspects rapid team growth makes consistent quality harder. He says Databricks had roughly 6,000 employees, around 1,000 engineers and more than 100 product people at the time. He finds keeping up with the product and sustaining innovation harder as an organisation grows.

Meyer sees optimism as central to building things that initially seem impossible. He cites medical deliveries by Zipline drones and the early experience of calling an Uber. Founders must persuade colleagues to join the effort; optimism can unlock action, although later he acknowledges the danger of believing too much in one’s own vision.

To persuade an engineer, Meyer walks through the implications of a choice instead of issuing an instruction. For example, a custom API may be elegant but require convincing thousands of developers and building an ecosystem; following that logic may lead the engineer to choose an existing standard. He calls this helping people discover the reasoning in their own terms.

When a team changes direction, leaders must recognise the emotional attachment people have to what they built. Meyer says to name the loss and give people space to mourn, rather than expecting them to infer why their work is being abandoned. He believes emotion can also help product leaders inspire customers about what is possible.

Meyer says he wanted to study fine art as well as engineering, but was told the dual degree he expected was unavailable and chose engineering. He now finds creativity in product work and in solving problems for people. He believes the work needs to inspire the person doing it.

He considers observation after launch essential: a team that spends months building something should watch how people use it. Publishing a product or putting it on a website is not sufficient marketing, he adds; the team must reach people who have the problem. He admits that, without having run marketing, he can be too quick to tell marketers how to do their jobs.

Meyer tries to begin with empathy: someone may be doing the best they can while dealing with pressures invisible to their colleagues. Rather than assuming a colleague is lazy or wrong, he asks what constraints or context explain their choice. He often learns that resources and competing demands are behind the behaviour.

Asked to divide product work into art and science, he says it could be 90% art if rigorous systems thinking and data observation are already assumed. If those habits are not automatic, they require much more deliberate effort. He warns that elaborate models can create a false impression of certainty: detail is not proof that the assumptions are right.

Meyer says his need to understand a system can make him a maddening, sometimes micromanaging manager. He hopes a human connection makes his intent clearer. Stebbings argues that leaders should adapt feedback to the person receiving it rather than apply a single formula; Meyer agrees that people need to feel seen.

Feedback should also invite a response, Meyer says. A leader can remain firm about the required change while asking why a person seems distressed or disengaged. Without understanding the reaction, the manager risks losing the person even if the original feedback was correct.

Meyer tells his direct reports that if they want to leave, he will help them find a strong next role. First he wants to know whether they are running away from a problem he can fix or toward a compelling opportunity. He recognises that people further away in the hierarchy may not trust or know him well enough to take that offer at face value.

He asks colleagues whether he has acted like a “seagull” manager: swooping into a meeting, criticising the work and leaving. People who know him may understand his intentions, but a new product manager may experience the same intervention very differently. He also acknowledges that his optimism can fail when others have not bought into the vision.

The captions leave a gap in the transition to product focus. In the visible discussion, Meyer and Stebbings caution against expanding a target audience too early. A product that tries to serve everyone can lose the dedicated users who recommend it and push the team to break through difficult problems.

Serving passionate users while remaining approachable to newcomers is difficult. Meyer advises using the product regularly and understanding the user’s actual workflow. Features requested by one person can add friction for another, so data on engagement or time to complete a task can reveal whether complexity is causing harm.

Meyer resists the assumption that fewer options always mean a simpler product. At Databricks, he initially noticed visual inconsistencies, but says developers cared more about execution speed and code completion. The test is whether users can do their important work, not whether the interface satisfies a new product manager’s aesthetic preferences.

He recalls frustration when a familiar Atlassian editing experience changed and some of his scripted capabilities became harder to access. He nevertheless believes the change broadened the market. Such a decision should be made with eyes open about whom it may lose; for Databricks, he says, developers remain central to the vision.

Product reviews, in Meyer’s view, happen continuously as teams use and test the product, with frequent demonstrations for the core group and periodic management reviews. Founders can provide important context early, but many founders debating small visual details can waste time. He wants decision meetings small enough for honest, high-bandwidth discussion.

Stebbings suggests four to six people for effective decisions; Meyer agrees that a large meeting can become a ceremony. Even remote listeners change the room, because shorthand or a blunt remark can be misunderstood and repeated without context. The exact number is their judgment, not a universal rule.

Decision notes matter because information must reach people who were not in the room. Meyer says he is personally poor at documenting and sending notes, so he benefits from working with someone strong in program management. When a smart team member makes a poor decision, he first asks whether he failed to provide the needed context.

In hiring, Meyer asks about a candidate’s impact and follows the explanation until he understands the underlying system. For enterprise software, he wants product managers to know how the product works and how dependencies affect decisions. He also asks about difficult situations, responsibility and whether others were harmed along the way.

The first conversation should both identify a poor fit quickly and leave a promising candidate interested in another discussion. Meyer believes genuine curiosity helps a person feel seen. To test collaboration, he likes a low-stakes exercise based on a problem the candidate knows, changing a constraint and exploring how they respond.

Stebbings notes that the candidate may know far more about their domain than the interviewer, making weak answers look impressive. Meyer accepts that risk, but argues that persistent questions can expose internal inconsistency. He listens for how the person reasons, not just whether they claim credit for a successful outcome.

One hiring mistake is assuming someone who excelled at one company will necessarily fit another. Cultures and needs differ. Meyer recommends a small cross-functional hiring group, including respected technical and product people and someone willing to challenge the decision, so the leader’s enthusiasm does not colour every assessment.

As product organisations scale, leaders can lose touch with how individual contributors spend their days. Small reporting requests accumulate until people are maintaining process rather than understanding customers. Meyer suggests regular customer support exposure and roughly dividing time among customers, product and engineering work, and thinking; he calls this an aspiration rather than a description of actual schedules.

He identifies sales and engineering as a common source of friction: sales seeks near-term deals, while engineering protects long-term coherence. At Databricks, he says, each side believed the other had too much influence. Product can mediate by examining whether a customer’s requested feature is the only way to solve the underlying problem.

A third option might meet the customer’s real need without derailing the roadmap, but Meyer admits it does not always exist. His own optimism can produce elaborate alternatives that sound possible inside his head but are difficult to coordinate at scale. The lesson is to test the alternative with the people who must execute it.

Meyer distinguishes persuasive vision from a harmful reality distortion. A leader can unite people around a difficult goal and help them do something previously thought impossible. But if conviction replaces truth-seeking, people may spend years chasing an impossible goal while the leader overlooks the compromises and damage involved.

On the relationship between a product leader and a founder CEO, Meyer says the CEO ultimately owns the vision. Both can have incomplete context, so they need candid communication and shared objectives. At Databricks he seeks Ali Ghodsi’s agreement on priorities, sends updates, and generally proceeds when there is no objection.

Meyer wants to improve his awareness of how his words and body language affect others. A mood caused by something unrelated can be interpreted as disappointment in the work being discussed. He advocates being direct and vulnerable about what is happening so people can interpret the interaction with the right context.

The higher a leader rises, the more asymmetrical small encounters can become. A brief, tired exchange may mean much more to the person meeting the leader than to the leader. Meyer describes the strain of a conference day filled with keynotes, customer meetings and a large dinner, after which he needs quiet.

For a PM seeking promotion, Meyer recommends knowing the product and understanding customer needs in aggregate. He says founders should be clear about a product leader’s level of agency: a founder CEO may want to remain deeply involved. At Databricks, he learned that Ghodsi wanted founders involved in the details rather than waiting for a finished solution.

A new product leader should resist immediately imposing comprehensive frameworks or changing everything in the first 90 days. Early wins can help, but Meyer prefers substantive human wins to vanity achievements. He recalls asking a former boss to teach him product management and receiving the answer that it could not simply be taught.

Asked what he would tell himself before becoming a parent, Meyer says to hold on to the wonder rather than rush children toward milestones. Parenting changes as children grow, he says, and balancing work and family changed his own sense of what counted as selfish. He acknowledges that his instinct to compromise is not always a substitute for setting boundaries.

Stebbings admires the template strategies of Notion and Canva. Meyer is especially interested in unusual business-model innovation and cites Opower as an example he associates with energy efficiency incentives. He believes difficult problems such as energy transition and social and economic equity require creative business models, a view rather than a tested solution offered in the interview.