Apart putting the video in the newsletter, there are two important things I want to call out from the session that you should not miss while going through it.

A Conversation

The first takeaway you shouldn’t miss is illustrated by a conversation I had with a founder recently. It shows how the nuances of defining, measuring, and improving PMF changes with the context. Here is the transcript of that, edited for clarity.

Founder: How do we know that we have gotten the PMF? We are tracking retention because we are b2c and expect people to use our app weekly.

Me: Yes, that makes sense. Retention is a good metric because it means customers are preferring you over others on a regular basis.

I like to add potential monetisation avenues to the PMF discussions as well. In my experience, keeping monetisation in mind while making the initial product choices, makes things easier down the road.

Founder: Yes, we haven't thought about monetisation yet. Let me think about it.

To understand PMF better, we have benchmarked retention with other similar products. We are at 40% of the best apps in the category in terms of weekly retention (W4)

Me: That's a good thing. As long as the retention curve flattens, it's a sign of PMF.

Founder: Makes sense. But how do we improve that number?

Me: I am sure you have studied Superhuman's blog around how they improved their PMF. They tried to identify what sort of people are loving the product, and then focussed on those.

Founder: Yes, we have. We can use that.

Me: Yes, but one issue with that approach is - it works well when you have a set of users who pay for your product.

When people pay, they are willing to take a longer survey like Superhuman. When it's free, like your b2c product, you might have a sampling bias in survey, where more engaged users take the survey and provide you a different picture than actual.

Founder: So how do we tackle that? Would doing interviews be better?

Me: Yes, it would be better. But even there, people who have used your product sparingly (dropped without getting value) won't be willing to speak to you. So you have to be careful - make sure that you have all the key personas listed before you start calling the users. That way, you can put more effort in segments where you haven't talked to enough users.

Founder: Makes sense! So we identify the segments for whom the product is working, and then target them?

Me: Yes, with couple of more things to keep in mind. First, make sure these segments are large enough for you. If not, you might have to work on making additional segments to love your product.

Second, make sure you understand why your product is working for them. Use that in your landing pages, ad copy, etc. and you might be able to attract them quite easily.

Founder: Sounds good! People say you should start amping up marketing spend after PMF. When do we do that?

Me: It's hard to answer this question when you aren't monetising. Get your investors' opinion. If you were monetising, I would have looked at the gross profit.

My takeaway from multiple conversations I have had around PMF is that a simple concept on paper can become much more nuanced in application. This conversation would have looked quite different for a different product - like enterprise or marketplace.

A Quote

When I ask people whether they have worked on a PMF problem, or are working on a PMF problem, they usually say ‘Yes’ if the product is in nascent stage, and ‘No’ if the product is in growth and maturity stage.

One of the most important quotes around PMF comes from Ben Horowitz, partner at a16z.

“Product/market fit isn’t a one-time, discrete point in time that announces itself with trumpet fanfares. Competitors arrive, markets segment and evolve, and stuff happens—all of which often make it hard to know you’re headed in the right direction before jamming down on the accelerator.” — Ben Horowitz

The quote summarises the second takeaway — because your product and market is continuously changing, PMF is a moving target.

Changes in your product changes PMF, and changes in your market (user preferences, competition, regulations, etc.) also changes PMF.

A Video

With those two takeaways, you can go through the session video and let me know how you find it :)

This would be all for now.

Thanks for reading,

Deepak

1. Product Interviews

2. Operating Well as a PM

I have previously written a long series (42 posts long) on Product-led Growth. You can get it in the email when you subscribe, or can find it on the newsletter home page.

10,000+ smart, curious folks have subscribed to the Growth Catalyst newsletter so far. To receive the newsletter weekly in your email, consider subscribing 👇

Subscribe now

Let’s dive in the topic now!

When it comes to sizing the market, even experts make mistakes while doing the exercise.

Back in 2014, Uber raised a large round of $1.2 billion, valuing the startup at $17 billion. There was a big debate between Aswath Damodaran and Bill Gurley on Uber’s total addressable market and valuation.

Aswath Damodaran is a Professor at the New York University, where he teaches equity valuation and corporate finance. He has written several books on equity valuation, corporate finance and investments. Bill Gurley is a seasoned (and reputed) venture capitalist and a parter at Benchmark Capital. He was an early investor and board member at Uber.

The debate around the valuation of Uber started when Damodaran wrote his analysis piece which valued the company at about a third of that value ($6 billion). Damodaran is a guru in valuation, and so the investor and startup community paid attention to this piece. He argued that since the total taxi market was capped $100 billion, Uber’s valuation at a 10% market share couldn’t be more than $6 billion. Even at a 20% market share, Uber couldn’t be more than $12 billion. He published a table around various scenarios, and what sort of valuation it led to.

Bill Gurley wrote a piece responding to Damodaran’s analysis of potential market size. He talks about a key mistake that people make when it comes to market sizing an innovation — an innovation can change how the market behaves, and measuring the market size on current behaviour isn’t correct! So sizing the market of Uber on the back of taxi market is also not correct.

He further talked about how Uber can be a car ownership alternative, and the size of car ownership market is pretty high as compared to taxi market.

“Uber’s potential market is far different from the previous for-hire market precisely because the numerous improvements over the traditional model lead to a greatly enhanced TAM. Now we consider Uber-like services as a car ownership alternative. This trend is just beginning, but because of the points highlighted herein, we believe this to be a real opportunity. For our model, we assume that Uber-like services will encroach on a mere 2.5%-12.5% of this market. This represents a potential opportunity of $150-$750 billion depending on how aggressively one believes these services can succeed as a car alternative.”

It has been 10 years since the debate, and it begs the question — who is proving more correct 10 years down the line?

Uber’s current revenue is $32 billion, and it is valued at $150 billion. But here is the catch — while it may look like Bill Gurley was more correct, part of the reason for such high revenue and valuation is Uber’s entry into an entirely new market — food delivery through UberEats.

Guess the size of ride-hailing market? $150 billion

Guess the size of food delivery (including grocery) market? >$1000 billion

UberEats today contributes to more than 30% of current revenue, despite being available in limited countries. That significantly expands the TAM of Uber, and lends to it’s current market valuation. Had Uber not entered this new market and stayed in taxi + alternative car ownership, Damodaran would have been more correct.

What Can We Learn?

So what can we learn from this case? One, it’s hard to predict the market size, especially for the Internet companies!

And there are two reasons for that.

First is what Bill Gurley was talking about. It’s hard to predict how innovation will change the market behavior and change the market size in future.

Second, the Internet changes how distribution happened. The Internet made the cost of distribution zero for companies with a good install base, and that’s one of the reasons why it’s hard to predict the market size of Internet-era companies. Uber as a ride-hailing business is x, but add delivery to it, it becomes 3x. Add self-driving to it, and it becomes an entirely different story. When it launched food delivery, it didn’t have to burn money like it did in it’s early days to acquire customers. It could rely on it’s current customer base to start ordering food.

And these two reasons make market estimations and valuations tricky for founders, PMs and investors. So what does it lead to, besides the challenge?

It leads to certain behaviours that we see in founders and investors of the tech companies.

1. You will see the large ambition from startup founders is rewarded heavily by the market, because that is the first step to take the company to a much larger market and win there. The possibility of this happening is higher for the Internet companies in absence of the distribution moat. The history of the Internet companies is full of such examples.

2. In absence of a distribution moat, the market rewards innovation heavily because that can help a company win the market. That reflects in tech companies investing heavily in R&D. Meta and Nvidia invested 30% of their revenue in R&D in 2022. Compare it to Pepsico, which invested just 1% of it’s revenue in R&D.

What Can Product Leaders do?

One of the most useful aspects of market sizing for product teams is also the ones least talked about — confirmed market size. A confirmed market is where the PMF of the product is confirmed! From the TAM, you need to filter out segments where the PMF isn’t there. For example, if the PMF lies in the online, women only audience for a fashion retailer. Use that as the filters to get to confirmed market.

The confirmed market size can be calculated by the total size of confirmed market, multiplied by the share a company can achieve.

A discussion around the confirmed market can lead to few good things for product teams:

1. Helps predicting growth and growth plateaus consistently — Imagine that you know that you have PMF in urban, k-12 teachers for an app built for classroom. You have already taken a huge chunk of market share and are saturating. While building the strategy for next year, you would be cautious to put high growth for the core app, and also push the team to plan out the next market to explore and move into.

2. Finding adjacencies to grow into — The benefits of knowing your confirmed market is that it becomes easy to figure out your adjacent markets. Adjacent markets take less time and energy to get into and capture.

And don’t forget, innovation expands the TAM, and so does getting into new markets where distribution advantage is there.

To summarise,

1. It’s hard to predict how innovation will change the market behavior and change the market size in future.

2. Internet made the cost of distribution zero for companies with a good install base, and that’s one of the reasons why it’s hard to predict market size of the Internet era companies.

3. The large ambition from startup founders is rewarded heavily by the market, because that is the first step to take the company to a much larger market and win there. The possibility of this happening is higher for the Internet companies in absence of the distribution moat.

4. In absence of a distribution moat, the market rewards innovation heavily because that can help a company win the market. That reflects in tech companies investing heavily in R&D.

5. As a product leader, you can use confirmed market size to predict growth and saturation. You can also use it to find adjacent markets.

We will end this post with the question I posted on LinkedIn around MVP this week.

The LinkedIN Question

I posted the following question with options on LinkedIn this week.

The audience is pretty split on this one, and here is my response.

1. MVP and MLP are hard to distinguish. After all, if you create value through your MVP, users will come to love it.

2. Most of the MVP designs have an objective to test the riskiest hypotheses — be it around customer needs, usage patterns, or business model. MVP is equivalent to Riskiest hypothesis testing. If you aren’t thinking about the risks while designing MVP, you are doing it wrong.

3. Experimentation and MVP are two separate things. Experimentation (a/b testing) is what comes after you have launched MVP.

So experimentation is the correct option.

Thank you for reading :)

If you found it interesting, you will also love my

1. Advanced Growth Program for PMs

2. Product Sense and Strategy Program for PMs

3. Bestseller Book ‘Tech Simplified for PMs and Entrepreneurs’

Subscribe now

It was a sunny day in 2018, and I had flown to Hyderabad for my Google PM interview. Google usually does screening rounds before inviting for onsite interviews. I had terrific feedback in screening rounds.

In the onsite interviews, Google tests various hats of PMs - analytical, product design, business, strategy, and tech. I had prepared well for all, or at least I thought I had :)

The first onsite interview happened to be the technical round. I come from a chemical engineering background and don’t have coding experience. At various times, I had tried to learn Javascript, HTML, Python, etc., rather unsuccessfully because there was never enough incentive to do so. In preparation for Google’s technical round, I had covered the data structure and algorithm basics plus the system design questions.

The interviewer gave me one algorithm problem and one system design. I solved the algorithm problem. In the system design question, I mumbled a few things for the next 5 mins — sharding, database, table structures, etc. The interview got over quicker than expected, and I knew that my chances of cracking Google were over.

There is a quote I read sometime back,

“Without the fire, the phoenix never rises from the ashes”

Google interview served as the fire for my technical aptitude. I completed Machine Learning Nanodegree from Udacity, a few books on system design and algorithms, etc in the next 2 years. All of that helped me get the role of leading the deep tech products(Voice Search and Assistant) at Flipkart.

All of these experiences culminated in the book I published early this year “Tech Simplified for PMs and Entrepreneurs”, which I wrote to make sure people coming from non-coding backgrounds don’t struggle as I did. So looking back, you can indeed connect the dots.

Based on my learnings so far, here is how you could crack the technical rounds in all companies that you interview for. Please note that I will use some excerpts from the book wherever it helps.

Technical Rounds are Messy

Technical rounds of PM interviews are messy because every company does it differently. Google is famous for its algorithm and system design questions. A lot of companies focus on whether you understand technical complexities or not. Some don’t even have a tech round. I did a survey on LinkedIn, and around ~50% of PMs said they don’t have a technical round in PM interviews.

Based on the survey, some of the prominent companies which have technical rounds are:

• Flipkart

• Google

• Coinbase

• CoinDCX

• Bukuwarang

• Cred

• Razorpay

• Delivery Hero

Some of the prominent companies which don’t have technical rounds are:

• LinkedIn

• Facebook

• Bigbasket

• Microsoft

• Tata Digital

• Meesho

• Ola

Please note that the data shared above is representative. For example, for AI/ML PM roles, almost all companies will have some sort of check on tech understanding. The same could be true about levels. At senior levels, they may check for tech understanding which isn’t required for APMs.

But it’s really important to prepare and be ready for all sorts of questions for technical rounds because it’s not standardized. And I am here to help you :)

Range of Questions

Usually, there are four categories of questions in tech rounds:

1. Behavioral questions around tech

2. Explainers for technical concepts

3. System design of the current product you are managing

4. System design of a popular product

It might seem random when you first look at various categories, but they aren’t for most.

1. Behavioral questions check how well you can work with engineers.

2. Explainers check how well you can explain technical complexities to non-technical teams like marketing and business.

3. System design of the current product checks whether you go to the details of the product you manage or not. Are you aware of trade-offs that your team has taken?

4. General system design questions check how well versed are you with tech, in general. This is the highest level in my opinion.

Depending on the kind of PMs an org needs, it may consciously or subconsciously choose to ask one or more categories of questions. Now that you understand why these various categories are important, let’s look at the details of these.

Behavioral Questions

A few sample questions here would be

The CEO is expecting a key piece of development on Monday. It's Friday and the engineers in your team call you to say that they had an unexpected issue and will need an extra week to finish. How do you tell the CEO?

Describe technical challenges from past projects

The beauty of such questions is that they reveal a lot about the depth at which a PM has operated in the past. The ideal way to answer such questions is to use examples and analogies wherever possible.

For example, in response to the first question, you could tell the approach you would take and that could be an okay answer. But a really good answer would be if you can draw similar situations from your past experiences and how you handled them.

As a checklist, you should do the following to prepare well for these questions:

1. Prepare your past projects well. Write them in detail to be comfortable when speaking about them.

2. Examples from the past are best while making a point. This also prevents any loss in communication because you always share examples with enough context.

3. In absence of a direct analogy or example, draw an indirect one

4. Put an ‘End-user > Org > Team > Individual’ lens in your responses when there is a trade-off.

Explainers

A few sample questions here would be

Explain DNS to a 5-year old

Explain APIs to your grandmother

To answer these questions, you should know about the terms. My book covers almost everything a PM is supposed to know, so you could read that. The book is also written in a very simple language at an 8th-grade level, so it may help with explanation in simple terms as well.

But even if you have read the concepts, you should do a mock practice by actually explaining something to a kid or your mom. It helps you assess your gaps and fill them.

System Design of the Current Product

For freshers, this question isn’t relevant. It is relevant for existing PMs. First, let me explain what system design is. From the book —

System design is an important topic for PMs for multiple reasons. Before we go into reasons, let's talk briefly about what system design is.

A system is a set of things working together to achieve the objective of the system. Depending on the objective, the system can be designed in multiple ways. For example, we design the railway system to help people travel via trains from one place to another. The railway system designed for maximum revenue from stations A to B will differ from the one optimized for minimum journey time from stations A to B. 

Apart from objectives, every system comes with its own set of constraints. The most common constraints are time, money, and quality. Whenever we design a system, we have to keep the objectives and constraints in mind. 

For software system design, we define how different software and hardware components will work together to achieve the objectives. For example, the system design of Youtube ensures that billions of people can watch videos every day. System design is also known as system architecture.

If the interviewer asks about the system architecture of your current product, you have to explain how various pieces of software come together and make the magic happen. So how do you prepare for it?

The best way here is if you don’t have to prepare at all. One of the best habits that I keep recommending to PMs is to continuously understand the system design of the product they are managing and its tradeoffs. If you aren’t doing it, start on it.

If you are already in the interview process, talk to an engineer/EM and understand how the current product is built. Write it someplace so that you don’t forget (when it comes to system design, don’t rely on your memory), and understand it well.

A couple of things to keep in mind are:

1. Be comfortable with saying “I don’t know”, when you don’t know the answer to some detail interviewer asked. Don’t try to wing it.

2. Keep gauging the interviewers’ reactions. When asked to explain how your current product works, try to give a summary first. Wait for the reaction of the interviewer and follow-up questions. Never make it a monologue for 5-10 mins.

System Design of the Current Product

A few sample questions here would be

How do the content recommendations work for a streaming services platform like Netflix?

Design a photo-sharing app like Instagram

Before we go into how to answer these, it’s important to understand why it’s important for PMs so that you could keep these in mind while answering these questions. From the book,

But why should PMs care about system design? There are three reasons in particular:

1. Any system design will involve trade-offs since it has time, money, and resources constraints. A PM knowledgeable enough to have a conversation with engineers around these trade-offs can add value to the decision-making. This is the major reason why PMs should understand system design.

2. System design determines the user experience. For example, the time taken to load a page increases as the number of requests increases beyond a point. A PM who understands the relationship between system variables and UX can anticipate the problems and act proactively.

3. In the technical round of PM interviews, system design questions are common at top companies like Google, Facebook, Amazon, Microsoft, etc. Over time, even smaller companies have started including a similar tech round in their PM interviews. 

When it comes to learning tech, system design brings everything you have learned together. It will help you see how everything works in sync.

And that’s why companies ask this question. You could go to any depth in system design. Here is a suggested 5-step approach for system design questions:

• Define the scope of the product: No one expects us to design a product like WhatsApp or Instagram within 45 mins of an interview. So it's important to define the scope. In an interview setting, defining the scope shows your decision-making and prioritization skills. Here is what you can cover as the scope:

  • Functional requirements — what features do you need?

  • Non-Functional Requirements (NFRs) — measure the quality of UX like latency, page load time, successful OTP generation rate, etc.

  • What’s not in scope  — equally important to state things not in scope

• High-level design as per functional requirements: Defining how the system works on a high level can be quite helpful. It helps in identifying key components of architecture and how they interact with each other. 

• Details of important components of high-level design

  • Database choices

  • APIs

• Details of how we are going to meet NFRs

  • Scalability

  • Latency 

  • Availability and robustness through replication/redundancy

  • Anything else that affects NFRs

• Close by summarizing and asking the interviewer if there is anything else to cover

It is easy to build insecurity while working in tech if you don’t come from a CS/coding background. But once you start understanding the tech, it builds up your confidence to operate and make decisions magically. Invest your time early in your career in learning the nuts and bolts of tech, and you would be happy for it :)

This would be all for this post. If you are looking for more practice questions for the tech round, here is a list I prepared.

Thanks for reading this one, and all the best!

Deepak