Episode #7: Customer-Led Product Management with Steve Choquette, Part 2

IBM did not suddenly discover artificial intelligence when Watson appeared on television. In Part 2 of our conversation, Steve Choquette connects decades of AI work with a practical lesson for product teams: technology matters, but customer context should guide what gets built.

What you'll learn

• Why Steve sees IBM's work in AI as a long-running research story rather than a recent pivot

• How access to customer data can shape the way companies develop and improve AI products

• Why relationships with customers and partners give product managers stronger evidence for prioritization

• How an outside-in perspective helps teams focus on business problems instead of exciting features

• Why communicating technical work in plain language can be a valuable product skill

AI strategy starts with history and data

Steve begins by challenging the idea that IBM jumped into AI recently. He traces the term artificial intelligence to a 1956 Dartmouth workshop that included IBM participants, then points to a progression of research projects. Chess-playing systems such as Deep Blue, Watson's appearance on Jeopardy!, and Project Debater each explored a different kind of machine capability. In his view, these projects reflect a research organization repeatedly testing difficult questions over many years.

The competitive environment changed as Amazon, Microsoft, Google, and smaller domain-focused companies expanded their AI work. Steve was especially impressed by how quickly Microsoft moved after a slower start in cloud. For product teams, his comparison highlights an important strategic issue: companies do not all have the same inputs.

IBM, he explains, had fewer consumer products feeding everyday interactions back into its systems. Search activity, voice assistants, and personal computing can produce large volumes of behavioral data for other companies. IBM therefore had to find different ways to train speech, search, and document-processing capabilities. Steve sees a benefit in not using people's data without permission, while also recognizing the product challenge created by having less data available. Steve says IBM's research work and experienced people helped offset those data constraints.

Customer relationships improve product decisions

When asked what product managers often lack, Steve first names relationships with customers and partners. At conferences, employees naturally gravitate toward colleagues from their own company. That may feel comfortable, but it wastes an opportunity to hear from people who use, buy, or support products in different contexts. His advice is simple: during breaks, sessions, or time on an expo floor, start conversations outside your familiar circle.

Steve recalls a technical leader who could strengthen feature discussions by naming real customers and explaining what they needed. Instead of bringing only an internal opinion to a prioritization debate, that leader brought direct evidence from the market. The lesson is not that every customer request belongs on the roadmap. It is that sustained relationships help product managers understand the problems behind requests and make better-supported tradeoffs.

For our teams, customer contact should not be treated as an occasional research event. It can become a regular source of context that improves planning, challenges assumptions, and makes roadmap conversations more concrete.

Work from the problem back to the feature

Steve's second concern is the tendency to become excited about a feature before defining the customer problem. An idea may sound commercially promising inside the company, but product managers still need to ask what customers are trying to accomplish, what they do today, and whether changing their behavior would create enough value.

He frames many business problems in terms of revenue or expense. A proposed product must make a meaningful contribution to one of those outcomes, and the customer may need to explain that value to the executives who control the budget. This outside-in approach changes the starting point. Instead of asking how to sell a feature, the team asks whether the feature addresses a costly, persistent, and recognizable problem.

Steve also connects outside-in thinking to his own career. In an early customer-support management role, he learned not to take an angry customer's reaction personally. The customer was frustrated with the situation, so his job was to step back, understand it, and help resolve it. He now tests his own clarity by asking whether he could explain a technical problem to family members without technical backgrounds.

Listen to Part 2

This conversation gives product managers a grounded way to connect strategy, customer evidence, and communication. Build relationships before a roadmap debate, define the business problem before celebrating a feature, and make complex work understandable to the people it affects. Listen to Episode 7 on Spotify for Steve's full discussion with host Dwayne Samuels.