The inspiration for this post came from various conversations that I have had with Founders and Professionals working in Tech. I’ve noticed people- even those within Tech- often have oversimplified narratives about the ‘Product Management (PM)’ role. This is understandable, as the output of a PM is usually not as tangible as design, code, leads, or bookings. Moreover, when someone has only worked at similar types of companies throughout their career, their perception of what a PM does is inevitably shaped by their environment. As a result, PM roles aren’t as well understood as perhaps Design or Engineering roles are. I hope this post sheds some light on that and helps you better understand the nature of PM work, and how it changes in different contexts.


1. The Times They Are A-Changin’

Lately, the Tech sector (including the product management function) has been doing some soul searching. The sector has seen instances of financial discipline where companies like X, Meta, etc. have managed to materially reduce their headcount and yet churn out more profits than ever. This is partly because tech companies had chased growth at all costs during the ZIRP era, resulting in excessive red tape—a sentiment aptly captured in this tweet.

Blog Pic

Now, there’s also a secular trend of AI adoption that’s driving up productivity across departments. The current slowdown in growth has forced the industry to reevaluate how we operate and adjust to the new reality of getting more done with less. Airbnb, for example, merged its Product Management function into Product Marketing Function. Some others have argued that AI will collapse the talent stack of product teams, suggesting that future PMs in an AI-first world will need at least some hands-on knowledge of both design and engineering. While there’s some truth to these narratives, I can’t help but wonder if it’s possible to generalize one trend for all of product management. That’s why I wanted to share my understanding of the PM function as it stands today, particularly for those who haven’t worked as PMs and might silently question the utility of the role.


2. Defining Product Manager Role

The challenge in defining a PM role lies in the breadth of work Product Managers handle and the wide variety of titles across industries. PM roles are often described as the “quarterback” of the team. While that analogy is somewhat accurate, it’s not particularly helpful because it could just as easily describe roles like “project managers,” “product owners,” or “program managers.” In some cases, companies mislabel these non-PM roles as PM roles to attract talent. This is especially common in early-stage startups, where organizational structures and function-specific responsibilities are fluid, and the scope of PM work is still being defined. At its core, PM work tends to include whatever “tasks” or “jobs” the business needs to get done but don’t fall under the expertise of specialists like designers, engineers, or product marketers. This varies significantly from company to company and, understandably, there’s a lot of confusion about what a PM actually does.

The best explanation I’ve come across is from Marty Cagan, who explicitly defines PM responsibilities by identifying four types of risk that a team has to manage:

  1. value risk (whether customers will buy it or users will choose to use it)
  2. usability risk (whether users can figure out how to use it)
  3. feasibility risk (whether our engineers can build what we need with the time, skills & tech we have)
  4. business viability risk (whether this solution also works for the various aspects of our business)

Here the business viability risk includes whether the product fits with the go-to-market or sales channel; whether the product would work within the constraints of contracts with partners and/or legal compliance; whether we can afford to cost-effectively acquire customers, whether we can effectively monetize the product, and whether the product is consistent with the brand promise; as just a few examples. Cagan states that every tech team has to manage the above four risks and here’s how traditionally responsibility for those risks have been assigned:

  1. The Product Manager is responsible for the value & viability risks, and accountable for outcomes.
  2. The Product Designer is responsible for the usability risk, and overall accountable for experience.
  3. The Product Lead Engineer is responsible for the feasibility risk, and overall accountable for delivery.

What I like about Cagan’s definition is that it is applicable to a wide range of industries and provides a shared language to understand how responsibilities are divided. For example, in finance, there are roles that, although not explicitly called “product managers,” function as such—they are responsible for managing both the value and viability risks of financial products. In Free-To-Play Gaming, on the other hand, the role of “product manager” is further bifurcated. There’s a role called “Producer,” responsible for the value risk—i.e., ensuring that the game developed will be well-received. Additionally, there are roles called “Product Managers,” who are responsible for the business viability risk and tackle problems like driving growth, engagement, and monetization.

When people say product management is not required or something along those lines, in essence they mean someone else on the team is stepping up to manage value risk and business viability risk. For example, during Airbnb’s pandemic-driven reorganization, the design function likely took on managing the value risk and the product marketing function took on managing the business viability risk. However, what worked for Aibnb doesn’t necessarily mean will work at other companies. Often times the skillset or interest of adjacent teams like design, markting, etc. don’t necessarily align with what is required from the business—it just so happened that in Airbnb’s case the reorg worked out as it is a consumer-facing company. Likewsie, if no one on the team is stepping up to address the value risk and business viability risk, then the organization is either likely relying on some centralized teams or there may simply be a gap due to resource constraints. The latter often happens in the early stage startups where founders take on the responsibility of managing all these different risks.


3. Dimensions That Govern Product Work Post Product-Market Fit

To understand a PM role one has to understand the context in which they are operating. Context governs what kind of role a PM will play in the company. Most product work by product managers is done post product-market fit. Product work in the early stages of a company is best done by Founders as far as possible; so we’ll discuss that separately. Broadly speaking, the PM role is shaped by three key factors—

  1. The stage of the company - A company can be characterized as falling into any of these 5 stages— Pre-PMF, Post-PMF, Hypergrowth, Scaled Up, and Decline. The stage of a company is perhaps the most important of the three as it determines the amount of structure and scope of a PM’s work. The stage of company also attracts different types of people depending on their risk tolerance, comfort with ambiguity and interests. For e.g., some people operate like pirates and are better suited for startups while others prefer who operate like the navy are more suited for big companies. You can read more the impact of stage of a company here.

  2. The business model or nature of the underlying business - Depending on the underlying business, different functions have different amount of say in the product direction since they are more closer to the customers. As a result, the business model and the nature of the underlying business greatly influence the culture of a company and the role of PMs within it. For example,
    • Enterprise SaaS (e.g., ServiceNow): PMs are aligned with sales-teams
    • Consumer (e.g., Spotify): PMs collaborate closely with designers
    • Hardware Tech (e.g., NVIDIA):, PMs focus on aligning with engineering
    • Marketplaces (e.g., Doordash): PMs focus on aligning with the business teams
    • B2B SaaS with PLG model (e.g., Notion): PMs drive the culture since growth is product-led

  3. The type of problems being solved- This relates to specialization within Product management. Broadly there are 4 types of product work—Feature Work, Growth Work, Scaling Work, and Product-Market Fit Expansion Work (!= Early Stage 0-1 Work). Many people, outside of Product and Engineering, believe a PM is an expert across all 4 of these areas of product work, based on an assumption that all PMs are created ‘equally’. But that is usually not the case. Different backgrounds, skills and interests lend well to the different specializations. For example, an engineer-turned PM is likely more suited for doing Scaling work, while an analytics person may be more suited for doing Growth related work. You can read more PM specializations here.

To illustrate the above, I’ve mapped my own experience below. I’d like to call out that while I have shown Growth work after Feature Work on the Y-axis, both tend to co-exist once the company has achieved product-market fit stage. Likewise, nature of underlying business has been captured in the brackets since only two dimensions can be shown.

Blog Pic

For those building a career in Product Management, it takes some time to develop breadth across different contexts. Because we are creatures of habits, it also takes some time to realize what worked well in one context (say a big company or B2B SaaS) doesn’t necessarily work in another (say a startup or consumer marketplace).


4. Early-Stage Product Work

In the early stages of a company, getting to product-market fit (PM-Fit) is the main goal. Most of the conventional product management wisdom that gets shared usually has an underlying assumption that the company has a PM-Fit. Once a company achieves PM-Fit, managing the product becomes somewhat easier—you know something is working and want to do more of what is already working; perhaps focus on making the value proposition more sustainable and the distribution process more repeatable. Before reaching PM-Fit, though, product work can feel like being in the wild, where intuition is equally important to frameworks, if not more. As such, the process becomes more art than science.

Data is usually limited—so you are looking to generate quality signals by doing fast experiments. You are looking for experiments that will result in an order-of-magnitude change in some material metrics instead of incremental changes. Essentially you’re optimizing for “learnings” about your customer and your market. You are aiming to build a mental model of how your target customer thinks and how the market is likely to evolve. By building this understanding you can then validate your assumptions about the problem you’re trying to solve and the product you’re planning to build.

All this requires constant iteration and rapid adjustments based on what potential solutions are working and what’s not. Founders, therefore, are best suited to do the early-stage product work as they have the maximum context. A dedicated PM usually doesn’t make sense at this stage—although they do occasionally exist to complement the background of the founding team.


5. Conclusion

I hope you now have an understanding of why product management can feel so messy and inconsistent. Many people assume that the complexity of product management—its lack of a shared language, the fact that it’s defined differently everywhere—means that product management itself is flawed. However, that’s because the changing nature of the underlying context impacts role of the PM. The messiness and lack of consistency are thus a feature, not a bug.

Poor experiences with product management in the past can lead teams to see it as an overhead—a bureaucratic layer that hinders execution rather than enabling it. To avoid that overhead, some may argue other functions should handle the work of a PM. But, that approach can prove counterproductive as not having a dedicated owner risks the product work not receiving the focus it deserves.

Product work, when done well, acts as a force multiplier. It ensures the teams move not only quickly, but also in the right direction. Much like stone cutting where one needs to know where to hit, product management transforms disparate efforts into set of focused actions that are driven by a coherent strategy. When done “right”, it creates clarity, momentum, and leverage. By driving alignment between what the team builds and what the market values, product management helps create sustainable growth—and growth fixes all problems.

Working Breaking Rocks GIFfrom Working GIFs


Afterthought - On Getting Early Stage Product Work “Right”

As we saw earlier, the nature of early stage product work is a bit different than once the company has a PM-Fit. Ideally, in the early stages, founders would want to aim for the Four Fits—Market-Product Fit, Product-Channel Fit, Channel-Model Fit, and Model-Market Fit and think about how their industry structure is evolving—to increase the likelihood of a good outcome. You need someone on the founding team to think about these broader product-related problems although the focus is on PM-Fit and building out the founder’s vision of the future. If someone on the team already has a product background and enjoys doing that, the team can get very far before they even feel the need to hire the first PM. But if they don’t naturally think about these problems, then the early-stage business may have unmet needs that the founders themselves aren’t even aware of! It’s a blind-spot situation: “You don’t know what you don’t know!”

This is because conventional YC wisdom emphasizes “Talk to users, write code,” “Do things that don’t scale,” and “Don’t scale your team/product until you have built something people want.” This is well-meaning advice that’s 100% accurate. Growing a team or product before PM-Fit is inviting more pain down the line. But if a team has been working at a problem for a while but isn’t seeing traction, maybe the business has some unmet needs that need to be addressed to progress to the next stage. So, what to do? Founders, therefore, have a few options:

  1. Learn the product work - Like any other craft, this takes time. And if learning product work isn’t something the founders inherently enjoy, it can be a drain on their energy—context switching has costs. They may not be able to operate within their Zone of Genius. In this case, the founders have to decide for themselves what’s the best use of their time.
  2. Talk to product advisors - This is what savvy founders often do. They seek out product advisors who are the “right” fit for their business because no single founder has all the skills and knowledge required to navigate the countless challenges of a startup journey. However, this option likely involves offering equity incentives to the advisor. On that note, asking for advice is also a skill—you can read more here, but that’s outside the scope of this article.
  3. Hire fractional product resource - This is somewhat in between the first two options but doesn’t require equity incentives—at least, not initially. You essentially hire a fractional product resource who can help fill your knowledge gaps and cover blind spots. You work with them more closely than you might with an advisor, but you aren’t delegating decisions to them. This allows you to continue learning product work (Option #1) while potentially reducing the time required to achieve PM-Fit.

Of these, I think Option #3 is underutilized and underappreciated! If there’s a product person who you believe can help and they’re available to work part-time, this option merits further consideration. At worst, it’s a low-stakes bet that doesn’t work out—you discover that the relationship isn’t working or their expertise isn’t helpful anymore and part ways without them joining your cap-table. At best, their expertise proves valuable, they can contribute beyond product work, and you also enjoy working with them. This approach also helps them evaluate whether they’d want to join your startup full-time later. Essentially, this option helps de-risk your future hire because hiring first PM is also a tricky problem! Product Management is a high leverage function. Ideally, you’d want a clone of yourself in that role. The next best option is finding someone who:

  1. You can trust,
  2. Aligns with your values, and
  3. Shares your worldview and understands your startup’s context.

It’s difficult to satisfy even one of these criteria, let alone all three! Working part-time is a great way to assess these factors compared to a job interview or a two-week trial—for both the founder and the PM.