I've spent the last 5-6 weekends (and a good chunk of my last vacation, haha) playing around with Claude Code, and found it to be a fascinating journey. It would be impossible to put all my thoughts on this subject into a single post, and if anything, that's not really the goal here – rather, I want to use this and likely the next few posts that I write as an opportunity to summarize & share some of my personal observations about it, both for one's personal projects but also for the future of our work, especially for product managers.

Flexible canvas vs. integrated experiences

Before I dive in, I wanted to share a few basic facts and also contextualize some of the observations I'm going to share later about Claude Code.

I'm a huge fan of AI workflows that the chat interface introduced a few years back – be it ChatGPT, Claude, Gemini, or whatever your AI chat of choice is these days (I'm partial to ChatGPT myself, because I think it remains a superior product from the UI / usability perspective, at least for the time being). I remember the turning point for me was a trip to Europe in the summer of 2023, when I realized that ChatGPT app on my phone became a crucial assist for exploring, and basically replaced all other tools I usually relied upon (except Google, since it could search web back then – but that has been long since remedied). And in many ways, I found AI chatbots to be incredibly useful for any kind of information search & discovery, writing assists, learning (that's one scenario I particularly enjoy), and so on.

At the same time, the chat obviously comes with limitations and while it is an incredibly flexible interface, some tasks don't quite fit with it (e.g., more sophisticated document editing workflows, coding, etc.)

That's not necessarily a problem, since we still have existing apps AI can be integrated into to support more complex scenarios (e.g., Copilot being integrated throughout Office 365, AI writing assists in Gmail or Outlook, things like Cursor or GitHub Copilot in VS Code, etc.)

We also have now all kinds of new apps that act as AI wrappers these days that add specialized UI/prompts/etc. on top of AI APIs, enabling more sophisticated / sustainable workflows for specific scenarios.

Ultimately though, we can broadly categorize those into two buckets. One is an AI chatbot running in the browser (or an app on your phone), offering great flexibility, but also existing in a sort of sandbox separate from the rest of your files, apps, and workflows. The other is the integrated experience where you have either legacy or new apps targeting specific scenarios that are now being infused with additional capabilities via AI.

Combining both worlds

What Claude Code, I think, introduces – and the reason why it feels so distinct from previous AI tools (as well as the reason why every major AI player is now trying to replicate, with Gemini CLI, OpenAI Codex CLI, Qwen Code CLI, etc.) – is that it combines the flexibility of the chatbot with the ability to support in a sustainable fashion complex workflows that you previously could only get in more specialized apps targeting specific use cases, thus bringing the best of these two worlds in a single offering.

I realize that none of those observations are necessarily particularly novel or insightful. Still, I think it's worth pointing this out, given that the clever solution that Claude Code relies on to achieve this (namely, the fact that it lives in the terminal) curiously seems to be a bit of a blocker for the "not strictly technical" folks in the industry, based on some of the conversations I had with friends in the last few weeks. Interestingly enough, there also seems to be some aversion to the idea of Claude Code operating in the terminal from some of the more technical folks as well if they are already heavily invested in workflows like Cursor or GitHub Copilot in VS Code – but that's a separate story.

While not the only advantage of Claude Code, the fact that it runs in the terminal is certainly one of those genius moves that seems obvious & almost inevitable in retrospect, but was anything but at the time. Perhaps there is a better or more vivid metaphor here, but to me the best analogy seems to be the spreadsheet: a clean, unrestricted canvas that gives you the flexibility to construct highly personalized workflows while abstracting away underlying complexity.

Claude Code in my mind offers exactly that: at its core, it remains a chat, but it now has the full power of the terminal at its disposal (plus the power of AI, of course). That means that it can now run any commands, find and edit files, intelligently manage context by saving it into files that can be consumed later, or via running subagents, etc. This is then further extended via the concept of MCP that turns it into a universal interface to connect to all kinds of tools that exist out there, without users needing to manually hook the AI to APIs or figure out how all of this is supposed to be work together, thus once again hiding all that complexity from the user.

The "spreadsheet" moment for AI

The flagship use case for Claude Code is, of course, software development (after all, that's why it has "Code" in the name). I'm not going to focus too much on this, given the amount of information already available out there (if you've missed it though, you should certainly go watch some YouTube videos, just to get a feel for the awesome things that people are doing with it). The 1-sentence version of it would be: the revolution (or hype, depending on who you ask) that began with AI-assisted coding with GitHub Copilot, Cursor and others in the last couple of years, and extended to rapid prototyping & 'vibe coding' types of scenarios earlier this year now came to the next logical step, namely, semi-autonomous agentic coding. This allows one to have Claude Code work fairly independently (or at least with limited supervision), provided you figure out the right setup / workflows (in the form of planning, instructions, etc.) Claude Code also further extends what can be achieved with vibe coding (again, provided you know what you're doing).

The interesting thing, however, is that you can do a lot of other things using Claude Code, many of which will have nothing to do with software development, and thus might be both more relevant & perhaps less intimidating for product managers or anyone else who is not a software engineer (although I would argue that the rapid prototyping capabilities that Claude Code offers are both incredibly exciting and very useful, certainly for product managers, but for a lot of other folks as well, especially if you think about your personal workflows as well).

Here, I want to come back to the parallel with the spreadsheets, flawed as it might be, because I think in many ways it offers some useful intuition here.

You can use the spreadsheets to build financial models, but also task management, knowledge management assists, trackers & other productivity workflows, various automation tooling, and who knows what else, depending on how creative you want to get. There are certainly a lot of specialized applications that offer similar functionality for each of these scenarios out of the box (e.g., various task managers, or trackers) – however, the problem with those is that your ability to customize them is by definition limited, which would often mean that at some point, you might start running into their limitations. Those don't even have to be real limitations, mind you – they might just be the differences between the mental model you have for solving your problem versus what the authors of that particular app or tool had in mind for that scenario – which doesn't make them any less real.

In contrast, spreadsheets give you a greenfield, which means you can design a workflow that works for your specific scenario and then keep customizing it in whatever fashion or to whatever degree of complexity that you desire. My personal favorite example here is the investment tracker: many of us want to be able to track what investments they have, how those grow, how the allocation to various instruments or regions changes over time, etc. There certainly are a ton of tools for that already available, and I've tried a lot of them over the years – yet somehow, inevitably, I would hit their customization limits. This is a common pattern: specialized tools offer out-of-the-box convenience but the trade-off is that you can eventually run into their limitations, forcing you to either accept the trade-offs, search for a new tool, or go back to flexible primitives. So for the last several years, I've been using a (fairly simple) spreadsheet that I designed to fit my specific needs – because for my use case here, I've discovered that I value flexibility more than other properties.

Going back to Claude Code, while it goes without saying that it comes with all the advanced AI capabilities, what feels equally exciting and almost paradigm-shifting to me is the medium you use to interact with it (and by extension, that it uses to interact with your system). It is the terminal that makes it so powerful; like the blank canvas of a spreadsheet, it both lacks the workflow-specific restrictions, and is completely tooling agnostic. To use software development as an example, Claude Code integrates with most IDEs – or you can just let it run in the terminal, if you are going to vibe code.

Now, can an argument be made that the chat interface in the browser already affords similar capabilities? Well, I would argue the answer is both "yes" and "no", in the sense that yes, the chat really offers a blank canvas of sorts, and that is exactly why it is already so powerful and has been so world-changing over the last few years, absorbing a lot of the use cases that many of us had before (for instance, I don't really Google much stuff anymore or use Wikipedia much, instead relying on ChatGPT & then fact-check some of the source links if necessary).

That being said, the advanced productivity capabilities of the chat are by definition limited, and it's also hard to imagine seamless workflows that extend the chat in non-opinionated ways. And that is the biggest difference with Claude Code and also the MCP.

One note worth making here is that Claude Code and MCP don't necessarily have to be bundled together. In fact, if anything, MCP is meant to be an open protocol, and so it is not something that would work with Anthropic offerings only; you can also use MCP via Claude Desktop, for example, thus offering an argument that the capabilities of the chat can be further extended without the need to jump straight into the terminal. But I do think that it makes sense to consider Claude Code and MCP together, because by combining them, you get a tremendously broad surface area, and thus almost unlimited possibilities for various workflows that you can now productively engage with, or customizations you can build from scratch for yourself.

Practical examples: embrace the terminal

One trivial example here is AI writing assist. Again, one could argue that the chat interface already works for those, or that perhaps this is a perfect example of a function that belongs in the word processor apps like Google Docs. And that would be fair, but what Claude Code adds is the ability to supercharge this use case, by efficiently managing context and AI instructions, as well as extend your workflows with any number of additional capabilities as needed.

To make this more concrete, one thing that I've been experimenting with lately was building an AI writing assistant that learns from my past pieces of writing, distills the key bits of how I write (both the good things I want to do more of, and the bad habits I'd like to avoid), and then turns that into a succinct set of instructions I can use over and over again. It then combines these instructions with in-context learning from a select few examples of my past writing, as well as various additional context (e.g., examples for what I consider exemplary writing that I would like to be able to imitate or strive towards); I can then use or forego this additional context depending on the situation. This can then be further extended by, for example, leveraging MCP to connect to additional models from other providers if you want a second opinion, or leveraging Claude Code web search capabilities to search for additional pieces of writing or to fact-check what you wrote, and so on.

Now, can this workflow be replicated in a chat? Once again, in principle, the answer is "yes" – but in practice, that would not be a pleasant experience. With Claude Code running in a terminal, I can have it access a library of dozens or hundreds of documents, seamlessly read instructions from disk, and then save the updated instructions there – all of which helps a lot when you inevitably run into the context window limitations (and believe me, you will run out of the 200k tokens context window very fast here). And then if you decide to extend the scenario further with MCP, that would also be hard to replicate on the chat. So, in a way, I would say while with this AI writing assist scenario, Claude Code does not necessarily offer you completely new capabilities that were previously unavailable, in practice, it sort of does because it creates a much more efficient and thus more practical workflow here.

Obviously not everyone writes in their personal time (although they should!), but it's not hard to see how you could build more or less the same process to distill what a perfect PRD looks like, for example. And then you use that to help you write PRDs at your work while iteratively improving the set of instructions and continuously feeding it additional great examples that you and others create via this or any other workflow at your company.

That, however, is not even the most exciting part. Things get really interesting once you begin pulling additional information that can then be infused into the context via MCP. For example, you could now have MCP servers that allow you to pull the relevant documents from Google Docs, search for the right Jira tickets, find and have Claude summarize the relevant discussions from Slack, etc. One can also build (or wait for others to build) custom MCPs handling much more complex knowledge management workflows specific to the tools & processes that exist at your company.

Then, you pull all that information into the same context window and now you can have an AI writing assistant that can not only help you improve how you structure your PRDs according to best practices, but can also reference the relevant definitions, user problems, recent conversations, products that exist locally at your workplace, and so forth. The possibilities are almost unlimited, as long as you're willing to spend time thinking through the details and write good instructions (which are truly everything with this tool).

Notice how none of the above is particularly technical, or limited to a specific use case and/or function. If anything, even the PRDs example that I referenced is just that – an example – and instead, those could very easily be marketing documents, engineering specs, or any other kind of documents for that matter.

Using Claude Code in the terminal is also fairly user-friendly – one would benefit from learning how to parse some basic commands, and perhaps be prepared to run a few queries to install the relevant MCP servers, but for the most part, the workflow is not meaningfully more complex compared to the chat we are all now accustomed to. And yet, by embracing this new interface (meaning running AI bots in the terminal), you now gain the ability to do even more stuff with AI, and much more efficiently too. You might also be able to get rid of some of the more specialized AI trackers or applications that you are using for these use cases, because it now becomes easier to just manage them via this generalized workflow, which, in my book is always welcome (app / tool overload is always a problem these days).

Those are some of my initial thoughts, some of which might be trivial but I thought still worth sharing; I certainly hope I'll have more observations to share in the coming weeks. I've been experimenting with using Claude Code to both build some extended learning paths for myself around the topics I wanted to learn more about, and also trying to use Claude Code to help build a custom interface to enhance the experience of progressing through those learning paths. So, stay tuned for that if you're interested.

"I know I'm adding value, but I feel like my skills are being underutilized. Engineers and data scientists here can accomplish things without me, but I also feel I need to somehow carve out scope for myself. This means that I am either reduced to being a glorified project manager, or I have to take over some of the work that was previously done by folks in Engineering – and that is not always welcomed."

If this sounds familiar, you're not alone. Over the years, I've often heard this sentiment from folks changing jobs, especially when moving from small, scrappy startups to larger organizations. They arrive with a clear mental model for what being a good product manager entails, only to find their new reality looks nothing like their expectations.

It can be jarring, and it raises a curious question: if you were successfully doing PM work before, why does it sometimes feel like you're back to square one?

Being a "Product Manager" – what does this mean, exactly?

Here's the thing: "Product Manager" isn't a real job title. Well, of course it is – that's what your (and mine) offer letter said after all – but in reality, it is more akin to a collective moniker for a rather large set of dramatically different roles.

Having worked with startups and in big tech, I've come to believe this is a critical insight that eludes many. Having the right mental model for this becomes critical when choosing companies, evaluating roles, settling into a new job, or defining what success looks like for you.

On that last point, I'm not talking about performance reviews. What I mean is the internal scorecard we all keep, aimed to help answer questions like: "Am I doing good work?", "Am I growing?", "Is this what I expected?"

Two key dimensions

While there are countless ways to slice the PM landscape, two critical dimensions can help rationalize a lot of it.

First: your specialization

Being a UX PM at Airbnb is fundamentally different from being an API PM at Stripe. Shipping Instagram newsfeed features requires different skills than integrating Copilot into Office. A Growth PM's toolkit looks nothing like a Platform PM's.

Most people grasp this intuitively – they have a vision for the kind of PM they want to be and seek matching opportunities.

Second: company scale

This is where things get tricky, and if you're feeling confused about your new role, this dimension is probably the culprit.

The PM experience varies dramatically between early-stage startups, growth companies, late-stage pre-IPO firms, and mature organizations with thousands of employees.

When I say "big tech," I mean any mature company with complex organizational structures – Fortune 500s, large financial institutions, or tech giants.

Why scale matters

In larger, well-resourced organizations, the PM challenge fundamentally shifts. At startups, you can add value by implementing the textbook PM playbook: taking over customer interviews from busy founders, creating structure where none exists, filling obvious gaps in strategy, wearing multiple hats across entire product areas, etc.

The situation is often different at scale. Engineers and data scientists are great and comfortable in their seats; customer engagement processes already exist – they might not be ideal, but people make do; product strategy may be well-established, driven not by a dedicated product org but by multiple teams co-owning pieces; the list goes on. There is also often a lot of organizational context and complexity that accumulated over the years, as well as, unavoidably, politics.

The challenge isn't that your team needs you to save them – you might discover that they were doing fine without you. In this situation, success means finding (often non-obvious) ways to add value rather than filling obvious gaps, while you also take time to learn the ropes and make sense of the organizational setup and existing dynamics.

If this feels disorienting, that's normal – everyone will have to go through this adjustment.

Note that this works in reverse too. PMs who've spent years at large companies often assume their skills will easily transfer to startups, when in reality that kind of arrogance can be very dangerous – the ability to navigate complex org matrices doesn't necessarily prepare one for wearing five hats simultaneously while the company burns through runway.

Redefining success criteria

When you join a mature organization as a PM, your initial work might indeed look suspiciously like project management. This might feel disappointing compared to your past jobs, but it's expected. Treat it as par for the course and a necessary part of learning the new context.

Your value will come from learning complex context and history, taking time to understand the real (and often hidden) team needs, building relationships with numerous stakeholders, and identifying opportunities others have missed.

Instead of fighting for scope or enforcing rigid processes that teams operated fine without, the highest-leverage activities will include conducting proactive user research, building stronger customer relationships than anyone expects, creating partnerships with adjacent teams, and finding white spaces between well-defined territories.

It takes time – but then it will pay off, trust me.

What this means for your career

The fact is, the skills that made you a standout PM at a 50-person startup are going to be different from what makes you succeed at places like Google or Microsoft. If you're working at a startup that's on the right trajectory and you stick around long enough, you might get to observe some of this transformation as your startup grows from 50 to 5,000 people. But if you’re jumping from a startup to big tech, don’t expect a seamless transition – the role might look familiar on paper but feel quite different in practice, especially at first.

That's why I think it can be very helpful to internalize and reflect on both the functional specializations that exist within the product management discipline and the trade-offs that come with working at smaller high-growth companies vs. at large complex organizations.

Do this, and you will gain clarity on what to expect at each place. You will also start defining what success looks like for you in your job. And most importantly, you will get to set the right expectations with yourself, and hopefully gain some peace of mind – which can be critical in the disorienting early days of any transition.

Final thoughts

Back to the question I quoted at the beginning, my advice for anyone facing this dilemma is simple: relax and enjoy the ride. Your confusion is valid, and if you ultimately decide that a certain place or type of PM role isn't for you, that's okay.

In any case, it's good to experience different environments, company stages, and types of roles before figuring out what works for you, and what doesn't. Besides, what energizes you will likely keep changing throughout your career. You might also discover that certain environments simply don't work for you, regardless of excitement, compensation or prestige they offer – and that knowledge can be very valuable too.

Finally, if you're still deciding whether to take that offer, or considering if you should try something new, it helps to think through what you're optimizing for.

If it is money, mature companies will typically pay more, but your role might not quite match your expectations. If it's career growth, define what growth means to you – e.g., title, scope, learning – then proceed. If it's specific skills, different environments offer different lessons, so it helps to reflect on the types of places you can get the most concentrated learning experience at.

In many ways, the specifics of the answer itself matter less here than going through the thinking process required to arrive at one.

What's been your experience moving between different types of PM roles and companies? Shoot me a DM if you have a story to share.

A few weeks back, I had an interesting discussion with a friend — our conversation centered around the question of whom does (or perhaps should) a good manager / leader serve. This seemingly trivial question led to an interesting (& heated!) debate, by the end of which I was surprised to realize that my own perception of this topic had apparently shifted quite a lot without me realizing it, and what I would have considered to be the correct (& obvious) answer a few years back suddenly didn’t feel quite right.

That’s why I thought it would be good to put some of my thoughts on the topic on paper & share it here, in the hopes that it would also be useful to others.

Also, before we get started, let me say this: some of the things I’ll state might appear quite controversial — if you find yourself disagreeing with any of it, that’s totally ok — in fact, I would be very interested to hear from you what your thoughts on the topic are!

World as an optimization problem

Over the last couple of years, I got to work in a couple product areas that deal with the optimization problem.

From Wikipedia:

Optimization problem is the problem of finding the best solution from all feasible solutions.

Many business problems are ultimately optimization problems: for example, Uber trying to match drivers & riders in a particular area at any given time in the best possible way is one, trying to construct an optimal investment portfolio within certain constraints is also an optimization problem, and so on.

Typically, solving an optimization problem involves constructing an objective function that takes in all the necessary parameters & constraints and outputs the utility that can be achieved given these parameters & constraints, and then searching for a solution that maximizes said utility, within the set of possible solutions.

The reason why I’m bringing it up here is that a ton of questions we face in the real world can actually be represented as optimization problems. And, as with things such as matching riders & drivers in the most efficient way for Uber, the approach to answer those questions shouldn’t be any different. This means:

• First, we need to define what the right objective function is

• Next, we also need to figure out what the set of possible solutions looks like (e.g., what the constraints are)

• Finally, we need to figure out how to solve the optimization problem, e.g., how to find the right solution maximizing utility (this also involves ensuring that we are indeed finding the right solution, and not e.g., the local maximum)

Now, going back to the question of ‘whom should a good manager / leader serve’, it once again is all about solving the optimization problem (trying to figure out what’s the right answer that helps maximize utility, that can be defined as net present value of future profits, or some other similar metric) — and, as with any optimization problem, if you don’t make sure that you have the right objective function & understand the constraints correctly, chances are you’ll never find the utility maximizing solution (or, even worse, you might be optimizing for exactly the wrong things).

The most intuitive answer to the question of whom does a manager / leader serve seems almost laughably obvious: of course, your goal is to serve “the business” (which would also be consistent with using something like net present value of future profits — or other similar things, like average LTV, free cash flow, etc. — as the utility you’d be trying to maximize).

This was the position my friend was advocating for during our discussion. Again, this appears to be a very reasonable & in a way natural answer — the argument being, serving the business ensures that you are optimizing for the one thing that matters the most in the long run.

The tale of stakeholder capitalism

A few years ago, I would have wholeheartedly agreed with this assessment (with perhaps one minor adjustment: I’d substitute “business” for “shareholders” — but this is mostly semantics).

I still remember learning about stakeholder capitalism (stakeholder capitalism is the idea that businesses have a responsibility that extends beyond their shareholders) back in business school & vehemently disagreeing with it, since it felt like an attempt to replace one clear ‘master’ (shareholders) with many masters whose interests are often in conflict and can’t be easily untangled / prioritized, making the problem incredibly & unnecessary complex.

To be honest, I am still not a believer in the theory of stakeholder capitalism when it comes to deciding how to run companies. Shareholders are, and should be, the only ultimate master the company’s management should serve. Other stakeholders (employees, customers, etc.) are of course important, in the sense that without them, there would be no business — but that seems to be exactly the reason why they don’t have to be viewed & optimized for separately: focusing on the interests of the shareholders should ensure that the interests of other stakeholders are also accounted for.

That, of course, rests on the assumption that the company in question operates in a competitive market with robust regulations, so that if the shareholders decided that the best strategy was to be exploitative towards either their workers or their partners/customers, then other players operating in the same space would over time eat away at that company’s business, until the company in question chose to reverse course (or went out of business). Now, in case of monopolies / poorly regulated markets, the situation would be quite different — but then, instead of proposing embracing the concept of ‘stakeholder capitalism’ to ‘fill in’ for the government, the government (and, by extension, the voters) should work to break up true monopolies & beef up regulations where necessary.

This way, all companies operating in the space would face the same rules — whereas calling on individual companies to embrace ‘stakeholder capitalism’ feels a bit like asking companies not to leverage legal tax loopholes: even if you personally chose to do that, some of your competitors surely wouldn’t, and as a result, it would ultimately just help shift the balance away from the responsible market participants and towards the exploitative ones, which won’t be good for anyone.

The reason why I am bringing the concept of stakeholder capitalism up here is that while I don’t believe it’s a very good idea in the context of running companies, I feel the ideas that it advocates for become a lot more useful in the context of being a manager / leader (but not the CEO!), and trying to figure out what you should be optimizing for.

To elaborate on this, when you are a CEO running a company operating in a large & competitive space, acting in the best interest of shareholders should be sufficient, since there is the market to take care of the rest, including situations where the shareholders’ demands for some reason become irrational — worst case scenario, the company goes out of business, thus punishing stupid shareholders & rewarding smarter shareholders with stakes in the competing firms; and if the CEO disagrees with the shareholders, they should really quit & go work elsewhere, which should be another way to maintain balance in the market.

Now, however, let’s consider a case where you’re a manager for a particular team, e.g., at a big tech company (I’ll focus on tech, since this is the industry I work in & am most familiar with — most of what I say below should be generalizable to other industries too though). It can be a small team (e.g., you’re a line manager, also known as M1), or perhaps it’s a rather large team (e.g., you’re M2 or M3 — in other words, there are other managers who report to you) — but ultimately, you’re still a small-ish cog in a very big machine, so there is plenty of management layers above you, and also tons of other teams & products in other parts of the company.

In this case, your immediate stakeholders include:

• Your team (both those who report directly to you, and their reports)

• A few partner teams that you work most closely with / have dependencies on

• Your org (e.g., your product division, etc.)

• Your customers

You could perhaps also argue that the ‘business’ (i.e., the company and/or the shareholders) should also be counted as your stakeholders, which brings us to the crux of the debate: is the ‘business’ really your stakeholder in such a case, and can you truly serve it as a manager / leader?

As you might have guessed by now, I would argue that the answer is ‘No’. That’s not to say that you shouldn’t think about the business (quite the opposite) — but for a small cog in a large machine, the ‘business’ in a traditional sense isn’t necessarily something you could possibly serve directly, and trying to do so would often do more harm than good.

Let me illustrate this with a few practical examples, which would hopefully help make this claim a bit less controversial.

”I lead, my team follows” fallacy

A version of this use case is what actually originally prompted the debate I had with my friend.

Without focusing on specifics, my friend had quite a lot of success building/scaling a couple of tech products/businesses in the past (not as an independent founder, but rather as a manager/leader in a large corporation — this part is important). They (just using a gender-neutral pronoun here - it’s still one person I’m talking about) also did it in a market that was markedly different from the U.S., both culturally, and in terms of the number of opportunities available to talent there. This in turn lead them to acquire a management philosophy where, for the lack of a better way of putting it, the leader knew best (optimizing to serve the business), and the team gladly followed, as long as the leader served the interest of the business.

On the surface, this doesn’t sound particularly problematic. In reality though, I am strongly convinced that if you were a manager/leader at a big tech firm in the U.S., following this mentality could be disastrous, for a fairly simple reason: you would likely lose all your top employees very quickly with this approach.

Why would this approach, that clearly works, albeit in a different geography, fail here in the U.S.? The answer mostly has to do with the culture of big tech in the U.S., as well as the differences in the job market’s structure & liquidity.

Culturally, most of big tech (and also many of the top-tier startups too) value the ability to think independently & be capable of solving ambiguous problems on your own. You do, of course, still have managers & some of the strategy inevitably has to be set top down — but ultimately, there is an expectation your manager will mostly coach you, rather than dictate you what to do. I’m sure there are some exceptions to this rule, but all the places / teams I worked on so far were like that, esp. at higher levels of seniority.

Second, the U.S. job market in tech is large & highly liquid (well, perhaps not so much at the moment — but surely in the long run). This means that people don’t have to tie their future to the wellbeing of a single company, and can instead focus more on their own goals & careers. The result is, people might often prefer to work at a place that provides them with flexibility to experiment, make mistakes & iterate (and ultimately learn from that experience), versus having to follow an authoritarian leader who might very well know better, but would stall their development.

This is also the reason why companies might sometimes keep producing great talent long after their heyday (Yahoo comes to mind as the most obvious example) — and vice versa, why other firms that are very successful as a business aren’t always going to be known as a great place to acquire useful skills/experience from the employees’ perspective.

The obvious question to pose here is: if the leader in question is truly capable & knows what’s best for the business, won’t it be worth for the employees to stick with them for the ride, and eventually be compensated in other ways (e.g., through promotions / higher pay / etc.)? Remember the famous phrase credited to Eric Schmidt, “If you’re offered a seat on a rocket ship, don’t ask what seat. Just get on“? This idea seems to fit nicely with the narrative of a visionary manager / leader who truly does know what’s best.

The nuance here, of course, is that, as mentioned before, we are talking about a manager/leader here who is still just a part of a much larger organization. This is a critical point: if we were talking about a startup founder and/or the CEO of a large firm, the situation would be different, since in that case, they would have the necessary autonomy to determine the right compensation model/culture/etc. As a manager at a large established firm though, you don’t have leeway to change those things: leveling & pay are typically set for the entire firm and can’t easily be changed for a single part of it, and so on.

So, as a leader in this context, you won’t have the necessary levers to compensate your team for what would likely be perceived as a negative change in culture (due to the loss of autonomy, if nothing else) — and as a result, if you choose to go ahead, hoping that your team will come to realize that you do indeed know better, you will likely fail & you will do so for a very simple reason: in your attempt to maximize utility (‘serve the business’), you didn’t correctly account for the constraints.

Don’t underestimate the power of constraints!

In the same vein, you are very likely to face similar issues if you choose to ignore other types of constraints that tend to exist in such environments, such as organizational culture, the existing alignment of various teams within the company, the political nuances of the place, and so on.

For instance, the priorities of your business might matter very little to the partner teams you depend on (and sometimes for good reasons too); trying to change the culture too fast & too drastically can in fact damage the morale of the employees beyond what can be justified by any business gains; long-term benefits of maintaining a less than ideal org structure (e.g., having two teams with somewhat overlapping charters) for a while might outweigh any gains you stand to reap from rushing ahead to streamline it (since you’d risk losing good employees who get frustrated in the process) — the list goes on.

In other words, as a manager/leader, you truly do have to resort to the ideas & principles of the ‘stakeholder capitalism’ here to maximize your gains, even if on a micro, rather than macro, scale.

Make sure you have both the right objective function & the constraints

Hopefully, the above examples help illustrate my point to a sufficient degree here. Does a good leader has to care about, and in a way, serve the business? Of course! But at the same time, a manager who tries to ignore the broader context of the org & the constraints they have to operate in, and instead just focuses on trying to build & scale their business first, is quite unlikely to succeed — and in a way, I’d argue that such a leader isn’t actually doing a job they were hiring to do very well, even if they somehow manage to do right by the business for a while.

That last point might be worth spending a bit more time on, and I’d like to use another example to illustrate this.

At one point, it was quite popular to frame the job of Product Managers as being “mini-CEO” or “CEO of the product”. I feel that framing is a lot less popular these days, and for a good reason — while it might not be a bad idea for a PM to assume the “CEO of the product” mindset if it helps them think about the product & the business holistically, in many other ways such framing is going to be by definition flawed: similar to what we discussed above, PMs operate under a large number of organizational constraints that are completely beyond their control (culture & pay, broader organizational priorities, the structure of the sales org, and so on).

Failing to understand those constraints, or worse, trying to ignore them, can be disastrous & certainly won’t lead one to success, and the same applies to most types of management jobs out there, including those that have nothing to do with Product Management (which just served as a convenient example here).

Conclusion

To sum it up, upon some reflection, the question of whom does (or should) a good leader serve seems a lot more multifaceted to me from where I stand today than I would have expected.

It also provides a great illustration of some of the benefits (and also dangers) of trying to turn real-world problems into mathematical abstractions: do it right, and you have an extremely powerful instrument to analyze the world with — but do it wrong, and your view of the world risks becoming dangerously one-dimensional.

Hopefully, this article has provided for some entertaining & thought-provoking reading! As always, if you have any feedback you’d like to share, or more thoughts on the topic, please let me know in the comments section below!

• We are now on the verge of achieving AGI (Artificial General Intelligence), and that’s good/bad/extremely dangerous (my opinion: achieving AGI with current tech is very unlikely)

• ChatGPT & other LLMs (Large Language Models) are awesome, and we’ll soon see many aspects of the human experience completely redefined by it (my take on this: we probably will, although perhaps in a less dramatic fashion that some are predicting, at least in the short-term)

• ChatGPT trustworthiness & thus by extension usefulness are very low & because of this, ChatGPT & GPT-4 can be dangerous (my take: while the point about trustworthiness isn’t untrue per se, it feels that this position is overly pessimistic & is missing the point regarding the advantages a well thought-through usage of these tools can bring)

To be fair, most people aren’t necessarily taking extreme positions one way or the other, and there is certainly a lot of acknowledgement of the amazing progress ChatGPT & other LLMs represent. Still, it’s interesting to observe these extreme reactions, because in a way, you can view those as an ultimate testament to the fact that these tools are blowing many of the previous expectations out of the water, and are causing understandable cognitive dissonance as a result.

With this post (or, rather, what I’m hoping will become a series of posts), I intend to leave the esoteric debate about whether LLMs like GPT-4 represent an existential threat to humanity to all those already engaged in it (and it’s a very lively debate — if you don’t believe me, just check out Twitter these days!).

Instead, I’d like focus on describing my own (ongoing) experiments with GPT-4 & ChatGPT, in the effort to figure out the answer to a much more mundane question — namely, whether this tool can be put to a good use by the product managers (& perhaps others too) today, to help increase their productivity / unlock new use cases.

Please note that while my declared focus here is on Product Managers (since I’m one myself, and hence, this is what’s top of mind for me), in reality, a lot of things I am going to cover should be relevant to a lot of other people working in technology (& likely other industries too).

With that said, let’s dive in!

Today’s topic: Designing A/B experiments with the help of ChatGPT

Below, I’m going to share a series of prompts I submitted to ChatGPT, as well as ChatGPT’s responses (some edited for brevity). Then, I’m going to discuss the significance of this example as I see it, as well as the reasons why I think this type of stuff can be extremely useful to PMs (and a lot of other folks too).

Note that with these prompts, I was trying to emulate the PoV of a relatively inexperienced PM who wanted to run an A/B experiment, and was trying to learn more about the right way to set it up, and also how to analyze the results & explain them to others. This example is obviously a simplification of any real-world scenario, but I believe in many ways, it’s a very good illustration of what ChatGPT can do for you as a PM.

Me: Imagine we are running an A/B experiment trying to increase user engagement. We have around 10,000 users per month on average, using our product for 15 minutes a day. What would be the minimum detectable increase in engagement, assuming we want to get an 0.05 stat sig level from our experiment?

ChatGPT: To calculate the minimum detectable effect (MDE) in an A/B experiment, you need to provide the desired statistical power (e.g., 0.8 is a common choice), among other things. Also, you need to determine the proportion of users assigned to each group (e.g., 50% to the control group and 50% to the treatment group).

Me: What’s the definition of statistical power?

ChatGPT: Power is often denoted by the symbol "1 - β", where β is the probability of a Type II error, which occurs when the null hypothesis is not rejected even though the alternative hypothesis is true. A higher statistical power means a lower chance of committing a Type II error.

In most research settings, a power of 0.8 (or 80%) is considered adequate. This means that there is an 80% chance of detecting a true effect or difference if one exists. A higher power, such as 0.9, would provide even more confidence in the results but might require a larger sample size or a stronger effect to achieve.

Me: What's the definition of Type I & Type II errors?

ChatGPT: Type I and Type II errors are two types of errors that can occur in hypothesis testing.

A Type I error occurs when the null hypothesis is rejected even though it is actually true. This means that the researcher concludes there is an effect or difference when there is not one. The probability of making a Type I error is denoted by the symbol "α" and is typically set at 0.05 or 0.01.

A Type II error occurs when the null hypothesis is not rejected even though it is actually false. This means that the researcher fails to detect an effect or difference when one exists. The probability of making a Type II error is denoted by the symbol "β" and depends on the sample size, effect size, and statistical power.

In hypothesis testing, the goal is to minimize both Type I and Type II errors. However, reducing one type of error often increases the other type. The balance between the two types of errors is determined by the statistical power, sample size, effect size, and significance level.

Me: So, type I error is essentially false positive, and type II error is false negative, right?

ChatGPT: Yes, that's correct. A Type I error is equivalent to a false positive, meaning that the researcher concludes there is an effect or difference when there is not one. A Type II error, on the other hand, is equivalent to a false negative, meaning that the researcher fails to detect an effect or difference when one exists.

Me: So, with power of 0.8 & statistical significance of 0.05, I'll be making Type I error in 5% of cases & Type 2 error in 20% of cases on average, correct?

ChatGPT: [some back-and-forth (it initially misinterpreted what I said, and said ‘No’, but after some clarifications, it eventually arrived at the ‘Yes’ answer].

Me: Ok. Now assume I want to go for 0.01 significance level with the same sample size. How does it change power level calc?

ChatGPT: If you want to decrease the significance level from 0.05 to 0.01 while keeping the same sample size and effect size, it will result in a decrease in the power of the test. This is because a lower significance level means that the researcher is setting a higher bar for rejecting the null hypothesis, which requires a larger effect size or a larger sample size to achieve the same level of power.

To calculate the new power level, you would need to perform a power analysis based on the revised significance level and other relevant parameters such as the effect size and sample size. However, as a general rule of thumb, reducing the significance level from 0.05 to 0.01 may decrease the power of the test from 0.8 to around 0.6 or 0.7, assuming all other things are held constant.

Therefore, when considering changing the significance level, it is important to carefully consider the trade-offs between the risk of making Type I and Type II errors and the available resources, such as the sample size and effect size.

Side note: everything above was generated by GPT-3.5 (rather than the latest GPT-4). The reason for this is rather mundane — I simply ran out of ‘credits’ to use GPT-4 when I was experimenting with these prompts (even with a subscription, GPT-4 today is still being severely throttled, to accommodate all that demand, so you can only send it around 25 prompts every 3-4 hours).

Up until this point, GPT-3.5 did a good job though, so I didn’t feel the need to switch to GPT-4. However, for the subsequent prompts, where I asked it to generate me some numbers, GPT-3.5 surprisingly struggled, making undeclared assumptions & performing incorrect calculations, despite listing the right formulas (this part in particular was very surprising to me).

So, I decided to go back to GPT-4 & test if it can do a better job. It did, so all the prompts you see below are from GPT-4.

This also highlights certain limitations of ChatGPT today one has to be aware of, that I am going to discuss at the bottom of this post, once we are done with this example.

Me: Ok, now let's go back to the original question.

Assume we are running an A/B experiment trying to increase user engagement. We have around 10,000 users per month on average, using our product for 15 minutes a day on average. What would be the minimum detectable increase in engagement, assuming we want 0.05 stat sig level? Assume the split of 50/50 between treatment & control, and 0.8 power level.

ChatGPT: Let's calculate the minimum detectable effect (MDE) for your A/B experiment using the provided information:

• 10,000 users per month on average

• 15 minutes of usage per day on average

• 0.05 statistical significance level (alpha)

• 0.8 power level

• 50/50 split between treatment and control groups

Since the standard deviation (SD) was not provided, I'll provide MDE for a range of standard deviations (1, 2, 3, 4, and 5 minutes).

1. Determine t_alpha/2 and t_beta:

   1. t_alpha/2 = 1.96 (for a two-tailed test with alpha = 0.05)

   2. t_beta = 0.84 (for a power level of 0.8)

2. Calculate the required sample size (n) for each group:

   1. Since there are 10,000 users per month and a 50/50 split between treatment and control, there will be 5,000 users in each group

3. Re-arrange the formula to solve for MDE and plug in the values for different standard deviations (SD): MDE = sqrt((t_alpha/2 + t_beta)^2 * (SD^2) / n)

   1. SD = 1 minute: MDE = sqrt((1.96 + 0.84)^2 * (1^2) / 5000) MDE ≈ 0.062

   2. SD = 2 minutes: MDE = sqrt((1.96 + 0.84)^2 * (2^2) / 5000) MDE ≈ 0.125

   3. SD = 3 minutes: MDE = sqrt((1.96 + 0.84)^2 * (3^2) / 5000) MDE ≈ 0.187

   4. SD = 4 minutes: MDE = sqrt((1.96 + 0.84)^2 * (4^2) / 5000) MDE ≈ 0.250

   5. SD = 5 minutes: MDE = sqrt((1.96 + 0.84)^2 * (5^2) / 5000) MDE ≈ 0.312

Here are the minimum detectable effects for different standard deviations:

• 1-minute SD: MDE ≈ 0.062 minutes per day

• 2-minute SD: MDE ≈ 0.125 minutes per day

• 3-minute SD: MDE ≈ 0.187 minutes per day

• 4-minute SD: MDE ≈ 0.250 minutes per day

• 5-minute SD: MDE ≈ 0.312 minutes per day

These values represent the minimum detectable increase in engagement for each specified standard deviation, given a 0.05 statistical significance level and a 0.8 power level.

Me: But isn't the duration of the experiment supposed to play a role here as well? (e.g., whether we run it for 1 day, vs. 1 week vs. 1 month)

ChatGPT: You are correct; the duration of the experiment plays a role in determining the minimum detectable effect.

In my previous calculations, I did not account for the duration of the experiment. To account for the duration of the experiment, we need to adjust the sample size (n) to represent the number of user-days in each group rather than just the number of users.

Assuming you have 5,000 users in each group and you run the experiment for a certain number of days (d), the adjusted sample size (n') is: n' = n * d .

Now we can use the adjusted sample size to calculate the MDE:

MDE = sqrt((t_alpha/2 + t_beta)^2 * (SD^2) / n')

Let's consider three different experiment durations: 1 day, 1 week (7 days), and 1 month (30 days).

1. Experiment duration: 1 day:

   n' = 5000 * 1 n' = 5000 ,

   MDE = sqrt((1.96 + 0.84)^2 * (1^2) / 5000) ,

   MDE ≈ 0.062

2. Experiment duration: 1 week (7 days):

   n' = 5000 * 7 n' = 35000 ,

   MDE = sqrt((1.96 + 0.84)^2 * (1^2) / 35000) ,

   MDE ≈ 0.023

3. Experiment duration: 1 month (30 days):

   n' = 5000 * 30 n' = 150000 ,

   MDE = sqrt((1.96 + 0.84)^2 * (1^2) / 150000) ,

   MDE ≈ 0.010

Here are the minimum detectable effects for different experiment durations:

• 1 day: MDE ≈ 0.062 minutes per day

• 1 week: MDE ≈ 0.023 minutes per day

• 1 month: MDE ≈ 0.010 minutes per day

As the duration of the experiment increases, the MDE decreases, making it easier to detect smaller changes in user engagement. This is because the larger sample size (more user-days) provides more statistical power to identify smaller effects.

Why I believe the above is awesome

What are your first thoughts, seeing the series of prompts above & the answers that ChatGPT generated? Let me know in the comments section below!

At the first glance, I can imagine how the exchange above might not strike everyone as anything particularly special (beyond the fact that you can have an actual productive dialog with ChatGPT, which, of course, is incredible on its own).

Here are some of the reasons why I think it’s awesome though:

• Understanding the intuition behind applied statistics isn’t easy; explaining it to others is even harder — as shown above, ChatGPT can be extremely helpful with both these tasks

  • To be more specific, you wouldn’t believe how many folks I encountered who didn’t understand the concept of the minimum detectable effect — including people who had to make business decisions based on the experiments’ results

  • That’s why being able to clearly articulate the point, especially to less technical folks, can truly go a looooong way

• Beyond just communicating the details on the setup of your experiment to others, I am hoping the above clearly demonstrates the value of ChatGPT as a learning tool — you can ask it questions, dig deeper, refine the task, and so on

• You can also get ChatGPT to perform fairly complex back-of-the-envelope calculations for you, which can be very helpful both for understanding the nuances of A/B experimentation better, and getting some talking points to share with others

Some important limitations of ChatGPT today

As I mentioned above when I was describing the prompts & ChatGPT answers, ChatGPT today certainly isn’t flawless.

In particular:

• It’s prone to making assumptions without always clearly communicating what those are (this seemed to be particularly true for GPT-3.5, and a bit less of a problem with GPT-4)

• ChatGPT can ‘hallucinate’ in certain instances, meaning it would make things up — and oftentimes, these things will sound quite plausible too

  • This problem is currently being actively discussed / researched, and is one of the key reasons people (correctly) question the trustworthiness of GPTs & other LLMs

• As I discovered while running a series of prompts for this example, you cannot automatically trust ChatGPT calculations either, even when it has the right formulas — it can still make mistakes

Are those limitations significant? Well, yes & no.

The propensity of ChatGPT (& other LLMs) to hallucinate certainly poses challenges (e.g., integrating those models into search can be quite tricky, since the quality & trustworthiness of response matters a lot there).

At the same time, if you are using ChatGPT to explore a topic you’re generally familiar with (and thus can notice & call out suspect info, as well as check calculations, etc.), I feel ChatGPT can be extremely useful in a variety of ways:

• It can be a powerful tool to help you refresh your memory on the topic & learn more about it

• It can also be a great productivity-enhancing tool, allowing you to quickly prototype & explore things (example above certainly falls into this bucket)

• Finally, it can help you find better ways to explain the nature of the problem, nuances around it & your results to others

Conclusion

As I mentioned before, this post is just the first one in a series of articles exploring how we can make use of ChatGPT & other LLMs in our daily lives / work.

It’s not often that we get to witness the emergence of this kind of revolutionary technology, and, as is often the case with such advances, the difference between embracing it early on (& thus enhancing your own productivity), vs. burying your head in the sand & pretending nothing has changed, will likely be pretty stark in the long run.

From my early experiments, I believe ChatGPT can be extremely useful for PMs & many others, so I plan to cover various scenarios it can be used for over time, and would love to hear about the ways you’re using it as well!

Hopefully, this was helpful! And, as always, if you have any feedback you’d like to share, let me know in the comments section below!

I am really interested in the field of Product Management. However, I keep hearing that Product Managers spend most of their time working with Engineers/Data Scientists, and generally need to be quite technical. Is this actually true? My background is in X, and I don’t think of myself as a very technical person, so this keeps me worried.

This is one of the most commonly asked & perhaps the most misunderstood questions about careers in Product Management. I’ve previously discussed a few aspects of this as part of the Q&A: Building A Career In Product Management, but I thought it’d be good to explore this topic in more detail.

I want to begin with a short & definitive answer to this question. The answer is a resounding ‘No’, you absolutely don’t have to be technical to be a successful PM.

That being said, there are a lot of nuances to unpack here, so let’s dig deeper.

What type of a PM do you aspire to be?

First of all, it’s good to have at least some idea of what kind of a PM you want to be. This includes a few things, such as:

• Industry focus: e.g., are you interested in financial services, cloud, productivity tools, marketplaces, etc?

• Target audience: do you want to work on B2B vs. B2C vs. B2G products?

• Functional specialization as a PM: do you aspire to be a Data PM, vs. Growth PM, vs. UX PM, vs. Platform PM?

It should probably feel intuitive that the level of technical depth needed to be an ML PM working on building productivity-enhancing tools for developers (e.g., something like GitHub Copilot) will be quite different from a UX PM working on consumer-facing part of a B2C marketplace (e.g., Airbnb).

More specifically, however, there are two aspects that matter the most here, namely:

1. You need to be capable of understanding (& being able to clearly articulate) the technical details & context at a level that would matter to the end user/customer;

2. You need to be capable of navigating the technical aspects of the product you are working on insofar as there are product decisions that depend on those.

As long as you can meet the bar for both of these requirements, you’ll be fine.

What exactly does it mean? A real-life example

To give you a concrete example, I’ve spent a few years at Microsoft building deep learning-powered enterprise search for SharePoint (you can learn more about my personal journey here, or on LinkedIn, if you’re interested).

In that role, it was critical to understand the general capabilities & limitations of the underlying tech, since a) that’s what the customers cared about, and b) you needed to understand those in order to make product decisions on what to focus on, etc.

That meant learning about things like vector encoding & NLP ML models, how search retrieval works, search ranking basics, etc., as well as learning how to set up, run & analyze the results of the experiments, and so on.

What that job didn’t require, however, was knowing all the details about models’ evolving architectures, the details of how search back-end infrastructure was set up, knowing what the key codebases were, etc. In fact, getting too involved with decisions concerning any of the above would probably have been a very bad idea, even if you had had a natural inclination/interest in those areas — the main reason being, the latter were the areas in the purview of Engineers/Data Scientists that primarily required sound Eng/DS decision-making (and Microsoft certainly had the top-tier talent to make those decisions — as do other big tech companies & many startups), whereas the former areas shaped the product & thus depended on PM input.

Prioritization is always key for PMs, as is the ability to acknowledge when your input isn’t needed and trust your engineering partners to make the right choices. That’s not to say that you shouldn’t be involved at all in the areas primarily owned by your Eng/DS counterparts (it’s always good to learn about those, etc.) — but if you think you can make better decisions than your engineers on things like how to design & train an ML model, architecture choices, etc., chances are, either things are very broken at your company/division/team, or you don’t really understand the point of your role as a PM, and will only get in the way of your Eng/DS team & frustrate them to no end by doing so.

Going back to the question of how technical you need to be, the things mentioned above in my example (understanding how vector encoding works, how search retrieval works, search ranking basics, how to run & analyze experiments, etc.) that you’d need to know & have opinions about in order to add value as a PM on such a product certainly fall into the ‘technical’ bucket.

At the same time, those aren’t things that require a deep technical background — you only need ‘101/201’ knowledge for most of those topics, which can be easily picked up from a few online classes / books (and practice!)

That’s not to say that, for instance, having a technical undergrad won’t be helpful — it certainly will be — but not having it doesn’t have to be a disqualifying factor.

In fact, in my case, I credit most of the practical knowledge I have to either the online classes / books, or to the classes I took in business school (which, ironically, was a lot more useful for e.g., learning applied statistics & the intuition behind it, than my 5-year combined MSc/BSc in Math ever was).

And, of course, learning on the job is a big part of it too — Product Management in general requires continuous learning, and so you should be ready for (and hopefully excited about) that.

Different flavors of PM jobs come with (very) different requirements

To re-iterate, the types of skills you’ll require as a PM will vary widely depending on the type of PM you want to become, the surrounding context, etc.

The example above highlights that to be a PM on a highly technical product, you will indeed need to acquire some technical skills. Still, I hope it also conveys the point that even if you want to work in a product area that is widely regarded as being quite technical, the lack of formal technical background doesn’t have to be an issue you can’t get past. Instead, you can gain most of the necessary knowledge on your own, and the level of depth you need to get to should be achievable for anyone sufficiently interested in the field, and with a bit of time on their hands, within 3-12 months (depending on where you start / how much spare time you have), regardless of their previous background (note that I am, of course, assuming that anyone interested in PM roles possesses a certain level of raw intelligence expected of a successful college graduate here).

For a lot of other types of PM roles, having technical background would be even less important or useful, compared to some of the other skills (e.g., knowing how to do user research, understanding the nuances of scaling a product, etc.) — in which case, you should focus on identifying, and fixing, the gaps in your knowledge / experience wrt those, instead of trying to become more technical just for the sake of it. That’s especially true if you believe you don’t possess good communication or writing skills, in which case, I’d suggest prioritizing working to improve those above everything else, since without those skills, even if you somehow get a job, it’ll be very hard for you to survive & thrive on the job.

Where are you in your career?

In one of my previous posts (Breaking into Product Management: key 'entry points' into the field), I discussed various common entry points into the field of Product Management.

Perhaps a bit ironically, the timing of when you decide you want to become a PM can have an outsized influence on how important (or not) being technical is going to be.

Associate Product Managers

One of the common entry points into the PM field these days is becoming an Associate Product Manager right out of college, and growing as a PM from there.

At that level, companies are mostly looking at smart, driven individuals with good fundamental education that they can teach how to be great PMs.

Obviously, as a new grad, you don’t have any ‘specialization’ yet — and that’s completely fine from the APM programs’ perspective since those programs are looking for people who can be trained as generalist PMs first (and then in a few years, some might develop a specialization, while others might remain on the generalist PM track).

Note that APM programs can be very competitive. So, if you pose a question of whether having a CS degree from Stanford can help you get hired as an APM at Google, the answer is going to be ‘yes, of course’.

But again, remember, those programs are not bringing you in for your specialized skills — and also, people who run them are very much aware of all the different types of PM roles (& the corresponding skills those require) that exist.

What this means is that in every APM class, you probably see people from a wide variety of backgrounds: some will have Engineering majors, while others will come from Econ, Business, or Liberal Arts backgrounds (even Google in its heyday of focusing on PMs being technical used to periodically hire people with BA in Philosophy, and similar degrees, as APMs).

Overall, I am going to argue that being technical is absolutely NOT a prerequisite for joining an APM program right out of college.

Joining Product Management field as an experienced hire

Compared to joining an APM program out of college, the situation becomes a bit different if you are trying to break into Product Management as an experienced hire.

At this stage, you are inevitably competing against people who already have several years of PM experience under their belts — and so, it becomes important to prove that you can do the job well, as well as to demonstrate a clear interest & commitment to the field you’re trying to break into (by field here, I don’t mean Product Management in general, but rather something a bit more nuanced — e.g., you want to be a PM for FinTech products, etc.)

Depending on the product/area you’re vying for, this can mean that having technical background / demonstrating technical proficiency can become a good differentiating point.

As mentioned, it’s likely that you’ll be competing against at least some experienced PMs at that level. Chances are, however, that some of those folks will have functional experience, but not area-specific experience (e.g., they worked as a PM before, but in a different product area). If that’s the case, you can demonstrate your interest & commitment by taking extra steps to acquire some area-specific knowledge.

Above, we discussed that a lot of PM jobs don’t require you to be technical in general; this remains true, so if you are after UX-focused or Growth PM roles, it’s unlikely that learning how to code or learning about ML would help you there. Similarly, it’s possible that you already have some useful skills from your prior jobs that would be useful & allow you to differentiate yourself from the competition.

That being said, I’d argue that for experienced hires, the benefits of becoming at least somewhat technical are higher than for e.g., college hires, if only because many non-technical people won’t be focusing on that & also because it can be a good way to demonstrate your commitment to the field of your choice.

Here, I’ll again use a personal example as an illustration. After graduating from business school, I originally joined a 1-year rotational program in Microsoft Azure’s Product Marketing. After 6 months, I knew that I wanted to transition to Product Management though, so I took a few online courses around AI/ML to develop some basic understanding of technology and tried to build a few simple things / wrote some articles of my own.

While none of these activities made me particularly proficient with AI on their own, they served as a very useful demonstration of my interest in the field. I then used that to network my way around Microsoft, scheduling informal coffee chats with various hiring managers working on AI products, until I found a team that was willing to interview me & ultimately extended me a job offer.

The interesting — and often overlooked — nuance here is that even for experienced hires looking to become more technical, the bar to do so doesn’t have to be set too high. In many cases, taking a few classes, or reading some articles / books might be sufficient to get a basic understanding of the space, after which you can leverage that newly acquired knowledge to start having discussions with various folks working in the field, and hopefully, eventually, find your way in (and then continue learning on the job).

And as for the folks with completely non-technical backgrounds, taking the effort to do some of the above (or perhaps going beyond that & taking a few college classes or doing a Master’s at some point, if you want to go all the way in) can be even more impressive & can often provide you with an excellent & durable differentiating factor. In my career, I’ve encountered quite a few people who studied things like English Literature at college and are now working as PMs at top-tier tech companies, and I can tell you from experience, that people around are always impressed by those examples, and can certainly appreciate the effort & determination it takes to make a hard turn in one’s career.

The key point here is this: as an experienced hire looking to break into the field of Product Management, you still don’t have to be particularly technical — but spending time learning the space & acquiring some technical skills can go a long way to help you prove your interest & ultimately secure a job.

Summary

To re-iterate, the answer to the question ‘Do you need to be technical to be a PM?‘ is most certainly ‘No, it’s not a hard requirement’.

So, if you’re currently a sophomore in college who has a vague interest in Product Management as a career, but you aren’t sure if you are ready to commit to a CS major, that’s perfectly ok. There is more than one path to becoming a PM, and while having a CS degree will certainly help, a person with a degree in Liberal Arts but also a genuine interest in technology (which can be demonstrated in a variety of ways), great communication & writing skills, and a bit of persistence, will likely have an easier time recruiting for PM jobs, compared to someone who believes that just having a CS degree from a top-tier school automatically entitles them to a job in the field.

Similarly, if you’re looking to break into Product Management space as an experienced hire, you don’t need to go back to grad school for an MSc in Computer Science/Statistics/etc. Rather, your time will be better spent on assessing your strengths & weaknesses, thinking through why you want to become a PM & what types of products you want to be a PM for, and then focusing on showing a clear interest in your chosen area (filling in specific gaps as needed — which might, or might not, have anything to do with technical skills) & networking your way in.

If you’ve been previously wondering if being technical is a critical condition of becoming a PM, hopefully, this post helps alleviate your concerns a bit and also provides you with some food for thought.

And as always, if you have some anecdotes from your personal experience or any other feedback/questions you’d like to share, let me know in the comments section below!

For reference, you can learn more about my personal journey here, or on LinkedIn.

Q: What’s more important / more effective for career progression: getting better at interviews, or becoming a better PM?

A: I don't think this has to be 'either / or' choice — instead, you should focus on getting better at both. Good interview performance won't be worth much if you can't do the job after you are hired, and vice versa, staying at one company for too long trying to exclusively focus on becoming a better PM can harm you in terms of both the speed of career advancement & the learning curve (switching teams / companies can be quite important to keep learning).

Q: In which domains did you work in your career, and were your roles primarily B2B or B2C?

A: I worked on both the B2B & B2C products at various times in my career. Domain-wise, I’ve always worked as a PM for technical products & my work usually revolves around AI/data/optimization problems of various kinds.

My general take, however, is that while it's important to develop some level of specialization over time, you don't have to go too narrow as a PM, especially at the beginning. In fact, doing so might harm you in the long run, and so it's good to seek a variety of experiences over your PM career.

So, if you are interested in AI or data, you can absolutely make it your focus (and benefit from having that sort of specialization) — but don’t go more narrow than that, and also make sure to try out different types of products/ environments, if you can.

Q: Is there a level / compensation amount that you would want to stop at?

A: I believe for a lot of people (myself included, at least for now), L6 & L7 are that sweet spot (using Google leveling ladder for reference here; if you want to learn more about how leveling in tech works, check out my previous post on this topic: Levels in Tech: how to make sense of them).

At those levels, you will typically make $500k-$900k TC at top-tier companies in the U.S., while keeping a sane work/life balance (that often deteriorates beyond those levels) & staying 'close to the ground', where you are either still an IC or are an M1 manager (which can be important if you actually love doing product work, and don't want to move to a pure people management track).

That being said, those things are rarely static, and what one wants to do at 2 YoE vs. 10 YoE vs. 25 YoE can change quite a lot.

Q: How did you find a role that is a good fit for you? Also, what is a good recruiting strategy in the current market for someone with few connections to other tech PMs?

A: The current market is indeed a challenge, there is no way around that, unfortunately. There are still jobs out there (e.g., at startups), but for many people, the best strategy might be to wait it out until the market improves (or at least not to get discouraged if you can't get offers in this market).

As for the rest of it, my advice to people is always to apply wide (like, really wide, 50+ companies wide) & see what happens. That's what I personally always do every time I choose to change companies, and it has always worked out so far.

Also, in my opinion, it's no good to stress too much about fit until you have offers in hand. You might think that a particular job is a perfect fit for you, and still get rejected without interview, simply because tech recruiting is both random & unpredictable to a significant degree. Conversely, if you apply wide, you might get offers for teams/products that you didn't even know existed, and some of those might turn out to be a great fit for you.

Lastly, I don't think connections with other PMs are too important. Assuming you're already working as a PM, you can just start applying to positions you’re interested in (again, making a mental note that currently we have a bad job market, so you might have to adjust your expectations accordingly). Referrals are always useful, if you can get them. Also, if you can figure out how's the hiring manager is for a particular job, reaching out on LinkedIn to introduce yourself & have an informal chat is often a good strategy.

But above all, always apply wide!

Q: Can you describe the interview process at Two Sigma and offer recommendations for preparation?

A: PM interview process at Two Sigma is not that different from other big tech companies (e.g., Google), in my opinion.

It typically includes multiple rounds (expect 5-6 interviews in total), consisting of a mix of product sense/product strategy cases & behavioral interviews focused on your previous background.

Preparation-wise, again, it's no different from preparing for interviews with Google/Meta/Microsoft/etc. You should plan to do some mock interviews, learn how to solve various product cases you might get asked, make sure you can speak about your past work with confidence & at the right level of granularity, and so on.

If you're fairly new to PM interviews, I personally really like Product Alliance materials — but there are a ton of other good resources you can leverage to prepare.

Finally (and this is very important!), don't over-focus on any one company (be it Two Sigma, or any other company) when recruiting — instead, always apply to a lot of places, and then see how it all shakes out.

Tech recruiting is a big numbers game, and so you goal should be to get a well-paying position on an interesting product at a good company — but NOT to get a specific position or get into specific company, since this is too hard to ensure, and just leads to disappointment in many cases.

Q: How did you break into hedge funds/HFT space, and how does it differ from traditional tech product management?

A: I didn’t explicitly focus on breaking into hedge funds / HFT space (in fact, Two Sigma was the only company from this space that I applied to, and interviewed with). Rather, I was looking for a new PM gig, and Two Sigma was one of the companies that I was curious about, since I knew they had a PM org there, heard good things about the culture, and was generally interested in the space — so, I interviewed there (among other places) & got the job.

The work itself isn't that different between big tech firms & Two Sigma — sure, the firm is smaller (~2,000 people vs. 20,000-100,000+ in big tech), you have to pick up some industry-specific context (a lot of it, actually) & adjust to building products for a few hundred users, but at the end of the day, it's still your typical Product Management job.

Q: What do PMs do at Two Sigma, and how does it differ from a role at a company like Google?

A: It's not that different from e.g., Google (or any other big tech company), actually.

The key difference is, you are working on building products to support Two Sigma businesses (chief amongst them, the quant hedge fund). As such, your users are Two Sigma quants, and the product you are working on is typically some part of the investment platform Two Sigma uses.

Beyond that though, you still do user research, trying to understand your users’ needs, pain points & workflows of your users, build roadmaps, negotiate trade-offs between various options, partner with other teams to build cohesive products, and so on.

In effect, this is still your typical PM work, just for a somewhat unusual set of customers/users. As such, most PMs at Two Sigma come from a variety of tech companies (Microsoft, Google, Amazon, Palantir, etc.), and some might go back to big tech or startups after a while.

Q: What are your top tips for new PMs with less than one year of experience?

A: First of all, congrats! You’ve already got the job, and that’s perhaps the most difficult part — breaking into Product Management field is tough, but once you’re in, it gets better from there.

For the first 1-2 years, focus on learning as much as you can about what it means to be a PM, and how to do your job well. There are a ton of materials you can find online, but it’s also good to find an experienced mentor (or two) to coach you, and, of course, learn as much as you can on the job.

If you already work at a top company, consider sticking around for a few years — it takes time to learn the context, and get productive, esp. when you are new, and switching jobs always has some overhead in that regard. If not, try to network with folks from big tech (go to meetups, ask someone you know to be your mentor, etc.), and eventually plan to switch. Remember, maximizing TC shouldn’t be your top priority at the beginning (focus more on what the job helps you learn) — it’ll pay off later.

Finally, spend some time figuring out which parts of the job you like vs. what you don’t enjoy. It’s very useful learning those kinds of things about yourself, to know what to focus on when improving your skills — but more importantly, it will help you on the road to figuring out what kind of PM you want to become eventually (there are many different types, and what they do can differ widely).

Q: How can someone who recently graduated from a bootcamp gain relevant experience, especially in a market that may not favor junior PMs or career changers?

A: To be honest, it's hard for me to advise here.

Breaking into Product Management is tough, and there is no way around that, unfortunately. Typical paths to do that typically include:

1. Switching to a PM role internally at your current company (usually by volunteering to take on some typical PM functions in addition to your day job, and then doing those things very well)

2. Going to a top business school to get an MBA, and then making the switch

3. Networking your way in, by finding folks that you can somehow convince you’ll be a good candidate

Depending on the person’s previous background & the nature of the bootcamp, this might be helpful for either 1) or 3). Developing an interest in a particular area, and clearly demonstrating it by taking courses, building a few small products, etc. might also be very helpful with 3). Beyond that, it’s hard to say.

Overall, breaking into PM isn’t easy, but it’s definitely doable — the industry is full of people who did something else in their careers before becoming PMs, so with sufficient determination, it can be done.

Q: Which hard skills have proven most beneficial to you, and have you learned those on the job, or independently? Also, have learning any skills not directly related to your role proven to be particularly helpful?

A: To be honest, I don’t actually think hard skills matter all that much, at least not the things like knowing specific tools, etc.

Having CS degree (or another engineering degree), or being technical in general certainly helps both for getting interviews & performing well on the job, especially if you want to work on technical products / work closely with engineers. Having a working knowledge of things like applied statistics (just the basics) can also help a lot, depending on the job.

Beyond that though, most skills that really matter are typically soft skills: e.g., communication skills, the ability to write well, negotiation skills, etc.

A capable person should be able to learn specific tools, etc. in the matter of weeks, but developing good communication skills, for example, can take years.

Q: Is it worth being a PM if you're not incentivized to improve business value, such as through stock options?

Note: Hedge funds only offer cash compensation (no equity), which is why this question came up.

A: This is a very interesting question, although I would argue its premise is flawed. Let’s dig a bit deeper here.

If you are working for a small startup where your work presumably creates enough impact to influence the future of the entire company, I agree, not getting any stock would be a very bad deal.

If we look at big tech though, one’s actions will have little to no material impact on the company, so getting stock compensation isn’t really about your personal impact — rather, it’s a convenient way for companies to provide you with additional upside ‘locking you in’ if the entire company does well (since your unvested stock value will go up, incentivizing you to stick around).

The downside of this is that if the stock price goes down, your TC decreases, and you might be forced to switch jobs, or accept lower pay for a while, even if you like the team / work (that’s exactly what happened to most of big tech companies / employees in 2022). This issue can be eventually fixed by getting equity refreshers at lower prices (due to market declines), but that takes time.

Now, with cash compensation, companies still have plenty of ways to incentivize you: bonus is still variable (and e.g., at hedge funds, esp. at higher levels of seniority, the bonus accounts for most of your compensation), so there is that — plus you won’t get promoted without showing impact (and might even get fired if you are performing poorly).

Ultimately, whether to join an early-stage startup vs. big tech vs. a hedge fund is a deeply personal choice. Having tried both big tech & hedge funds by now, I’m personally not a huge fan of the equity compensation in big tech — I think having a high & stable cash comp that allows you to invest savings in a diversified set of assets & then focus on your work without having to stress over the company’s stock price, is generally a better deal for most — but again, it’s largely a matter of personal preference.

Q: How would you classify most of PM jobs at hedge funds? E.g, are those internal tooling PM jobs?

A: Again, this is an interesting question. Re ‘internal tooling’ piece, I am inclined to say ‘no’, since ‘internal tooling’ typically means a very different thing in big tech, compared to what I (and most of the other PMs at hedge funds) do.

At a high level, you can classify most PM roles as:

• Platform PMs: building the foundation for other Engineering teams to build their products/services on

• Internal tooling PMs: building for internal stakeholders, far removed from revenue generation, e.g., building better HR tools, etc.

• Customer-facing PMs: building products that bring in money for the company

Using this classification, most hedge funds’ PM jobs will be in the third bucket (‘customer-facing PMs’), since the products that you are building are tied to revenue generation & are immediately used by your customers (quants) to earn money for the firm.

The nuance here, of course, is that your users are working for the same company, so there is no sales org that has to sell your product after it’s built, etc. However, that doesn’t really change the fact that the products you are working on have direct impact on the ability of the firm to make money.

Q: How much of your success so far would you attribute to being in the right place at the right time?

A: The short answer is, ‘a lot’. Moreover, I’m convinced that anyone who tells you otherwise & tries to downplay the role of luck in their career progression isn’t being honest with you (or themselves, for that matter).

You still have to hassle to get there, of course, and there are a lot of things you can choose to do to maximize your chances (be open to change, apply widely whenever you are interviewing, learn how to negotiate, and, most importantly, learn how to do well on the job), but luck will always be part of the process (as it is part of most of life in general).

Q: How valuable is an MBA from a top school for a product manager?

A: I believe having an MBA from a top school can be quite useful, but it certainly depends on what you plan to use it for.

For example, if you already have a job as a PM in big tech, you certainly don’t need an MBA — you can acquire most of the knowledge you need on the job or in your spare time (and since you are already a PM, you don’t need to worry about how to break into the industry either).

In fact, perhaps the best career path in PM starts with becoming an Associate PM at a place like Google or Uber right out of college (if you haven’t seen it, check out one of my previous posts that touches on this topic: Breaking into Product Management: key 'entry points' into the field).

At the same time, if you are looking to do a career switch from some other field to working in tech and want to break into Product Management, an MBA from a top school can be super-helpful.

A lot of companies hire top business school graduates as PMs these days, and business schools can help a ton with recruiting (a lot of companies come to recruit on campus, there are a lot of things in business school that can help you prepare for the interviews, etc).

Top U.S. MBA programs are also usually 2-year degrees, which gives you an opportunity to intern somewhere during the summer, and thus make it a bit easier to break into the industry.

Finally, most MBA programs are quite flexible these days, and have a lot of classes that can be useful for aspiring PMs (data analytics classes, basic software development classes, dedicated PM classes, etc.).

Oh, and for international students, getting an MBA in the U.S. can get you a 1-3 year working authorization (via OPT / OPT-STEM route), which gives you sufficient time to figure out U.S. immigration.

That being said, getting an MBA is a huge commitment & it’s expensive, so:

• I wouldn’t recommend it to everyone

• You should really focus on the top schools — and MBA from a place nobody knows about will very likely be a waste of money

Q: What are the two most important factors for successfully changing jobs as a PM?

A: It's a bit hard to narrow it down to just 2 things, but if I had to do that, I'd say the most important things are:

• Focus on doing interesting, impactful work (preferably, at a top-tier company) that you can then confidently talk about (learning how to discuss your work is almost as important as doing the actual work)

• If you decide to switch jobs/companies, always do it from a position of strength; this means starting interviewing when you are actually happy to stick around at your current company, and focusing on both applying wide & setting your terms upfront (e.g., people often let companies determine their level, whereas it's a much better idea to set the expectations upfront, etc.)

Those are 2 things that I would say are most important, in my experience.

Specific skills are also important, but more so for doing well on the job, rather than for being successful when interviewing/switching jobs.

Hopefully, this was helpful!

If you have other interesting questions worth answering / have any other feedback you’d like to share, let me know in the comments section below!

In this post, however, I’d like to focus on exploring the similarities & differences between two critical roles in the tech world: Product Managers (PMs) and Software Engineering (Development) Managers (SDMs).

My goal here is not to ‘pick a side’, or tell anyone what path they should pursue (I personally think both those roles are great, and among the best & most interesting careers one can have in tech; I also believe that great SDMs in particular are worth their weight in gold, so to speak), but rather to provide some insights into the complexities of these roles and also help people further recognize their complementary nature & the benefits of developing a deeper understanding of the ‘other side’.

The Basics: What Do PMs and SDMs Generally Do?

I know that for many of you, this is quite familiar (in which case, feel free to skip this section), but I believe it's useful to do a recap of this nonetheless, if only to align on the basic facts for the later discussion.

What do PMs do? A brief overview

At the highest level, PMs usually focus on the following:

1. Defining long-term product strategy & vision for the product

2. Conducting user research & gathering customer feedback

3. Translating customer needs into product requirements / building product roadmaps

4. Prioritizing features & managing the product backlog

5. Collaborating with cross-functional teams to ensure successful product launches

Note that this is not an expansive list by any means, but rather a recap of some of the key activities Product Manager role usually entails.

What do SDMs do? A brief overview

In turn, SDMs typically focus on the following (again, this isn’t a list of everything SDM role involves, but rather a short summary of some of the key activities):

1. Managing & mentoring software engineering teams

2. Overseeing the software development lifecycle (SDLC)

3. Ensuring code quality & implementing best practices

4. Collaborating with PMs on product strategy & requirements

5. Balancing technical debt & feature development

How are PM & SDM roles similar vs. different?

PMs and SDMs have a lot in common, especially at higher levels

While the way PMs & SDMs get started on their respective career paths is in many cases different — e.g., PMs are often career switchers & generally come from a variety of backgrounds, while most SDMs start as software engineers & then move to the management track — PMs and SDMs usually end up working very closely together, and as their careers progress, the lines between those two roles become increasingly blurred.

That might sound surprising at the first glance, but it actually makes a lot more sense once you spend some time thinking about it: for instance, both roles require deep understanding of product strategy, putting user needs first & figuring out effective collaboration with cross-functional teams, amongst other things.

As a result, at higher levels (e.g., M2 and above), PMs and SDMs may even find both themselves managing both engineers/other SDMs and PMs, regardless of their own previous background — in fact, more & more companies move to this model, though the exact point of convergence will differ between companies (usually, it happens at the Director or VP level).

One other thing to note here is that while I focus on software engineering/SDMs in this post, most of what I write should also be applicable to the data science/data science managers career path.

Some interesting trade-offs between PM vs. SDM careers

Another aspect that I believe is important to understand when thinking about PM & SDM careers is the typical balance between tactical & strategic work at each level, and the nuances of overall career progression, for both PMs & SDMs.

If you look at key job responsibilities listed for SDMs above, it’s fairly clear that a lot of it is focused on building your team, helping people become more productive & become better engineers, and managing day-to-day aspects of software development. For the lack of a better word, I’d describe those activities as tactical, although this is in no way a judgement on their importance — in fact, without this work, all the strategic insights will be worth nothing, because nothing will actually get built.

PMs, on the other hand, spend a lot of their time trying to figure out the answers to the ‘what?’ & the ‘why?’ questions — e.g., what should get built, why is it important for the team to invest in it, etc. Again, for the lack of a better term, many of those activities can be described as strategic, in the sense that you’d get to focus on longer-term strategy for the product, spend more time with the customers, company leadership & so on, in order to figure out answers to some of those questions.

Next, it’s also worth highlighting certain differences that exist in career progression between SDMs & PMs. Software engineers interested in trying their hand in management can usually become SDMs earlier in their careers (more on that below), and will then progress to the M2 level (manager of managers) a lot quicker too, compared to PMs. In contrast, it typically takes longer for PMs to become managers, and then PM managers will often remain at the M1 level (line managers) for a lot longer.

The interesting thing is that this progression from an IC (individual contributor) to M1 to M2 has little to do with the leveling ladders (if you want to learn more about levels, check out one of my previous posts on this here). In many cases, M2 on the SDM side will have the same level as M1 or senior ICs on the PM side.

If this sounds a bit weird, consider this: the normal ratio of PMs to engineers varies from 1:8 to 1:20 (and sometimes it can go even higher). This means that if you visualize the org chart as a pyramid (with CEO at the top and ICs at the foundation), the foundation of the ‘engineering pyramid’ would be a lot wider than it is for PMs.

Then, once you take into account the fact that it’s virtually impossible for a manager to allocate sufficient time to more than 10 direct reports (and even ten reports would be pushing it), it becomes pretty clear why SDM ladder usually starts at more junior levels, and why there will be a lot more M1s, M2s and so on in Engineering, compared to Product Management (I’ve also touched on this point in my previous ‘You got multiple job offers, all in different functions? Congrats! Now what?‘ post — if you haven’t seen it, you might want to check it out).

This means that PM M1s or senior ICs are often aligned to M2s or M3s on the SDM side in terms of scope and strategic focus, while M1 SDMs will naturally focus on delving deeper into the technical aspects of the work then PMs ever could, coaching junior engineers, and so on.

Again, none of the above is supposed to indicate that one career is better than the other. Instead, I think it’s useful to understand this trade-off between getting to do more strategic work vs. starting in people management earlier that exists for PMs vs. SDMs.

Which path is better for you? There are no right answers, just some things to consider

When comparing PM and SDM careers, it's much more important to consider your own interests, strengths, and long-term goals, in my opinion. Both roles have a lot in common, but there are some key differences that can impact your job satisfaction and career trajectory.

Growing in your chosen field

Both PM & SDM careers represent a great choice, and you can have a very happy career in either of the fields. In both roles, you'll be exposed to various aspects of product development, strategy, and cross-functional collaboration. As your career progresses, you might even transition between the two roles, leveraging your unique experiences & insights to drive success in your new position.

However, in your early- to mid-career in particular, those two roles can also be quite different, based on the different focus areas for each that I touched on above — so choose carefully (but also don’t stress too much if you think you made the wrong choice — I’ve seen enough examples of SDMs switching to be PMs & vice versa to know that it’s quite possible to do that with a bit of effort)!

The Individual Contributor route: another viable option in Tech

You should also keep in mind that the great thing about both Product Manager & Software Engineer roles is that you’ll have the option to remain an individual contributor and still have a rewarding career, making it a viable path for those who prefer not to move into management roles.

For engineers, the individual contributor ladder extends all the way to Distinguished Engineer and Technical Fellow positions (which are often equivalent to VP positions on the people management ladder), while PMs can reach at least L6/L7 (I’m using Google levels for reference here), and possibly higher in some cases.

In contrast, many other functions within tech companies have more limited growth opportunities for individual contributors, often capping at L5 (again, using Google ladder here for illustration purposes).

Levels and career progression in ‘Big Tech’ companies

At companies like Google, Microsoft, Meta, or Uber, there are specific levels at which one can become an SDM or a PM manager.

For SDMs, the earliest level is often L5 at Google (more realistically, L6), L63/64 at Microsoft, L5a at Uber, and so on.

For PMs, the earliest level for becoming a full-time people manager is typically L6 at Google (though more often, that will happen at L7), L63/64 at Microsoft (although it's quite rare, with L65-66 being more common), L5b at Uber and so on.

Understanding the leveling structure at each company can be very helpful for setting realistic career progression goals.

Conclusion: embrace the complementary nature of PM & SDM roles

If you’re a PM, your SDM is going to be your closest partner in many cases (and vice versa) — so, as you progress in your career, it's crucial to recognize the importance of cross-functional collaboration between PMs and SDMs. Both roles bring unique insights and skills to the table that, combined, can drive the success of the product & the team.

By gaining a deeper understanding of the ‘other side’, you can hopefully better appreciate the value of each role, leading to more effective collaboration and overall success in your career.

And again, remember that it's not about choosing one path over the other – rather, it's about understanding the landscape and making the most of it.

P.S. I’m assuming by now you’ve all heard about the release of GPT-4 model earlier this week. For the fun of it, I’ve tried to make GPT-4 to write this post for me, using a detailed initial prompt (and a lot of clarifications later on).

At the end, it took me a while to get it to generate something that I was reasonably happy with, and even then, I had to do a lot of edits on it to get to the final state I am sharing with you (realistically, it would have been a lot faster just to write this post from scratch on my own).

That being said, I believe that the capabilities GPT-4 brings to the table are insane, and there are a ton of ways to leverage it to improve your workflows (be it for work, or with personal stuff).

I intend to write a separate post to cover my experiments with it so far, and also discuss some of the implications of it for people working in tech (and other industries today), as I see it — so, if this sounds interesting, stay put!

• Levels in Tech: how to make sense of them

• Deciphering your big tech job offer

• You got multiple job offers, all in different functions? Congrats! Now what?

Today, however, I’d like to focus on a topic that would be most relevant for those considering starting their careers in, or switching to, Product Management.

What’s so different about Product Management?

First of all, I’d like to touch on the topic of what makes Product Management fairly unique compared to the other fields & functions in technology.

For disciplines like Software Engineering or Data Science, the vast majority of people will either begin working in those fields directly out of college (some might get a Masters or a PhD first, but that doesn’t really change things), or will do a ‘hard’ career switch at some point, meaning they reset any career progress they had in their previous field, and have to start from scratch as a Software Engineer or a Data Scientist, usually joining as a junior SDE or junior DS first, and then rising through the ranks over time (that’s usually the path graduates of various ‘bootcamps’ have to take, for example).

For some of the other disciplines, like Marketing or Strategy, it’s not uncommon to see experienced hires who didn’t work in those fields (at least not in the tech industry) before successfully make the switch to tech without having to lose their previous career progress. Some will take the business school route to make this change more straightforward, but many would just find jobs & switch (e.g., it’s quite common for former management consultants to move to functions such as Strategy or Operations in the tech industry).

The reason why this is possible is that in functions like Strategy or Marketing, almost none of the things you do are unique to the technology industry, and so if you worked in one of those for a while, even if it was in a different industry or space, your experience will most of the time be relevant for the tech firms as well (you’ll still need to learn some nuances / pick up some context, of course, but that’s just par for the course).

Product Management, however, it’s a different beast entirely. The discipline of Product Management came to be in 1980s & a lot of it is quite unique & specific to the tech industry, since it were the tech companies who created it in the first place (some other industries — e.g., FMCG — also have Product Managers, but those jobs are nothing like PM jobs in the tech space).

Because of this, nothing from the other industries/fields quite maps to what Product Managers do in tech, and that’s exactly what makes it challenging to break into Product Management as an experienced hire (that, and also the fact that everyone and their mothers want to be Product Managers nowadays, it feels like).

That’s not to say that you cannot break into Product Management if you already have some years of experience under the belt. You absolutely can do that, but there are some ways that work better than others, and the first step towards successfully executing such a move is to get to learn more about & understand the key ‘entry points’ to Product Management that most people who work in the field today used, which is the focus of this post.

Key ‘entry points’ to Product Management

There are 3 key ‘entry points’ most people end up taking to get into Product Management:

1. Join an APM program out of college

2. Join as a PM / Senior PM out of business school

3. Switch to the PM discipline later on as an experienced hire

Let’s take a look at those one by one.

APM programs

APM stands for ‘Associate Product Manager’. APM is usually the most junior title for Product Managers at the companies where such title exists (e.g., at Google, it roughly maps to L3; see more about ‘big tech’ leveling here).

APM programs are typically 2-year rotational programs aimed at bringing in recent college grads & then training them to become highly productive product managers over time.

The first APM program was created by Google in 2002 and proved to be very successful, so then a number of other similar programs were created over the years, e.g., Meta’s Rotational Product Manager Program, Uber’s APM program & Salesforce’s ​​​​​​​​APM Program.

There are also some well-known programs that don’t quite fit the definition of an APM program, but have the same idea behind them, most notably, Microsoft’s Aspire Program & Kleiner Perkins Fellows Program (both these programs aren’t limited to Product Management either, and instead exist for a variety of disciplines; also, both have 2 possible ‘entry points’ for PM roles: 1) right out of college, and 2) out of business school).

The idea behind APM programs is fairly straightforward: since Product Management is such a unique role, instead of having people work somewhere else for a few years, it makes more sense to bring in bright college grads on board from the very beginning & then train them how to be great PMs internally.

As part of a 2-year program, APMs typically get to experience 2-3 different products/teams, and also receive centralized training/mentoring. Companies like Uber & Google spend a lot of resources to make sure APMs get a great experience, and more senior PMs are usually happy to pitch in helping to train APMs — both because it’s important for the company, and because it’s often a good way to get someone to help out with your product & get some early management experience yourself along the way.

At the end of the program, APMs typically choose a permanent team to work on (oftentimes, one of the teams they spent a rotation working with) & also get promoted to the next level (L4 at Google / Meta / Uber).

Note that L4 at those companies is also the typical entry point for new hires joining out of business school, as well as many of the early- to mid-career experienced hires joining from other firms. All those folks will usually have more than 2 years of experience that APMs gain by the time they finish the program, so in a way, APMs are getting a pretty sweet deal.

APMs also get to learn both the ropes of both the Product Management discipline & also how to navigate the company they work for during the program, which often puts them on a fast career track. I’ve seen some examples of extremely high promo velocity for people who started as APMs, where a person would rise to be a GPM or even a Director at top-tier firms within 10 years of graduating college — that’s not an easy feat even for APMs, of course, but it would be virtually unheard of for anyone who joined Product Management discipline later on in their career.

Finally, it’s worth discussing whether there are any drawbacks of becoming a PM right out of college. In my opinion, the answer is ‘not really’. APM programs at top-tier tech companies are very competitive, so if you think you’re interested to try your hand at Product Management and you can secure a spot in one of those, you should take it — worst case scenario, you can apply to business school / go do something else after 2 years (and get some impressive experience on your resume in the meanwhile).

Of course, one cannot really turn back the clock — so unless you’re reading this post while you’re still in college, chances are, it might be too late for you to consider the APM route. Not to worry though — if that’s you, just keep reading.

Going to business school to become a PM

Next, a very popular (for better or worse) option to break into Product Management is to go to business school to get your MBA, do an internship while there and then become a PM after you graduate.

Note: Before I continue, I’d like to call out the fact that this is the route that I myself ended up taking a number of years ago: I started my career by working at an early-stage venture capital firm, and then went to business school with the explicit goal to switch to Product Management afterwards. At the end, I’d say it worked out pretty well for me (see the ‘About’ section on this website, if you’d like to learn more about my journey). That being said, I think there are a number of pros & cons of taking this route one should be aware of, which is what I am going to focus on in this section.

So, is it a good idea to go to business school in the hopes of becoming a PM afterwards? The answer, as with most things in life, is ‘it depends’. Let’s unpack it below (note that I’m going to use the words ‘business school’ and ‘MBA’ interchangeably from this point on).

Have a plan

Overall, my personal belief is that business school is one of the best routes to change careers (not just in the context of Product Management, but in general too). The way MBA degrees are structured, the flexibility they allow for, the network & dedicated career services you get — all of it can be very useful for someone looking to change fields/industries, be it to Product Management, or to something else.

The caveat is, you really have to have a plan, ideally before you even arrive on campus. Business schools are often advertised as places where you can spend a lot of quality time figuring out what you want to do next. That, in my opinion, is a bit disingenuous — while there might be some situations / careers where doing so is fine, anyone looking to switch to Product Management after graduating should really be focused & have a plan from day 1. The specifics of the plan can vary based on person’s background, previous experience, exact goals and so on (this probably warrants writing a separate article about) — but having a plan is essential.

Understand your strengths & weaknesses

Next, you have to understand that in a field like Product Management, especially now that it got so competitive over the last few years, not everyone can get the top jobs straight out of business school.

Someone who has spent a few years as a software engineer or a data scientist at a top-tier company before coming to business school will probably have much easier time securing interviews (and likely passing them), compared to a person looking to switch from a completely unrelated field. That’s inevitable, and nothing to get too frustrated about — unlike with some of the other fields, PM interviews are about more than just raw brainpower, dedication, or the ability to network your way in — there are certain backgrounds that can be quite useful for Product Management, and others that won’t be relevant at all.

There are certain advantages to this situation too, provided that you do a thorough reflection on, and can play to, your strengths & weaknesses.

For once, you don’t have to go to the very top-tier school, if your goal is to break into Product Management — it’s very possible that you’ll get more exposure to tech & more opportunities to network at a place like University of Washington’s Foster School of Business, compared to some of the more prestigious schools located on the East Coast, just because of the Foster’s location (Seattle) & close ties to companies like Microsoft & Amazon that are based in the area.

Next, there might be companies for which you would be a naturally better fit, based on your hobbies, past experience, or interests. And so, while you can’t turn the time back, changing your major in college & becoming a software engineer (same as you cannot go back & do an APM program out of college), you can, for instance, decide to focus on the analytics classes, read up on how one scales SaaS companies, and then leverage your past experience in, say, Sales, to position yourself as a really good PM candidate for the B2B SaaS startups (doing some networking also won’t hurt, of course).

Keep your mind open

That being said, my main advice to people who want to become PMs out of business school is to always look wide & keep your options open, instead of spending too much time trying to optimize for a few select jobs / companies. Recruiting in general is a numbers game, and tech recruiting in particular can be both chaotic & at times dumb (in reality, it’s not so much dumb, as it is optimized for avoiding ‘false positives’, where you hire the wrong people — ‘big tech’ in particular is heavily optimized for this mindset, even if it also means missing out on a ton of good candidates).

Remember: once you get your foot in the door, it’s a lot easier to switch companies (or, in some cases, switch functions if you’re already working at the right company — you can find some more info on this in one of my previous posts here). So, you should apply to a lot of places, even if some aren’t your dream jobs — it’s much better to have multiple options to choose from, than to have none because you were too picky.

Which roles can you get out of business school?

Most companies (at least, ‘big tech’ companies — it’s a lot harder to generalize for startups) hire business school graduates at the second lowest PM level they have, which is also the same level APMs will graduate to, if the company in question has an APM program.

For Google / Meta / Uber, that would be an L4 level; for Microsoft, it’s usually called L61 (sometimes, L62); at Amazon, it’s L6, which confusingly carries ‘Senior PM’ title, but in reality is still the second lowest PM level Amazon has & is roughly equivalent to L4 at Google / Meta / Uber.

Also, remember that some of the APM-like programs are also open to MBA grads (e.g., Microsoft’s Aspire Program & Kleiner Perkins Fellows Program) — those are very much worth considering, since if you get in, you’ll get all of the same benefits APMs get, which are manifold (mentoring from experienced folks, opportunity to experience several products/areas, a chance to quickly build a rather wide network, etc.)

Is it a good idea to go to business school to become a PM after all?

That is indeed a million dollar question. For most people looking to make a career switch, I’m inclined to say ‘yes’, provided that they spend time & effort to figure out a plan, and then stick to it.

In some cases, you might be better off networking your way into PM roles at your current company, instead of going to business school (e.g., if you are already working at, say, Microsoft or Google, especially in a technical role, you can probably find a way to switch to Product Management internally without going through too much trouble).

Overall, my key advice here is this: if you already know that you want to be a Product Manager, try to make the switch as early as possible — and if the business school fits into that paradigm, then it’s probably worth it for you.

That also brings us to the last scenario I wanted to discuss today, which is switching to Product Management as an experienced hire.

Switching to PM as an experienced hire

Ok, so now let’s discuss a situation where you already have years of experience under your belt — way too many to become an APM, or even to go to business school (or perhaps you did go to business school at some point, but then decided to work for a few years in another field, before realizing you want to be a PM). This probably means you have something like 7-10+ years of experience — a classic example of what’s often called an ‘experienced hire’ or an ‘industry hire’.

So, what do you do then?

At a high level, most of the things that I wrote in the previous section still apply, with some additional caveats / nuances. To recap:

• Having a plan is still critical — even more so than it is for those going to business school

• Your background / prior experience will still play a role, and there is no way to get around that, so instead you should figure out a way to use it to your advantage

• Targeting top-tier jobs only isn’t always the best strategy — or, in some cases, you should indeed shoot for top-tier companies, but accept the fact that you might not get to do straight-up PM work, at least not at first (and that’s ok)

• Casting a wide net is super-important, as is not getting discouraged by the rejects you will inevitably receive (everybody gets those)

Note: one thing that I’d like to point out is that here, I’m focusing on the cases where one has to do a straight-up career switch to become a PM. If you are already working as a PM at a smaller startup/consulting firm/bank/etc., and want to switch to being a PM in ‘big tech’, it’s a bit of a different story. Making such a change isn’t always easy, but doing so is very different from breaking into Product Management for the first time, which is the key focus here.

Above, I listed some of the things that are similar between the ‘experienced hire’ case & getting hired out of business school. However, there are some differences to be aware of as well.

Aim to switch as early as you can

For once, as with any career, the more experience you gain, the more specialized you become. In many cases, that can be a good thing (since that’s what makes you valuable as an ‘experienced hire’) — but in case of switching careers this typically works against you.

As I mentioned at the beginning, Product Management as a discipline is fairly unique to the technology industry, and so there is no clear equivalent of it in other fields. That means that it’s highly unlikely that the experience you gain in another industry (and thus also another discipline) will directly translate to Product Management.

In practical terms, this means that beyond a certain level, it becomes a lot harder for you to make the switch, since you are now considered to be overqualified for the jobs you can realistically perform decently well in. This in turn means that you have to be willing to take a down-level (be it in terms of pay, level of responsibility, or scope) to be able to make such a transition (and would probably also have to convince folks interviewing you that you are genuinely interested in such a move & will be fine with it).

To illustrate this point, I fairly often encounter people who have spent several years post-MBA working in consulting, and are now looking to make the switch to Product Management in the technology industry for various reasons. I’m going to use McKinsey system of titles in this example, but the same idea carries over to the rest of the consulting firms as well.

As a Senior Associate at McKinsey (0-2 years out of business school), you won’t have to face a down-level, drop in pay, etc., — in fact, if you can get an L4 PM position at Google / Meta / Uber / etc., your pay might actually go up. At the Engagement Manager level (2-5 years out of business school), things are going to get a bit more tricky, since you’d probably want to shoot for L5 PM positions at those firms, but getting those will be a lot tougher, since you’ve never actually done the job, and so the hiring managers will be quite reluctant to hire you, especially if they also have good candidates with PM experience. Beyond that, at the Associate Partner level & above (so, 4+ years out of business school), it is going to become exponentially harder to break into Product Management, for all the reasons mentioned above.

Note that what I’m describing above isn’t unique to the Product Management industry — in fact, you can see the same patterns in most spaces — but I would argue that the nature of Product Management exacerbates those trends beyond what you might see in other fields.

The implication here should be very clear by now: once you figure out you want to make the switch, you should aim to do it as early as possible, since staying on your previous path will have very little benefit & at some point might actually start working against you.

Not all PM roles are the same — use it to your advantage

Next, previously I have already alluded to the fact that PM roles are not all the same — in fact, I believe one would be hard-pressed to find another field that has so many very different jobs gathered under one umbrella title.

To give you an example here, being a Data PM on a highly technical platform product is going to be very different from being a UX-focused PM for a fast-growing consumer-facing product, and that in turn would also be very different from being a PM responsible for running a customer engagement program for a mature, well-established b2b product. In fact, I’d argue these 3 roles have very little in common — and yet, they are all PM roles.

This fact can be used to your advantage, since it allows you to look for PM roles that best align with your past experience, and then go after those. Note that you don’t have to commit to doing those types of roles forever either — rather, focus on getting your foot in the door, and then, once you have your PM title, you can work your way to the types of roles you fee truly passionate about.

Think hard about the types of companies you want to work for

Finally, while it might seem to be a no-brainer to go after PM roles at ‘big tech’ companies out of college or after graduating from business school, the more experienced you get, the harder I believe you should think about the types of roles that appeal the most to you.

True, many of the advantages of joining ‘big tech’ firms are still going to be there, but you might also find yourself in situations where ‘big tech’ companies don’t value your past experience much, thus requiring you to take a substantial down-level if you want to join them (I’ve seen this happen many times), require you to work on products that you don’t really care about, or just generally seem like a poor fit for your career aspirations.

At the same time, it’s possible that you’ll find PM positions that fit with your goals / interests / past experience a lot better at startups, or just at the companies outside of what’s typically known as ‘big tech’. If that happens, and you think the role is a good fit, don’t stress too much about what could have been, had you gotten a position at Google or any of its peers, for a) it’s not worth to dwell on it for too long; b) you can always attempt to switch later, once you are working in the field; and c) at some point, the fit should start mattering more than abstract things like prestige.

Hope this article gives you some idea of the various ‘entry points’ one can take to break into Product Management, and pros & cons associated with each of them.

Also, if you have any comments / feedback, or just want to share your personal experiences on the matter, please do so in the comments section below!

Now, it’s time to discuss what in my opinion is one of the most confusing & misunderstood aspects of working in tech — namely, the concept of levels!

Some common misconceptions

Let me start by listing some of the many things about leveling in tech that I’ve heard over the years (spoiler alert: they are all wrong!):

• Levels & titles are essentially the same thing

• The way levels align across companies is straightforward to figure out

• I don’t have to worry about levels when interviewing, since the company will just assign me the right level at the end

• If I am a Director at a startup, I should probably aim for Director level positions in ‘big tech’, right?

• Within a company, levels work the same way across all functions (e.g., PM vs. SDE vs. Finance vs. Marketing)

This list can be easily continued, but I think you got the gist by now. The simple truth is, people tend to make a lot of assumptions about the way leveling works, and most of those assumptions are going to be at best incorrect, and in some cases actively harmful for the person in question.

In this post, I will try to provide some clarity on the topic, with the hopes that it would help both those actively interviewing for tech jobs, and also people already working in tech & thinking about their next move.

With that said, let’s dive in!

The basics

First of all, we should start with the definition of what levels are:

Levels represent a way for a company to standardize their employees' experience & assumed ability. Companies then use levels to determine compensation bands, set expectations on the level of impact of one’s work, etc. Companies also often think about open positions in terms of target levels, which are used to indicate the level of seniority required, as well as the scope that each position entails.

Now, let’s take a look at a specific level ladder to illustrate this further — I’ll use Google Product Management ladder as an example, which looks roughly like this:

Note: you shouldn’t see the table above as the source of absolute truth; instead, it aims to help directionally illustrate what kind of experience / scope / compensation each level entails.

A few things worth noting here:

• At Google, titles have roughly 1-to-1 mapping to levels — but this is very often not the case for other companies, where one title might be used for multiple levels (Facebook & Microsoft, I’m looking at you here!)

• Each level has a range (often called a ‘band’) of target number of years of experience (YoE), total compensation (TC), etc.

  • The higher the level, the wider the range gets

  • There is also often an overlap of level bands for things like YoE or TC

  • For example, it’s very possible that an experienced external L6 hire will have both the higher number of YoE & TC than a newly promoted L7

• At some levels, you can still be either an IC, or a Manager

  • On the Engineering side in particular, there are often a lot of levels like that (in effect, you can choose whether you want to stay on the IC track, or switch to management)

• At most companies, you have a concept of a terminal level, which means the level that you can stay at forever, without feeling the push to advance further

  • Typically, the title that corresponds to this level would be ‘Senior’ — although that’s not always the case

  • On the Engineering side, this is typically L64 at Microsoft, L5 at Google/Facebook, etc.

There are certainly some additional nuances, but hopefully, this gives you an initial idea.

How do levels align across companies?

Now, let’s take a look at how levels work if we attempt to compare across companies.

Again, I believe it would be much easier to understand it if we look at a specific example:

The chart above is from http://levels.fyi.

I’ve already mentioned this resource in one of my earlier posts, and I’ll most likely keep referencing it over & over again. In short, Levels.fyi contains a trove of crowdsourced compensation data (which is generally quite accurate), as well as information about how leveling systems at various companies align, etc.

If you’ve never encountered it before, be sure to check it out!

Let’s take a closer look at what we see on this chart (btw, while I’m using Product Management levels here as a way of illustrating some of my points, all of it generally remains relevant for Software Engineering, Data Science & other fields).

Deciphering the chart above

What are some of the things that come to mind looking at this chart?

First of all, it’s very clear that every company uses different conventions both for the levels & for the titles:

• For instance, looking at L6 at Facebook, you can see that it roughly aligns with L6 at Google, but the titles are different

  • In fact, Facebook uses the same title for L4 through L7, making it quite confusing

• At Microsoft, Facebook’s L6 falls between L66 & L67 (Microsoft also uses different titles for both of these levels, compared to Facebook & Google)

• At Amazon, the situation repeats itself — there is no way to clearly map Facebook’s L6 to Amazon levels, plus Amazon titles are also different

Next, while this chart can be quite helpful, those who are intimately familiar with PM leveling across companies might immediately complain that it’s not entirely accurate.

For instance, Microsoft & Amazon folks might point out that mapping Google’s & Facebook’s L6 to Microsoft’s L67 or Amazon’s L8 is ridiculous, since those levels at both Microsoft & Facebook clearly imply more seniority & higher scope.

Those people are not wrong — which brings us to the third & perhaps most important point here, which is this:

Levels are quite subjective, especially since they attempt to capture so many things all at once.

In order to unpack this statement a bit, let’s take a look at a few practical tidbits on how ‘big tech’ leveling/compensation works I collected over the years:

• Historically, Google considered itself (& was considered by others) to be a very ‘prestigious’ place to work, so it had a habit of down-leveling folks (meaning bringing in experienced hires at a lower level than they could operate at)

• Amazon & Microsoft (mostly at higher levels) both can be quite generous with handing people significant scope of responsibilities, but historically, the pay at both companies wasn’t great, compared to e.g., Google/Facebook

  • Amazon has mostly fixed the pay issues by now, but for Microsoft, those are still the case until very high levels (usually L67 & above)

• Each company offers a very different set of trade-offs in terms of work/life balance, promotion velocity, compensation, etc.

As a result, while it is true that Microsoft’s L67 will usually have a higher scope than Facebook’s L6, it’s also possible that an L6 at Facebook would be paid the same or more (due to discrepancies in pay & other factors between two companies), will have a better average promo velocity, etc.

That’s not to say that a person who is L67 at Microsoft would necessarily want to join Facebook as L6 (things like that happen, but are somewhat rare).

Rather, the point is to illustrate that the way levels align across companies is often quite convoluted, and that can in turn determine certain patterns in people’s behavior when moving companies (e.g., going from Microsoft’s L64 to Google’s L5 is usually a no-brainer, while doing the same for someone who’s an L7 at Amazon’s would probably be a bad idea).

Titles & functions

Finally, in my opinion, there are two more questions here that are worth exploring:

1. Do titles matter after all?

2. Within a single company, are leveling ladders the same across all functions?

Does the title matter?

On the question of titles, I am hoping you can guess the answer by now: generally, titles matter very little, compared to the levels.

Here is what it means in reality:

• For ‘big tech’ companies, every company knows how their leveling system aligns with everyone else’s — and thus will focus on levels, not titles

• If you are looking to break into top-tier tech firms & are currently working at a startup (with some exceptions) or a more traditional company, you should fully expect that your title won’t be given much weight

  • I know this can feel frustrating, but that’s just the way things are

  • On the plus side, in many cases, you can still get things like higher TC by making the switch — so maybe losing that title won’t be such a big deal

That’s not to say there aren’t cases where your title can work to your advantage. Levels are generally private, and while companies might try to get you to disclose it, you don’t have to do that — so, if you have a title that covers several levels, it can help you obfuscate things a bit (which can be advantageous for a number of reasons).

There are a few other ways you can make your title work to your advantage when interviewing — I’ll cover those in a separate article later on, since it goes a bit beyond the scope of today’s post.

Are all functions created equal?

Regarding the second question (‘Within a company, are leveling ladders the same across all functions?‘), the answer is a bit complicated, since it really varies based on a company & function in question.

As a general rule of thumb, you can probably safely assume the following:

• The leveling ladders used for PMs, SDEs, DS folks & SDMs are usually going to be very similar, with 2 minor nuances:

  • SDE/SDM are often paid slightly better (~10% difference) than PM/DS

  • PMs would often have higher average number of YoE, compared to other functions for each level

• As for the other functions (e.g., Finance, Business Development, Marketing, etc. — in other words, what can be generally described as ‘business functions’), the following is often true:

  • On paper, leveling for those will appear to be similar to that of PM/SDE/DS/SDM

  • At the same time, in reality, for each level, the pay on the business side is typically lower (starting at 10-15% difference for lower levels, to 50%+ difference for higher levels — though it varies by company, e.g. the difference at Microsoft would be less pronounced than, say, at Facebook/Google)

  • Most of that difference in TC is a result of lower equity grants / refreshers for business functions, compared to PM/SDE/DS/SDM

  • It’s also often harder to stay an IC, compared to PM/SDE/DS, if you care about the speed of career progression; at some point, you have to find a way to switch to management (which isn’t always easy) to keep growing

  • At the same time, business functions are usually much more open to people considering making a career switch (e.g., consultants looking to switch to tech), and in many cases won’t require taking a down-level (unlike e.g., PM roles)

So, to sum it up, while some functions might operate on the same, or similar, leveling ladder, there are real meaningful differences one should be aware of, especially when considering making a career switch to tech.

Hopefully, after reading this post, you now have a better understanding of how leveling in tech works. Again, it’s a complex (perhaps unnecessarily so) topic, and the one that’s not very easy to navigate.

At the same time, as with other complex things, knowledge is power, and so if you develop a good understanding of how leveling works, you can in fact use it to your advantage (in particular, when looking for a new job) — I’ll cover this in more details in one of my future posts, so if you’re curious, please subscribe (if you haven’t done that yet) & keep an eye out for future publications! :)

But what if you have several offers to choose from — or if you are trying to figure out how this new compensation compares to your current job that might come with a very different pay structure?

That’s what this post is going to be all about.

Note #1: For those of you already working in technology, most of the information in this post might sound quite familiar; however, from talking to people over the years, I’ve found that even for those already working in the industry for some time, there are certain nuances of this that are generally not very well understood — I’ll do my best to cover & highlight those.

Note #2: Also, information from this post is going to be useful for those considering offers from what’s generally known as ‘big tech’ and also some of the late-stage pre-IPO startups. Early-stage startups are a bit different — so instead of trying to cram every bit of information in one post, I am planning to write another article covering early-stage startups — if you’re interested in those, just stay put.

Establishing terminology

All right, let’s dive in!

First of all, here is a bit of terminology that’s going to be useful to understand:

• Total compensation (TC): the total amount you should expect to earn per year; it typically consists of:

  • Base salary: your regular pay, paid weekly/bi-weekly/monthly

  • Annual bonus: typically performance-based & paid at/after the end of the financial year

  • Annual equity compensation: annual $ value of the equity you will get (from both the initial grant & refreshers)

  • Sign-on bonus: an extra bonus you might receive in your 1st and/or 2nd years

• Equity grants: the amount of equity you will be granted in the company

  • Initial equity grant: the initial amount of equity you will receive when starting the job

  • Equity refresher: additional equity grant(-s) you’ll get while working (typically granted on the annual basis, but can also be one-time grants)

• Vesting: the process of your granted equity actually becoming yours over time

  • Vesting schedule determines the exact mechanics & timeline for your equity getting vested

  • Vesting cliff is a special condition determining when the first portion of your grant will vest

Going forward, I’m going to use the data from levels.fyi for illustrative purposes in this post.

If you are not yet familiar with this resource, it contains thousands of crowdsourced data points detailing compensation packages for all major tech companies (and many of the startups), and it also provides indispensable data on how leveling systems used at different companies align with each other (I intend to write a separate post on this topic soon).

While not flawless, this information can be extremely helpful to candidates at multiple points during the recruiting process, such as setting upfront expectations with the recruiters, negotiating compensation after receiving the initial offer, and many more.

Understanding the basic calculation

At its core, total compensation calculation looks quite simple:

Total compensation = Base salary + Annual bonus + Annual equity compensation + sign-on bonus for that year (if applicable)

Let’s dig a bit deeper to see how each component in the formula above is calculated.

Base salary

Base salary is fairly self-explanatory — it’s typically just a number that should be clearly listed in an offer. Base salary is largely determined by the level your offer is made for, although there is usually some degree of variability within the level, to allow for higher base salaries for experienced candidates, and also to create some room for future pay increases.

Using Senior Software Engineer (L5) at Google as an example, looking data from levels.fyi, it looks like the average base salary for that level is roughly $195k, with the range (excluding some outliers) of $180k-$210k for L5 level.

Annual bonus

Next, let’s talk about the annual bonus. Annual bonus is typically is calculated using the following information:

• Base amount: fixed $ value, or (more often) % of annual base salary

• Multiplier: applied to the base amount & typically performance-based

Again, using Google as an example, the base annual bonus for L5 there is typically set at 15% of the annual base salary. Some companies, such as Uber, will use a $ value instead — for instance, base annual bonus for L5 at Uber will typically be around $35,000 (note that with an absolute $ value, the number will probably get adjusted every few years).

Typical bonus multiplier usually goes from 1.0x to 2.0x of the base amount, and will depend on both the company performance & individual’s performance (sometimes, the two will be clearly separated, but more often, there will be just a single multiplier). Multipliers above 2.0x or below 1.0x aren’t very typical, but those do occasionally happen — e.g., at Microsoft, if you are underperforming, you bonus multiplier might go as low as 0.6x.

Equity compensation

Finally, we get to the annual equity compensation. That’s where the things get a bit more tricky.

First, when you start a new job, you will typically receive an initial equity grant. On your offer, this will typically be specified as a certain $ value, to be converted into shares using the stock price at some date soon after you start (e.g., often it’s the 15th of the month you start, or the next month; it could also be the average price for that month).

This initial grant will then vest over a number of years, with each vested portion becoming yours if you’re still with the company by then (if not, all unvested stock is usually forfeited after your last day of employment).

The above may sound pretty complicated, so let me illustrate this with an example.

Let’s say you’re joining Meta as a Product Manager at L6 level. The size of initial equity grant can vary quite widely — but let’s assume you receive an $900k initial equity grant (not an unreasonable number for L6 PM at Meta).

Here’s how the mechanics of your initial grant will look like:

• Initial equity grant size: $900k

• Vesting timeframe: 4 years

• Vesting schedule: quarterly vesting schedule, with 6.25% vesting each quarter (or 25% per year)

This means that you will receive $225k ($900k / 4) worth of stock per year from your initial equity grant, provided that Meta stock price stays the same.

Some companies (e.g., Google & Uber) use a front-loading vesting schedule, meaning that more of your grant will vest in the first couple years after your start date — e.g., Google uses 4-year vesting schedule, with 33% / 33% / 22% / 12% of your initial grant vesting in the 1st, 2nd, 3rd & 4th years respectively, while at Uber the schedule will look like 35% / 30% / 20% / 15% of your initial grant vesting in each of the 4 years.

Similarly, some companies might choose the opposite approach called back-loaded vesting, with Amazon being the most famous example. At Amazon, you would see 5% of your grant vesting in the 1st year, 15% vesting in the 2nd year, and 40% vesting in both the 3rd & 4th years. To compensate for back-loaded vesting, Amazon typically offers sizable sign-on bonuses paid in the 1st & 2nd years, provided that you remain with the company during that time.

Regarding the mechanics determining how the equity grant gets converted from $ value to shares, let’s say you decided to join Microsoft in August 2022, and your initial grant was $250k. In that case, your grant got converted to shares using the share price on September 15th, 2022 (the next month after the one you started on). The price per share on that day was $245, so you would receive approximately 1,020 shares ($250,000 / $245 per share) as part of your initial grant.

Some companies also use the concept of cliff, which specifies when the first portion of your initial grant will vest — e.g., both Microsoft & Amazon use 1-year cliff, which means that while both companies use quarterly vesting schedule, you’ll receive your first equity after one year with the company (so, 4 quarters worth of it, or 1/4 of the initial grant, assuming 4-year vesting period), after which the vesting will continue on a normal quarterly basis.

Next, at most (although not all) companies you will also receive annual equity refreshers (or just annual refreshers) as part of your performance cycle reviews.

In many ways, annual refreshers’ mechanics is quite similar to that of the initial grant: you get a certain $ value of equity, which then gets converted into shares on a certain date at that date’s price & then vests according to a pre-determined vesting schedule.

However, there are a few notable differences between annual refreshers & the initial equity grant, namely:

• Annual refreshers are typically smaller than your initial equity grant (assuming you stay at the same level)

  • On average, you can expect those to be around 1/3 to 1/5 of the initial equity grant

  • Similar to annual bonus, annual refreshers typically consist of some base number, plus a performance multiplier

• Annual refreshers almost always have a flat vesting schedule (e.g., 25% of your annual grant vests every year for 4 years) and usually don’t have a cliff

• Vesting period for the annual refreshers is often similar to that of the equity refreshers, although there are exceptions (e.g., at Microsoft, annual refreshers vest over 5 years, while initial equity grant vests over 4 years)

The idea behind annual refreshers is two-fold:

• To increase, or at least maintain, one’s compensation over time

• To make sure that employees always have a sizable amount of unvested stock (both to create incentives to stay & to make employees invested in the long-term success of the company)

Let’s take a look at a quick example for how annual refreshers work, using the same L6 PM offer at Meta:

• As we discussed, the initial grant for that hypothetical offer was $900k

• The target annual refresher for L6 might be $200k — this would then be multiplied by a performance multiplier (let’s assume 1.0x for simplicity)

• Vesting schedule for the annual refresher at Meta would be the same as for the initial grant

So, in this example, the annual equity compensation for each year (assuming share price remains constant) will look like this:

• Year 1: $225k (initial equity grant of $900k / 4)

• Year 2: $275k ($900k / 4 + $200k / 4)

• Year 3: $325k ($900k / 4 + $200k / 4 + $200k / 4)

• Year 4: $375k ($900k / 4 + $200k / 4 + $200k / 4 + $200k / 4)

• Year 5: $200k ($200k / 4 + $200k / 4 + $200k / 4 + $200k / 4)

As you can see, in the example above, the annual equity compensation keeps growing every year (due to new annual refreshers getting granted every year), until year 5, when the initial grant runs out & so the annual equity compensation falls & stabilizes.

In reality, this drop in year 5 should be less pronounced, or non-existent, for multiple reasons:

• Annual refreshers you get every year should increase over time (due to better performance and/or promotions to the next level)

• Stock price should increase over time, making unvested portions of the older grants more valuable (remember, those are converted to a certain number of shares soon after they are granted, so if share price increases, that upside is captured by the employee)

Still, this is one of the reasons some companies (e.g., Google & Uber) decided to switch to front-loaded vesting schedule for the initial equity grant.

At those companies, instead of seeing increases in compensation every year until the initial grant runs out (and potentially facing a drop in compensation at that point), employees are supposed to see a steady compensation over the first few years — and then over time, grow that compensation via promotions and/or growth in stock prices (the opinions on front-loaded vesting are polarized — some people love it, but others hate it & believe it to be a ploy aimed to reduce the size of the initial grants).

Finally, at some companies, there are either no annual refreshers (Snap was one company that traditionally operated under this model), or annual refreshers are much lower than the value of initial stock grant (Microsoft at lower levels is a prime example of this). At those companies, to compensate for the eventual decrease in compensation due to the initial equity grant becoming fully vested, employees often rely on a combination of one-time refreshers and/or larger initial grants.

Note that unlike all the other components of one’s compensation (base salary, bonus, initial equity grant, etc.), annual refreshers are very rarely specified in the offer letters, and are instead decided every year by the company. At least for most of the ‘big tech’ companies, you can typically find at least some directional guidance on the size of annual refreshers online — however, there are no guarantees that those will stay the same in the future.

Calculating TC: examples

Now, let’s now bring it all together with an example — let’s say you received the following offer from Google for an L4 Data Scientist position:

• Base salary: $155k

• Target annual bonus: 15% of the base salary

• Initial equity grant: $300k, with 4-year front-loaded vesting (33%/33%/22%/12%)

• Sign-on bonus: $40k, paid over 2 years ($20k at the start of each year)

Let’s calculate what the total compensation will look like in year 1; in this case, the formula will be, assuming you get 1.0x multiple on annual bonus:

To recap, we got to $297.25k in total compensation for year 1 in this example.

Now, let’s take it further, and look at the subsequent years. After year 1, you’ll go through a performance review, and receive your first annual refresher. For L4 at Google, the target refresher should be around $70k (for simplicity, let’s again assume that you met expectations, and thus received 1.0x multiple on the refresher).

This refresher will start vesting in your 2nd year at 6.25% rate per quarter (unlike the initial grant, this refresher won’t be front-loaded, but rather would vest at the constant rate).

So, for years 2-5, your total compensation might look like this:

Here, we assume constant base salary & stock price. After your 2nd year, you no longer get a sign-on bonus (but the number of refreshers you received that are now vesting keeps growing). After your 4th year, your initial equity grants runs out, and instead you now receive a combination of a base salary, annual bonus & vested chunks of your equity refreshers for each of the previous 4 years.

Now, the numbers above are still an oversimplification of reality, in three key ways:

1. You should expect to get annual increases to your base salary, so, starting from your 2nd year, your base salary should grow

2. As you spend more time in a level, hopefully, you’ll start performing better over time, and thus will get higher annual bonus multiplier & larger refreshers

3. Lastly, the stock price should hopefully also keep increasing over time, which should affect the value of the unvested portions of your refreshers

Accounting for the above, the actual numbers for your 5th year might end up looking like this:

In the example above, total compensation for your 5th year consists of the following:

• By your 5th year, there is no sign-on bonus or initial grant in the picture anymore

• Your base salary is now $180k, after a few years of increases

• You have portions of 4 refreshers vesting each year that might look like this:

  • Y1 refresher: originally $70k, but due to the increase in stock price, the remaining unvested portion has more than doubled in value ($150k * 0.25)

  • Y2 refresher: originally $85k, due to the increase in stock price, the portion vesting in Y5 is now worth $140k * 0.25

  • Y3 refresher: originally $100k, due to the increase in stock price, the portion vesting in Y5 is now worth $150k * 0.25

  • Y4 refresher: originally $140k, due to the increase in stock price (more modest the for the earlier refreshers, since it was granted only a year ago), the portion vesting in Y5 is now also worth $150k * 0.25

As you can see, in this case, your TC for your 5th year would be $365.3k.

This number above captures the idea behind ‘big tech’ total compensation well: the idea is to bring candidates at a healthy compensation, and then have them see their compensation gradually increase (or at least stay stable) through a combination of base salary hikes, stock price growth, larger refreshers & annual bonuses, and also an occasional promotion.

This way, in most scenarios, even after your sign-on bonuses and/or initial equity grant run out, your compensation shouldn’t dip. However, if it does decrease (for instance, due to steep stock price declines, as we saw happen with many tech companies in 2022), your employer might choose to compensate for this with additional one-time equity grants (that typically work exactly as annual refreshers, but are granted off-cycle to act as one-time retention vehicles for valuable employees).

One final thing to call out here is that the calculations above assume that your start date is aligned with the beginning of the financial year for the company. If you start mid-year, the calculations might be a bit different in two ways:

• Your annual bonus for your first year will likely get prorated

• Depending on your start date, you might not be eligible for an annual refresher at the end of the first financial year you spend with the company, and instead will start getting annual refreshers in your second year

Hopefully, the information & examples above will help you better understand how compensation at ‘big tech’ companies works, and will make it easier for you to make sense of your compensation, e.g., when you receive a new offer.

If you’d like to share your thoughts on this topic, feel free to post in the comments below, or reach out to me at me@alexstern.me!

“I have an offer for a Product Management position from a company X, and another offer for a Product Marketing/Business Planning/Strategy & Operations/etc. position from a company Y. I think I want to be a Product Manager, but I am not sure. Can you help me decide?”

Sometimes, there are additional details, like one company is offering a slightly better compensation package than the other, or a team/area at one place looks like a better fit. However, those differences are usually minor enough to be generally unhelpful at resolving the fundamental dilemma that the person is facing.

As someone who had to go through a number of these situations over the years myself (I started my career in venture capital, then went to business school to make a career switch to big tech, worked for a bit as both Product Marketing Manager & Business Planner at Microsoft, and then worked in 3 very different Product Manager positions over the years) — and also helping others navigate similar situations fairly frequently — I came to view those kinds of dilemmas through a specific framework, which I am going to share in this post.

First & most important question to ask yourself is:

Do you know which function (product management, marketing, strategy, etc.) you really want to work in long-term?

• If you do, great — go with that, and commit for the next few years at least (more on that below)

• If you don’t (e.g., you haven’t really experienced any of those functions yet, and you just know that you want to work in tech), you have 2 options:

  • Go with the function that pays the highest and generally has the largest number of job openings at any given time (outside of software development/data science — and sales, which is a bit of a special case — that’s usually product management)
    OR

  • Go with the highest tier company you have an offer from, and then plan to figure it out from there

A few things to unpack here:

• When in doubt, choosing the function that offers most flexibility (in terms of the number of jobs, and generally higher pay) should be self-explanatory

  • That being said, it’s also important not to focus on pay/flexibility above everything else

  • For example, if you are absolutely sure that you want to work in strategy, don’t join a company as a PM instead, since you will probably do better & be happier in the long run by choosing what you like & can do well (if the main thing you care about is making as much money as possible, Private Equity still pays loads more than anything in Tech — but you can also make plenty in technology not to have to care much about that)

• Overall, changing functions is not easy, even within the same company, not to mention when also trying to change employers — so if you know which function you want to work in, that should have a highest priority over both the company’s prestige & pay (within reason)

  • That being said, if you are unsure, or you have offers from 2 companies with widely different pay / prestige, going for a higher tier company might still be a sensible choice (e.g., if you are trying to decide between Google Strategy & T-Mobile Product Management offers, I’d advice most people to take Google offer)

In many cases, answering this question will already provide you with a clear path forward.

However, if you have multiple offers to choose from, or some offers that seem quite similiar, you might want to dig a bit deeper, before finalizing your decision — in which case, keep reading.

The next few things to consider in your decision-making process are:

• Do you feel that one team is a much better fit than others, based on your interactions with them?

• If you are choosing between offers for widely different product areas (e.g., cloud vs. ridesharing marketplace vs. smart home hardware), is there one area that looks a lot more interesting to you than others?

Note that I’ve bolded ‘much’ & ‘a lot more’ portions above — this is truly a critical piece here.

When you’re still interviewing / chatting with the hiring managers after you got an offer, there is only so much information you can get: both you & the hiring managers face time constraints, there are often details that the company can’t share with you until you join, not to mention that certain things (such as culture fit with the team, or understanding the true nature of the work you’ll be doing) that take time to get a good feel on.

So, the signal you get on things like fit (both with the team & with the product) is going to be weak. Still, the magnitude of that signal matters: if you love one team & are ambivalent at best about all the others, or you’ve always wanted to work in one particular product area that you got an offer for, this is useful information to consider. Likewise, if you like a team / product area at one company just a little bit better than at the others, I’d suggest disregarding that information completely, and focusing on thinking through your answers for the initial question one more time instead.

You might have also noticed that I keep saying ‘product area’ & not ‘product’ here. I believe that’s another important thing to understand: while you might be able to get a general sense of what it would mean to work in the cloud space, vs. working on hardware, you stand almost no chance of figuring out whether working on Amazon Echo devices would be more exciting than working on Nest Doorbell (note that both products I’m using as examples here generally belong to the same broad product area) — so, at that point, focusing more on company / team culture & fit would be a lot more useful.

So, to recap, when trying to decide between multiple offers from different companies & different functions, in my experience, it’s very beneficial to think through the following questions (in that particular order):

1. Function you want to work in (if you have strong convinction on this)

2. If the answer to the previous question is ‘I don’t know’, you need to decide if you want to a) prioritize future job mobility & pay, or b) go for highest-tier company you have an offer from now

3. After that, if your choices still haven’t been narrowed enough, consider if you feel you have a much better fit with a) a team or b) a product area at one company, vs. the others

Obviously, there are other considerations to take into account, such as compensation, work format (remote vs. hybrid vs. on-site), office location, etc. — all of those are still very important & something you should carefully think through, even if they were out of scope for this post.

Hopefully, following this framework (as well as understanding the reasons behind it, discussed above) will help you make better decisions (or at least make those decisions easier) next time!

For those of you who don’t know me, my name’s Alex Stern. For a number of years now, I’ve been working as a Product Manager in various tech & tech-driven companies (Two Sigma as of late, Uber and Microsoft before that). Prior to making a transition to product management, I also got to try a number of other things: spent 2 years in Chicago getting an MBA & Master of Design Innovation from Kellogg School of Management at Northwestern University, worked in venture capital for a few years & tried my hand in startups for a bit, all the while moving a few times across continents & also trying out living & working in a few very different places.

Throughout this time, I’ve had many chats with people who were either looking to do some of the same things I’ve done (e.g., trying to figure out what to do next career-wise, how to get into big tech, or what’s the best way to transition to product management), or attempting to do something that was close enough to allow my experience to generalize to a point where the insights stemming from it would be useful to them.

Recently, however, I’ve come to realize that while in-person chats can be incredibly rewarding, oftentimes you end up rehashing some of the same points over & over again. It also doesn’t scale very well — there are a lot more people I would like to be able to help than I could ever realistically have in-person conversations with. Finally, I feel that at this point, I’ve developed a distinct way to think about many of those career-related questions that might be worth documenting & can then be helpful to people who are looking to tackle the same, or at least similar, problems.

For those who don’t know me very well, I am no stranger to, for the lack of a better word, blogging — in the past, I published quite a few essays & articles on various tech-related topics — here are a few examples of those publications:

• How to Craft an Industrial AI Strategy For Predictive Maintenance

• Why AI investors don’t get it right

• Ecosystem Maturity Framework

• Reflections on the State of AI: 2018

• Apple’s Revenue Drop Was Inevitable

• Revisiting The Unicorn Club

However, at this point, I am less interested in writing about general technology trends & news — there are plenty of people who already do this very well that you can subscribe to (I suggest starting with Stratechery, if you are looking for that sort of thing — it’s great!). Rather, I would like to focus on a few specific areas, namely:

• How to think about your career, esp. during early (0-10) years

• Pros & cons of going to grad school for those looking to change careers

• Navigating recruiting in a new country

• Choosing between various work functions in technology

• Navigating early & mid career journey in tech

• Strategies for maximizing total compensation

• How to break into product management, etc.

The list above is by no means exhaustive — e.g., while I have a lot of experience with product management, many of the insights & topics I intend to discuss here should remain quite relevant to data scientists, software engineers, product marketers, and so on, as well as people just considering careers in technology. You will also almost surely see some posts from me that touch on technology trends & other things — but the main focus will remain on building successful tech careers, and things that can help you with that.

My intention right now is to attempt to post on a regular basis (I certainly have a long backlog of topics that are worth exploring at this point) — but let’s wait & see how it goes!

In the meanwhile, if you want to chat about anything, or have suggestions for the topics you consider important that you’d like me to cover, please don’t hesitate to reach out to me at me@alexstern.me or on LinkedIn!