Ravi Mehta
Why Tinder’s CPO starts with JSON, not design, covering team leadership, startup building, and product design.
Episode
The secret to better AI prototypes: Why Tinder’s CPO starts with JSON, not design | Ravi Mehta (product advisor, previously EIR at Reforge)
Summary
Ravi Mehta, former CPO of Tinder and EIR at Reforge, discusses his framework for product leadership and building AI prototypes — specifically why he starts with JSON data structures before design, to test logic before visual polish. He covers a five-layer strategy stack, a leadership matrix distinguishing scalable leadership from selective micromanagement, and a PM competency model built around 12 skills.
Key Takeaways
When building AI prototypes, start with JSON output rather than design to validate the logic and data model first — the visual layer is easy to add later.
Use "selective micromanagement" strategically: temporarily step in to course-correct when direction is unclear, then pull back.
Think of product strategy as a five-layer stack (mission → company strategy → product strategy → roadmap → goals) and use it bidirectionally.
Map PM skill gaps across three buckets — customer understanding, product execution, and go-to-market — rather than treating "being a better PM" as one undifferentiated thing.
The shift to AI products requires PMs to think less about feature specification and more about data architecture and model behavior.
Notable Quotes
“And more often than not, when I talked to teams and helped to debug that issue, what it came down to was that there wasn't a deep enough understanding of what the strategy is. So what is the framework that should actually inform that prioritization? And so oftentimes I was seeing difficulty prioritizing as well as tactical issues surface in the day-to-day and be able to be tracked back to pretty fundamental gaps in terms of an individual PM's understanding of strategy. And oftentimes those gaps were not just because the person might not understand the strategy, it may also be because the strategy hasn't been completely defined.”
“And so the analogy I like to use, it's a little bit like working with an architect. You would never work with an architect that didn't provide you a blueprint of the house that they want to build for you because being able to describe a house in words alone is not enough. Everyone will come away from that with sort of a different interpretation of what is needed. But once you can see the blueprint, and the blueprint doesn't need to be high fidelity, it's a conceptual framework that shows you how things are laid out, it helps you understand how the pieces are going to come together. And most products are ultimately rendered in terms of visuals. They're pixels on a screen. And so it's important for you to understand how are those pixels going to be organized.”
“And so I think about all of the pieces of the strategy stack as being really clear about what is the end destination that you're solving for, and then you should work on goals to the extent that they help you reach that destination. And if you find that achieving your goal is actually pulling away from the destination, then there's a really important conversation to be had about do we leave that gain on the table because it's not aligned with our destination, or do we need to change our destination? And I think what happens too often when people start with goals and then create the roadmap is that the goal takes precedence and there's no context, there's no principles that are ultimately driving that. And so those decisions about the direction of the product come and go without even really being noticed because there's nothing to calibrate against.”