In this episode, we’re joined by Kunal Thadani, a product leader at Houzz, where he’s working on one of the harder consumer problems out there: helping people who have no idea where to start make high-stakes, expensive decisions about their homes.
Before Houzz, Kunal was Head of Product at The League, the dating app acquired by Match Group. He also writes Insider Growth, a newsletter that explores growth case studies from companies like OpenAI, Asana, and Uber.
In this episode, Kunal shares:
Why “remove every step of friction’ is a rule that only works for low-stakes, stateless products — and the three-bucket framework he uses to decide where friction actually belongs
The two ways friction goes wrong, including the one almost every company is guilty of and doesn’t notice
Why the personal AI setups product leaders keep posting about are fragile, inconsistent, and non-transferable — and what his team built instead
How a shared context layer in a single repo turns “five to 10 user interviews” into research at a scale PMs have never had access to before
1. Not all friction is bad: Why "remove every step" only works for low-stakes products
Product-led growth often says to strip out every step between the user and their “aha!” moment. Kunal’s experience working on fintech products taught him that this advice assumes a kind of product most teams aren’t actually building:
“What fintech has really taught us is all friction is not bad. Classic product and PLG thinking says, ‘Hey, remove every step.’ And that works well when the product is very low stakes and it’s stateless.”
Home decisions, loan applications, identity, money movement, fraud, underwriting — none of these are stateless. They have consequences in the real world, and often the user has to wait on something happening outside your product entirely.
His framework has three buckets:
Required steps can act as trust signals.
Delays can be turned into progress arcs.
Constraints can be commitment moments.
Product takeaway: Before you delete a step, ask what job that step is doing. Friction that signals trust, fills a wait, or marks a commitment is doing work that a smoother flow won’t do for free. The question isn’t “how few steps can this be?” — it’s “which steps earn their place?”
2. How splitting one ask into two decisions 10x'd our conversion rate
We told Kunal about how LaunchPod itself got validated. We put a modal on the LogRocket blog asking if people wanted a podcast and requesting an email. Conversion was atrocious.
We nearly killed the idea. Then someone suggested splitting it: ask for a yes/no first, then ask the yes’s for an email. Email conversion went up more than 10x — by adding a step.
Kunal’s read on why:
“What changed wasn’t the UI. It was more about the psychology. When you asked for the email up front, the user had to make two decisions at once: Do I even want this? And do I want to hand over my contact information to this company?”
Separating the two removed the cognitive load from the first decision — and once someone has said yes out loud, the ask lands differently.
But he was careful to bound the lesson. At The League, the team ran a live speed dating product where interest was easy to collect and attendance was not.
“If it’s a feature where you’re actually getting people to pay, I’m pretty bullish on: you still separate the decisions out, but how do you collect some sort of down payment?”
Their fix was a $4–5 ticket to join the waitlist. Low enough not to gate anyone out, but high enough that people actually showed up.
Product takeaway: Splitting a big ask into a small one and a bigger one reliably lifts top-of-funnel numbers. Just don’t confuse the lift with real demand. If the downstream behavior you care about is showing up or paying, put a small, real cost in the flow — otherwise you’re optimizing a metric that stops predicting anything.
3. The two failure modes: Friction that serves you, and friction that doesn’t
Kunal isn’t arguing that friction is always underrated. He has a sharp view of where it goes wrong, and it’s two specific failure modes:
The first is friction that’s dressed up as care but exists to serve the company. Cancellation flows are a popular case: hit cancel, get an offer, decline, get a discount, decline, get a downgrade option.
“It’s being framed as more like just making sure — versus, hey, helping you understand what you’re actually giving up.”
His version of an honest cancellation flow is one that tells you exactly which features, workflows, and automations stop working, and on what date. Same number of screens. Completely different intent.
The second mode is subtler, and almost everyone is guilty of it: friction that was legitimate once and never got dialed back after trust was earned.
“If I’m already a loyal verified user and you keep making me reprove myself, re-verify, re-KYC every time, it ends up being less protective and starts to feel more like, ‘Hey, you don’t trust me.’”
Product takeaway: Audit your friction on two axes: who does it serve, and is it still calibrated? Protective steps should decay as trust accumulates. If a verified two-year customer hits the same gate as a stranger, that’s not security — it’s a system that never learned anything about them.
4. Why personal AI setups don't survive an org and what a shared context layer fixes
Product leaders nowadays are asking, what are you actually doing with AI? A common answer is “I built my own personal OS.”
Kunal’s problem with that answer is that it doesn’t survive contact with an org.
“Everyone is building personal AI setups, but even at these dinners with product leaders leading the internal AI charge, very few are focused on what that operating system looks like at scale. When you start to build individual OSs, they’re pretty fragile, they’re inconsistent, they don’t have a centralized context layer — and a lot of the value just walks out the door when the person who built it leaves.”
So his team built a shared one. Claude Code, one GitHub repo, and non-engineers living in the terminal.
Product takeaway: The thing that makes an AI setup an asset instead of a personal habit is that the context lives somewhere other than one person’s laptop. And when you hit retrieval costs, reach for better routing before you reach for summarization — compressing your source material is how you quietly lose the details you built the system to find.
5. Research at scale, no handoff tax, and a feedback loop that compounds
The gains Kunal describes aren’t marginal speedups on existing work. They’re access to work that wasn’t previously possible.
The biggest one is research and validation. By piping Gong data into a database his agent can query, the team can sift every closed-lost conversation to find where deals died — and rank product gaps by how many sales each one cost. Same on the retention side, mining customer success calls for what churned users were vocal about.
“What we used to get was five to 10 user interviews. But now you’re getting it at scale and much quicker.”
The second change is to the shape of the PM role. Kunal frames the old model in terms of a tax:
“Every time you have to work with another cross-functional team, you’re paying that handoff tax of re-explaining that feature.”
When product marketing, sales ops, and data science all draw on the same context, that re-explanation mostly evaporates.
The third is a compounding effect that only exists in the shared version. When the AI drafts something and your judgment differs — a Slack message with the wrong point of view, say — you correct it in the system, not just in the message you send.
Product takeaway: A team OS isn’t a personal OS with more seats — it’s a different asset with a different payoff curve. The individual version improves at the speed of one person’s corrections. The shared version gets a feedback loop, and that loop is what turns a clever setup into institutional capability.
Chapters
0:00 Introduction
3:23 Why "remove every step" falls apart when the stakes are real
5:51 Three kinds of friction that actually help
6:39 Same verification steps, completely different framing
12:29 The two ways friction turns toxic
13:28 What a cancellation flow should tell you instead
14:39 When re-verification punishes your most loyal users
17:52 Everyone's building a personal AI OS, nobody's building one for the team
23:57 Using Claude Code to mine sales calls and cut the handoff tax
28:27 Why feedback loops get faster with every person you add
29:49 Conclusion
Links
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.