The LaunchPod with Kunal Thadani
===

[00:00:00] Hey, Kunal. What's up, man? Welcome to the show. Yeah, thanks for having me. Background on your end, super cool. You've done a lot of product, a lot of growth, interesting stuff with AI. I don't wanna steal the thunder, but before we dive in, could you just give us the quick TLDR, like how'd you get to where you are at Houzz?

And just like, yeah, how does Kunal become Kunal? So basically the short version is I got deep into interior decorating my place in New York and hit the same wall a lot of other people do, which is basically having no idea where to start.

And kinda what pulled me into Houzz specifically was the gap of how far interior decorating software had come, but how advanced users and consumers and the rise of this DIY interior decorating market had become. So it felt like there was huge gaps in terms of like what the software could solve, and I [00:01:00] feel like it's a massive market, decisions are high stake, and from a product perspective, it's a big, hairy, ambiguous problem to solve.

Before Houzz, was the head of product for The League, which is a dating product, and we had exited to The Match Group. Mm-hmm. And then I think what you kinda touched on in Parallel, I'm basically writing insider growth, and I kinda compare it to insider trading, but it's basically getting all the secrets and case studies about how like other companies have grown.

So you can talk about OpenAI, Asana, Uber, . Nice. I found it's always- Interesting thing, get outside yourself and outside the core role. And I know some companies sometimes have worries about it and stuff, but I, for years and years and years, had a kinda side thing, and I only found it enriched and kinda made me better at my core job.

Yeah, exactly. I think the key thing was, like, how do you expose yourself to learn outside of the four walls of your job and company? Yeah. And I think, you know, it's in-person events, dinners, but then this newsletter really encourages me [00:02:00] to go out and meet a lot of other product leaders in the space.

Speaking of coming from one place to another, like you said, you're at Houzz now, but you spent a lot of time in fintech as well. And I think one thing you brought up last time we talked that was really interesting, I kinda wanted to highlight while we are here, is the kinda concept of everyone is always obsessed with reducing friction, kind of getting things out of user's way, making passes easy as you can.

And I think you brought up point that that's not always the best way for it. Sometimes friction can be healthy or additive or accretive to what you're doing for the business. So I actually haven't directly spent a lot of time in fintech, but I've carried over a lot of the key learnings, right, from Venmo, a lot of Robinhood, et cetera.

And I think I have been kind of doing product-led growth for many years and core product. I think what fintech has really taught us is all friction is not bad, right? And I think a lot of, like, classic product and PLG thinking says, "Hey, remove every step." I mean, kind of the user, their aha moment. [00:03:00] And, you know, I think that works well when the product is very low stakes and it's stateless.

But in fintech, what you start to kinda realize is a lot of this home-related decisions, they have actions on, like, the real world. There's actually consequences of like, "Hey, I applied to a loan. I need to wait for something outside of this product to happen." There's like identity, money movement, fraud, underwriting.

So I think the product challenge that you end up actually experiencing is, like, less about removing friction, but it's more about how do you actually design around the right friction. And I can kinda go into the framework and three buckets on how I kinda think about this. I've always thought this was somewhat true or always kind of had some level of intuition almost that, that this must be true at some level.

I can't remember for the life of me the company now, but it was a story a product kind of designer talked about at one point where they built in at a certain stage a basis of like, oh, processing whatever it was, is building a report or kind of building some kinda customized offering for you. And they would purposefully introduce a [00:04:00] spinner on it and put it and kinda show it, like, spinning and kinda loading and whatever.

And they're like, "Yeah, we don't need to do that ever. It's done almost instantly." Yeah. But we found that when we did that, people thought, "Oh, I'm getting something really high value here." Like, they really have to crunch the numbers. Yeah. But yeah, so it's three buckets. Tell us more. Yeah. So I think that's a good example 'cause I feel like even in the dating space, every time we would take a lot of time to show you maybe these, like, your high-quality match for the day- Mm-hmm

people felt like, "Oh, wow, I need to take my time with, like, voting, look through their profile," and you could see the time they spent on these matches versus, say, the generic matches, was much higher. Basically, how I kinda think about the three buckets, right? So the first bucket is required steps can actually act as trust signals, and then the second one is delays can actually be turned into product works or getting them to use a different part of your product while they wait.

And then I think the last one is constraints can also be, like, commitment moments, right? So I think the best [00:05:00] example is, let's take, like, identity verification. If you frame it as, "We need this because of regulation," then it feels like company overhead, but if you actually frame it as, "Hey, we actually use this to verify you and protect you from identity theft," it lands very differently.

The steps didn't change. It's just more about the framing, right? You're saying you're actually doing it for them, and you're basically using it as a way to build a trust signal. Like, hey, all the data that you pull in, we handle it properly, and we make sure all the money movements that are happening will be protected on the platform.

So let's take, like, maybe the progress arcs. Mm-hmm. The progress arcs is like, I think Robinhood does a really good job here, where before they launch a product, they basically have a wait list, and it's like a, kind of a facade door approach to gauge demand for this feature. And the more and more you refer people to this wait list, your number gets bumped up for the specific feature.

You get access to it much [00:06:00] earlier. I would say that's, like, a clear kind of example for the second mechanic. And then I would say the last one, which is, like, a constraint as a commitment moment, I guess how I kinda think about this is, you know, think about, like, any card that you apply for. When you apply for it, the decision is actually instantaneous, but then you have to wait two, three, four business days for it to arrive.

So a lot of, I think, what a lot of these companies are doing is you can actually design your custom card, so it could have, like, you know, Kunal or, like, your family, uh, crest or something on the card. Mm-hmm. So it makes kind of the excitement level and, like, oh, wow, it's because I customized it. That is why it's taking longer to get that immediate kind of gratification.

I'm curious to kinda get your take on where this falls. A ways back for one of our podcasts, we were trying to decide early, early on if we were going to actually do a podcast, 'cause we had a really popular blog, and we weren't convinced that we had the demand or the audience where they really wanted that.

And so we were trying to figure out how do we pass/fail the idea? How do we kind of [00:07:00] fail the idea out really fast if we just don't have proof that it could work? And the first thought was, let's just put on our site a little pop over, and you know, like a little modal in the bottom left that popped up and just said, "Hey, we're gonna start a podcast on this general topic area.

Are you interested?" Like yes, no. And we actually first started with, "Hey, we're gonna start this. Give us your email if you're interested." Yeah. And no one filled it out. It was... The conversion rate was atrocious. Yeah. And we were gonna kill it and be like, "Oh, I guess we shouldn't do a podcast. It's a bad idea.

No one wants it." And I forget who it was. Someone had the idea of let's first just forget the email. Let's just ask even if they're interested. Maybe people just don't wanna give us an email for it, right? Maybe they just don't wanna sign up, but we can at least get some up-down voting on yes, no. So we just put an up-down vote, and literally, like, I think seconds before we deployed it, someone piped up and said, "Hey, if they say yes, just ask for the email anyway.

Like, we already got the yes. Can't hurt, but throw the email in, see if they'll give it to us, and, and if anyone says yes and gives us the email, that's, like, a bonus." We can way easier just send whatever we make to a few people, [00:08:00] you, whoever does it. Probably most people won't, we don't think, 'cause no one did.

And it didn't slightly increase our conversion rate. It legitimately, like, 10X'd our conversion rate of people who gave us emails. The yes, no, we had a way, way higher engagement with that, but even when you controlled for people who actually went from giving a yes, we'd go, "Oh, great. Since you're interested, give us your email.

We'll shoot you a note when it's done and send you the first one." And the conversion from yes to giving us the email was, like, 85% of people who hit yes gave us the email. But the conversion rate of just, like, showing the thing To getting an email more than ten X, I think, which is wild to us. And it was all by adding a step, actually.

Yeah, it's actually pretty interesting. I think it's a great example of like commitment preceding an ask. What changed, it felt like wasn't the UI, right? It was more about the psychology, right, of, "Hey, you asked email up front," then the user had to make two decisions at once, right? Do I even want this? And then do I want to hand over my contact information to this company, right?

And I think what you ended up doing was you actually [00:09:00] separated out the separated interest, right? So once someone came, they can just make a decision, am I interested in this podcast? Yes. Right? And then you remove all that cognitive load, and that can be pushed out. And then it's more like, "Hey, if you're actually interested and you're not lying to us, why don't you just give us your email?"

Yeah, I like that kind of psychology a lot. I think one thing to kind of keep in mind is I think it works for very top of the funnel, but then I think tying it to kind of my time at the league, which was we had launched this, you know, live speed dating product where we actually did something similar where, you know, opted in and then you would have to connect your calendar to block.

So it was basically like we combined both steps like, "Hey, connect your calendar," and then, "Are you basically interested in one step to join this like live speed dating session?" But what we ended up actually seeing downstream is even though when we separated it, we had a lot of people interested, how many people actually showed up and paid.

So like propensity to basically pay. So if it's a feature, I think a podcast is different. But if it's a [00:10:00] feature where you're actually getting people to pay, I'm pretty bullish on, you know, you still separate the decisions out, but how do you collect some sort of down payment? So in this case, what we ended up doing the next time was collecting like a one ticket purchase to join this wait list, which wasn't a high commitment.

It was like you're talking about four or five dollars, but it made that commitment, so they would actually show up that day and meet their prospective matches. Maybe you can talk through cases where you've seen friction crosses a line and actually is causing worse. I think we give a lot of examples where it makes it better or it kind of optimizes for an end goal.

You know, have you seen where it makes it where we're crossing the line, maybe? Yeah, it's a good point. I mean, I think friction can basically fail in two ways, right? So I think the first is it's dressed up as like, say, protection or thoughtfulness, but it's really just serving the company. So I think like Amazon Prime's cancellation flow is like a classic example that, you know, everyone refers to.

And then I'd say the second is when friction was like legitimate at one point, but never gets dialed [00:11:00] back after the trust is earned. For example, if I'm already a loyal verified user and you keep making me reprove myself or reverify or re-KYC myself every time, I feel like it ends up being less protective and it starts to more feel like, "Hey, you don't trust me."

So I'd say those are probably like two kind of areas where I see the two kind of failure modes. Can you give an example of the first one there? So let's take, like, any cancellation flow. Mm-hmm. I think before the lawsuit and all that stuff, if you went through cancellation of, like, Amazon Prime or any product where I feel like they may not have the best product market fit, you kind of hit cancel within the product, and then they'll try to give you an offer.

Then you say no to that offer. Then they say, "Okay, we'll lower your monthly billing." Then they ask you, "Hey, do you wanna switch to kind of a lower kind of billing cycle?" So it's kind of just, like, being framed as more like just making sure versus, like, hey, helping you understand what you're actually giving up.

Technically, like, a [00:12:00] cancellation flow should just be like, "Hey, when you cancel, these are all the features you're gonna lose. All these workflows and automated workflows that you've built are what you're gonna lose." And then, "Hey, starting..." Maybe you created a couple of, like, co-works. These are gonna stop running after, say, September 1st, right?

So it's more about helping the user really understand what they're giving up versus just giving them offers and say, "Are you sure you really wanna cancel?" Yeah. In the other case, the re- kind of auth thing, that is interesting 'cause that's friction post-customer in the case of, like, re-verifying over and over and over.

I'm a Bonvoy member, and this is a major pet peeve of mine. I travel a ton for work. As a member, I get bumped up to the next level of super fast internet at hotels, which is, it's like five bucks, right? But whatever, sure, I'll take it. And every time I go to log in, I have to log in. They want to send me a validation email to my email to, like, get a link to click into it to go, but I'm like, "I don't have internet yet.

I'm trying to validate so I can try to authorize so I can get into my email, [00:13:00] and I can't get my email because you won't let me in. But I just did this last week. Why do I have to, every day I do this, have to re 2FA and do all these things when it's me? It's the same browser and same computer I've used for a year and a half."

Yeah. And they have a button you can check to say, "Don't do this again for 60 days," and it never works. So that's terrible friction right there. Yeah. And it's, it's huge in fintech and generic overall kind of PLG because what ends up happening is all these new financial products require re-KYC-ing in a lot of the cases.

Mm-hmm. And I think a lot of the times companies don't spend the time to ... You need to, like, properly store KYC data, or you actually can't store it on behalf of the user. So what ends up happening is if a company has multiple financial products, every time you want to enroll or activate in a new product, it requires you to effectively reverify.

And a lot of the times it doesn't even tell you, why do you need me to reverify? What additional information do you need that I haven't already provided? So I think it's interesting. Yeah. It's an [00:14:00] interesting set of flows and, and I think everyone who might listen to this show at least is probably quite familiar with

I don't know if this happened, but in Claude now, whenever you switch almost anything, I feel like I have to reauth every 10 minutes. Yeah. Because their models are so powerful now that they have to make sure it's me. I do love the cycle in AI of like, "Oh, it's so dangerous, it broke out of an air gapped set up and somehow hacked into this other company.

It's, it's incredibly dangerous and powerful, and oh my God, it's going to take over the world." And you can have it in a week. All you have to do is reauth every kind of couple minutes and you'll be fine. Yeah. But I digress. They don't even allow you to turn off permissioning, right? But as long as it's me, I can use the dangerous stuff.

They just wanna make sure it's me using it and not- Oh, yeah. Yeah. Yeah. You know? All right. I could keep going. I mean, I don't wanna just start ranting about different frictions, but I think that's the, you know, idea is, is there's a lot of cases where it can be really additive and accretive and cases where increasing friction can be bad, and then similarly cases where maybe reduced friction, you know.

I worked at a company early on in the internet where- [00:15:00] We took a form and majorly reduced it, and then it got it down to one click, but we were a lead gen company. So basically all we were doing is delivering the same amount of leads to customers, but they were far less committed to whatever we were doing.

So we upped our own inventory- Yeah. Uh-huh ... and improved their results at the same time. Yeah. But, um, speaking of the AI stuff, and to kind of move off of the negative sides of AI, this is a topic that comes up, I would say a lot, but I feel like that would be vastly underselling how often this comes up.

Like when I'm out on the road, we do a lot of dinners for product leaders, and we'll get together 30 to 60 product folks in a city to talk through privately what's going on. What are the things in your way? What's worrying you right now? So a lot of stuff comes up. It's just become, how are you using AI on your team?

Because we're all being asked to move faster and do more with less, and basically justify all the money we spent on models, but what are you actually doing with it? And I feel like I've seen a lot of people talking about here, "Oh, I built my own personal OS," which is great, but I don't know about you, I work with a team across the [00:16:00] company, and it's much more helpful when people all have kind of similar ways of working or at least a similar touch points, and this is something you've, I think, done a really good job of.

Rather than building kind of a personal OS, experimenting and kind of helping to bring through at your company more of a team-based AI OS for the product team. My view is similar to yours, right? I think everyone is building personal AI setup, but even being at these dinners with product leaders that are leading kind of the internal charge of AI, very few of them are actually focused on building what does that like operating system look like at scale.

And 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 someone basically who built it leaves the company. So what basically makes it a, a team OS is we're using cloud code.

Everything is stored within one GitHub repo. And I would say actually the kind of exciting part is historically everyone [00:17:00] has built their individualized context layer. So kind of the base of this is actually creating a product context layer, which effectively before this, every skill had its own logic of where should this information live, what is the outcome?

You say the personas, the competitive data specs, and if everyone was kind of creating different skills, then it would be really hard to retrieve the right information at the right time. So now we just have one skill that is called within all these other skills, but it basically is one like shared lookup service that knows the rules.

Every skill basically defers to it. So like, hey, competitor data goes here, or feature track specific data will go here. And then on top of that, this is obviously a very, very, like, as you use this OS more and more, you're gonna have thousands of thousands of thousands of files. And I think a lot of people now are talking about like how to properly utilize their tokens.

Mm-hmm. So then we've basically built kind of a knowledge base skill, because [00:18:00] right now trying to read thousands of thousands of human written files every time someone asks a question is actually very expensive for the agent. So there's basically a compile step that happens. It's about like five hundred to a thousand tokens When index is up front and just says what exists, what doesn't, and when a question is asked, it will basically pull the most two to five most relevant articles in out of maybe the seventy-five that it found within the file.

So then you're still getting the raw files, but you're not actually having to search through this, like repository at all times. How do you go about ensuring the, the balance between if you abstract or summarize or kind of however, whatever you're using for indexing and kind of like fast search, if you summarize your abstract too much, you have the risk of basically you might not actually deliver the most relevant stuff.

If you don't do enough, you're just gonna burn, you know, half your token, half your context on any search just from loading it. Like where does that kind of happy medium sit or, or is there a better way to do [00:19:00] it? Yeah. So the interesting thing is it's technically not summarizing any of the files. It's basically a step that the agent will just point them to, "Hey, based on this question, go look in this section of the product context layer."

So then that drastically decreases the search and token usage that the agent would have to use, right? Before it would be like, "Hey, let's go just check the whole context layer based on keyword, et cetera." But now it's kind of more of just pointing the agent, "Hey, based on this question- Mm-hmm. "I know where everything is stored and the hierarchy.

You should just go look over here." So you're actually not getting any paraphrased or shortened files, you're just having to look through, say, fifty to seventy-five files versus a thousand when the question is asked. Yeah. Is that, you basically have, like, a sub-agent kind of operating that knows j- Yeah, yeah.

Exactly. Okay, that makes sense. 'Cause we've run into, in some of the marketing applications we use it for, we have big databases of, we wanna go, uh, look across a ton of sales calls, for instance, just to see, like, how do people talk [00:20:00] about this problem that we see often? And there's kind of two ways you can do it, as we kind of approached it early on.

One was have a summary of each call, or bullets or index kind of points of what was covered there, and it can go first look at who has that item checked or whatever you wanna represent it as, you know, pretty easily, pull in all those calls, and then kind of go deeper on them. And we found we missed a lot, and kind of my cheat for a little while, if I really want, it was I just make sure to, like, go read every line of every transcript and just find me everything that is mentioned.

And it worked. Yeah. But it was super resource intensive really, really fast, and that, like, so that's an interesting way of approaching it, which, uh, we'll have to look at and I think would be useful for other people. Yeah. So how is the team using this right now? What does that look like across the team?

What's the value they're getting of having this kind of shared tool versus you have one, I have one, and, and we generally try to keep maybe something similar? Yeah. So it's pretty fun. So we're using Cloud Code CLI. Mm-hmm. So we're all in, non-engineers, all in terminal now, so it's definitely a fun, uh, change of our day-to-day work.

So how we're kind of using it, I mean, my [00:21:00] full workflow as a, you know, product leader and PM is kind of within this. So basically how I see massive amount of gains has been around research and validation. Through Gong MCP, they don't give you, like, the raw transcripts, but if you send that to a database that you have, your agent can now sift through and really figure out, hey, why are we actually losing sales?

Mm-hmm. Looking at all our closed lost data, all the conversations, where are the product gaps? And rank them by the number of sales we've lost because we didn't have this product gap. And then on the existing side, looking through all customer success calls, figuring out why people churned, what were they vocal about, where is it really not working?

Where I think what we used to get was five to 10 user interviews, but now you're getting it at scale and much quicker, right? So I would say that's been a huge, huge win, and I think it's been a huge win because when you're getting access to a data set that you never [00:22:00] really had as direct access to historically, it changes your workflow a lot.

I think second, what we're kind of seeing is the role of a PM once it gets into execution and go to market, you're kinda blending a lot of the roles together. I think what historically used to happen is PM could create the prototype still as say, an IC, can write the PRD, but then would have to pay some sort of handoff tax to say work with, you know, say product marketing or work with sales operations or data science.

Every time you have to work with another cross-channel team, you're paying that handoff tax of like re-explaining that feature, but now everyone has all the latest context, so they were out sick, they have the meeting notes. They don't understand parts of the PRD, or they don't know where the PRD or Figma is stored.

They have all that an- information to write these documents. But then what I'm also seeing is the role of the, say, PM or builder can actually effectively take on a lot of these things. So now say, [00:23:00] PMs can now focus on go-to-market plans, while maybe now product marketers can now focus more on sales training and go-to-market training and maybe holding them more accountable.

"Hey, why aren't we actually, you know, getting the adoption we're getting?" So it's kind of like removing a lot of that, say, lower value work, which had to be spread across multiple teams. I think one of the things in there that resonates on our end, so we don't necessarily have like a, a PM OS or, or a centralized OS.

We do have, uh, I think something similar to what you're talking about, where We built kind of a company brain internally, for lack of a better word. Yeah. All the data across the company is now indexed, and we've spent a good bit of time explaining all the relationships, building the context to understand how all these data tables and other points we ingest can interact and how they kind of relate to each other.

What that means now is, kind of to your point, we can very easily ask, maybe trials are up, but we're not seeing increased [00:24:00] sales. Yeah. Why not? What's going on? And it knows how to kinda churn all the, like, little touch points of, you know, what are our funnel steps? How do these things interact? Or to your point, product team can ask, why did this opportunity or why did these five opportunities die?

And it knows enough to go in and read all the transcripts and all that. But having the centralized context layer of that, when I ask what happened with page views or why demo requests are up or down, I get the same analysis that if the CEO asks or if a member of the product team asks or if a member of the sales team or anyone asks.

Yeah. So it ensures we all are kind of getting the same data. It, it gets rid of the whole thing that we used to all have where my number and your number for the same thing were different. Yeah, yeah. Yeah. When you have an individual OS, you're kinda working through it, and then you're improving, say, the skill or the workflow that you've automated.

But with this kind of team OS, within all the skills that you've created, you have to create a feedback loop, right? I think that's the key part, right? So say you take, like, a judgment [00:25:00] pattern for product more managers or PMs, right? Every time that you wanna, say, draft a Slack message on your point of view- If it differs from what was actually sent to you by AI, you should actually correct it within there so it understands it, and then you actually then use the Slack MCP to, say, post your Slack message.

I guess what I'm seeing is, like, once you have volumes of volumes of volumes of people, much more than one person using it, the improvement speed and the feedback loop is just much more quicker, and it gets to where you want it to get just at a fraction of the time. Like, the more people you add to it, and it kinda figures out how to handle more people, adding each marginal person after that is probably faster.

Yeah. Because once it can kinda handle five people, the number of corner cases that haven't been seen yet are probably gonna start to diminish at an exponent or, or something similar to that. I think I could keep going about ... I mean, we're basically covering all my favorite topics, like friction in workflows, AI, and nerding out on how we're actually bringing in and making people faster and stuff.

But speaking of team, [00:26:00] I'm pretty certain at House you have a, a team that probably wants you back at some point. I appreciate you coming on, man. This has been fantastic. Would love to keep up and maybe follow on and, and have you back on in a couple months and see how things are evolving. Until then, thank you so much for coming on.

This was a blast. I feel like I learned a lot. If people are looking to kinda maybe ask more questions or follow on anything, is LinkedIn a good spot to kind of ping you? Or- Yeah, I think my LinkedIn and, um, you know, you'll see kind of, um, I have my newsletter up there. Yeah, sign up for the newsletter, actually.

The newsletter's really good, so people should sign up for that. What is the website so people can sign up? Just insidergrowthhq.com. If you want very tactical case study kind of written feedback, it goes very, very deep on ... I think we try to go with the approach of, like, you can take an article and apply it to your next sprint as a PM or, or even as a founder.

Nice. Yeah, thanks a lot for having me on. I think this was a blast going through commitment, commitment levels, PLG, and then also building this Team OS. I'm super curious if anyone else who listens has things they built or how they're progressing on the Team OS thing. Let us know. [00:27:00] Love to hear more about it.

But yeah, Kunal, thank you for coming on. Have a good rest of the day and, yeah, hopefully talk to you soon, man. Sounds good. Thanks a lot, Jeff.