AI itself is evolving rapidly daily— product management and its various processes are ever-changing. AI can now help with writing one-pagers, requirements, and automating everyday tasks. Alongside this are AI products themselves — PMing an AI product is different than a non-AI product. AI-native products focus on discovering AI use cases, customer conversations, security, trust, and rapid experimentation. PMs are now expected to vibe code with tools like Claude Code, Cursor, Loveable, and Replit. AI note-taking as well as AI-generated PRDs have become the norm. With all that said, let’s explore the pros and cons of working in each sector (big, medium, and small) based on what I’ve gathered from various interviews and experiences.

Big companies can be agile too, depending on team

Traditionally, outside of FAANG, folks would assume that large tech companies adopt innovative technologies for the sake of the board and to keep competitive, but are slower in execution. With a slower pace and flexibility as a PMN comes more stability; we all know that’s the main ‘big tech’ trade-off. This holds for most large tech organizations. Even FAANG companies, which sit on top of a large pool of cash to invest in AI, can move more slowly to ship and adopt. When I started my PM career at Microsoft, we had access to GPT3 back in 2022, pretty early on, before the rest of the industry caught up, but execution couldn’t match the pace of ideation. The only key point, though, is that it’s all team-dependent. If you have a fast-moving team in a large company, it can feel amazing: you move faster than the rest of the company with a safety net if things go south. Let’s summarize the benefits here:

• PMs get less risk and more stability, and could potentially still move fast and work with AI well, depending on the team.

• Potentially has a large pool of cash for AI investment.

• Better salaries and benefits, as well as stable equity.

And in my opinion, the cons are:

• Despite wanting to remain innovative, big tech tends to move and execute more slowly due to size and red tape.

• The chances of gaining 0 to 1 product experience, especially if it’s an AI-native product, are slimmer.

• Similar to the above: while possible, experiencing product growth at a massive scale is unlikely.

If you’re exploring the idea of working as a PM in a large tech company, there are obviously many aspects at play outside of their usage of AI:

• Is their culture what you want and align with?

• Are you passionate about the product and/or the space?

• Are they offering you sufficient compensation and benefits?

A big company with a culture that enables fast AI exploration is still possible. You look at teams like Meta and Google, which prioritize AI-enabled services and teams while also using it to replace internal processes and tasks where possible. But in general, I wouldn’t be surprised if most large tech companies are still leaning on traditional processes without changing too much of their daily operations (why change something if it has worked in the past?). AI adoption and culture are likely team-dependent. Some teams may be vibe-coding MVPs for better discovery work to show clients or customers their product ‘vision,’ while others may be moving more slowly without using AI that much at all.

Mid-sized companies are a wild card.

Planview, a company with between one and two thousand employees, a couple of hundred million in revenue, with many products and a mature platform, is the epitome of medium tech. You have a company that’s experiencing some growing pains, but is still trying to be AI-forward. Of course, medium tech is a broader, subjective term. Some could refer to a company that comprises fewer than 50 employees as a medium-sized company if they already bring in over 50M in revenue and have been around for decades. Because of the rise in early-stage startups and the enablement of fast-growing ones due to AI adoption, the definition of medium tech could also change in the future.

In a medium-sized tech firm, I experienced both the pain of working with old legacy software that suffers from slowness, yet can’t be deprecated due to customer use, imbalanced team paces, and AI innovation. I believe you’ll see the same pattern across medium-sized companies: an interesting dynamic between PMs who drive the steering wheel like they’re in a startup and want to move fast and innovate, and teams who prioritize the current ship or move more slowly due to traditional company culture that’s been cultivated in prior years. This causes an imbalance that needs to be navigated carefully. That’s why I believe choosing a medium tech firm can be a wild card: if the organization is in a transition to adopt AI more rapidly while shifting its culture to reflect that, it can be a good sign. Similarly, that said transition can also be poorly executed, or the company itself is happy with its stable revenue and doesn’t move as fast to adopt new technologies. As a PM, it could be less exciting to move fast and experiment with AI, although I’m sure you’ll have other interesting work to do.

In my opinion, the pros of working in a medium-sized tech company are:

• Similar to big tech, the risk and stability levels are comparable. You may also get more visibility in your work than in a big tech firm.

• While compensation may not be as high compared to VC-funded startups or large tech companies, they’re still good and well-respected.

• AI adoption is a wild card, but the team could execute faster than a big tech firm.

And the cons can include:

• Imbalance within the culture, especially if a medium-sized company is older and comes from traditional backgrounds.

• Medium-sized companies will prioritize growth and retention, which means there could be less innovation on the AI front.

Some medium-sized teams will definitely have adopted AI well, both internally and within their customer-facing products. Vibe-coding and generating one-pagers with LLMs could already be at play. But you never know — and that’s a key answer to seek while interviewing for new PM roles, no matter the size.

Startups offer faster experimentation with AI.

AI-native (or adjacent) startups move fast, are deep in discovery, and expect all their employees to tinker or build with AI. They live and breathe it. Even non-AI startups are exploring their various applications internally or pivoting to include its use in their existing platforms.

PMs in AI-based startups will expect to move faster, if not just as fast as non-AI startups, but the biggest differentiator is product discovery work. Understanding the barriers of building with AI will be tricky, as B2B startups will seek niche use cases, jump over security hurdles, and pivot fast (and vibe-code) within scenes of ambiguity. That’s reality.

Generally, startup land is thrilling; you have the chaos of experimentation and shipping MVPs fast; you have the environment for highly rewarding discovery work. Finally, you get to scale something from a baby to a massive success and accelerate your career ladder if things fall into place. Let’s summarize these benefits:

• A good startup with strong funding or available cash (from revenue or elsewhere) can definitely make for a fulfilling PM career accelerator. Being part of a positive rocketship can feel beyond amazing.

• AI startups are all about becoming AI-native, or shipping AI features fast with the latest capabilities. There will be nothing short of opportunities for you to explore and tinker with.

• Autonomy and visibility are no longer privileges; they’re responsibilities. It’s a double-edged sword: when the business is winning, you’re the hero.

If you’re in or interested in product management and are still early in your career, I always recommend startup experience — the grind and the growth can be fun and fulfilling… when things are going well.

When things aren’t going well:

• Being part of a sinking ship can feel worse than being laid off — I’ve had countless folks tell me about their startup struggles.

• Being laid off isn’t uncommon in the startup scene, as everyone knows. They’re always looking for the best of the best, and anyone who isn’t aligned with their energy or performance might get the can.

• PMs who get a lot of autonomy in a startup will be the ones responsible if the business collapses. I mentioned above that winning feels like you’re the main hero. Losing…feels like hell.

But lastly…

Join somewhere that is AI and tech-forward.

No matter what, there’s value in both learning, career growth, and connections across all tech company sectors and sizes, as long as it’s a tech-first company. Tech-first companies operate differently from non-tech-forward companies — the former are usually more innovative, have interesting tech to work with, are AI-friendly, and are caught up to speed with the latest ideas or processes.

While I have done internships and pro-bono gigs with startups before, I’m joining one full-time now that I have over 5 years of PM experience under my belt to fully witness the chaotic life of clearing ambiguity and achieving early growth. Joining any startup that has a limited runway can be daunting, yet exciting.

I went from Microsoft (100k+ employees) to Planview (1k+ people) to Unbounce (180+ folks), so the natural course of my career was to go even smaller and work to grow a startup to a billion-dollar valuation.

Whether that becomes a massive success or not will depend on the team, including me. There’s risk. But there’s also thrill and energy.

About Me

My name is Kasey Fu. I’m the co-founder of PM Hive and work full-time as a PM. I host the PM Hive Podcast, write for various publications, and keep a newsletter with over 3000 subscribers. Consider subscribing to the PM Hive newsletter today!

Product development shifts drastically depending on the team size and organization you’re a part of. Whether you’re viewing it from a product management, software development, or designer lens, anyone can admit that the environment matters.

While startup life entails a separate topic entirely, I figured a more direct apples-to-apples comparison between big and medium-sized tech firms would be appropriate.

The way we’ll do this analysis in two ways:

• We’ll evaluate the pros and cons from just a general career perspective

• And we’ll dive deeper into the nuances of product development and product management between the two types of environments.

Both levels of analysis will greatly influence one’s product management (PM) experience; either interchangeably or in correlation with each other. One thing to clarify here is that we won’t cover the differences in compensation or benefits, since this could be a separate topic.

Pros & Cons: Big Tech

Pros:

The most obvious one is the abundance of resources available to grow and educate junior and senior product managers (PMs) alike. Mentorship is everywhere. It was straightforward for me to shoot emails over to folks I found interesting and wanted to chat with. Many companies already have established mentorship programs to grow their junior employees.

Typically, you’ll find a decent-to-strong product culture in the organization across both discovery and execution. Large, modern tech companies have continuously embraced product managers to lead product teams and drive stakeholder management. Many will boast established cross-functional teams that know how to set their product managers (PMs) up for success better than ever before.

The diversity of technology and products remains unparalleled, especially at conglomerates such as Apple, Amazon, Microsoft, and Google. PM processes are incredibly diversified. They vary between individual product teams to the point where some could be more different between teams within the same organization rather than across organizations. For both early and mid-career PMs, this poses an incredible opportunity to gain rich exposure across methodologies and best practices to run a product team.

Breadth and depth. We’ve already covered the diversity of exposure in large organizations and their abundance of people and resources, but finding that balance between breadth and depth makes working at large tech giants incredibly fun.

One anecdote from Microsoft would be the crazy amount of problems in the world of Bing Search: on the one hand, you could touch a myriad of areas (search algorithms, indexing, data processing, scrawling, etc.), and on the flip side, there are hundreds of million dollar problems to solve (how can we reduce the number of garbage URLs from showing up in the top 40B indexed database for Bing search?).

Cons:

The relatively lower risk of job vulnerability spurns a trickle-down effect on the culture and environment of the business. Teams may be less willing to take risks, or leadership may attempt to treat their team like a start-up, resulting in process misalignments and lost expectations.

As a product manager, it’s generally difficult to move fast when you’re dealing with tens, if not hundreds, of moving pieces and dependencies. For instance, if you’re leading a new machine learning (ML) project to improve a product, you must navigate a web of conversations about capacity, infrastructure, cost, team dependencies, leadership and stakeholder approvals, A/B testing, and numerous other intricacies. Each of these prerequisites must be addressed before any significant progress can be made.

This complexity can be frustrating for a product manager, but those in larger organizations often recognize these challenges and develop strategies to manage the friction. While it may slow down the pace, experienced PMs understand how to work within these constraints to keep projects moving forward.

Pros & Cons: Medium-sized Company

Pros:

Generally speaking, you may get more visibility for your work and/or scope. Your exposure to politics and stakeholder management will bring you out of the chaos as a better-equipped PM who can fight any battle. This type of experience is invaluable, and the rewards are reaped with incredible results that pertain to both product and personal success.

While the technology and products may be less diverse on average, a narrow focus can help benefit your PM career in the long term, especially if you work at a fast-paced, modern organization that continues to scale. Becoming an SME (subject matter expert) in your respective space comes more easily in this case, since both you own personal brand and experiences could be more aligned with your company’s domain. Just be sure to pick the right time in your career to double down on a domain/industry that you’re passionate about!

With more visibility typically comes more involvement with various tasks and responsibilities that could fall outside the realm of a traditional big-tech PM. I could name a plethora of things off the top: running blogs, sales enablement (educating sales or marketing on your product’s most valuable features), creating documentation, filming tutorial videos, and even establishing execution processes.

Cons:

Both responsibilities and processes may grow chaotic at times with more direct leadership control. This is where risk really populates: product development and business processes will be ever-changing due to company circumstances and growth. Leadership will bear the responsibility to ensure the organization is kept in line; competent leadership is always a must in this case, otherwise, friction will occur.

While there tend to be different financial compensation packages that may or may not offer as much as big tech, educational resources in the form of network connections could be the more limiting factor. It’s important for all tech people (PM or not) to network and seek mentorship or knowledge-sharing beyond their own organization. It’s fine to stay within one’s ecosystem of people if it’s a massive conglomerate, but proactiveness to step out of said ecosystem is needed in smaller companies.

Product management processes may feel either more streamlined or less “flavorful” compared to big tech. Since there are obviously fewer PMs and smaller product teams, there may be limited exposure to different ways teams “do product.” Imagine moving from somewhere like Meta or Google, where PMs stem from all sorts of diverse backgrounds and experiences to pool their knowledge together, to a smaller company that may boast fewer practices since the product culture may be more unified. Of course, that’s not to say this is necessarily bad — you may find engineers who live and breathe a strong product culture no matter the organization.

About Me

My name is Kasey Fu. I’m passionate about writing, technology, AI, gaming, and storytelling 😁

I’ve experienced having a first anniversary since starting a new PM job several times (First Microsoft, then Planview, and eventually Unbounce), so let’s discuss the expectations on the job.

Product management is one of those fields that often involves a slower ramp-up period, with a positive impact that is not realized until later down the road by the business or maybe even your own team. Even project and program management can be similar - project deliverables don’t arrive and pay dividends immediately. Perhaps some people may not accumulate the said impact until they have long left the company. Thus, let’s tackle this topic from the angles of all PM roles.

However, by the end of the first year, expectations begin to accumulate, and most PMs should be able to concretely describe their value or impact through their product’s success metrics.

My typical way of describing a PM’s impact on a product team for developers or other curious engineers would be: “Imagine if your PM left the team. Do you feel like there would be a hole to fill, and things would fall into chaos?” Because if yes, you got yourself a fine PM.

The “One Year” Expectations

That being said, it should be relatively easier to describe the high-impact expectations of a PM once they reach the one-year mark. Let’s take a look at some examples of great and poor results, derived from my multiple conversations with veteran PMs and personal experiences. Do keep in mind that this is still a small reflection of subjective opinions since the PM role can be so varied!

Examples of great results:

• The main KRs (key results) that the PM was responsible for have been met, or are on their way to being met (unless there was a justifiable disruption)

• Your co-workers acknowledge the importance of your decision-making and include you in critical meetings that involve your product/feature

• Your organization’s broader KR (think: revenue targets or adoption improvements) is close or has been achieved with a noticeable boost since your arrival

• Your engineers/product team enjoy your company outside of deep discussions (aren’t afraid to chat with you 1:1 or seek you for help)

Examples of poor results:

• Your KRs aren’t even remotely close to being met (assuming no pivot or change in product strategy)

• Your co-workers are reluctant to include you in critical team discussions or even trivial calls/work sessions.

• Your organization’s broader KR hasn’t budged outside of external factors, or there haven’t been noticeable gains/traction since your arrival.

It’s important to know that, obviously, qualitative benchmarks like the above seldom do justice to the real impact a product manager could bring within their first year. So many nuances are at play. For example:

• A product manager could be wearing multiple hats and doing many tasks that other team members despise, yet it’s not reflected in KR or business-related performance.

• Daily operations could be disrupted — and thus a team’s velocity impacted — if a PM were to take any sort of leave of absence.

• Politics could easily get in the way of a PM’s impact, and those factors could be out of their control or pay grade.

So does a PM set themselves up for success by the one-year mark?

For PMs just starting or who have already invested a year (or several) in their company, the following still applies:

1. Explore where you can provide immediate value.

While especially useful for new PMs on the job, current PMs should never dull their eyes when it comes to seeking areas of immediate impact. Stuff like starting an internal newsletter or inner circle, creating small mockups for your designers to better understand your ideas, or perhaps handholding customers down your funnel more closely. Even if it’s the small things, it could go a long way.

2. Team dynamics matter — and are an underrated factor.

It’s ultimately important for your company and product to achieve its North Star goals and metrics (like revenue, adoption, retention, or a combination of everything), but team dynamics matter.

I’ve seen and heard situations where a PM is hard to work with (for example, they’re not great listeners or are tone-deaf), hindering sentimental productivity across the board. If you were an engineer expecting a strong PM to lead your team’s strategy, would you want a narcissist to make the environment miserable?

Chances are, probably not; it’s a factor that should be more considered in the grand scheme of things: if a PM doesn’t establish a healthy and empathetic working relationship with their team, nothing else matters anymore.

3. Never lose sight of your team’s 1-year product and business goals.

As stated above, the first year’s KRs can truly show where a product manager’s impact is most felt — direct business impact. Never lose sight of those 1-year goals; it can stay true even for PMs who have already crossed that first-year mark — keep crushing (or working toward) those periodical KRs to show your true worth!

Check out more at PM Exercises!

PM Exercises is a global platform and community focused on growing product manager careers around the world, and has a keen focus on AI.

Check out their article about building empathetic relationships: https://www.productmanagementexercises.com/blog/essential-pm-skills-empathy-why-feelings-matter/
or this article on soft skills: https://www.productmanagementexercises.com/blog/6-soft-skills-every-product-manager-needs/

GenAI and its various applications have taken life by storm over the past few years. We have corporations leveraging their power to multiple degrees; we have Tobi lütke of Shopify requesting his employees to use AI instead of hiring wherever possible; we have teams of all sizes building AI-based products or internal tools to increase valuations and keep competitiveness. It’s been non-stop action since GenAI models flooded the market.

Now that being said, the traditional PM (product manager) role in most product teams hasn’t changed drastically in terms of goals or expectations. PMs are still hired to lead product teams in achieving business success, no matter where they are. I’d wager that smaller organizations and teams set ever higher demands on PMs, who likely wear multiple hats and have a larger stake in the pie. So my first strong opinion to kick off this discussion:

PMs aren’t going anywhere. They’ll become more important than ever.

That being said, my prediction is that the PM role will be changing. And that’s not unique to just the PM position; the tech industry as a whole is seeing a whole recomposition of job responsibilities. Developers are using AI tools for coding, diagnostics, QA, and debugging. Managers are using AI agents for various workflows and decision-making processes. PMs will have to adapt to this rapidly changing landscape, so what are these shifts when it comes to one’s daily operations? And, subsequently, what does the future hold as we continue this AI adoption and subsequent transformation across product teams?

In this blog, I answer these questions with my own intuitive reasons and derived experiences. So here are my three bold and educated predictions.

Fewer PRDs, more productivity

PRDs (product requirement documents) have become less popular over the last few years, as they have traditionally been plagued by flaws that have remained constant. Not everyone reads the full extent of a PM’s documents due to time limitations (or perhaps some PMs are just not writing good drafts), and things become outdated or lost in time and space.

So many AI agents and LLMs are able to draft requirements and thus go deep into competitive analyses, strategy explanations, and user stories. Why spend hours writing them when we can rely on bots to do the tedious work with an integrated internet search as a reference? GPT-5 and Claude Opus or Sonnet 4 each have their respective strengths — Claude is known to produce powerful LLMs that code well (enabling products like Cursor) and perform scientific research, while Gemini 2.5 Flash is known for its text-to-image performances. It’s pretty safe to say that AI can not only write PRDs or one-pagers (or specs, as some others describe them), but it can also drive workflows, do internet search-based analyses, and perform other impressive activities. PMs can start focusing more on roadmap maintenance, building customer relationships, and user testing.

PMs can now shift away from spending hours writing PRDs and one-pagers every week to spending more time working with sales teams, talking to customers, and understanding their market more deeply. Or perhaps, if they’re in a technical team, they can spend more time with their engineers in product development. This is a significant shift in daily operations — and hopefully drives greater PM productivity.

AI will do lots of the research and drafting; PMs will just do more thinking and tinkering.

Deployment Strategists and Product Engineers are Becoming Popular

Some who observe the job market will notice the developing popularity of the Deployment Strategist and the Product Engineer title — especially in tech-savvy regions such as Silicon Valley and New York City.

These titles are derived from the traditional Product Manager role — they include many overlapping elements, but obviously with focused areas or activities tailored to the organization’s product strategy and business requirements. For example, Deployment Strategists at companies like Palantir play the product manager role but in a more customer-exposed environment that involves complex data modelling. They’re translating requirements, integrating customer data, and impacting the product interface in an agile way.

Likewise, Product Engineers are essentially AI engineers who can overlap roles with product managers. They’re not only contributing to the code base with the help of AI tooling (and building an AI tool themselves), but are also prioritizing work and driving cross-functional support. Their main expectation is to take customer feedback and requirements into their own hands and prototype solutions accordingly. These roles are typically more commonly found at startups nowadays that try to have a hybrid product manager who can contribute to the AI code base — effectively killing two birds with one person.

Another interesting term in Silicon Valley is the concept of a ‘forward-deployed angel’ — essentially an angel investor for an early-stage startup that also contributes to product development. We’ll get into that in a separate blog.

Use of multi-modal tools for creating PoCs

Multi-modal simply means the ability for an AI model to generate multiple forms of output, such as images, videos, and websites. It’s revolutionized the way we produce, lowering the barrier to entry for website-building, art creation, and prototyping. There are a multitude of tools available that allow anyone who can simply type a prompt to create outputs that seemed impossible just years ago. It’s empowered a whole society, driving everyone to the prompt-input screen to start generating content.

I personally think that every PM should learn how to use vibe-coding or other AI technologies like Loveable, Zapier, Cursor, and V0 to:

1. Prototype ideas or PoCs (Proof of Concepts) for engineers or designers faster and with higher fidelity. I’d try this with Loveable or V0.

2. Contribute to internal dashboards or internal tools that can indirectly support the product or the team building it. After generating an idea or a dashboard with Loveable, PMs could leverage Cursor - a VS Code Wrapper - to build internal data telemetry and ‘productize’ the tool to make it functional within an actual team. For example, I could vibe-code a dashboard that delivers weekly updates about our competitors to understand where we stand against them in various features or areas of business.

PMs have never been more empowered to build and prototype themselves in the age of AI. Whether it’s internal tooling or driving a PoC to explain product requirements or to simply build side projects that perform (and thus automate) certain tasks, activities, or workflows, every PM should learn how to leverage these tools to their advantage. It only goes up from there.

Now, that being said, outside of areas that make obvious sense, when it comes to blogs, newsletters, and journal entries, I’m still a proponent of writing without too much AI support. All my articles have always been 100% written by yours truly; never with AI. Why? We’ll get into the importance of preserving writing skills and the ability to dive deep into subjects without AI help in another article.

About Me

My name is Kasey Fu. I’m the co-founder of PM Hive and work full-time as a Sr. AI PM. I host the PM Hive Podcast, write for various publications, and keep a newsletter with over 3000 subscribers. Consider subscribing to the PM Hive newsletter today!

I’m diving deep to explain how one should navigate their anxieties thanks to technology, distraction, and a jobless economy in one of the most important phases of our lives.

Blankets of grey sheets flood the sky as I stare up in disbelief that it’s still August while strolling Ossington Ave here in downtown Toronto. Endless cars screech to halting stops as traffic piles up in what is typically one of the west end’s congested neighbourhoods. Colourful litter and scraps poke out of adjacent alleyways, hinting at poor sanitation but a glimpse of life. I popped my head into a nearby cafe, becoming immediately intrigued by Rooms Coffee’s unique decor: old yet aesthetic oak shelves and tables lining up the sides like that of a crowded suburban garage, with your oddball piece sitting here and there for added fun. Conversations amongst guests danced into my ears. It looked like your most typical east coast cafe; I certainly miss this type of vibe every time I fly out.

With my flight back to the west coast planned for that very evening, I found an empty table and hesitated before plotting down to deliberate how I wanted to spend my work day. When I visit the east coast while working a remote job, I typically visit WeWork or nearby cafes anyways. So why did I feel idle?

I found myself spiralling into a deeper series of existential thoughts: is this how I want to be living the rest of my 20s?

Anxiety tends to brew the hardest in our 20s, where our actions start defining how we’ll spend our thirties and beyond. Of course, time is still plenty, but it passes by in a blink of an eye. So does our energy, money, and access to loved ones.

Ironically enough, everything in the cafe delivered half the answers. Some guests worked on documents in a split screen view on their laptop. Others sat near the window, immersed in morning gossip. One was propped up, typing an email and taking a call like their lives depended on it while decked out in business casual. Meanwhile, the baristas never gave up their endless smile as more folks trickled in for their morning caffeine. An abundance of variety, yet one shared theme: we’re all working towards our dreams while managing an underlying anxiety. It’s normal.

This entire atmosphere reminded me that we’re all flowing in a constant — that we’re all finding our footing or moving through life in different phases. Some of us have broader dreams we’re chasing. Others are living day-by-day, focusing on what brings them immediate happiness first. Even for those in their 20s struggling to find their way, we’re still striving for the next adjacent goal.

Why we feel this way

In what is arguably one of the most pivotal moments in modern human history (digital devices distracting us from the outside world, the age of AI replacing everything, one of the toughest job markets for new graduates, and the middle class shrinking ever-so-slightly), it’s no wonder we all feel anxiety. Life doesn’t seem fair; it appears gloomier than ever.

This perpetual anxiety that brews amongst Millenials, Gen Z, and Gen Alphas isn’t uncommon, and will only continue growing. The questions we ask ourselves lay daunting. Did our older generations really have it easier, or are we simply getting lazier in an era of technology that prioritizes only the best of the best to keep their jobs?

So let’s dive deep into what we should all focus on for the remaining years of our 20s and 30s.

Be smart with navigation

All sorts of opportunities can be available – but we have to be smart with our energy.

If you think a rapid shift in our job and personal life prospects is a result of this inevitable fourth Industrial Revolution, you’re not wrong. But it’s important to understand how we navigate this shift instead of sitting and complaining without taking action. Things may appear bleak, but we have to adapt. Perhaps that means identifying hidden openings or opportunities between the weeds, or simply adjusting our skill sets to fit the needs of this new generation. For some, it’s not just about jobs – it’s about mental health. Reducing screen time while machining quality moments and experiences with loved ones may be harder to achieve than in the past. Our daily lives are clogged by digital media and technology to the point where we start comparing ourselves to other unrealistic reference points. Likewise, access to stressful news, political conflicts, and other attention-seeking media continues to stifle us in endless dread.

It’s important to remember that we’re all feeling this way; we’re all anxious. Most of us are consumers of mass media. But let’s turn that cautiousness into energy to improve our mental and physical lives while strategically winning the fourth Industrial Revolution the right way.

Focus on adapting to the wave of AI.

Just because design, artistry, writing, or other forms of creation are part of your career or current role doesn’t mean AI will make you obsolete — you can think about ways to develop your own craft with the help of AI tools instead.

In the first Industrial Revolution a few centuries ago, people adapted to the shift in job composition by moving to burgeoning cities for factory work. They transitioned from farming and skilled rural crafts to machine operation and specialized factory tasks – unlocking a whole set of new professions to get by. Our current fourth Industrial Revolution should be tackled in a similar pattern: if we can adapt by developing new skills that follow where the money goes (or at the very least, leverage these advancing technologies to better our work and livelihoods), we will feel less stressful over the overwhelming wave that is the AI takeover.

Time and health are still the most important.

In my upcoming book, Dare to Dream, I write about the importance of “doing yourself a favor” – meaning: looking after oneself above all else. Our mental and physical health should hold precedence over everything; they must be prioritized. Next comes the energy and time we spend, and allocating said efforts in the activities that bring us the most fulfillment and long term happiness.

For me, I plan to spend the rest of my 20s and 30s investing in my physical and mental health through fitness, meditation, eating healthier, reading, spending time in solitude, and of course, writing. Yes, work is important. But without the body and mind ready to take on the day, we have nothing.

Learn personal finance.

Some of us simply aren’t educated enough on the importance of financial management and investing. If we take a step deeper, a subset of us don’t even save money because we’re spending it like it’s Trump change.

We should be be leveraging mass media access for educational purposes rather than doomscrolling Reels. An hour-long breakdown on personal finance is one YouTube video away – yet some of us still don’t invest the time needed for financial independence or retirement.

And even if you are educated, explore ways you can save and/or earn more as you ride out your 20s and 30s. Don’t let time win the battle.

Keep your loved ones close, but your friendships equally as tight

Humans are fundamentally social creatures, but we also thrive off of deep, genuine, and emotional connections. Friends are easy to let go or keep afloat with half-assed strings, but it’s worth it to invest more energy and time as long as the relationships are meaningful. Spreading our eggs across multiple sources (baskets) of happiness ensures greater stability.

I sigh in regret as I write this myself. It puts a retroactive guilt on my shoulders just thinking about all the times I could’ve expressed more reciprocation, actions, gifts, and appreciation to those that extended their hands to me. I sure bet keeping relationships healthy and valued will pay dividends in our 30s and 40s.

Putting our anxieties at bay

A cool breeze strokes my nape as I strolled back and forth near a river while finishing this article. Watching those around me enjoying life to the fullest makes me both happy and surprised. Why aren’t they worried like I am? I wonder. I think this all the damn time. Chances are, some of them probably do experience elements of anxiety. How would I know for sure they’re just happy all the time?

So just know that none of us are alone. We all feel it. But we need to start taking the steps to fundamentally set ourselves up for success in this tough economy, whether that includes our health, relationships, digital screen time, or identifying winning opportunities in a saturated job market.

But most importantly, keep that smile from dwindling :) Keep up the fire!

Read more and explore more about me.

While many similarities and differences are well-known across the tech industry, many product managers ponder on whether one or the other are a better fit for them. It’s a fair analysis.

Typically, while many PMs jump between the two fields evenly, some are advised to stick to one or the other for sake of concentration. Of course, if you’re relatively junior in your PM career, exploring both sides of the coin (B2B vs B2C) helps diversify your experience and enables you to decide which one you’d be a better fit for.

That being said, let’s dive into four hidden differences — perhaps nuances so-to-speak — to really help new PMs grasp where they truly fit.

1. B2B can involve more “top-down” guidance from leadership.

The realm of B2B involves direct engagement with clients/customers on a daily basis — and it’s not even a contest. If your clients or customers aren’t satisfied with your product, it’s essentially game over. The relationships you build over time with these clients are what keeps your own business afloat and enables competitive advantages, even if your product may be inferior compared to a direct competitor’s.

Thus, leadership is just as involved in the customer engagement process as the product team. While B2C relies on the product team to truly understand customer and user pain points, a B2B environment calls for leadership to provide guidance and structure for how a product is delivered to customers — especially long-time clients with 10+ years of established relationships.

B2B PMs who are okay with leadership guidance should embrace this culture. Don’t be afraid to lean on managers and directors for their support when it comes to establishing those relationships, and in return, the leadership team will fully trust you to deliver those features and solutions that their customers truly need.

2. B2B will involve more webinars, deep dives, and client presentations.

While this initially sounds like a no-brainer, let’s discuss the trickle-down effect it applies.

Product managers are often expected to act as their respective domain’s “subject matter expert” (SME). In a B2C setting, this could mean a PM would have to collaborate with their Marketing divisions or conduct some product marketing and evangelism themselves. They’re also expected to answer questions from their peers or other acquaintances about their product or problem spaces. It’s normal. But in a B2B setting, being the SME involves different applications of such.

First, B2B PMs may have to focus on being a SME but consider their customer scenarios more heavily. For example, if a client is only using your B2B product for a niche use case such as using a specific API, then the PM needs to consider the problem space from their client’s point of view.

What challenges does our API post for this specific customer and their industry? Any way we can design something that’s more of a “white glove” solution just for this customer, while not jeopardizing our general product?

Another thing to consider is the type of evangelism. B2C PMs often send out newsletters, release updates, marketing posts, and host once-in-a-while deep dive video meetings to go over how their product solves a specific user need. B2B PMs, while perhaps doing similar activities, are geared more for client-specific webinars and presentations that might even resemble that of a consultant’s. There’s a critical opportunity to strengthen their business relationship between their own company and their client’s. This means that PMs always have to think from a specific standpoint:

What’s the best way to host a webinar to strengthen our relationship? Should I focus on the general product or hone-in on a specific use case that our client cares about more than others?

3. User research and feedback is easier for B2C.

Now before you flame me for the controversial take, here is the point I’m trying to drive across: B2C customers typically amount to a larger use base (or potential user base), and thus user experiments are easier to quantify.

Of course, this isn’t always true. For large B2B companies, if you sell software to a client with thousands of employees, than boom, you’ve acquired thousands of new users by the agreement of a single contract, and they can be your source of testing new features with.

But more often than not, there exists less accessibility for A/B testing or metric-guidance. In a B2B environment, while you have easy access to your closest customers or business partners and can view how they use your product, revenue is often the closest north star metric. You often hear claims such as, “Who cares if our product usability sucks, if our clients find use out of it still and pay us?”

We can summarize this into two main reasons:

1. The nature of B2B means a “customer” and a “user” are different. The customer provides the product revenue, while the user provides the feedback. This can make user feedback harder to acquire and analyze due to this barrier, and product improvement is based on revenue and customer relationships rather than other engagement metrics.

2. Business customers could be less incentivized to invest in having their users provide feedback, and likewise, the product team providing the solution could also be less incentivized to invest in seeking the feedback. Now obviously, this isn’t what happens for all business partners. But think about it — if your B2B company is earning the revenue as long as their clients are getting value out of your product, why dig into all these complicated metrics — especially if a user base is only in the hundreds or thousands?

4. Contrary to popular belief, B2B can be riskier than B2C.

There’s a few reasons why. While obviously B2C means it may take more work to pull users from acquisition to revenue, B2B relies on customer relationships which can easily go sour. Even if a broader user base likes a PM’s product, if the customer — AKA buyer — doesn’t, then it could go down the drain.

There are many famous failed B2B startup examples to stem from, starting with this list here. Just look at this failed case with ScaleFactor, a B2B bookkeeping software startup that provided subpar services to its customers. While the initial idea of using AI and automation for bookkeeping was great, which drove the acquisition of clients steadily, the product itself was of poor quality, and perhaps the initial revenue provided by its early customers made the startup founders more complacent. This ultimately led to them neglecting the quality of their services.

B2C is obviously hard too with the early acquisition of users being a huge challenge in a saturated tech world. But B2B is no different with its emphasis on customer relationships and easiness of product neglect.

About Me

My name is Kasey. I’m passionate about writing, product management, and storytelling. I’m one of the leaders of PM Hive, a PM community.

Check out my website and my Linktree, and add me on LinkedIn or Twitter, telling me you saw my articles!

So what gives — what’s happening? Is domain expertise truly being valued more than general product knowledge and fundamentals?

😥 So what’s happening?

I interviewed over 50 industry professionals in product management in the current tech hiring market — and it’s quite interesting what I’ve discovered:

• In general, it depends on the industry. The more gate-kept an industry is, the more SME matters. For example, for a tech company in the mining or gaming industry, candidates with prior experience in those respective fields will be prioritized. A candidate PM with SME experience > a candidate PM without SME experience.

• In the space of AI, domain expertise matters, depending on the scope of the PM role that’s being filled. If the product is entirely AI-based, then yes, SME will be prioritized. If the product is only partially focused on AI, then it may matter less.

• Product experience still matters — but since many candidates now boast relative product experience (in either PM or some adjacent role), strong product experience for most non-graduate PM job openings is now expected. That’s the minimum bar.

• Other specific product fields will also prioritize SME, but it depends on the company. This includes fields like search, e-commerce, payments, or autonomous vehicles.

• Startups are all over the place. Some startups will care, some won’t as long as the candidate is a proven PM with a strong track record. It’s best to just ask the hiring managers what they’re looking for in a strong candidate.

• If a PM job opening is a new graduate role or for a product in an industry that is less gate-kept (think: B2B SaaS or health tech), then SME may be prioritized less — but again, research the company that’s hiring and what they’re looking for.

🤔 Why is this happening?

To put it bluntly: the product management role is changing.

Doing product has always evolved. Back when Marty Cagan released Inspired, which highlighted the importance of a close relationship between the PM, the designer, and the engineers within proximity, it wasn’t just about the best practices of a product team. It also emphasized a clear focus on product discovery before prioritizing execution, and product management was more well-defined. Additionally, fewer people understood how PM worked compared to today.

📈 Two key changes continue manifesting:

A) The PM role (and its skill set) is becoming more ubiquitous across tech. I term it ‘PM Ubiquity.’

Marty Cagan’s Inspired was first published in 2008, and I bet most of us had no idea what a product manager even was. Even back in 2018 — when I discovered product and developed a desire to become a PM — most of my peers in tech only knew of the role but not much about what it entailed. Some who worked more closely with PMs knew, but some others — even those in adjacent roles or functions like consulting, business analysis, or project management — weren’t as knowledgeable. Now, even peers who are several degrees away know of the PM role; with more ubiquity comes greater adoption of PM skills among the general crowd of tech workers.

This means that other functions like business analysts, managers, directors, community builders, technical leads, and others are now adopting (or turning their existing skill sets) ‘PM-esque’ skills, thus diluting the market that once valued PM fundamentals. Don’t get me wrong — PM fundamentals are still important — but the market continues to dilute itself with everyone wanting to become a PM or put a label on their PM skill set. So what differentiates a good PM hire from a bad PM hire if the market continues diluting with wider PM adoption? One way would be domain expertise, explaining why subject expertise is becoming more important in the PM hiring process.

B) Some PM tasks are being automated by AI.

Yes, Marty Cagan’s ideas are timeless and can still be applied today. But now, organizations across the globe are changing, especially thanks to the onset of AI in many of their daily operations. Some components of a typical PM’s day are being automated, while other areas are still reliant on a human brain.

Think about it: If startups and modern tech companies are leveraging AI agents to perform mundane PM tasks like breaking epics down into user stories, collecting market research, or reminding stakeholders of dependencies, then that changes how PMs must perform on a day-to-day basis. PMs have to pivot and perform more strategic or experience-based tasks, and to increase the chance of success, domain expertise is needed.

🧑‍💻 How to prepare for an evolving job market as a PM

Sit down and ask yourself: What type of role am I looking for next? Do I have any SME to leverage for my job search, and if I don’t, should I develop some first before making the jump?

This will greatly affect how you approach your employment search — and how you apply your existing PM and SME combination.

If you’re someone just starting or trying to break into PM and are looking for an entry-level role to learn the fundamentals, you want to target places that hire generalists, unless you see an opening that would appreciate someone with specific domain experience.

If you already carry forward years of specific domain expertise from a particular industry in your past, you ideally want to leverage that as much as you can — especially if you’re still trying to get your foot into the ‘PM door.’ For example, if you used to be a software engineer in the autonomous vehicle space, a PM hiring manager may already value your industry experience over any lack of PM experience; the latter could be developed over time.

🤖 The future

Because of the expanding adoption of AI agents and the ever-growing impact of PM ubiquity, I have a strong prediction on how the PM hiring market will evolve in the short term (who knows what will happen in the long term).

It’s true that many companies — especially startups — are trying to grow leaner by relying more on agents rather than people, and PMs are part of that equation. So ask yourself: what type of PM will win the near-future job market, and what skills will they have to grow revenue for their business?

I predict that there will be 2 types of product managers that will branch out from the diluted crowd of candidates and become the biggest stars in the future that hiring managers will prioritize:

1. The exceptional business PM with a proven track record of making money.

2. The tech-savvy AI PM who can build or test any PoC (proof of concept) on their own.

Let’s expand on these ideas.

The exceptional business PM is one who is so good at sales or winning customers to grow revenue that they can beat out any AI agent and mesh well with sales teams to win contracts or accelerate cash flow. They’ll take on the burden themselves to optimize inbound or outbound sales and marketing, or work so well with their respective sales or marketing teams that their impact on revenue is significant. They’re still worth the hire, especially if a startup is looking for a PM who can wear many hats (and often wear the hat of a strong salesperson too).

The tech-savvy AI PM is someone who knows how to code or, at the very least, knows how to leverage AI tools (including technical ones) to build proof of concepts and MVPs (minimal viable products), test out ideas, or optimize other business processes to save or earn more money. They’ll probably be expected to work closely with the engineers (or wear the engineer hat themselves in a lean environment) to test ideas, build and ship quickly, and beat out other PMs who move more slowly in the AI wave. This can also allow their businesses to move faster, become more efficient, and win with faster market adoption.

Let me know what you think — will these two specific PM roles conquer 90% of the future PM job market?

😎 About Me

My name is Kasey — I’m a Sr. PM with a track record of building and shipping 0 to 1, and have also worked in big tech. I’ve also published 2 fiction books and built a PM community called PM Hive.

Subscribe to the PM Hive blog! And check my site to learn more about me.

👋🏻 Why Me?

I can speak from my own experience and subsequent learning lessons.

I started my first community — a product management community called PM Hive — back in December 2023 with a few other co-founders. I’ve gone through hills and valleys with PM Hive, revolving between co-leads who were the best fit for the team. We’ve hosted over 50 events under the brand and co-hosted numerous other events, reaching an aggregate of over 1,000 members in the city. I’ve grown our newsletter from 0 to 1.4k subscribers and boasted an average Luma rating of 4.7.

Likewise, Vancouver Tech Week is a week-long festival (along with side events throughout the year) I co-hosted with fellow leaders Toki Hossain and Irem Ozekes — focusing more on general yet technical content for community members in the tech space.

The playbook will be compartmentalized into two categories:

1. The logistical side

2. The emotional side

📖 Logistical Playbook

Rule 1) Be specific or state your intentions

Now, first of all, underlying any community gathering is the desire for social stimulation; no matter what ulterior motives or goals attendees may have, people will breathe the desire for making connections and socializing. But that’s only the first layer, and usually, it may not be enough for retention. To foster deeper conversations, you must be specific about a particular topic and domain. If not, you should at least clearly state your goals and intentions to your community.

You don’t have to shovel yourself into the lowest depths of specificity, but you do want your community members to know what they’re getting themselves into. It’s like building a product from 0 to 1 — breaking into the community space with a broader topic is harder than jumping in with a more niche lens. I’ve found that in general, with deeper dives comes deeper knowledge advancement, and stronger audience fulfillment. If your community is broader (take, for example, a community for all things robotics), you at least want to position it with the right messaging by always stating your intentions:

• What’s the ultimate goal with my community?

• How do I hope to differentiate from other similar communities?

Topics can range from broad to incredibly niche, but if your community boasts a general umbrella, ensure that:

• Each event has its specific purpose or topic of discussion.

• You state your intentions clearly.

Rule 2) If technical, prove you’re capable

If you’re running a community to gather fans of your favorite video game, you’ll be driving fellow fans whose primary goal is to make new friends or connections that can share their love. I’d be a head-scratcher if you’re not at least somewhat knowledgeable in that particular game or franchise.

This doesn’t need to apply if you’re hosting in-person or online events for the sole purpose of connecting others — in that case, people will rely on you for your circle of connections more than your knowledge of a certain field.

Suppose you’re running a career-oriented community for a specific career path or job title. In that case, you’ll likely get network-focused people who could be job-seekers, knowledge-learners, or those desiring to expand their circle of connections. But they’ll also be expecting you — the community builder — to showcase why you’re leading.

Hint: it helps if you have co-founders! If you’re less knowledgeable in the domain of your community, have at least one co-founder who can fill in the role of SME (subject matter expert).

Rule 3) Test the waters and learn event management basics

-With a few pilots!

If you’re just starting, run your first event casually. Keep it simple and easy to set up, manage, and execute! If you do this:

• It helps validate demand for the community, depending on your attendance, thus confirming whether it’s worth doubling down on.

• Helps teach you (an early community builder) the ropes one step at a time, without over-complicating events.

At PM Hive, our first event was just a basic coffee chat social — we’d call a cafe to inquire about availability, book the space, tell our attendees to buy a drink to give back to the cafe manager, and post the event online. It was important to state the goals of the meetup and the activities involved, no matter what we used. We then got a huge crowd for our first event, thus validating the public demand for it!

If you’re growing your community organically in person, keep the first event simple.

Take it easy on the event you’re hosting. Learn about the free or cheap venues in your city that you can take advantage of — whether that be a local coffee shop or office space that’s open to the public on weekends.

Once you’ve run your first or second event and validated the demand for such a community (did enough people show up?), you can continue growing your audience with similar or varied events that slowly increase in complexity. Maybe you’ll go from a simple social to a workshop or contest. Just remember: start small, but keep growing and never stay stale!

If you’re growing your community online, keep it simple and leverage a trustworthy platform.

Platforms such as Circle.so, or even something broader like Discord or Slack, can act as the main medium that your community members can engage in. Of course, take a look at other online communities that primarily drive energy and growth via online events or interactions to see what works and what doesn’t. For example, some online groups like Crypto circles or a Discord server for a particular video game series drive engagement with daily and weekly polls, contests, games, and online chats.

If you want to host an online event or webinar, look no further than tools that already have community-specific support, like vFairs, Circle.so. Even basic weapons like Zoom or LinkedIn Streams can do the trick.

Rule 4) Set rules

Set up friendly rules that can tailor your events to specific attendees. Now remember, the goal is to remain as inclusive as you can while attendees respect and adhere to your rules — you’re the host!

For example, a set of rules for any in-person or online event can be:

• If an attendee was not accepted to an event, but they arrived at the event anyway, they must be turned away.

• Event attendees automatically consent to getting their photos taken (as per guidelines posted on the event page) for social media unless they raise concerns.

• Event attendees (online or in-person) must remain respectful to other members and are subject to being removed from event spaces if they cause disturbances.

Other Suggestions

1. Ask for advice from other community builders (both in-person and online).

2. Pick an event platform and stick to it for consistency! At PM Hive, we use Luma.

3. Gather feedback from event attendees as much as you can. Also, ask attendees what they’d want the most out of an event.

4. Market diligently but strategically — it’s okay to blast your event on all social media platforms, but also focus your efforts more deeply on tailored channels, like your own WhatsApp group or another person’s community platform (with their permission!).

📖 Emotional Playbook

Community building, unlike product development, is fortunately (and unfortunately) all about your ability to demonstrate emotional integrity and navigate millions of different personalities. It’s not easy leading a group of people who share a common interest, passion, or goal.

In my opinion — and perhaps this is subjective based on my own experiences — anyone can start a community and host a few events, but to scale and grow as a respected leader, emotional maturity is needed. So let’s dive in to understand the chops.

Rule 1) Show compassion no matter what

From my personal experience, success at community-building is a function of high emotional intelligence. You could be hosting a community event for the most technical or sophisticated topic out there — be it neural networks in machine learning or the art of crocheting dolls — but if you don’t show at least elements of empathy, honesty, and sincerity, your growth (and brand) as an inclusive and friendly community leader can be limited.

So, what are some ways you can demonstrate compassion as a community builder, and what are the benefits? Here are some examples:

• Imagine a member of your community developed a poor reputation among everyone else. How could you remain inclusive of that individual while maturely managing (and mitigating) the impact they may have on others?

• What if other community leaders or other loud voices began reaching out, targeting your community for either good or bad purposes? How would you navigate this and remain authentic to your own values?

• If you have co-founders, imagine a fallout between co-founders. How can you manage this while keeping the health (and energy) of the community intact?

Rule 2) Be as inclusive as you can, but draw boundaries

If inclusivity isn’t one of your core values, consider it heavily and the type of brand or platform you want to position your community as. But of course, as an event organizer, you have the power to choose who comes to your events. Just be aware of the impact your selections have on the general public’s perception of your community.

If you’re hosting an in-person event and your venue has capacity constraints, you can either:

• Do first come, first serve.

• Prioritize admission acceptances based on their registration (you can offer a registration form and choose based on the quality of answers).

• Prioritize based on other specific criteria.

But be aware that you may face backlash or complaints if you’re not viewed as inclusive enough (and that’s okay — just be prepared to navigate them). At PM Hive, we do try to be more selective for our conference-based events due to the amount of effort our team puts into ensuring those who put more effort into their registration form are prioritized. However, for our casual monthly socials, we try to be as inclusive as we can with the venue we have. A few tips to navigate this include:

• Providing a message to those on a waitlist that you unfortunately couldn’t fit everyone due to venue constraints.

• Stating clear criteria for admissions on the event page so you have receipts to go back to if people complain.

• Show empathy for those who weren’t admitted — let them know what they need to do to be admitted for next time.

If you’re hosting online events, then of course, the floor is yours on inclusivity — but just be sure to follow moderation rules for a specific online group, and hire (or use systematic rules) mods to keep larger crowds from creating public disorder.

Finally, don’t forget to draw boundaries against those who take advantage of your inclusiveness. This means:

• Preventing salespeople and other folks from taking advantage of your community gatherings (online or in-person) to sell their products or services.

• Showing the door to those who disrespect you or other members.

• Establishing quotas (maximum number of strikes) for those who arrive late, or prioritizing those who are historically punctual.

Rule 3) Navigate conflicts by keeping true to your values

It’s a no-brainer that a community leader should demonstrate kindness and empathy to their community members and treat all members equally, but if you find yourself in conflicts with members or being dealt a tough hand with a disrespectful individual, always pause and remind yourself:

• What type of person do I want to be in this scenario? A community leader who can establish boundaries, or someone who barks back with arrogance?

• You’ll always face people who will challenge your patience — it’s an unavoidable part of being a community leader. So, what can you do now and in the future to manage conflicts peacefully?

Likewise, if other stakeholders like outside community leaders or other partners reach out with conflicting values, always keep to your own (and the community’s) principles.

Lastly, I don’t care if you’re trying to make money off of your community. No matter what, always welcome competition and cross-pollinate if possible. The product of strong community builders is the people, after all.

Rule 4) Demonstrate modesty

Hopefully, this doesn’t need explaining — it’s one thing to be an expert in the field you’re hosting a community for, but it’s another thing to show arrogance over your knowledge.

So keep yourself in check by:

• Always displaying a growth mindset.

• Showing a desire to learn from your community members.

• Being modest yet supportive.

😀 Conclusion

Happy building — and never forget: the world can never have too much community. Cross-pollinate, show respect with clear intentions, display empathy, build smartly, and grow ✨!

Follow Kasey for more blogs and articles, and don’t forget to subscribe to the PM Hive blog!

1. Prepare a list of frameworks, but apply them intuitively

Many PMs know the typical product or business-related frameworks that they’ve learned over the years. These frameworks can help establish mental models for a PM on the job, which can optimize product decision-making and navigate through other difficult situations. For example, the good ol’ SWOT analysis or Porter’s 5 Forces are world-known frameworks; they don’t get used on a daily basis for a product manager’s project, but they can, of course, provide a mental model for how one starts off on problem exploration. A PM can use parts of a SWOT or Porter’s 5 Forces to understand their problem space and its key competitors better.

My recommendation is to always have a general (not necessarily comprehensive) list of applicable frameworks that a PM can apply in real life. Of course, this may be counterintuitive to the usual argument about how frameworks taught in online PM courses or in business school should be used sparingly or only for mental models in the workplace. Many of my own mentors have advised me to never “directly use a framework for the sake of using it, as real-life problems aren’t that simple.”

That’s why a list of frameworks at your disposal, coupled with some experience on how to establish mental models, can actually help. PMs can, of course, just use parts of a framework (where applicable) to adjust to real-life scenarios, but having a full list in hand will bring awareness to more than just the few that a typical PM knows. You could learn to fuse various models together or apply parts of different frameworks instead. This hinges on how much experience you have in applying them in real-world scenarios, but the best way to learn is to start trying.

A list of frameworks + knowing when to apply them intuitively = success.

2. Focus less on the tools and more on what your team prefers

A new PM with previous experience using their favorite triaging, ticketing, prototyping, or document tools might have to say goodbye to all of them upon joining a new team.

Tools don’t matter. Even if one truly feels they’re more productive with one specific tool over another (think: Jira vs Azure DevOps vs Trello). If a team already had a good way of executing, then a new PM trying to “disrupt” their process for the sake of “introducing new things” might only backfire.

A great mentor once told me: It doesn’t matter if you’ve got experience with Jira or Trello. It doesn’t matter if you prefer Balsamiq or Figma for prototyping. It doesn’t matter if you need MixPanel, Qlik, or Google Analytics for data monitoring. Of course, having experience with these tools vs not having experience might give you a slight edge (since you reduce the ramp-up time needed), but it’s hardly ever a make-or-break.

A great PM will focus on their fundamental craft rather than their experience with various tools. These crafts include knowing when to apply proper mental models to real situations, prioritizing backlog requirements, conversing with cross-functional teams, and writing the perfect requirement documents for other teams to understand and execute on.

So be less obsessed with your 10+ years of experience with Jira, and more with your ability to make a positive product impact.

3. Providing feedback in careful but deliberate ways

A good PM knows never to hold back valuable feedback to either their coworkers or the product. If anyone who has a growth mindset can understand, it’s that people should always be open to constructive feedback to develop as both an employee as well as a person.

But as a PM working in a tough cross-functional team of engineers and designers — one that involves many different personalities and needs — it requires some careful articulation. Here’s an example.

If one engineer is okay with taking in any type of feedback that gets thrown their way, that’s great. But some may be staunch defenders of their work or designs, with justifiable reasons backing them. Product development is always complicated, so of course, deep conversations are needed.

A great detail-oriented PM in this case would ensure to listen to every piece of reasoning from their engineers or designers. They would offer compromises or bring business justifications to logically reason it out with their counterparts. But most importantly, they will tailor their articulation of feedback based on who they’re talking to. Thus, an arsenal of ways to converse and points of logic would be useful, and a PM should always escalate to leadership (in a peaceful manner) only when disagreements can’t be solved. It’s important to learn the personalities of those they’re working with, and converse with them accordingly.

Learning to tailor your conversations based on your audience is key.

4. Always being available for your team

This one won’t require lots of explaining: as a PM, since you don’t code or design, your responsibility to be as available as you can during working hours is important for the rest of your team.

Especially for PMs who have responsibilities that overlap with project managers, needing to help unblock teammates or external stakeholders is critical. Staying on top of emails or messages during work hours to ensure your team is issue-free not only cements your reliability as a PM but also increases the trust others have in you.

This, of course, doesn’t just apply to project execution — any questions or external outreaches may flow through you first. Being available during regular working hours as often as you can (outside of meetings, of course!) can help to establish a foundational reputation across your entire team.

Be available, and be reliable.

About Me

My name is Kasey. I’m passionate about writing and product!

Follow the PM Hive blog for more product, productivity, and job-hunting tips! Check out our PM Hive events over at https://lu.ma/PMHive

Imposter syndrome, perhaps one of the biggest plagues within a PM career, can be managed and turned into confidence with proper steps.

Imagine you’re a product manager, wrapping up your day either at home or in the office. You’re reviewing your to-do list, finishing your final meeting, or sending off that last email.

Then you get a general Slack ping from another channel featuring developers or other tech functions from a different product team, celebrating a major win. You react with a cheer emoji, close the laptop, and sigh.

Are my own wins worth mentioning? Have I done enough to justify that? What have I even done to contribute to my team’s success?

Imposter syndrome is an issue that a multitude of tech functions suffer from, but product managers (PMs) are certainly one of the most popular folks that get affected. We don’t code alongside our developer peers. We don’t design alongside our designers. We (usually) don’t write content for newsletters or documentation as our main role, like a technical writer would. Yet we’re constantly suffering from frequent meetings, stress, and product responsibility when goals are missed. If the product fails to meet key success metrics, the PMs are usually the first to be blamed. So what’s going on here?

This article comprises educational steps on how PMs across all domains can learn to identify the sources of their imposter syndrome, and conquer it in the workplace by turning it into self-confidence.

Focus on IMMEDIATE value

When I first joined Planview back in October 2023 as the product manager for their new AI Assistant, I immediately realized just how ambiguous the role was. Of course, like all PMs, I was assigned key targets and goals by my boss and CTO, but the methodologies and sources of value that I needed to execute were all undefined. If I just sat there through meetings and did what was asked of me, I would have felt both inferior and like a bot. There’s way more I could extract out of myself, and I knew I had to find points of immediate value to bring to the table for all my stakeholders. So I asked — where can I focus on bringing immediate value?

I came up with the following areas, which I still do to this day:

• All forms of evangelism, including drafting and publishing content for marketing and internal usage. By doing so, I could help marketing boost my product’s engagement and drive excitement for my product. This resulted in clear boosts in adoption data, and also made me the go-to contact among all AI customers we had whenever questions needed to be answered.

• Joining internal field teams for enablement and education. Not everyone — even internally — knows how your product works as much as you do. So I had to join team meetings hosted by our Sales and Marketing leaders to educate our own people on how my product worked and the upcoming roadmap, so they could sell our capabilities to customers and prospects better. This ended up driving the majority of our Early Access program, which I’ll cover below.

• Starting an Early Access program and an inner circle with current customers or prospects to discuss the domains of interest relevant to my product. I collected as many emails as I could from interest lists on the topic of AI, and hosted various Inner Circle meetings, where I could lead an interactive call with everyone invited to chat about AI and my product’s capabilities. This helped drive my Early Access program — a 90-day free trial program to test out my product, Planview Copilot, from 0 to 50+ customers.

Whether you’re a product manager who just joined their team or have been a part of a product team for a decade, there are always points of immediate value you can identify and provide. Dig around and see where you can support your team, leading to tangible results where you can state, “I did this work, and I achieved this.”

Proactively Build Customer Relationships

Customer obsession is a key product management trait across the board; a non-negotiable habit that all hiring managers look for.

While typically B2B product management offers more opportunities to have online or in-person meetings with customers due to its nature, B2C product managers still need to find ways they can contact and build relationships with their customers (or users).

Customer relationships — almost eerily similar to that of a regular social relationship in terms of stimulation and satisfaction — reminds us why product managers are so valuable in the first place. Yes, we dictate product strategy and make data-driven and intuitive decisions for our product, but who could forget the importance of customer experience, especially for sophisticated products that need more hand-holding?

When you start relationships with your customers in the form of periodical meetings, or even asynchronous emails, you’re representing a connection for the product itself, and opening a pipeline for honest, frank feedback that could be more valuable than anything else on the job. You’re representing the face of the product to them as well as translating critical feedback into requirements. I’ve seen too many PMs in their earlier careers not obsess with customers enough, including myself.

When I started at Microsoft as a PM on the Bing Search platform team, I wasn’t establishing regular connections with neither Bing users nor the feature teams that we’d work closely with. It ultimately contributed to my imposter syndrome, because I felt inferior to my other PM peers who already had existing relationships with internal and external stakeholders. I was under the impression that those customer calls and relationships would get handed over to me on a silver platter.

Be proactive with seeking to establish customer relationships, but be respectful. Show sincerity and inquisitivity on the problems they suffer from, and don’t wait for relationships to be handed over to you.

Rethink your PM Goals

We all know how success metrics and OKRs (Objectives and Key Results) work — they’re a PM’s bread and butter for measuring impact.

Product goals have traditionally been quantitatively easy to define — north star metrics typically involve a category of adoption, engagement, stickiness, or revenue. But what if I told you that, for a product manager on the job, it’s not just about reaching quantitative goals from a product perspective?

While this sounds counterintuitive, defining goals as a PM can also be done in a more ambiguous way to help manage anxiety and realize a sense of accomplishment. It’s true that business goals like achieving adoption metrics or making millions of dollars in revenue are still the most important. But for a PM during their day-to-day activities, it may be healthier to think of goals are constant moving targets while defining their goals as what they’re doing to achieve their business objectives.

For example:

Today, I will…

• Make more progress on the requirement document for MVP A

• Have a customer call to figure out the problem XYZ more

• Educate my marketing team on the new feature we’re releasing by working on the new enablement slide deck

Notice how these goals don’t necessarily capture a final destination, but are instead methods to allow a PM to make peace with constant moving targets, and to capture the effort they put in on a daily basis, even if it’s the smallest change or a nuanced task that may not get represented in their product’s success.

It’s a Source of Growth

Learning from mentors and seasoned professionals is one of the most effective ways to navigate imposter syndrome. Those who have been in the field longer have likely faced the same doubts and uncertainties, yet they’ve developed strategies to manage them.

Whether it’s finding ways to deliver immediate value, building meaningful customer relationships, or redefining success beyond rigid metrics, experienced mentors can provide insights that make a real difference. More importantly, their stories remind us that imposter syndrome isn’t a sign of incompetence — it’s a challenge that can be overcome with intentional effort.

Beyond the advice itself, mentorship offers perspective. When you hear how others have struggled with similar feelings, you begin to see that self-doubt is often a byproduct of ambition rather than an indicator of failure.

The key is to absorb different approaches, experiment with what resonates, and craft a personal framework for confidence. Some may swear by meticulous goal-setting, while others lean on peer validation or customer feedback. There’s no universal solution — only the process of refining your own approach over time.

At the end of the day, the goal isn’t to eliminate imposter syndrome entirely but to transform it into a source of growth. The very doubts that make you question your worth can also push you to improve, learn, and adapt. By proactively seeking ways to contribute, engaging with customers, and reshaping your definition of success, you shift the narrative from insecurity to self-assurance.

And as you progress, remember: confidence isn’t the absence of doubt — it’s the ability to move forward despite it.

1. Learn the System Architecture of your a Product/Project that’s SIMILAR in design.

This sounds like common sense, but some people get lost in the weeds.

Learning about system architecture is scary for those with non-technical backgrounds. There are questions such as, “Where do I get started?” and “I can’t learn so much material in such little time.”

But an easy way to get your mind flowing is to simply:

1. Find out what product or project you’re interviewing for.

2. Learn the system design of it.

Of course, it’ll be hard to find third party resources available to learn exactly what’s under the hood of any prospective team’s product. So do the mindful and learn the system architecture basics of how a generic version of that product would work. Here are some examples:

• If you’re interviewing for a mobile food app, then explore a tutorial on how to build a more basic food app yourself on YouTube.

• If it’s an API, then obviously, learn the layers of how an API works.

• If it’s an analytical dashboard, maybe pick a few open-source examples which are pulling from different data sources.

If a similar product (like a competitor!) exists, and the resources to how that said product works are more readily available, then boom, you have an advantage.

Of course, for non-technical folks, general software knowledge is also useful. It doesn’t hurt to learn the basics of coding and how software is built (layer-by-layer would be helpful!). Knock back any fear and stand tall with a growth mindset bathed in humility. Try some basic stuff, and check out how basic apps — across any platform of your choosing — are made, so you that serves as the first step. Next is when you should do the above and dive deeper into the product area related to the one you’re interviewing for.

Get your hands dirty in creative yet tailored ways.

2. Prepare to talk about your failures as much as your accomplishments.

And perhaps, even boast about those failures; here’s why.

While it’s great and all that everyone brings their set of accomplishments to the table, a defining trait that sets you apart to all hiring managers is your ability to walk through certain work failures and the lessons learned.

In product management, it’s common to make small mistakes or failures — this can be the product launch, go-to-market strategy, prioritization, or even smaller decisions. A strong PM would never falter; it’s important to learn from mistakes to ensure the team succeeds in the long-run, and to fail fast. Being able to demonstrate your desire to fail fast and to learn from mistakes reflects the genuine dedication you show to your product and the product team. Any hiring manager appreciates that.

Ultimately, employers want to observe whether you’re willing to take risks, and what better than to ask about your past experiences?

Your accomplishments are the gold standard, but never pretend like you never encountered any failures. To have achieved so many accomplishments meant that you probably had to tread through mud to get there. Explain that process.

3. Talk in point form when demonstrating your ability to learn from failures.

While we’re on the topic of failures, I think it’s important to articulate your learning lessons in a rather fashionable way.

PMs often have to talk in point form anyway to their colleagues — it’s quite common, as it helps bring clarity and such when it comes to decision-making or explaining product decisions. This helps a trillion when it comes to explaining your past product failures; both the types of mistakes you made, and the learning lessons that came with it.

It helps if you’re pairing every accomplishment you’ve achieved with a mistake or failure to go along with it. It brings out a more human side to your ability to manage products. Doing so in point form, like the below example, helps make things easy to understand:

“While we did successfully launch the feature and achieve our objective, there were several mistakes I made along the way.

“First, I should’ve consulted with the Legal team earlier about a certain data usage risk that our feature entailed. Second, I could’ve raised the risks of launch delay due to limited capacity a bit earlier with the team, so they could plan some alternatives. Instead, we needlessly risked it.”

All in all, it’s about pairing your sincerity with structured articulation.

4. Don’t just practice product design questions — focus on the problem space of your prospective employer.

It may be useful to learn from the books on product design interview questions, but these days, employers care more about how you approach their problem space.

Take for example: Microsoft Bing. There are obvious challenges for anyone who could guess: competition with Google, high quality search results, and gaining ground with the new AI chat feature. If I were to go into the interview with this team today, I would try to understand the problem spaces more deeply beforehand. The main questions I’d think about are: what matters more, search quality or product design? Where else can the power of LLMs and OpenAI models be leveraged in the Microsoft ecosystem? How does a search engine stack work?

Approach your research and practice with context on the deepest challenges related to your prospective employer.

Conclusion

Never forget: product management interviews are hard. It’s still going to be a long and competitive road to drive, depending on where your starting line is. But keep in mind these suggestions I mentioned today, and you’re well on your way.

About Me

My name is Kasey, AKA J.X. Fu (pen name). I’m passionate about writing!

Follow me on Medium for more writing, product, gaming, productivity, and job-hunting tips! Check out my website and my Linktree, and add me on LinkedIn or Twitter, telling me you saw my articles!

As AI products continue to surge in popularity thanks to both endless VC investments, internet hype, an endless stream of use cases, and a seemingly boundless set of possibilities, the practice of product management has also experienced subtle changes. But while the fundamental skills needed by a product manager (PM) to drive their product to success haven’t changed, there is a clear difference in how all AI product development should be approached.

1. Best Practices for Product Development are still being defined & refined.

Traditionally, technologies such as B2B SaaS, mobile apps, and e-commerce have better-established best practices and guidelines when it comes to both product development and product iteration. Here are a few examples:

• In enterprise B2B SaaS, depending on the use case, customers (such as clients and partners) often have an idea of the value and the problem they’re trying to solve. Engineering teams can work with customer-facing teams to ensure those requirements are translated into a product via modern or traditional development cycles.

• In many other traditional industries, product shape or form can vary but can follow the same underlying set of methods: some form of scrum or kanban, a backend engineering team, a frontend engineering team, a designer, and a product manager. From there, they would follow an iterative process of ideation and requirement gathering, backlog triaging, running sprints, and tracking dependencies. This method allows for use case discovery to be scrappy, iterative, and agile.

As you’ll soon see in lesson learned #2, the challenge of discovering the best “killer use cases” becomes apparent in the AI space. Many development teams follow the same model of leveraging some sort of large language model (LLM) in their product, with an underlying “platform” either developed in-house or borrowed from an AI platform such as Azure AI or AWS Bedrock. Some products even have multiple LLMs (large language models) that focus on specific use cases depending on what’s asked by the user (the prompt). These can be developed in-house or found through enterprise solutions in the form of “AI agents” (such as the Generative AI Agents by Oracle).

Because of this nuance, product development practices for AI-powered products remain a blur. Questions targeting engineering operations or the product life cycle still remain unclear. For example:

• Should we have a dedicated backend team only focused on building these “AI agents?”

• How do we operationalize these AI agents and monitor them?

• Who helps monitor and foot the bills for the LLMs being used — or how do we even divide the costs reasonably?

• Because of the lack of clarity on “killer use cases,” do we focus more time than normal on product discovery instead of delivery?

Best practices for product development remain a gray cloud, but as more organizations adopt AI-powered solutions, we’ll all collectively approach the light in the tunnel.

2. Depth of Use Cases > Breadth of Use Cases

This may sound like common sense in the world of product, but there’s a certain “AI flavor” that differentiates how PMs would approach product development.

With LLM models now widespread and generally available across numerous platforms and consumable through public APIs, thousands, if not millions, of tech startups have ventured into the AI world in hopes of solving a key set of problems. The nuance begins right at the beginning of problem discovery: PMs soon find ourselves in the deep end, finding out that LLMs aren’t solving for their initial “brilliant” idea as well as they thought, and thus begins the “iterative testing cycle” with AI.

Many teams attempt to solve one idea at a time with AI, failing fast and receiving feedback from customers as they go. In general, many use cases — especially those in the software productivity space — tend to fall into the following categories:

• “Needle in the haystack” discovery. For example, “What work item should I focus on today?”

• Breaking work down into smaller components.

• Summarizing all content into a simplified message.

• General help guidance is based on the provided documentation. This one is interesting, as it usually relies on an AI-based technique called RAG, which stands for retrieval augmented generation. Generally, content stored in a repository of sorts would be referred to and “retrieved” by the AI bot so it could use it as a reference in its answers. An example would be, “What are some best practices to do XYZ?”

• Some sort of niche “action” that the AI product can help do for you as part of a larger overall user flow or process. Imagine a developer trying to create a new repository structure for a newly defined web project — and then some form of AI creating all those code files for them to replace the otherwise manual effort needed.

But developing products with generative AI (GenAI) inherently introduces a dependency on a clear “AI-enabled” use case. The problem lies with GenAI itself: with such a powerful technology and the amount of data trained to develop these LLMs, it becomes unclear where the true value and set of use cases lie.

Just look at Atlassian’s newly announced Rovo or Microsoft’s 365 Copilot. Each AI-enabled Copilot aims to solve a certain set of use cases, but it’s clear that some use cases are better performed by AI than others. Time will tell as more players in the industry continue to discover new abilities and niches that AI can conquer.

3. Work Diligently with Higher Context Windows.

Before I dive in, let’s educate everyone on what context windows are in relation to LLMs. When a user types a prompt and submits it to an LLM (such as the textbox you can type into in ChatGPT), the amount of content you can type in constitutes the context window. It represents the amount of context — or information — you’re providing the model for it to refer to when it generates its response. A simplified example would be:

Today’s temperature is 30 degrees Celsius. Tomorrow, it’s 80 degrees Fahrenheit. Now tell me, what’s the difference in temperature between today and tomorrow?

That first line — the one depicting information about today’s and tomorrow’s temperature — sets the context for the main question you’re asking.

Even with Google Gemini releasing a 1 million context window as of May 2024, it’s important for many PMs and AI developers to understand the retrieval limitations AI still faces — especially in products that absolutely must not make mistakes.

More content being thrown into an LLM, either within the context window, through the RAG, or both, will mean more data for the model to sift through and filter. This ultimately lessens the chance of the model finding the most optimal pieces of information that ultimately provide the highest value based on the user’s question. What many developers will find is that while AI exhibits immense creativity with the data it’s fed, it can often result in inconsistent answers if the pool of information becomes too vast. Another common side effect when dealing with large datasets (and thus larger context windows) is the sheer amount of time needed for AI to process everything to generate a response.

Working with a product team developing an AI-based Copilot myself, I’ve witnessed this first-hand. There’s both a dependency on computing resources and the speed at which the model can process the large amount of data, and answers can often take well over a minute to generate, depending on the size. A 1 million context window introduces numerous opportunities for the model to discover certain patterns or key points (thus the “needle in the haystack” use case), but it faces a battle against both the time it takes as well as the consistency of answer quality.

4. We’re all dependent on Compute & Infrastructure.

There are so many dependencies to track and make note of when building AI products, to the point where more are being discovered every day. With the obvious one being the need for tokens, GPUs, and computing power, let’s look at some that founders and PMs will have to watch out for:

• Fighting for PTUs (provisioned throughput) when using third-party LLM infrastructure. This type of throughput within a deployment of an AI model determines the amount of processing power you get (and thus the number of machines allocated to you) when using an AI product. For example, if you’re borrowing Azure AI’s infrastructure and using the GPT4 API, you may have to pay for additional PTUs to get faster processing time and, thus, faster response time in answer generation.

• Token processing costs.

• API availability/uptime.

• Costs: both LLM and infrastructure costs.

I’ve really only scratched the surface; there is a plethora of dependencies to think about when leaning on third-party LLM APIs, computing power, and infrastructure. Almost all startups and side projects rely on these (now widely available) services, so it’s important to calculate the risks of cost, API uptime, and, of course, processing power.

Sometimes, it could result in the AI service being overloaded with users trying to process the models simultaneously, resulting in the service being unable to generate a response at times. Just look at Microsoft Designer below at 11 PM PT on a Wednesday evening:

You’re fighting for your spot in line!

About Me

My name is Kasey Fu. I’m passionate about writing, technology, AI, gaming, and storytelling 😁.

Follow me on Medium for more passion, product, gaming, productivity, and job-hunting tips! Check out my website and my Linktree, and add me on LinkedIn or Twitter, telling me you saw my articles!

Many in and out of tech think product managers are the “holy grail” of any product team who work with cross-functional teams while getting to define everything. Well, if you enjoy the role as much as I do, you’ll still be satisfied, but you’ll understand the differences between theory and reality.

Let’s first state what textbook product management is, and then dig into what real product management is.

Ever since my first exposure to product management through internships back in college, I’ve been obsessed with both the title, career path, and job responsibilities. To me, who was someone that loved working with others while being the center of everything, the PM job was my dream.

What Product Management is by Theory

As someone who was just starting out — first by way of online (and in-person) courses and then through internships, I developed a naive perception of a PM early on. I thought the following:

• Product managers got to own their product’s entire strategy, roadmap, and vision, end-to-end. Some even consider themselves the “CEO” of their product (while leading without authority).

• Product managers get to be the face of it all and own a lot of decision-making for their product itself, and subsequently, their backlog.

• Product managers get to merge their business acumen with a technical product mindset, and track success with key product metrics.

• Product managers get to analyze and/or query data (or do A/B testing) to make informed feature decisions.

• Product managers got to draw wireframes or concepts and work with designers to capture their idea for the full product experience.

Now you may be thinking: “hold on a second, this is actual product management.” And you’re right. Put it simplistically, this is product management. But my point is not to refute these responsibilities; it’s to point out that realistically, things are much more complicated than they seem, and product management varies greatly from team to team, so much so that it’s arguably one of the most dynamic jobs in tech. In other words, you’re not guaranteed to do all of those responsibilities I pointed out above; you might do a twisted combination of some of them, or you’ll have to dip your feet into some more operational tasks based on the requirements of your business or team.

In my personal opinion, venn diagrams like these just paint the role with an unnecessary and simplistic picture:

This makes it seem like the PM is the center of all things product development, and get to own a piece of every process. While this can be true in some cases, often times your role is much more complicated than just these three circles.

Looking back in retrospect, I can understand why I thought product management to be the “holy grail of all tech jobs.” First, many books and courses talking about product management are going to be slightly biased in their content; it’s natural. Not only is it to upsell their stuff, but it’s also to paint the job with a slightly rose-tinted glass. If product managers got to own so many impactful areas, such as their team’s product strategy, long-term vision and roadmap, then of course everyone would want to double-click on that idea and promote that for marketing. Not to mention the notion of “cross-collaborating with everyone in their product team and demonstrating user empathy.” Everything people lay out make product management sound like a dream job for business-minded techies who don’t want to code. Of course everything is partially true, but you can’t just forge a simplistic view of product management that way.

Real Product Management

I’m not saying to lower your expectations; I’m asking you to change them, not because product management isn’t fun, but because each team does things so differently. Focus on what your team needs and it operates, not chasing the dream set of responsibilities that product management typically entails.

Here are my 6 key nuances of real product management:

1. There’s no “one size fits all” with building products and establishing processes. This we’ve established; there are products in all shapes and sizes, which impacts what your teams will look like too. You’ll have to fit and conform to what’s best for your specific team. Following the general responsibilities a PM is allowed to do without considering the specific needs for your team could be detrimental. For example, what if you worked on a database product that badly needed to be migrated from in-memory to cloud? Suddenly, you’re working with engineers more closely on an execution level than product strategy or with any designer. Unless you’re super technical, engineers may get more say in what goes into the product than you simply due to the nature of it.

2. Some mundane, operational (or executional) tasks could come your way. Building off of my first point, based on the specific needs of your team, the PM (Especially one that’s more junior) might have to handle more execution or operational work than strategy work. Just think about it: setting up meetings, taking and sending meeting notes, writing documentation, handling capacity management, and sending weekly/monthly reports. This could stay especially true for a start-up, where people have to wear more hats anyway.

3. You have to remember that humans have emotions and opinions, and a PM must trek carefully. On paper, making decisions and prioritizing may sound fun, but in real life, managing piles of chaos with human emotions and different personalities can be eye-opening. Honestly, take a look at Dr. Bart Jaworski’s article on why real PM is different than Theory here, where he mentions this point.

4. You can’t forget that you’re working with seniors and a PM manager. Many courses, curriculums, and books teach you how empowering being a PM is, but in reality, there are still some non-negotiable deeds that you must fulfill for seniors or your own manager. I’m not saying that’s bad — I’m saying it’s a reality that some people forget.

5. Sometimes, you have to come up with the right tools and processes yourself. It surprised me how loosely defined these structures were in my previous team back at Microsoft, despite the company being obviously massive and product-focused. You’d think there’d be a unified, structured, and very streamlined way each team would do product! Instead, each team has completely different methods of operating and executing, which makes sense, given the diversity of products and people. Just like any other company, PMs would have to adopt best practices for their teams themselves, which is fair. These could include user research tools or practices, OKR tools, prioritization frameworks, and even dashboards to track bad user feedback. Heck, I’ve heard from others that they observed this at Google as well.

6. Since you’re the center of many business functions and product decisions, you’ll definitely need some self-time to gather your thoughts, undress the chaos, and organize things with clarity. Constant context-switching is normal, so you’ll need A LOT of time to “think,” “organize thoughts,” and do “research,” but you’ll always struggle to find that time. Why? Cause you’ll probably be in too many meetings to get enough focused work done. For example, let’s say you’re a PM for a new AI-based marketing tool. You already have a bunch of “to-dos” related to researching the competitors and organizing your roadmap for the next quarter, but you also have 3 meetings with other business functions related to product execution, a meeting with another PM to discuss how your tool relates to theirs, a customer research meeting, a bunch of design requirements, a meeting with your boss and the CTO, and you need to give a few presentations (with slide decks you haven’t started on yet) both today and later this week. Not to mention the countless emails and Slack/Teams messages you’re getting on a daily basis which could cover just about anything. Each day would give you only 2–3 hours max for focused work without meetings or distractions.

Conclusion

Remember, this is coming from someone who absolutely loves being a PM. I wouldn’t trade my profession for anything else in the world. I hope I didn’t paint a poor picture, but rather a more realistic one. I urge all prospective PMs to ask the right questions during their job interviews, understand their team, and to adapt the best way they can. Cheers and good luck!

About Me

My name is Kasey, AKA J.X. Fu (pen name). Follow me on Medium for more writing, product, gaming, productivity, and job-hunting tips! Check out my website and my Linktree, and add me on LinkedIn or Twitter, telling me you saw my articles!

In a world full of so many career opportunities, noise, and seemingly successful influencers experimenting with a multitude of media platforms, it’s no wonder our idea of “chasing a passion” has become so distorted. The very notion of aligning one’s passion with a career has introduced an abundance of questions, and in this article, I want to dive deeper into how young knowledge workers (especially Gen Z) will know if they’re trending down the right career path in life.

When I say passion, I’m encompassing everything including its dictionary definition as well as the realistic societal use to describe any sort of topic, hobby, interest, or activity that brings joy to human lives. One plain textbook example for Gen Z would probably be video games — so a question perhaps one could ask is, “I grew up on video games and I’m passionate about them. Should I become a video game developer/designer?”

I’m currently writing a book on a deeper expansion of this topic: what are the best practices to combine one’s passion with a sustainable and fulfilling long-term career? Below are a few high-level answers that only scratch the surface but will get readers thinking harder:

1. Passion Validation

Many of us are passionate people; we dream of achieving big things in life and accomplishing mountain-high goals that are shaped by an underlying passion that fuels everything we do.

This very definition of passion begs many question marks, such as the all-time “Should I quit my day job and chase my passion?”

But while this notion sounds inspiring and motivating, I want all readers to step back and think: how can I validate that I’m willing to suffer in this passion of mine?

The idea of “passion validation” really stems from my argument that people tend to be overly obsessed with the end vision or dream of an idea, rather than the actual hurdles of reaching said dream. That end vision ends up being the main catalyst propelling people to chase their passions without first understanding the requirements to get there. For example: if a businesswoman loves sports to the point where she dreams of becoming an analyst for her favorite hometown team, is she willing to suffer through years of rejection, grinding for connections, skill development, politics, and unpaid internships? Because those foundational activities are the actual low-hanging fruits they should focus on enjoying first rather than being infatuated by the end goal.

Validate whether you’re truly willing to suffer and fail fast for something vs. just liking the vision of success. You need to be truly willing to suffer through the hard times. If you can’t suffer through a career field’s worst, you don’t deserve its best.

2. Block noise from social media

Our digital age of content and entertainment is vast and seemingly endless. As Cal Newport stated in his 2016 book Deep Work, we have digital slot machines in our pockets at all times.

Notifications, buzzes, and rings all fill our days with dopamine-seeking social media consumption on our phones. And while not all consumption is bad, some of it can distort our perception of reality and how we perceive the notion of success.

Think: when all our favorite influencers and digital creators live their best lives and showcase only smiles across their faces through a lens, it makes us think we’re missing out while we stay “stuck” at our day jobs. But is that the case?

To provide a clear example, think of a video game streamer on Twitch you’re fond of. They may have achieved moderate or even astounding success (either financially or in popularity or both), and it’s influenced you to take that first step to become a streamer as well.

It’s okay to be influenced like this and to curate a dream for yourself by seeing the success of others. But my suggestion is to play it smart: validate that you’re not only passionate about the end picture or dream but rather the actual work it takes to get there. Are you trying to become a streamer because you daydream about certain scenarios if you became one, or is it because you’re aware of the hurdles and challenges with the actual work needed, and you’re ready for the battle? Plan your strategy out. After all, you’re sacrificing your own precious time to experiment! The path to success is long and not always fun; the content we consume sometimes makes it appear as if fun is all that ever exists.

Social media has the power to allow creators to cherry-pick the “best” depictions of their lives to show their viewers. While this is fine in moderation, I urge everyone to be more wary that what they see online isn’t always the same as reality.

3. Build and Produce — Focus on Skill Development

One of the most simplest yet hardest suggestions in the world of passion-chasing is to simply put your head down and build or create instead of blabbering on about an empty box of nothingness.

This helps two things: first, becoming a builder or creator enables you to obtain a critical skillset valuable in today’s market, which therefore accelerates your path to a dream job in a dream industry. Second, and perhaps equally as important, it helps you build the right habits to succeed.

I wrote this article on the art of building and producing while others are distracted in a world of digital attention. Slowly develop habits for producing content or creating value instead of content consumption.

Of course, I’m not telling you to become a workaholic. I’m suggesting to visit other forms of entertainment that may add greater value to your life. A good starter might be picking from various crafts, side projects, writing, reading, exercising, or anything along the lines of “value-creation and/or knowledge/skill development. Learn a new instrument, write a book, start a blog, or pick up a sport! Establish healthy hobbies to replace your old dopamine cravings. Focus on skill development rather than public acknowledgment.

4. Avoid the “Nostalgia Trap”

Some of us were lucky enough to experience a wonderful childhood or upbringing, culminating in glorified memories filled with glitter, charm, and fantasy. Obviously, I’m not speaking for everyone here, but for those who can relate, I’m sure you understand why this term even exists.

For those who don’t, the “Nostalgia trap” refers to the phenomenon where people get caught up in an idealized or romanticized view of the past. But instead of connecting its dictionary definition to how it leads victims to avoid embracing change or progress, my angle is more about how it could both boost and distract one’s career journey.

For example, millions of us from a younger generation grew up cranking up hundreds of hours playing video games that have since shaped our childhood and our love for fictional entertainment. Without first validating whether they enjoy the challenge of problem-solving, politics, stress, risk of layoffs, and failure of product success, they dive head-first into the games industry, hoping to live their childhood dream of becoming a game producer, designer, or developer.

Subjectively speaking, it’s okay to chase a passion based on nostalgia. But our generation needs to be wary of reality and focus on becoming passionate about the challenges associated with chasing their nostalgia. That’s why it’s called the “Nostalgia Trap.”

Conclusion

In a digital age of content, resist the noise and focus on your own career goals. Not everyone in the world is as successful as social media makes them out to be. Keep your head focused, build and produce brilliant content for a niche yet engaged market, and avoid the nostalgia trap by embracing the challenges that come along for the ride!

About Me

My name is Kasey Fu. I’m passionate about writing, technology, AI, gaming, and storytelling 😁.

Follow me on Medium for more passion, product, gaming, productivity, and job-hunting tips! Check out my website and my Linktree, and add me on LinkedIn or Twitter, telling me you saw my articles!

While I know there are many generic suggestions out there for stress management, such as “understand some things are out of your control,” or “your product success doesn’t define you as a person,” I find that advice in-actionable and lacking real-world value. Who would want to find the same advice their relatives provide in an article online?

So here are 4 pragmatic ways a PM can realistically manage their stress, pressure, and workload 🔥.

⏱ Reset your plate by reviewing everything you’re handling/working on, and prioritizing them all in a list.

I’ve done this multiple times while I was at Microsoft, and have already done it once while here at Planview, leading their AI Copilot project.

When you’re a PM on a growing product, you’re almost certain to crash into chaos, where many things are happening at once. Think about it: stories/epics, strategy documents, new marketing initiatives, announcing releases, contributing to technical operations/strategy, creating onboarding content, product evangelism, sales enablement, and other items that spring up unpredictably. This doesn’t even include the abundant meetings that clog up your schedule (and result in more follow-ups as well).

When this (inevitably) happens, it’s important for PMs to step back and “reset their plate”: reflect on all that’s happening, and jot down a top 10 list of items that are currently happening in a prioritized manner. As you craft this list, it’s important to weigh its value based on ROI and alignment with your own mission as a product manager for the company.

One such list could look like this 👀:

1. Spending time working on the product roadmap for the next quarter. ROI: High, Alignment: High

2. Work on a partner marketing program to get vendors to market our product, ROI: High, Alignment: Med

3. Draft a spec for an internal tool needed to analyze bugs. ROI: Med, Alignment: High

4. Write a new training blog for first-time consumers as part of the onboarding experience. ROI: Low, Alignment: Med

5. Hold weekly meetings with other engineering directors on the new release strategy proposed by management. ROI: Low, Alignment: Low

Reset by jotting everything down, analyzing, and prioritizing.

📆 Start declining unnecessary meetings with justifications, even if you’re relatively new.

The biggest mistake I made within my first few years on the job was essentially accepting every meeting invite sent my way. Meeting had no context? Accepted. Meeting about something we could’ve chatted over Slack/Teams or email about? Accepted. Meeting to chat endlessly about your next dinner recipe? Accepted.

Perhaps it’s that feeling of being too junior to decline meetings. Or — and this happened to me back at Microsoft — a lack of technical/domain knowledge within my first year led me to believe that every meeting was crucial and destined for me to learn something.

Now of course, in your first three to six months, it’s appropriate to accept meetings you vaguely know the context for since the purpose is for you to gain that context. But soon after that six-month mark, you’ll start figuring things out and gain more confidence to reject certain invites that you think are irrelevant to your goals.

If you’re not the “rejection” type of person, the next best alternative is blocking time off your calendar for “focus” time — A.K.A deep work. As a PM, you’ll most definitely encounter shortages of time for you to get your own work done due to the abundance of meetings/calls. Manage things carefully the best way you know how by either rejecting irrelevant invites or blocking hour-long time slots on your calendar to catch up on work.

Manage your time and be conscious about the meeting invites you receive. Are they a top priority based on the top 10 list crafted (introduced above)?

🗒 Draft Personal “PM” KRs.

I know this is the most “PM” thing you’ll ever hear — but c’mon, sometimes you just have to live the stereotype. OKRs are not just an important structural model for business growth, but also for PMs to align their day-to-day jobs with their higher objectives.

What I tend to do is first evaluate my organizational OKRs: the objectives for the product I’m owning, and the corresponding key results which include success metrics/goals that I would need to track. Then, based on those metrics, I self-assign “personal PM” KRs.

An example of how I translate organizational KRs to personal PM KRs:

Organizational KRs for the year:

• Grow the DAU of the platform integration feature by 50%

• Increase customer NPS by 20%

• Grow enterprise and consumer bookings growth by 30%

The personal PM KRs for the year are tied to these:

• Ship the new API for the platform integration to enable 50% DAU growth.

• Dedicate >50% of the entire product roadmap to just customer feedback to grow customer NPS by 20%.

• Conduct 50 demos and 10 training videos as part of the onboarding process to grow bookings growth by 30%

Write a list of KRs for yourself that match the success metrics of your product, and review your weekly workload to ensure your projects align with your KRs or success metrics. It keeps you laser-focused on a core set of priorities out of what otherwise would be a whole chaotic storm of requirements and “things to do.”

🗣 Grow your “storytelling” skill and use it.

And before you claim that this has nothing to do with stress management, my argument is that storytelling drives positive stakeholder management, which is one of the main factors in stress management.

Stress for a PM could potentially stem from leadership pressure or even a strained relationship with your own boss. I believe that bringing clarity to the story of a given tense situation — not just speaking like a robot, but tailoring your story to a particular audience with empathetic elements — can help surface collective understanding 💪.

In my previous article about stakeholder management in PM, I cover the importance of storytelling to bring full end-to-end context and clarity to complex or nuanced situations. This skill applies to numerous scenarios, including prioritization discussions, customer calls, and leadership reporting. Here’s an example involving storytelling:

Product manager: “We’ve missed our DAU target for this quarter by 5%.”

Leadership: “How? And what are the detrimental effects?”

Product manager: “At the beginning of the quarter we were focused on growing DAU and that reflected in our roadmap, which was mainly feature growth-focused. However, halfway through, we suffered retention issues despite strong growth in adoption. This led me to believe that our platform and infrastructure as a whole had major performance issues, and we needed to pivot, otherwise the value of our product would never surface properly and live up to expectations compared to our competitors.”

This is just a simplified example, but as natural storytellers, PMs need to tailor to their audience and aim for collective clarity and understanding.

🔚 Conclusion

Stress comes at so many levels and types for a PM thanks to the boundless sources that drive us into the ground. It comes with the territory; it’s a natural part of the job. But we have room to take responsibility to manage this stress by being resilient and smart. Happy PMing!

About Me

My name is Kasey Fu. I’m passionate about writing, technology, AI, gaming, and storytelling 😁.

Follow me on Medium for more passion, product, gaming, productivity, and job-hunting tips! Check out my website and my Linktree, and add me on LinkedIn or Twitter, telling me you saw my articles!

With the product management discipline growing more popular than ever, there’s little reason to argue against its growth. More organizations across both tech and non-tech environments are seeking strong PMs to help manage stakeholders, drive product success, and own responsibility for the roadmap. It’s both a lucrative and inspiring role that shines a spotlight on someone in a way no other job can.

PMs are always expected to demonstrate strong energy from the get-go after they join a team; if the product and problem space is a good fit, they’re naturally inclined to demonstrate a strong motivating drive.

It’s not difficult for great product managers to feel energized about their work, especially in the face of success. But that’s not always the case; some PMs lose some of that motivation after a while due to many factors, so instead of pin pointing on the causes, let’s dig into four suggestions to ensure the spark is never lost.

💬 Both you and your team must stay engaged with each other.

Product management by nature involves building relationships with a multitude of parties. Imagine a single person having to empathize with so many different individuals and dependencies; it’s no wonder PMs are known as perennial stakeholder managers with seemingly infinite energy.

But while engaging with all parties can appear important, PMs must focus their energy on the engagement they have with their closest functions. These most likely consist of your main developers, engineering manager, boss, designer, and marketer.

Strong engagement doesn’t just mean clear and constant communication. It also entails a sense of trust that underpins the relationship you have with each of them. For example, if an executive or an external customer asked for a feature that your team deems unfeasible, your developers shouldn’t be afraid to raise this with you privately or in a group setting. The PM should also feel comfortable enough to ask stupid questions, such as “Why?” and “Here are some alternatives, what do you think?” and continue the conversation in an engaging matter.

It’s really these small nuances that truly uplifts the motivation of a PM — if you don’t stay in constant communication and maintain strong relationships with everyone, things start to deteriorate. For example, you may feel you’re less involved in decision-making, unimportant, or you’ve lost the trust of your team members, which could spiral into further lifelessness. Maintain a strong sense of trust among your team by demonstrating your product thinking (using frameworks or listening to users during development), and by telling the full story of each feature request (Who is the customer? Why is the ROI high?) end-to-end.

Stay engaged, maintain strong relationships, and earn your team’s trust.

➕ Recognize how you bring value.

Delivering impact and value as a PM and the battle against imposter’s syndrome is a tale as old as time.

I wrote a whole article about the challenges PM face when it comes to the syndrome. Read it if you can. For those who know about the syndrome: to be quite frank — and this may come out as subjective — I think the true value a PM brings to the table correlates with their motivation. Here’s why.

True positive impact can be hard to realize as a PM since we usually don’t code or design. I’ve asked myself this constantly: “Well, then what am I doing here and why? Where is the impact that justifies my salary?”

The answer lies in the small nuanced bits of value that strong PMs absolutely bring to a team, which pay dividends down the road. This consists of bringing clarity among stakeholders, driving product direction through a roadmap and clear strategy documentation, prioritizing all feature requests for the team, and building strong relationships with the end customers too. Not to mention the blogs, educational content, newsletters, emails, and internal/external forms of evangelism that a PM can help with to drive product growth.

Besides product and business success, once a PM can fully recognize everything they bring to the table, they can grow more energized and motivated. They’ll know exactly what tangible value they provide, and how they stand out as unique employees in an otherwise smart and hardworking team of developers.

Recognize your own value as a PM. Understanding the value of your PM skills will result in a symbiotic relationship that grows your motivation.

🧑‍💼 It’s not about the company, it’s about your boss

I’m concluding this article with a last tidbit that isn’t exactly pretty but real: A PM could land their dream tech job at their dream company or industry, but if they have a boss that doesn’t care about them at all, that experience goes down the trash bin faster than a trash chute.

In my upcoming book about how young knowledge workers can combine passion with sustainable work, I’ll be highlighting the importance of a good boss as one of the key factors. As common sense as it is, readers can still learn a thing or two as I dive deeper.

I’ve been lucky enough myself to work with managers who care both about my experience and development as well as the business. But I’ve chatted with those who weren’t so lucky, and my hunch is correct: staying motivated as a PM really hinges on that PM-boss relationship.

Before you jump into any PM role, make sure to ask the hiring manager (or whoever you’ll be reporting to) these set of questions:

• What type of culture do you have to ensure your team stays energized?

• What does a strong PM look like to you, and do you think the team can set them up for success?

• Are you able to make time for weekly 1:1s, not just for business progress, but also for career mentorship? If not for the latter, would you be able to assign me a mentor?

🤗 Take responsibility in seeking mentorship.

I’m alluding to the value of mentorship in that last bullet; having a strong PM mentor in your company can make an enormous difference. You can ask them the stupidest questions, but you can also rely on them for political and management support. It acts like a home phone in most households: often nearby and attainable, but seldom used to launch a fulfilling career.

If you’re a current or aspiring techie and looking for some mentorship, I recommend Merit. It’s free and it allows you to seek the perfect mentor profile that fits your needs the best. I’ve used it as a mentor, and I’ve seen some great reviews from fellow mentees (not talking about myself but for other mentors, obviously :P)

Build a strong relationship with your boss, and seek mentorship!

🤜 🤛 Conclusion

Aspiring product managers grow energized by the product role when they learn about the opportunity to see their idea get built from start to finish.

All in all, it’s really about four key aspects: finding the right environment, staying engaged with communication and trust, working with a boss that cares about you, and keeping yourself responsible for your own motivation through mentorship or finding a better fit elsewhere.

You could be a strong PM with a strong foundational skillset, but still lose motivation due to various factors I mentioned or even missed. On the flip side, you could be a relatively new PM but achieve success faster or more easily because you’ve been set up well for it within your environment. Both can happen, and it’s important to ensure PMs stay motivated and respond/act accordingly if they realize they’re losing motivation.

Keep that drive up, and your product success will reflect it!

About Me

My name is Kasey Fu. I’m passionate about writing, technology, AI, gaming, and storytelling 😁.

Follow me on Medium for more passion, product, gaming, productivity, and job-hunting tips! Check out my website and my Linktree, and add me on LinkedIn or Twitter, telling me you saw my articles!

The Strategy for 2024

With a job market barely crawling out of misery and an economy more obsessed with product management than ever before, of course, the road will be challenging.

Undoubtedly, the “product manager” position has blasted off in popularity. Based on statistics by Steve Bennett on Webinarcare, interest in the search term “product manager jobs” has increased by 270% since November 2014 (over 9 years ago). While popularity has become more widespread, here are my 4 tips to stay unique in the job hunt.

1. Don’t overthink the product management interview.

While leveraging frameworks and mental models has always been “PM tradition” in an interview, I’d recommend an alternative way to approach your questions, especially product-sense ones.

People get anxious about tough “product-sense” questions which often get thrown their way like a curve ball. Stuff like “What’s your favorite product? How would you improve it?” or “Solve the problem of food waste by designing me a new product” can cause goosebumps.

My suggestion: don’t think too much about one specific type of question; you’ll never know what the interviewer has in store for you. You really don’t. Yes, you could practice all types of questions hundreds of times so you could be ready for anything, but that still doesn’t guarantee you’ll dodge a curve ball. Instead, adopt a more holistic approach: learn the various frameworks (such as the CIRCLES method), but don’t just memorize product-sense answers; try to gain first-hand experience building a product for a specific problem. You could join a product hackathon, build your own side project with a case study for it, or help a start-up (there are millions!) with product management work.

The key here is that getting the experience yourself rather than memorizing a bunch of frameworks may help you more across interview situations. You’ll obtain experience in problem-solving with product design and strategy in mind. You’ll also be able to touch on customers, marketing, technical analysis, and other practical areas that an interviewer may not necessarily ask explicitly in an interview, but may be implicitly hiding in the way they ask their questions.

Now obviously I won’t forget to mention the other typical pieces of advice: keep up to date with the latest tech news so you can draw from a larger pool of knowledge when answering. Also, practice product questions by starting small (solve the easier ones first!), and then keep practicing different questions until your line of thinking and mental model becomes natural. Finally, explore the different product-related questions you could be asked, not just “product design” ones. Strategy, estimation, and marketing are all on the table!

2. Join various communities, learn, and stay humble.

Online and local communities, such as the fantastic PM group I co-founded here in Vancouver, are game-changers, and that’s an understatement. When you’re diving into product management, the larger your network and support system are, the better. The key here is to join groups that hold regular online or in-person coffee chats or networking events!

Resume reviews in these tight-knit communities are incredibly easy to find. Likewise, you can come across opportunities for mock interviews and learning sessions much more easily. You also learn about new mental models, methods, and techniques that have helped others reach the finish line. However, I believe what’s most important is having a “tight community.”

No matter how ubiquitous the other benefits are, having a strong network of like-minded techies (current and aspiring product managers) boasts many other benefits. Not only does it create a support system for all things product job-hunting, but it also promotes a mindset change. When you network with other hard-working product managers, you adopt their best practices and learn from their mistakes. But most importantly, you start realizing that even the most successful product managers and techies are still human. They may be folks whom you want to be in the shoes of, but you may also discover that you have more similarities with them than you initially thought. They may have more experience, but they still encounter failures from time to time.

Some of the smartest product managers I’ve ever met are ones who always demonstrated a growth mindset. They’re always doubting themselves and reflecting hard about their experiences. Striving to learn from others comes as a no-brainer. Identifying and having these types of people — product management experience or not — in your network will help push you to adopt a stronger growth mindset. You’ll feel motivated to soak all experiences and lessons like a sponge.

3. Build while demonstrating a product mindset via case studies.

Not every product manager boasts an online product portfolio to show off, so this is your chance to develop or polish yours.

Similar to how software developers keep a small portfolio of projects on their site or GitHub, product managers can do the same. Instead of building code-based projects (you can still do that if you have the skills), you can take a case study approach: a portfolio of different strategy documents for every product idea you have for actual problems you’re passionate about. This is where showcasing your product sense is key. Dig deep into a problem space, identify your market, know your user personas and pain points, and finally, design solutions to solve the problem (with trade-offs attached for each). Tools like Balsamiq and Figma are beginner-friendly for designing basic mock-ups, so there aren’t many excuses!

If you’re still stuck on getting started, an example to follow (and I know, it’s not great) is my own. I used a Notion template to create my portfolio, where each page features a case study and design on a problem I’ve identified in day-to-day life.

Finally, I want to mention the difference between product strategy/discovery and product delivery/execution. It’s possible to show both in case studies within a product manager’s portfolio.

With product strategy, it’s all about depicting the way you did your problem exploration. User research, customer market analysis, and even iterating on early user feedback are key components of product management that could be reflected in one’s side project.

Likewise, execution isn’t only about building out your project and showing the results — key tasks such as listing out dependencies, performing cost-benefit analyses on key product or technical decisions, and even showing your actual roadmap or schedule within the project document are helpful.

4. Books are great but keep up-to-date with the tech landscape.

Books such as The Lean Startup, The Lean Product Playbook, Inspired, and Swipe to Unlock are some of my favorite product reads of all time. They’re game-changers and can completely shift your mindset.

Complementing these product books are some more self-help titles, such as The Subtle Art of Not Giving a F*ck, Deep Work, The Seven Habits of Highly Effective People, and Atomic Habits.

There, I just gave a starter kit for anyone who wants to jump into product management yet stay productive and impactful. But…

It takes a little bit more to always keep up with today’s ever-changing tech world, and it’ll only progress faster than ever. There are other ways you can stay informed and demonstrate everlasting quench for curiosity:

• Subscribe and read a few tech and business newsletters: Morning Brew, Wellfound, The New York Times, TLDR, and Tech Crunch.

• Read a few tech news sites every day, including Tech Crunch and Wired.

• Take some cheap (or even free) online PM classes that include resources for interviews and mental models. I’d personally recommend Exponent!

• And of course, never stop going to in-person or online meet-ups!

The journey to becoming a product manager is arguably one of the toughest in tech. But stay relentless and passionate. You’ll find your way.

A common agreement yet perhaps oversight is the idea that stakeholder management comprises the product management job: it’s the core skill that truly defines a good vs bad product manager (PM).

It’s easy for most to understand that product success often hinges on effectively understanding and addressing the needs and concerns of various stakeholders. The reasons are simple: a PM’s stakeholders consist of customers, dependencies, leadership, marketing team, sales, and other parties that are key factors. But while we hear all the buzz about the importance of PMs who get to be the center of excitement, the driver’s seat entails more turbulence than what most people imagine.

Aspiring PMs grow energized by the product role when they learn about the opportunity to see their idea get built from start to finish.

Here are four reasons why product management can be viewed as essentially stakeholder management:

😫 1. With every function of a business comes different expectations.

Many product managers will tell you they have a seemingly infinite amount of stakeholders to deal with all the time. But if we dive a bit deeper, what does that mean and why is it important?

When you’re the face of a feature or product, you’ll get the opportunity to work with many people outside of your dev, design, and marketing teams; maybe even folks with positions that you’ve never even heard of. In the B2C (business to consumer) world, these could be DevOps (developer operations), Legal, technical writers, and even an advertising department. For example, what if your business was working with a third party to develop an advertisement for your new product — you may have to work with unfamiliar faces to provide content and suggestions on your product’s most marketable features.

B2B (business to business) features teams focused on sales, education, and client growth. Product managers would need to adjust their lingo and tailor their explanations to the right audiences. Imagine the product team is developing a new feature that Sales has no idea how to pitch or earn money off of without your support. Likewise, other teams involved in selling, operations, or process improvement will also need to know what’s going on in product land before key decisions are made which may hinder business growth. While most can assume that each stakeholder group has its own sits interests, priorities, and expectations, the practical experience of managing them with various nuances is not felt until a PM actually jumps into the chaos.

Managing these diverse stakeholders requires careful communication, negotiation, and alignment of goals to ensure that the product meets the needs of all parties involved.

📊 2. Trade-offs every day, with everyone.

Engineering and Product are well aware of the ubiquitous idea of calculating trade-offs in decision-making. Typically, PMs will be tasked with making product decisions involving product ROI (return on investment), feasibility, effort, and viability. One generic example could be an internal dashboard that a product team may need to build for better dependency tracking, but it would require several developer months to get it done. A product manager would have to measure the opportunity cost to build the dashboard as opposed to working on something consumer-facing that could drive immediate revenue.

Trade-offs in stakeholder management on the other hand can become a different beast, with product management easily getting caught in no man’s land. Seldom are all stakeholders fully aligned with each other, and can easily have competing interests and priorities, resulting in butting heads. For example, imagine a PM prioritizing a feature request from the sales team that could push a contract to its finish line. Suddenly, marketing, design, and even your development team could be against the decision, citing concerns about tech debt or usability. A strong PM will weigh the pros and cons of each opinion or suggestion while aligning everything to the main goals of the business.

Effective stakeholder management involves weighing these trade-offs and making decisions that maximize value for the product and its stakeholders.

🗣 3. Bringing clarity to all.

In my first product role at Microsoft, my boss reminded me that a key part of my role was to “bring clarity” to our respective teams, which would demonstrate my value more readily.

Retroactively speaking, this proved to be difficult when I started. My ability to bring clarity across developers, data scientists, engineering managers, and other parties was hindered by my lack of understanding of a deep data platform. However, even as I worked to build up this technical knowledge, another factor came into play: storytelling.

Engineers were focused on efficiency and operational excellence in their development, which is a key piece of Microsoft’s Bing data platform. But when I tried vouching for key features or projects that needed attention, I wasn’t doing it the right way; the success metrics were communicated, but the end-to-end story was not. This was maybe because of our KR (key results)-driven culture. When it came to describing business impact, it wasn’t just about, for example, improving daily active users or search engine market share. It was about telling the end-to-end user experience, the high-level objectives, and how it positioned our product in the market. Everything — including dependencies, customer needs, ROI, and product positioning — needed communication. Once I began doing this, I encountered less friction in bringing alignment and driving collaboration.

Product managers must facilitate open communication channels, build trust, and create a shared vision for the product for all stakeholders. But they almost must do it in the right way and tell the full story of their ideas.

✍️ 4. Perpetual dependency tracking.

Building products is obviously complicated. It’s not as simple as, “Let’s develop this strategy document, flesh out the requirements, and start building with a deadline in mind!”

Dependency tracking has continued to grow more important as third party solutions and cross-team collaboration also grow. Building products from 0 to 1 or 1 to 100 takes multiple teams in today’s sophisticated software landscape. I’m not just talking about critical support from other teams such as Developer Operations (DevOps), design, marketing, and leadership resource investment. I’m also calling out the multi-developer team dependencies which can hinder product development easily if not addressed early. For example, if your development team is reliant on another team’s API or platform for data or infrastructure, then boom — that’s your dependency right there. If that other team’s API or platform becomes outdated or a newly innovative feature requires another supporting team to build something new, then your product is at risk of not being delivered in time. This introduces a new form of stakeholder management I insipidly call “dependency management”: fighting for your features and priorities against the interests of other dependencies.

Development dependencies matter, and can easily fall into our last bucket of stakeholder management.

🤝 Becoming better at stakeholder management

To become better stakeholder managers, product managers can adopt the following approaches:

A) Exercising open-mindedness and empathy for all stakeholders, not just your end customers.

Just because you “own” something doesn’t mean you always make the final calls. It’s the realistic nature of how decision-making in software teams works. If only the product manager made all the calls, chaos would ensue.

Understanding the perspectives and motivations of various stakeholders is crucial for effective stakeholder management. PMs should invest time in empathizing with stakeholders, actively listening to their concerns, and considering their viewpoints when making decisions. Otherwise, they’ll become the lone wolf in a team that will move on with or without them.

B) Clear and frequent communication.

PMs often need to ensure that the right stakeholders are kept informed about project statuses, new processes, designs, engineering decisions, changes, and other decisions in a timely and understandable manner. This itself could become its job if there are too many stakeholders at play.

Clear and transparent communication is essential for managing stakeholders effectively, but there are many ways PMs can do it optimally. Simple tactics, such as using various channels and communicating important decisions on a regular cadence could do the trick. But more nuanced approaches could be more impactful. This includes presenting ideas in meetings or saving 1:1s for leaders of teams that all need to be communicated.

No matter how it gets done, the message needs to get out there. Additionally, providing avenues for stakeholders to voice their opinions and feedback can help foster a sense of inclusion and ownership.

C) Investing in relationships.

A common trap I see is a PM investing their time and energy in product strategy and execution but seldom doing the same for their stakeholders.

Building strong relationships with stakeholders is key. PMs should invest in building rapport, trust, and credibility with stakeholders through regular interactions, collaboration, and delivering on promises. Cultivating positive relationships can help mitigate conflicts, build trust, facilitate smoother decision-making processes, and garner support for the product’s initiatives.

By focusing on empathy, communication, and relationship-building, PMs can enhance their stakeholder management skills, which can easily reflect on the success of their product 🔥.

About Me

My name is Kasey Fu. I’m passionate about writing, technology, AI, gaming, and storytelling 😁.

Follow me on Substack and Medium for more passion, product, gaming, productivity, and job-hunting tips! Check out my website and my Linktree, and add me on LinkedIn or Twitter, telling me you saw my articles!

• His interesting and diverse background in music and education

• How he first joined Mozilla in their VR team

• Where he obtained his PM skills across his diverse set of experiences

• How aspiring PMs can get into product management

Subscribe to the podcast for future episodes featuring top guests in the PM space in Vancouver!

Special thanks to Stephen Flach himself, who helped edit and improve the sound quality of our podcast! Check him out: https://www.linkedin.com/in/stephen-flach-sf1/

Epiphanies such as these aren’t uncommon in a fast-paced tech world full of new insights and best practices that shower us blindly. It’s difficult to keep up with every piece of feedback and adapt so readily to new teams, features, and ideas.

Product strategy is one of the most pivotal areas that demonstrate your product knowledge the best in any given scenario. Almost 100% of the time, your ability to strategize and drive a product to business success will always be mandatory in a product-related role. Whether you’re a junior product manager (PM) or someone with over a decade of experience under the your belt, I feel this article may help remind everyone in the product community about the best ways product strategy should be applied.

Without further ado, here are three key elements that product folks must be acutely aware of when developing product strategy.

1. Your strategy isn’t your roadmap.

For me, this was the toughest pill to swallow. For the first few years of my product career at Microsoft, my product roadmap WAS my strategy, and I focused too much on OKRs that fit the bill. It didn’t help that my approach to writing OKRs (objectives and key results) was very “timeline” and “execution” focused, which again, was the “roadmap” effect. I didn’t give enough thought into the real reasons on whyproduct had to move in a certain direction, both engineering-wise and business-wise.

For example, at Microsoft Bing, I would write something like, “Ship a 90 precis-on classification ML model to the top x billion URLs we process, enabling the feature teams to filter out specific websites by y%.”

And while this isn’t necessarily a poorly-written KR, it’s focused on the “what” without really being attached to a greater cause or how that could strategically impact product delivery. Ultimately, while this led to our projects being used/consumed by other teams, they weren’t valued as “differentiators,” and were scrapped by the end of the year for something more sustainable with higher pa otential for impact.

In retrospect, I could’ve written a product strategy document that outlined the objectives of my product team first. I would dig deeper on why ouintowork was important, how it impacted business growth, and the oll direction our team needed to head and how ,we would differentiate ourselves in the market (in this case, compared to Google). Then, I would propose a specific product delivery method (varying forms of scrum or kanban) that fit our strastegy the best. Suppose we wanted to work on a new internal feature that benefited other developer teams that needed a lot of trial and error — I would propose a 1-week sprint cycle in the form of a scrum, so we could benefit from easily pivoting whenever we wanted.

However, instead, I wrote KRs on what needed to get done, loosely tied it to a higher-level objective, and focused on a timeline without much care into the “why” of our delivery methods. I focused too much energy in workingowith engineers to estimate the amount of developer months needed to get work completed, and spen more time on a schedule to ensure work would be delivered punctually rather than on a strategic way to deliver based on why we needed it.

Product strategy isn’t about delivering things on time. It’s about outlining not only why a team has to build something in a certain way, but how they can maximize the value out of their project for the market/customers.

2. Don’t mistake the mission and vision of your product for the strategy.

A post by Shreyas Doshi confirmed my suspicions: many PMs could be tackling strategy documents the wrong way, even from just the start of it.

Typically, PMs begin their strategy docs by stating the mission and vision of their product or feature before digging into the details about the “why” and the “how.” Other times, only a brief overview of what needs to be built will be described. Usually, this is fine if you’re just only writing a requirement doc on a feature for the engineering team; only the “what” and the “how” need to be covered. Yet funny enough, many include a “why” section as well but they don’t state anything pertaining to actual strategy. They instead just state the mission and vision, and introduce why the feature is useful, not why it’s a game-changer both internally and externally.

Product strategy isn’t about stating the mission and vision of your product an/or team. It could be included, but most PMs mistake this for actual strategy. Actual strategy depicts how you differentiate your product/feature from your competitors. It highlights how you plan to win the market to achieve your business goals. You can still write about where you see the product in 3–5 years and why you want to get there, but what about the part explaining how you’ll achieve business success?

For example, at Unity Technologies, our product strategy documents started with a background on not just the “why,” but also the key element that differentiated us in the market. We didn’t write too many things about mission and vision; we focused on the methodology that would elevate our value and make us unique to our customers, thus winning them over and accelerating revenue growth.

Mission and vision is great for broader alignment, but proper strategy is how a team becomes successful with the right value proposition.

3. Differentiate the “tactics” from the “strategy,” but don’t exclude the former from your document.

And before you think I’m being too simplistic: in my subjective opinion, tactics DO belong in strategy. Reason being? Tactics should be regarded as a subset of lower-level strategy that could contribute to how a team differentiates their product in a specific market.

Tactics by business definition is “how things should get done,” or a short-term fix to mitigate a problem, as opposed to the “why” and the “what,” which are more strategy-focused with long-term emphasis.

Imagine this example: At Microsoft, we were trying to figure out how to develop a certain machine learning model that could improve country tags for the top x billion of websites in Bing Search. The strategy was already defined, because I already did the discovery work: I found out that a certain percentage of URLs appearing in the top 3 search results of Bing suffered from poor country labeling. I wrote out the strategy plan to highlight my findings and conquer this problem, but what I didn’t do (and I should have) was include the tactical solution in the document: the “how.”

We decided that a new model was needed — and thus a lot of engineering prep work kicked off following our product decision. But here’s the thing: product managers need to adapt to the delivery system their engineers work in. If engineers prefer to take over tactics, that’s fine. If it makes sense for a PM to support tactical decision-making, that’s also fine. The problem is that some PMs mistake tactics for strategy, or they decide to exclude tactics entirely from their documents, letting engineers take over the realm. PMs should at least include a write-up of their engineering team’s tactical decisions in their strategy document for reference, no matter who owns it.

Tactics can still be part of product strategy if it impacts the way you can differentiate yourself in the market for business success.

About Me

My name is Kasey, AKA J.X. Fu (pen name). I’m passionate about writing, technology, AI, gaming, and storytelling 😁.

Follow me on Medium or Substack for more passion, product, gaming, productivity, and job-hunting tips! Check out my website and my Linktree, and add me on LinkedIn or Twitter, telling me you saw my articles!