3 interviews with Product Visionaries you need to see
Interviews from the co-founder of Matic Robots, Plaid, and Elon Musk that you need to know about.
Recently, I stumbled across 3 incredible interviews that all Product Builders need to know about.
Here’s the interviews and major takeaways:
1) Mehul Nariyawala, co-founder of Matic Robots
First of all, if you haven’t seen these home robots, they look amazing! This interview is jam-packed with insights for all types of product builders on keeping your product simple and connected to your customer’s problems.
Key Takeaway #1: Spend more time in the problem space.
Before building a robot vacuum, Mahul and his team built a problem deck, exploring questions like:
- Why is cleaning still mental overhead?
- Why do robots damage rugs?
- Why are kids scared of them?
Their conclusion? People don’t want robots. They wanted clean floors with zero thinking. Only after fully mapping the pain did they touch the solution.
Key Takeaway #2: Be transparent about your product’s deficiencies.
After 6 years of building the MVP, they were under huge pressure to ship. Instead of overpromising, they emailed customers and said:
“This is what our robot does.
This is what it doesn’t do yet.
Who still wants it?”
Some customers waited to buy, but others said: ship it. Those became their best users and best feedback loops.
Lesson: When you’re not ready, don’t fake it. Tell the truth. The right customers will stay and help you improve the product.
Key Takeaway #3: Protect your product's simplicity.
Mehul shares that it must be immediately obvious what the product does. When you open Facebook and Instagram, it's not obvious what they are for anymore.
WhatsApp, on the other hand, is still obvious. It's for texting your friends. He gives other examples like In-N-Out Burger hasn’t changed in 80 years, Netflix deletes features aggressively, and Telegram ships with ~30 people.
Lesson: Simplicity requires discipline.
2) William Hockey, co-founder of Plaid & CEO of Column
This interview was inspiring because William talks about getting out of the Silicon Valley bubble, taking more risk, and diving deep into domains to create truly differentiated products.
Key Takeaway #1: Stop building in a consensus bubble.
William Hockey says the biggest threat to your product isn’t the competition.
It’s your zip code.
If you live in Silicon Valley (or any tech hub), you are living in an “Elite Consensus Machine”.
Elites building for other elites.
Solving problems that only 0.1% of the world has.
The fix? William spends time in places like Kinshasa in the Democratic Republic of the Congo, where he can observe how a country with under-penetration in financial services operates.
Lesson: If you want to build a global product, get out of your bubble.
Talk to the users who don't look, think, or spend like you.
Key Takeaway #2: Leverage obscure knowledge in your domain for product insights.
Everyone is reading the same "X" threads. Everyone is using the same LLM to summarize the same articles.
If everyone has the same inputs, everyone has the same outputs.
Hockey found a 2,000-page obscure book about an ancient Japanese bank.
He didn’t skim it. He didn’t ask for a summary. He read it cover-to-cover.
Buried in those pages was a single, forgotten idea that became a core feature of Column’s product.
Lesson: Deep domain expertise isn't found in a 5-minute search. It’s found in the rabbit holes that everyone else is too lazy to go down.
3) Elon Musk’s Starbase Site Tour
This 5-minute snippet from the Elon Musk Starbase site tour is important for all Product Builders to hear.
Key Takeaways: Make your requirements less dumb & delete requirements
Question requirements, especially if they’re from a smart person. Requirements should always have a name, not a department.
And that person needs to still be at the company.
Otherwise, you may spend time optimizing for something that shouldn’t exist.
It’s very common for builders to build something “just in case”, but Elon argues if you’re not occasionally adding things back in, you’re not simplifying the process enough.
The Tesla team was struggling with a fibreglass mat that was choking the entire Model 3 production line.
Then he asked: “What are these mats actually for?” and the truth came out.
The Safety team thought they were for noise.
The Noise team thought they were for safety.
After a simple sound test proved the mats did absolutely nothing, they deleted the requirement entirely and solved the optimization problem.
Lesson: You should not optimize something that shouldn't exist in the first place.
That’s why you need to delete things first, then optimize.
Final Thoughts
Let me know in the comments which one of these interviews resonated, and any other interview recommendations you’d like to share!