Leader Spotlight: The benefits of being a full-stack PM, with Kunal Thadani

---

Kunal Thadani is Director of Product Management at Houzz, a software platform for home design and renovation. He began his career in strategy consulting at Accenture before transitioning to a product management role at GREE International Entertainment, a mobile game company. Kunal then worked at Gigster and, later, EME Hive, which kickstarted his move into the dating app industry. Before joining Houzz, he served as Head of Product at The League. In addition to his role at Houzz, Kunal teaches a course on increasing revenue growth and co-produces the GrowthInsider’s Newsletter.

In our conversation, Kunal talks about the necessary qualities of being a full-stack PM, including being resourceful, process-driven, and willing to wear many hats. He shares examples of finding product-market fit and identifying leading and lagging indicators from his time at The League. Kunal also discusses how mentorship helps you “break out of your local maxima,” i.e., enables you to learn from the successes and failures of others around you. 

---

Learning how to be resourceful

What would you say are some of the most valuable lessons you’ve learned from being the first product manager in a startup?

As a full-stack PM, the number one thing that comes to mind is being resourceful. You don’t always have the right team members in every position. When I first joined The League, I had to go through advanced SQL training during my first week to ensure that I could pull and use my own data. At the time, we also didn’t have a full-time designer or QA person, so I was often jumping into Figma or dogfooding my own product on every release. As a result, it was important to learn every part of the product development cycle.

Being resourceful helps you identify new opportunities. You start to figure out where the team can actually improve processes. At a smaller startup, you can’t have meetings go longer than expected or let things fall through the cracks because revenue is always the North Star. Being able to close experiments quickly and run efficient meetings gives everyone time back to focus on that North Star metric.

Another valuable lesson is to be process-driven. I’ve carried that tenet into every PM role I’ve had. When you join a larger company with a more established product, you can fall into a mentality of being in a feature factory. At a smaller company, it’s less about the velocity and more about clearly understanding the problem. Do you understand who you’re solving the problem for and how important the problem is before diving into a solution?

Once you have the solution, you’re then focused on impact and outcomes.

When hiring people for a team in a startup environment specifically, what qualities beyond skill sets do you look for?

Willingness to wear a lot of different hats. Even on the engineering side, I’ve seen people taking on tasks to design features or come up with new scenarios for users. At one early-stage company, my colleagues and I all acted as copywriters (this was before ChatGPT), coming up with our own marketing copy and go-to-market content.

One of my previous roles was at The League, a dating app. The dating industry especially is very data-driven, so that was a quality I looked for. Even if you’re in a QA or ops role, everything needs to boil down to a data-oriented decision, so I look for people who understand the limitations of the data that we collect. They also need to understand our base metrics; this helps them easily get aligned with stakeholders. It’s important for people to have confidence and be able to truly understand the business.

Lastly, being able to handle ambiguity is critical. A lot of things that we were doing were new to the dating industry. For example, we launched a live speed dating platform early on in the pandemic. There was a lot that had to be figured out as we went.

Carefully leveraging tools and processes

As the first product person, you have no team, no tools, and no formal tests or processes. How do you go about advocating for resources when you’re in that position?

From a process perspective, it’s more about setting expectations with everyone at the company. What are things that they would want from a PM? What are things that perhaps rubbed them the wrong way? I assimilated all the things that they didn’t like within a process to identify where I should spend my time to drive improvements. That’s also how I uncovered the largest pain point in my team.

From a tools perspective, it’s all about the ROI it provides to the company. Heavily focusing on putting together a business case can help with getting buy-in from the founder and cross-channel teams.

Do you have an example of this process, from either the tools or process perspective, from a previous role?

A funny story that comes to mind is from The League. The team was running the sprint on a Google Doc, and these sprint start meetings for a long time — close to 3.5 hours. I knew immediately that this was costing us money. If there are 10 people in the meeting, that’s a large cost to the business on an hourly basis. We brought in Jira and rebuilt our sprint from the ground up, and that was a huge win. We were able to bring the meeting time down to 30 minutes per sprint.

Another thing I’ll mention is that a lot of smaller startups can’t compete directly via cash compensation when it comes to hiring. They can make up for it with equity but also can compete on culture because teams are small. That’s something we did well at The League — we started integrating our interview process with our social events. Or, the candidate could spend a half day with the team and work through a specific problem, so it didn’t really feel like an interview.

We’d throw parties to launch the product in a new city and open up the waitlist. We’d invite our interviewing candidates to the launch parties. This allowed us to see if they were excited by the problems the industry was facing, and in turn they could see if we were a good fit for what they were looking for.

Evaluating the opportunities where users struggle

Could you talk a bit about your approach to finding product-market fit?

A key component is understanding the customer voice and shaping the roadmap. I focus on what the data at large is saying. There are only so many kinds of data points, so, at The League, we set up this concept of integrating every single aspect of customer support.

Every time someone filed a ticket in the app to chat with our support agent or emailed us, we linked that through our Slack channel so we could have a steady drip throughout the day of the common themes that were coming up. It was less about the direct feedback component and more about being able to evaluate the clear opportunities where users were struggling.

From a metrics standpoint, we monitored things daily pre-product market fit. One metric was retention, and we honed in on the 7–14 day retention period. There was also this concept of ICP (ideal customer profile) and non-ICP. In the early days, you have to ensure that 1) the product that you’re building is actually for the intended audience, and 2) that you’re attracting the right audience that you’re building the product for.

At The League, we had an initial onboarding questionnaire to identify if a user fit the ICP of our product. We were building a product for driven professionals from the top 25 universities who were active on LinkedIn and wanted to date. The number one characteristic this group was looking for in a future partner was drive and passion, so we wanted to make sure the people we were attracting and letting into the dating app actually met that criteria.

It seems like monitoring user feedback in Slack was useful because it gave you a sense of customer sentiment in real time. As you scaled, did it become unwieldy?

It did get unwieldy. This was before AI was a real thing, so we had to optimize with what we had. We ended up taking all this feedback and creating a dashboard that was updated every so often. We would do a text analysis on the dashboard to group a lot of key problems together.

We could drill into the specific data points to see details, such as which user ID reported which problem, etc. We could then double-click and schedule some user interviews with them. With the dashboard, we could modify the cadence at which we checked. We went from checking it every hour to only at the beginning of the day, for example, to make sure our roadmap was still aligned with what was being reported.

Identifying leading and lagging metrics

In a startup environment, revenue is a critical metric. You don’t always have the luxury of waiting to see if a new product iteration will give you the return you need. How do you determine when to give up on a particular initiative and move on?

We worked closely with the data science team to identify leading and lagging metrics. Say we ran something on onboarding where the leading metric is if a user completed their profile. We’re assuming if more profiles are completed, then something downstream will have an impact on revenue. In this case, it could be the initial conversion to the subscription. Usually, for the average time to conversion, we’d see a big spike on the first day. But to really see it mature, we’d have to wait for the first 30 days until people feel the pinch of the matches that they’re seeing to convert.

Revenue is definitely a North Star metric, regardless of the team you’re on. What I’ve noticed regarding the PM role transition from feature shipping to impact and outcomes is that even the roles you didn’t think connected to revenue are actually connected to it in some way. If you think of a core PM who is focused on engagement, that’s still a leading metric to get more people to activate (convert from a trial to a paying user) or use your software at a deeper level (retention).

Could you provide an example of a time you implemented this process in identifying leading and lagging metrics?

So, when it comes to lagging metrics, most people care about the payback period if they’re running paid ads. We could do something called a look-back period, which is where we revisit the experiment in 60 days and make a decision in the interim. Do we roll it out or roll it back? 60 days down the road, we work with data science to refresh the analysis and see which variant had higher revenue.

The biggest thing is optimizing for the payback period. Most teams don’t have the luxury of waiting, say, 12 months to see if they’re paid back in under a year. The biggest thing for us was creating a model, where based on 14, 21, or 30 days of data, we could plug and play and then forecast what the payback period would be using the initial data we collected from an experiment.

When working on dating apps, did you also measure matches that were successful to the point where the two people eventually left the app?

There are a few components. First there’s a match, which is when two people like each other and indicate that on the app. The second is what we had a strong strong pulse on: a quality match.

Third, is whether the couple actually went on a date. We could see if there was an exchange of contact details — whether it be email, phone, etc. We used that as a leading indicator; seven days after the exchange, we’d ask, “Were you able to go on a date with this match?”

In addition to matches and dates, we tracked success stories like weddings or long-term relationships. There was a feature within the product to share that information, and we would highlight it on our website. Those would go to the customer success team, and then we would hear a lot about them. That’s how we tracked the quality of each relationship throughout its lifecycle.

‘Breaking out of your local maxima’

How important is mentorship for someone who is the first product manager in a startup, and what are some strategies they can use to seek that out?

Mentorship helps you break out of your local maxima. There’s a global maxima that’s much higher, so mentorship is key. It gives you the opportunity to learn from the successes and failures of others around you. Mentorship helps you go from your local maxima to reaching your global maxima.

It also doesn’t have to be formal. You can get mentorship through friends within the product space or even your LinkedIn connections. Having a network is key, and you can join specific groups for this. I’m in a group called Supra, which is for product leaders. Each month, they divide product leaders into groups of six and bring something called “the most important problem” to that conversation. The session is led by a coach, and everyone discusses their most important problems. The other group members help think through solving the problem. It’s a great way to get unbiased feedback and brainstorm.

Regardless of how senior you are within the product industry, I recommend starting by contributing to LinkedIn and having a point of view. Slowly, people will connect with you, follow you, and come to you for information. You can develop relationships, whether in person or digital, and share your knowledge. The concept of providing value to receive value is key.