Building Customer-Centered Platforms | Episode #17 with Chakkaradeep Chandran

Chakkaradeep Chandran entered product management by noticing that software problems often begin before development. After starting as a developer, he moved into consulting because he wanted to understand what customers were actually asking teams to build. His interest in Microsoft's program management model eventually led to an 11-year career there, followed by a move to GoDaddy as a principal product manager.

That move also expanded his perspective from a large enterprise environment and B2B work into a more consumer-focused business. At GoDaddy, he owns an authorization platform in the core identity area. The role illustrates how a principal PM's scope differs from owning one feature: the work spans a horizontal platform, several product verticals, internal partners, and the customer experiences those partners create.

What you'll learn

• How principal product managers align teams around a platform rather than a single feature

• Why internal product teams are also customers of a shared platform

• What quantitative behavior data can reveal, and what it cannot tell a PM about the next product idea

• How mockups, research, and experiments turn possible solutions into tested hypotheses

• Why technical depth must be translated differently for executives and engineers

Seeing platform users and end customers together

For Chakkaradeep, customer centricity starts by asking whether the platform enables customers to do what they intend and whether the resulting experience lets them succeed. A platform PM cannot answer those questions by looking only at the platform's technical surface. The team must work with internal partners, review the journeys those partners support, and understand what their end customers expect at each step.

He pairs those conversations with research into market segments, trends, and the businesses customers are building through GoDaddy. This is important because platform value is often indirect. An internal team may use a shared capability to build a customer-facing service, while that service helps an external customer launch a domain, create a website, accept payments, or continue building a business.

The principal PM has to connect these layers. Strategy requires aligning teams on shared outcomes, gathering requirements from business partners, and tracing platform choices through to customer value. The job is no longer limited to improving one payment feature or one isolated interaction. It is about making a foundation useful to many teams without losing sight of the people ultimately using what those teams build.

Combining behavioral evidence with customer understanding

Chakkaradeep treats quantitative and qualitative evidence as complementary. Quantitative data shows where current users are, how they use a feature, where they complete an action, and where they leave. It can also support acquisition and growth analysis across a journey. For example, a customer who begins with a domain may later build a website and enable payments.

Behavioral data can expose friction, such as a process taking too many steps or too much time. It does not, by itself, identify the best new experience. A team could imagine hundreds of solutions, and engineering all of them would be wasteful. Chakkaradeep's process is to develop plausible ideas with the team, turn them into simple design mockups, select relevant research participants and market segments, and observe which concepts help people succeed.

Those findings create a stronger hypothesis. The team can then invest in an implementation and run an experiment with real customers. The result may show improvement, no meaningful change, or a worse outcome. Each result is useful because the investment was guided first by current behavior and then by qualitative learning. This sequence limits expensive guesswork while preserving room for genuinely new ideas.

Matching technical detail to the audience

Chakkaradeep identifies technical depth as both a weakness and a strength. Earlier in his career, he could go too far into implementation details when speaking with executives instead of stepping back to the level of outcomes and decisions. He has practiced choosing language and information based on what each audience needs.

The same technical fluency strengthens his relationship with engineers. He can discuss architecture, microservices, and API contracts while showing empathy for the people who must build the product. The lesson is not that every PM should dictate technical choices. It is that understanding engineering constraints can improve collaboration when the PM still communicates the scenario, customer need, and intended value clearly.

Listen to the full episode for Chakkaradeep's complete explanation of platform scope, mixed-method discovery, experimentation, and technical communication.