Episode #66: Harish Potabathula on Building MVPs for Maximum Learning

An MVP should be small, but it still has to solve something that matters. In episode 66, Harish Potabathula shares a product management approach built around problem discovery, rapid learning, and team alignment.

What you'll learn

• Why customer requests should lead to deeper problem investigation

• How to define an MVP around an end-to-end customer journey

• When early product speed should give way to scalable architecture

• How product management expands from execution into business strategy

• Why writing can sharpen both individual thinking and team direction

Start with the problem behind the request

Potabathula began his career in management consulting at IBM. He enjoyed solving problems but found that many assignments became repetitive. Product management offered a more dynamic environment, with changing customer questions and the ongoing challenge of aligning internal teams around a shared goal. His interest in puzzles made that uncertainty appealing rather than discouraging.

In B2B software, customers often arrive with a proposed solution rather than a clean statement of the underlying problem. They have already interpreted their situation and formed an idea of what a product team should build. Potabathula’s response is to spend more time in the problem space. By investigating the need beneath the request, a team opens more possible solutions and reduces the chance of committing too early to the customer’s first suggestion.

The work is not limited to customer discovery. Product managers also need to bring engineering, design, sales, marketing, and other contributors toward a common objective. Misalignment among those groups can become one of the hardest parts of launching a product. A clear problem and goal give the team a stronger basis for prioritization.

Define an MVP for maximum learning

Potabathula frames an MVP as the minimum product that produces the maximum learning. That definition shifts attention away from merely reducing scope. The goal is to build enough to test whether the product delivers meaningful value, then use feedback to guide the next iteration.

Learning starts before engineering. Potabathula spends time discovering the problem and validating possible solutions before the first line of code. Early concepts can be revised more quickly and cheaply than a developed feature. Once implementation begins, the feedback loop should continue rather than waiting for a large launch to reveal whether the original assumptions were right.

The MVP still needs to address the customer’s main journey from end to end. Delivering only half of a workflow may not allow the customer to complete the job or the team to evaluate value. The first version can leave out rare corner cases and layers of complexity, but it should provide a basic, meaningful resolution to the central problem.

This gives teams a useful test for scope decisions: does the release support the essential journey, and will using it teach the team something important? If not, a smaller backlog does not automatically make it a better MVP.

Scale after patterns become visible

Early products often need room to move quickly and pivot. Potabathula argues that it can be reasonable not to optimize architecture for the next several years when the team still does not know which direction customers will value. Building a complete platform too early can invest heavily in assumptions that have not been validated.

The signal to change comes when customer patterns emerge. He describes seeing a consistent problem and value pattern across roughly four or five customers as an indication that the team knows what to optimize. The question then shifts from proving the problem to making the product work for many more customers.

At that point, teams may need a substantial platform or version upgrade. Architecture must support new features without disrupting existing customers, and repeatable delivery becomes more important. Potabathula treats that rework as a normal stage after evidence of product-market fit, not necessarily as a failure to predict everything at the start.

Product management grows beyond execution

Earlier in his product career, Potabathula focused heavily on execution: coordinating with developers and designers, meeting deadlines, and protecting quality. With experience, his scope expanded to include strategy. A feature now has to be considered in relation to the target customer, positioning, value proposition, go-to-market plan, and the needs of sales and marketing.

That broader view improves execution because technical choices are no longer isolated from how the company will present and sell the product. Product leadership becomes the work of connecting customer value, delivery, and the business system around the product.

He also expects AI to change how people interact with software. Today, users learn a different interface for every tool. Potabathula’s prediction is that software will increasingly understand ordinary human language, reducing the burden on people to learn each product’s particular interaction model.

Potabathula once resisted writing and tried to keep ideas in his head. Over time, he found that putting thoughts on paper creates structure, reveals gaps, frees mental space, and makes direction easier to communicate. He now encourages team members to write even when a document is only for their own thinking.

That habit fits the episode’s larger theme: learning improves when assumptions become visible and testable. Listen to episode 66 for the full conversation on MVPs, scaling, strategy, and AI-driven product interaction.