Subscribe now

Let me ask you something. Have you built an AI agent in the last six months?

If yes, did it actually work the way you wanted?

And if it did, are you still using it today?

When I spoke to ~100 product managers at the ProductLab Conf in Berlin recently, only about 10% could answer yes to all three questions. We're all experimenting, failing, learning — and mostly failing again.

The promise was that agents would come in, take over, and run the show. But in reality agents mess up. Handovers fail. Latency kills user experience. We're facing the same issues in both our personal experiments and enterprise implementations.

And it's fundamentally changing what it means to be a product manager.

What We Talk About When We Talk About Agents

Let's start with clarity, because the industry loves throwing around terms like "autonomous agents," "LLM workflows," and "agentic systems.”

An agent is a goal-oriented system that can reason and act with autonomy. It can plan, act, and loop. It has dynamic decision-making ability — using various tools and applying reasoning to solve problems. Think of booking a trip to Thailand autonomously: the agent needs to reason through multiple steps, make decisions, and use various booking systems and platforms.

Most importantly, an AI agent can adapt in real-time to changing context and user needs. A user can switch languages mid-conversation or pivot to an entirely different topic, and just like a human would, the agent adapts.

An agentic system is the workflow where these AI agents interact with each other, plan, make decisions, use tools, and adapt dynamically.

The Three Fundamental Tensions

I've been leading the AI agents product org at Zendesk — meaning my team and I live and breathe these systems daily, so much so that sometimes I wonder if we’re not stuck in the AI bubble. Through this work, I've learned of three fundamental tensions that are breaking everything we know about product management.

1. The Control Paradox

Users say they want control. They want to train the bot, shape how the system behaves, be part of the process. But they don't want any complexity. They don't actually want to do the work.

At Zendesk, we give users the ability to create what we call "instructions" — strings of text they can inject into the system's behavior. Here's what they’ll write:

• Instruction 1: "When a customer says X, always escalate to a human agent."

• Instruction 2 (immediately below): "But resolve everything autonomously."

This contradiction might seem banal, but it reveals something profound: Most users want the illusion of control, not actual system effectiveness.

Individual feedback from supervisors who don't understand the larger system creates local conflicts and contradictions. The solution isn't more control panels or opportunities to mimic control. It's about designing touchpoints that preserve user agency without breaking the underlying system.

What does this look like in practice?

• Binary signals: We need users to validate what the AI creates because human judgment is still best 👍 / 👎

• Evaluation layers: Not every piece of feedback should modify system behavior — we need to understand how feedback fits into the larger picture

• Three-layered architecture: Aggregate analytics for the big picture, drill-downs for specifics, and opportunities for qualitative feedback with conflict detection

2. The Orchestration Trap

What most of us in the space are learning about AI agents: specialized agents perform better. But every specialization increases complexity exponentially.

More handoffs between agents means more latency. And if you've ever waited 10, 15, or 20 seconds for a chatbot response, you know users are incredibly sensitive to this. We expect AI to respond with human-like speed. Humans have notoriously low latency, and we expect the same of our machine systems.

More agents also means more failure points. When one agent can't update or fails, the ripple effects are unpredictable. The more complex the system, the harder it becomes to track what happened and why.

Most teams start with two or three autonomous agents — you typically need at least some kind of intent classifier agent to understand your user and perhaps a RAG agent for knowledge retrieval and response generation. We're now at nearly a dozen, and they're becoming so specialized that their names barely translate to human language anymore — they're doing tiny, specific things that only make sense in the context of the larger orchestration.

Even worse, we're essentially rebuilding everything every three months. The foundation models keep evolving. Your prompts break when models update. Performance shifts. You're building stable systems on fundamentally unstable foundations.

But here's where it gets interesting: We're not just creating product interfaces for humans anymore. We're creating digital workspaces for AI agents to collaborate with one another.

Think of it like the Spotify model with product tribes, but for agents. You have domains, teams within domains, orchestrators for each domain, and a meta-orchestrator on top. It sounds clean in theory. In practice? Agents don't always belong in their assigned domain. Sometimes they need to jump between contexts. The pain is real, and we're all feeling it.

3. The Evolution Crisis

Teams are starting to split along new lines: those working with AI and those who aren't.

AI research cycles don't correspond to traditional product planning. Something might take six days or six months — that's the nature of probabilistic systems. You can't write an upfront spec (though you never should have been doing that anyway).

Should teams building agentic products stop building user-facing features? Should the autonomous agents be building features instead? These aren't rhetorical questions — they're decisions the tech industry is making right now.

What's changing:

• PRDs → Prototypes and context architecture

• Feature specs → Agent instructions and prompt engineering

• User stories → Agent capabilities and interaction patterns

• Sprint planning → Research cycles and hypothesis testing

• Launch planning → Continuous orchestration

• And a new skill is emerging: evals

Planning has always been hypothesis testing, but AI makes it impossible to pretend otherwise.

The New PM Toolkit

The PMs who will thrive in this world are builders and orchestrators. No, not everyone needs to become technical. We still need strategy, market understanding, and all the classic PM responsibilities. These don't go away — they become more critical because AI systems can't replace human judgment.

But you need to experiment personally and find opportunities to architect at scale. The new AI PM is part builder, part orchestrator — someone who creates agents for themselves, documents what breaks and why, and shares learnings publicly.

Here's your roadmap:

This Week:

• Build an agent using Zapier, n8n, or even ChatGPT

• Map one workflow (personal or professional) as agent interactions

• Identify one human touchpoint where you could simplify

This Month:

• Prototype instead of writing a PRD

• Run a research cycle instead of a sprint

• Share your learnings publicly

Ongoing:

• Learn to write evals (this will be the #1 skill tested in interviews next year)

• Design agent interaction patterns by chaining agents and watching them break

• Create transparency and explainability in your products

• Document everything

The Bottom Line

None of us have this figured out. But community is our competitive advantage. Forums, conferences, newsletters like this — these are where we exchange experiences and learn together.

The question isn't whether you'll become an orchestrator. It's whether you'll do it intentionally and learn along the way.

We're evolving from feature builders to orchestrators of human-machine collaboration. We're deploying agents to solve human problems and business outcomes. And we're doing it all on shifting foundations that change every three months.

It's messy. It's uncertain. And it's exactly where product management needs to be.

What's your experience building AI agents? What's worked, what's failed spectacularly? Hit reply and let me know — I read every email.

And if you're looking to break into AI product leadership, remember: experiment personally, share publicly, and focus on the orchestration patterns that will define the next era of product management.

Subscribe now

The alarm goes off at 8:00 AM, and Sarah, a Platform PM at an enterprise B2B company, opens her laptop to start her day. Her AI assistant has already analyzed overnight API usage patterns and discovered something interesting: customers are combining features in ways the product team hadn't anticipated. This insight kicks off a day of AI-enhanced product management that would have seemed like science fiction just a few years ago.

By 11:00 AM, Sarah is discussing this discovery with her team in an online strategy session. Their AI collaboration tool has generated several development paths, complete with resource requirements and risk assessments. But it's Sarah's product intuition – a uniquely human skill – that steers the discussion toward transforming this emergent behavior into a new enterprise service offering.

Welcome to product management in 2026/2027. While this might sound like a distant future, McKinsey & Company predicts that generative AI could enable automation of 70 percent of business activities across almost all occupations between now and 2030. The transformation of product management isn't coming – it's already here.

The AI-Native Product Manager

Brian Balfour of Reforge explains what this future looks like: "The next generation of product teams will be trained as AI-native from day one. They will think, work, and build differently." This isn't just about using AI tools; it's about fundamentally reimagining how we approach product management.

Consider Ahmad, a B2C Product Lead at a HealthTech company. His morning looks quite different from Sarah's. While she's analyzing API usage patterns, his AI assistant has processed millions of user interactions from their health monitoring app overnight, identifying behavioral patterns and areas where users are struggling. By mid-morning, he's reviewing AI-generated user archetypes that go beyond traditional personas, incorporating real-time behavioral data and predictive health outcomes.

The contrast between Sarah and Ahmad's workdays illustrates an important point: while AI is transforming all aspects of product management, its application varies significantly based on context. Enterprise B2B and consumer-facing B2C products require different approaches, but both benefit from AI enhancement.

The Core Competencies of an AI Product Manager

To thrive in this new landscape, product managers need to develop three interconnected sets of skills:

• Technical AI Skills: While AI PMs don't need to be technical experts, they need enough understanding to make informed decisions. This includes basics of AI/ML fundamentals, data processing, model evaluation and observability, prompt engineering, and API integration. Think of it like being a film producer – you don't need to operate the camera, but you need to understand what makes a good shot.

• Traditional PM Skills: The fundamental skills of product management become even more critical in an AI context. Strategy development, user research, roadmapping, and stakeholder management all remain essential, but they're enhanced and transformed by AI capabilities.

• Human Skills: As AI handles more routine tasks, uniquely human capabilities become more valuable. Strategic thinking, ethical judgment, and the ability to lead and mentor teams are irreplaceable. AI can analyze data, but it can't make ethical decisions or build genuine human connections.

The magic happens at the intersection of these skill sets. When technical understanding meets product thinking, we get data-driven strategy. When product skills meet human judgment, we create ethical product leadership. When technical knowledge meets human wisdom, we ensure responsible AI development.

Learning Through Real Examples

Let's make this concrete with a practical example. Imagine you're managing a SaaS product, and your data science team proposes building a churn prediction model. The model suggests an 85% accuracy rate in predicting customer churn. What does this really mean for a product manager?

It means that of 100 customers predicted to churn, about 85 actually will, while 15 are "false positives" – customers incorrectly flagged as likely to leave. As a PM, you need to decide if this accuracy rate justifies building automated intervention systems. You need to consider questions like: Should we invest in improving the model further? How do we design intervention systems that account for prediction uncertainty? How do we communicate the system's reliability to stakeholders?

This example shows how technical understanding enables better product decisions. You don't need to know how to build the model, but you need to understand its implications for your product and users.

Starting Your AI Journey

The path to becoming an AI-capable product manager might seem daunting, but it doesn't have to be. Start with foundational learning through courses like Andrew Ng's "AI For Everyone" on DeepLearning.ai or Marily Nika's "AI Product Management 101" on Maven. These provide the basic understanding you need to begin working with AI tools.

But theory alone isn't enough. The real learning happens when you start applying AI tools to your daily work. Begin exploring now.

Tools like, Replit, Bolt, v0, and Cursor can help you quickly validate ideas and product prototypes and even full applications.

Platforms like Amplitude now offer AI capabilities that can help identify patterns and opportunities in your product data. Use these to make more informed strategic decisions. I also really like ’s GPTcsv.

Tools like Dovetail and even ChatGPT can help you analyze user feedback at scale, identifying patterns and insights that might be missed through manual analysis.

I’m shamelessly stealing this recommendation from , but it’s such an amazing watch that I have to recommend it to everyone. gives a lightning lesson teaching you how to prototype using AI in 10 min.

Leadership in the AI Era

For product leaders, the challenge isn't just personal development – it's building and enabling AI-capable teams. This starts with asking the right questions about AI readiness:

Are your company leaders aligned on the value of AI? Do you have budget for AI exploration and training? Do you have the necessary technical infrastructure? Is your data ready for AI systems? Do you have good use cases to explore?

The cautionary tale of McDonald's AI-powered drive-thru experiment shows why these questions matter. After a three-year experiment, they ended the program in June 2024 due to customer frustration with the experience. The technology worked, but the use case wasn't right.

To avoid similar missteps, leaders need to create ecosystems of learning opportunities. This includes providing access to courses and bootcamps, enabling hands-on work with AI tools, rotating PMs through AI projects, and encouraging experimentation through innovation labs and hackathons.

The Symbiotic Relationship Between Product and AI Research

One of the most crucial aspects of AI product management is the relationship between product teams and AI research. This relationship needs to be symbiotic – product teams need to stay at the forefront of AI capabilities, while AI research needs feedback loops from real-world product usage.

To foster this relationship:

• Develop a shared product vision that includes AI

• Align AI research with business and product strategy

• Create time and space for researchers to go deep

• Encourage small-scale pilot projects

• Build a shared experimentation culture

• Make AI research visible in the product roadmap

Preparing for AGI

As we look further into the future, product leaders need to prepare for the potential emergence of Artificial General Intelligence (AGI). This preparation involves developing capabilities in four key areas:

Ecosystem Design

Learning to create and manage multi-product ecosystems, thinking systemically, and aligning product strategy with long-term societal goals.

AI Ethics & Advocacy

Engaging with policymakers to influence AI regulations and understanding the ethical implications of AI development.

Workforce Resilience

Learning how to train humans to work alongside AI and guide teams through technological transitions.

Human-Centered Product Design

Creating products that prioritize human value over mere utility, understanding how to leverage new technologies for emotional experiences.

The Path Forward

The transformation of product management through AI is both a challenge and an opportunity. While the technical aspects might seem daunting, remember that the core of product management remains unchanged – understanding user needs, solving real problems, and creating value.

The key is to start small and build incrementally. Begin with simple AI enhancements to your current processes. Experiment with AI tools in your daily work. Build your understanding through a combination of learning and doing. Most importantly, maintain your focus on creating value for users, using AI as a powerful tool rather than an end in itself.

As Lenny Rachitsky notes, "PMs will become editors of super-intelligent suggestions." Our role isn't to be replaced by AI but to evolve into something new – leaders who can combine human judgment with AI capabilities to create products that were previously impossible.

The future of product management is already here. The question isn't whether to adapt, but how quickly and effectively we can embrace these changes while maintaining our focus on creating genuine value for users and businesses.

I recently gave a talk on this same topic on the Product People livestream. Watch it below:

It may strike you as ironic, dear reader, that it took me 13 months to write another post after satirizing the alleged “sudden demise of product management” and return with, above all things, a story about AI. But the truth is that I got myself so knee-deep into the world of AI that I ended up building autonomous AI agents at Zendesk.

My day job makes me think a lot about how to be a product leader in AI and live in a world developing AI. About the people building AI, the people building with AI, the people who lead the people who build.

The sector moves fast. The range of models and services is unprecedented. Everyone is moving fast. Everything is moving faster. It’s a constant game of excited catch-up.

It’s demanding.

It can be taxing.

It’s thrilling.

It’s humbling as it surrounds you with some of the most brilliant and fascinating people you’ve ever met.

This inevitably causes product managers working in and with AI to adapt. And so do their product leaders.

What is unique about product leadership in AI and shipping AI-powered products? How is being a product leader different when you're shipping AI products? How do you train AI PMs? And how does AI research fit into the picture?

I’ll be talking about this on Thursday, Sep 19, 2024 at 1pm CEST / 4am PST.

Check it out and get your tickets here:

Subscribe now

Before I jump into a discussion about why all the posts on LinkedIn prophesying the death of product management as an independent function are fake news, a brief note on my absence.

I haven’t posted since April. In the past few months, I’ve experienced two large personal life events that though resolved in the best way possible, required time and effort away from anything that wasn’t family and work. We are only human, after all. And the demands of life sometimes mean disconnecting.

Scrolling through LinkedIn for the first time in weeks, it was quite the surprise to learn about the imminent demise of product management as a function.

The chatter on LinkedIn — with several poorly researched posts in it — claims that product managers are being slowly but steadily supplanted and replaced by teams of product engineers, as it becomes increasingly difficult to keep up with developments in tech and the advent of the AI age and LLMs without coding and other technical skills.

It seems to me we have this discussion cyclically, as I remember a time when Web Developers were meant to replace product managers. Or Program Managers (of which I was one). Or Subject-Matter Experts, the dreaded SMEs.

We are also always running in a circle on the discussion on how technical PMs really need to be. (Hint: They don’t, but it helps.)

Granted, this is a unique moment in tech history, and a renewed focus on technical understanding required to harness the full power of advances in AI technology does not seem at all out of place.

But I have absolutely no fear that “product engineers” are going to supplant “product managers.”

If there is one thing nobody wants right now, it’s to take on even more responsibility in the scope of a single role and position. We are all already doing that after rounds and rounds of layoffs and departures across all of tech, product managers and product engineers alike.

There is no doubt that product managers have to continue to upskill.

If anything, EVERYONE — not just PMs — should be learning about generative AI and LLMs, and perhaps it’s time to dust off those rusty Python skills, and get yourself a Jupyter notebook or something.

But dumping all of the responsibilities of the product management role into the lap of product engineers is not a new idea. It didn’t work before — remember, product managers emerged as a combined discipline of former marketing folks and software engineers, with a good sprinkle of business. We established a wholly new product development discipline to account for the gaps that existed previously.

Here are just some of the responsibilities of a product manager:

• Own, develop, and evolve the vision and strategy for a product

• Maintain a steady roadmap of product features and innovation in collaboration with Commercial, Marketing, Leadership & Management, Customers, Legal, and any other function relevant to the business

• Define and prioritize a steady stream of product innovations in a living, ever-evolving product roadmap

• Together with Design and Engineering, develop product solutions that are desirable by customers, solve real problems, generate value in the form of revenue and profit for the business, and are technically feasible within the scope of the product, the platform, its architecture, domains, and infrastructure

• Co-develop concepts, designs, and high-level technical solutions, and comms detailing the product itself, its development, stakeholders involved, its dependencies, potential value, proof and validation of value, and value to customers, the business, and the market sector

• Join user interviews and run customer research, and regularly speak with customers, their business users, and end users

• Co-develop and test product prototypes by organizing user testing and alpha, beta, and early access programs

• Run A/B and multivariate tests, often working side by side with BI and Data Science teams, and demonstrate success on product outcomes as expressed through metrics

• Develop product metrics and co-design event tracking infrastructure to monitor product health

• Write product briefs, strategy briefs and memos, collaborate on marketing collateral

• Co-develop pricing for products you own

• Write public roadmap posts announcing new features in collaboration with Product Marketing

• Run product analysis, often in collaboration with Product Analysts, and develop benchmarks, track results, and share findings

• Analyze complex data sets — now even with the help of AI tools — to gain new insights based on figures and determine the direction of the product based on its past and present performance

And that’s not even everything we have to do…

SIDENOTE ABOUT PRODUCT OPS

Some companies have ProductOps, those angels sent down from heaven, to help carry, ease, and automate away some of this burden.

I used to believe PMs didn’t need ProductOps. I saw it done poorly too many times before, but after having seen it done right, I’ve changed my tune. ProductOps is critical, but it requires competent folks to execute it right. Ideally, they should have been PMs themselves before.

But even with Product Ops, product managers have a lot of work on their hands.

I didn’t even mention all the support calls, technical troubleshooting, going above and beyond to help a customer solve an immediate problem.

And in case you’ve missed it — BUGS. 🐞

Yes, the engineers fix the bugs. But the product team prioritizes which bugs and other items to work on at any given point in time. That requires both the insight and skill of a product manager working with their team to resolve issues in a way that truly adds value.

Product management is a full-time job. One that is sorely needed.

Yes, some big companies out there have experimented with removing product management or shifting these responsibilities into roles like product marketing or even product engineering. But the truth is more complicated than a few outdated stories.

Büşra Coşkuner, a great product coach who I warmly recommend, wrote this amazing comment on LinkedIn that sums it up quite nicely.

I quote it here verbatim with all the links, including one to a great article she wrote in response (with a video reaction, too!):

Just to correct a small piece: Airbnb has removed the siloed function (function as in department) but not the role. They are actually hiring PMs right now: https://www.linkedin.com/jobs/view/3674017616

Google as well (because you mention FAANG): https://www.linkedin.com/jobs/view/3660157575

And Apple (Role's name is PMM but in the description they call it PM): https://jobs.apple.com/de-ch/details/200494361/developer-product-marketing-manager?team=MKTG

And Meta: https://www.metacareers.com/v2/jobs/169780102757589/

And Netflix: https://jobs.netflix.com/jobs/274255075

And Amazon: https://www.amazon.jobs/en/jobs/2410999/sr-product-manager-gtm-echo

Having said that, teams and org setups are evolving. And as I mention in my statement about Airbnb's changes (https://www.busra.co/post/my-opinion-about-airbnb-s-org-changes) it's good for them if they found a new way of working that works for them. It's going to be another interesting case to watch and see how it evolves. It's important that product management gets done somewhere in the company so that the right product is build that drives business and makes users & customers happy, but it's less important WHO does it. As long as nobody burns out it's cool :)

(Source)

Avoiding Burnout

To avoid any confusion, all the great engineers I’ve had the privilege to work with — including the amazing folks I work with now — are more than capable of doing product work, moreso as a team, on top of their existing duties. And sometimes they do.

Because great teams help each other out when they can or the situation demands it. They are great PRODUCT engineers.

But they have to do all that on top of their existing, critically vital jobs. And all of the ones that I’ve worked with who like to do this work have themselves already become product managers.

But the list of responsibilities for a product engineer is just as long as it is for a product manager, with significant overlaps, but clearly distinct responsibilities and overall duties.

We are inviting burnout by trying to mush roles together that took us decades to separate. The advent of new technology means we all must develop new skills.

But when speaking about product managers, the idea that we must continuously upskill for the rest of our careers is hardly newsworthy. I see no sudden demise on the horizon, just a bunch of folks with a fantasy about saving a few bucks. If you ask me, this entire idea couldn’t stand on shakier legs than these.

And if it does anything, it will burn out a generation of brilliant engineers and marketing folks, as they’ll be too busy to evolve the role — which is what would be necessary for this to work. That may lead to a whole new discipline. But if you have to do everything a product engineer does and then everything a product manager does, you are bound to drop something along the way.

And all that would mean is that some of your responsibilities would have to go to someone else.

And then you can burn out together.

If you enjoyed my discussion (and odd joke), not to mention the AI-generated Grim Reaper, please consider sharing this post!

Share

Subscribe now

The traditional method of becoming a product leader (or moving into any leadership role, for that matter) is to keep your head down, do the work, show up every day, and get rewarded on merit by a promotion into a leadership role.

This continues to be a fan favorite and most certainly a viable way to move into leadership. It is certainly a matter of great pride for folks, and if you ask some, the only way that a person ever ought to get promoted into leadership.

The problem with this way of thinking is that it assumes all careers are linear, that all paths are equally possible to all, and most importantly of all, that merit will inevitably be rewarded.

Why is that a problem? Well, there’s more than one reason.

Product Careers are Rarely Linear

Most of you reading this did not follow the so-called perfect path into product management, i.e., studied computer science, worked as a software engineer, moved into product. This was how people became PMs in the early days of what evolved into modern product management. And the expectation that a PM must have been an engineer first lingered for a long time after. Google wouldn’t hire PMs without a Computer Science degree for the longest time (even though its first SVP of Product Management didn’t have one).

But we’ve been over this for a long time now. Product managers today come from all walks of life, and their experiences are incredibly varied. I used to be a poetry translator, and today I work with machine learning, conversational AI, and automation products. There is nothing linear about my career.

Privilege Plays a Role

If, like most people, you moved into tech without a CS degree or engineering experience, chances are you started out as an intern, and quite possibly an unpaid one at that. Not everyone can afford that.

My first job in tech started out part-time while I was a student. In 2 years, I moved up to team lead. And then after losing that job, I found it extremely hard to land another job. My personal narrative made no sense. I was a translator for nearly 7 years, then suddenly had a 2-year stint in data management, and after 100 failed applications to full-time gigs, I realized I had to start over. I landed an internship. It was paid, but it barely covered my rent. And as a working-class kid who immigrated to Germany from Bosnia, I was broke for most of my internship and maxed out my cards every month, sometimes going without a meal for a day or two.

But I worked my butt off, and I got promoted into a full-time role in 3 instead of the 12 months that the internship was supposed to last. I don’t share this story often, because I dislike the “rags to riches” narrative ploy, but I want to be honest about the part that relative privilege plays in moving up in a career.

Merit Alone is Insufficient

Individual hard work and achievement ought to be praised, supported, encouraged, and acknowledged. But individual merit is rife with systemic bias caused by the inequities of our societies.

Some of you will ask, “But didn’t you just tell me a story about how your hard work and merit got you the promotion?”

Yes, it’s true, that did happen. But instead of putting everyone through the ringer like that, with the misguided idea that it’ll somehow make them stronger and better at what they do, what if instead we focused on creating opportunity and propelling others, especially if their circumstances don’t afford them the privilege needed to build a career?

No one should have to miss a day of food to move up in their career.

No, merit alone is insufficient. And the world is not fair. I’m not here to talk about how to change the system, because that would be a different kind of newsletter.

What, then, can I do to get promoted into a leadership role?

Alright, let’s set the stage first.

1. Your career path into product management probably hasn’t been linear

2. You know you want to be a product leader

3. You know why you want to be a product leader

4. You know what kind of product leader you want to be

Wait a minute — you don’t know? You’re unsure? You’re wondering why all of the above even matters?

“I Want to Be a Product Leader”

Here’s the thing. A lot of people dive headfirst into the idea that they want to be leaders. Maybe you think it’s the surest way to earn more money, or you crave the respect that comes with authority, or you just want your parents to be proud of you for being such a good hard-working child.

Maybe it’s all of the above or none of the above. It doesn’t matter.

What matters is that you first decide that you do, in fact, want to be a product leader.

“I Know Why I Want to Be a Product Leader”

Leadership, and especially product leadership, is a really really really difficult job.

It’s also an incredibly rewarding job.

But it’s a job that will challenge you, excite you, frustrate you, stress you out, burn you out, make you grow, make you fall, force you to get back up.

So before deciding you want this, you should ask yourself why you want it.

IMHO there are no bad reasons for wanting to become a product leader. OK maybe egotrips are a bad reason. But all other reasons are valid. Money, prestige, reputation, respect from your peers.

Product management is, after all, the most exciting job in the world. You wouldn’t be doing it or reading this newsletter if you didn’t already think so. I certainly think so!

“I Know What Kind of Product Leader I Want to Be”

Leadership often gets confused with management. Product leaders are not always people managers. But people who manage product managers are always product leaders.

Much like engineering before it, product management has developed two tracks:

• Individual Contributor

• People Manager

I’ve written about this in more detail here: Product Management Career Ladder and talked about it at ProductCamp Europe in March 2023.

”OK, OK, I get it — I know the answers to all these questions, just give me the framework already.”

Well, since you’re asking so nicely, here you go.

If you go through each section of the above canvas and take the time to think through all the questions, you’ll end up with a way to position your brand as an aspiring product leader.

Career Vision

• Why do I want to become a product leader?

• Do I want to be a people manager or an IC leader?

• What is my ideal work situation?

Career Narrative

• How did I get to where I am now?

• How has my previous experience prepared me for the next step?

Standout Attributes

• What unique capabilities, skills, and experience do I have that others might not?

• What makes those unique skills valuable to a product leadership role?

• Does my resume showcase my standout attributes?

Context

• What context makes my value obvious?

• Within what context do I stand out as a candidate?

Proof of Competency

• Do my boss and coworkers perceive me as competent?

• Do I have previous leadership experience?

• Is there social proof of my competency (content, website, conferences, podcasts, meetups)?

These questions are designed to help you examine your aspirations and understand how your skills and experience fit within the context of a job you want.

I know some of this might still sound pretty vague, so here’s how I would fill this out for myself:

There’s no real science to this. But this is what I’ve used, albeit not in this highly formal version, to help grow my own career. And it’s worked for me. I can’t guarantee it’ll work for you.

What’s missing from this is a more detailed discussion about how to position yourself for a specific product leadership job, which is IMHO as much about what you want out of a job as what a job wants out of you. Perhaps I’ll dig deeper into that in a follow-up article.

Until then, I wish you a lot of luck with this. Let me know if you use it, and if you see some glaring flaws that aren’t obvious to me.

If you enjoyed the practical tips in this article, please consider sharing this post!

Share

Subscribe now

I wasn’t going to write about this, but so many people have recently been asking me about how to negotiate a raise when their companies are laying people off, I figured it was worth it.

If you're a product manager or product leader trying to negotiate a raise in this market (or in any market, for that matter), you need to start asking yourself questions that go beyond your personal feelings and dreams of trips to Bali.

Let me explain what I mean.

Negotiating a salary is emotional for most people, naturally so. We tend to look at a money amount as somehow proportionate to our value as humans, and we are of course calculating how well a certain figure divides into our basic survival needs, the comforts and luxuries we want to afford ourselves, and potentially the needs of others in our care.

So people approach negotiating a raise with that backdrop in mind and go through all these scenarios, often burying themselves into a hole in anticipation of disappointment. What I find puzzling is how many people have already given up way before they've even started having the conversation.

What folks fail to consider are two things: context and leverage.

What is the context in which I am asking for a raise?

• Are the company's financials good at the moment?

• Is the company profitable?

• Is revenue growing?

• Are we hitting our targets?

• Is there budget for raises? Have others gotten raises?

• Is my boss a person who would risk political capital to get me a raise?

What is the leverage that I have?

• Am I considered an important employee? Does my boss see me that way?

• Am I indispensable? How easy is it to replace me?

• If I quit today, are there immediate negative effects for the business? For my team? For my boss?

• Do I create value for the company?

• Would it cost a lot to replace me? Would it take a long time to replace me?

Why should you know the answer to all these questions to ask for a raise?

Shouldn't it be enough that you are a good product person who does their job, and it's been X amount of time since you last got a raise?

Should you just wait for the new review cycle like everyone else?

Look, whatever companies tell you, raises have a life and logic of their own.

First, you can get a raise outside a review cycle if you're valuable enough of an employee.

Second, all of the above questions are what your CFO, your CEO, your CPO, your boss, your boss's boss, your boss's boss's boss, and their accountant are asking themselves.

Third, most companies have tightened the purse strings right now. So you need to consider that.

Put simply, if you want a raise, try to answer all of the above questions. If most of the answers are "Yes," then you should go to your boss now and ask for a significant bump to your current pay.

If most of them is a "No," chances are your boss isn't going to expend their political capital to fight for your raise.

And sometimes you also may just need to wait a little longer.

Or, you know, find another job.

Anchoring Bias

Even if you do find another job, you’re going to have to negotiate the new salary. So before I let you go, let me tell you about anchoring bias. Here’s the Wikipedia definition:

a cognitive bias whereby an individual's decisions are influenced by a particular reference point or 'anchor'. Both numeric and non-numeric anchoring have been reported in research. In numeric anchoring, once the value of the anchor is set, subsequent arguments, estimates, etc. made by an individual may change from what they would have otherwise been without the anchor. For example, an individual may be more likely to purchase a car if it is placed alongside a more expensive model (the anchor). Prices discussed in negotiations that are lower than the anchor may seem reasonable, perhaps even cheap to the buyer, even if said prices are still relatively higher than the actual market value of the car.

In practice, that means that whoever gives the first number sets the anchor.

I like to think of this in terms of a private anchor and a public anchor.

Private Anchor

The private anchor — also known as the resistance point — is the lowest amount you’re willing to go. It’s essentially what you need to cover all of your living plus quality-of-life expenses (such as travel or your Netflix subscription). It’s the lowest you’re prepared to go.

Never compromise on your private anchor with yourself. Consider that you need those quality-of-life expenses not as an indulgence, but as compensation for all the hard work, frustration, stress, and overtime you are undoubtedly going to do in most jobs.

Public Anchor

The public anchor is not a single amount, but rather a range where the minimum is ideally at least somewhat above your private anchor. This may sound sneaky, but the truth is you have no idea how much the other side values you or the position in question, and having a little extra wiggle room is not a bad thing.

There’s no real science as to how to set the range, but I tend to keep it fairly wide in the very beginning of a conversation (if this is a new job) where you have little information on what the role might entail (i.e., how much life it might suck out of you).

In an existing job scenario where you’re negotiating a raise, I’d use a single target anchor, but put it above my target raise, because that again creates negotiation wiggle room.

Let’s Practice

Now that you’re sufficiently confused by the number of anchors I’ve introduced, let’s walk through two practical scenarios. These are purely fictional and in no way related to any real person.

Imaginary Scenario A: Negotiating a Raise

You’re a senior product manager earning between EUR 85-95k p.a. (The amount here is irrelevant. This is a typical salary for a Senior PM in a number of Euro countries. This amount would typically be quite a bit higher in the US, the UK, and Switzerland, depending on company and location.) The company you work for is not profitable, but its financials are good. There is plenty of cash on hand, a long runway, and revenue has steadily been growing quarter-over-quarter for the past year. You’ve gone through a round of layoffs and have reduced your cash burn, which has freed up budget and others have gotten raises.

You are a valued employee, very visible in the company. Your work is recognized as high quality, and your boss regularly speaks well of you. However, in the time you’ve been at the company, your growth has stagnated, and although you’ve done a couple of big things, you haven’t taken any risks, so you’re seen as overly careful. Some folks have wondered whether a more dynamic, less risk-averse PM might not work better in your role.

Let’s interpret the above.

• The context is at first glance favorable for getting a raise

• However, the company is clearly being conscious of its spending

• The PM is valued, but there are lingering questions about whether or not they are replaceable

I find this scenario to be extremely common. This PM typically sees themselves as deserving of a raise. And you know what, they probably are. But unless they have a boss who’s willing to use some of their capital because they really believe in this hire, I am doubtful that it would be easy to get a raise.

What this PM could do is try to take on a larger initiative and demonstrate they are capable of managing risk.

None of this is to say that this PM can’t still try to negotiate.

I’d approach the boss here directly and go in with only one anchor — the actual desired amount — which should be realistic and not major, ballpark ~5% raise. Because this person is doing a good job, and they should be rewarded, but they don’t have enough leverage to ask for a more significant increase. Replacing them would be more expensive than giving them this minor raise.

But this PM should be ready to up their game.

Imaginary Scenario B: Negotiating an Offer

A junior product manager is negotiating their second ever job position in a company. They initially lowballed their ask and went 10k lower than what they actually want. The company they’re interviewing with has made them an offer and used the amount they initially gave. The junior PM now feels like they can’t say no to something they originally asked.

I’m pretty sure some senior PMs reading this will remember doing something like this even after they were no longer junior hires. Product management may be a business function, but PMs are not always businesspeople, and the negotiation muscle gets developed later.

Let’s interpret this situation:

• The PM gave away their private anchor and upon realizing that they could get more, felt frustrated

• The company wants to hire them, so they gave the PM what they asked for, but they probably have more budget for the role because companies never look for just a junior PM — the budget is typically a range that includes a more senior potential hire

Another extremely common scenario. But a much easier scenario to handle than the previous one.

This PM should thank the company for the offer, and go back asking for more, plain and simple.

Now, this PM may not get the higher end of their public anchor, i.e., the higher amount. Nor should they ask for it in this situation. We’re now talking about +5 to max. +10k on top of the existing offer, and that ask will need to be somewhat justified.

“After having learned more about the role and the requirements, I would be more comfortable with this amount and ready to close.”

“Thank you for the offer. If we could amend the amount to +5k, I would be happy to sign and finalize.”

Etc.

Many ways in which you word this, but make sure you always include that action verb at the end and the promise that you’re making things easy for the person on the other end.

After all, the sunk-cost fallacy will serve you great here, because they’ve already spent so much time and effort on this, I promise you, they’re as eager as you are to get it done with.

And that’s it. Negotiating is really more of an art than a science, but provided you have an understanding of the context, know what leverage you hold, and have an idea of your desired amount and private anchor, you can help yourself and your employer find a win-win scenario here.

All good salespeople will tell you that sales works best when creating wins for all parties involved.

And so it is with negotiation, too.

Disclaimers and Caveats

Folks may not always only be negotiating for a raise on their base salary. You can discuss stock options, vesting periods, vacation days, benefits, or whatever else might be on the table or is already part of the deal you’ve got.

Additionally, I can’t guarantee this advice is foolproof and will always work. More seasoned negotiators will break your anchor, reposition the conversation, and make you forget your first name by the time they’re done with you.

But equally as important — this is not a contract negotiation, however similar to sales it may be. At the end of the day, you always have some bargaining power, some leverage.

And sometimes, although I advise you not to do this — it’s the emotional side of things you can go for. Because maybe your boss just doesn’t want to lose you because it makes their life so much harder.

But be careful when playing this card. Honestly, I wouldn’t. Because there’s so many better things to use in negotiation. Like, say, all of the above.

Good luck out there, and feel free to reply and write me if you have a scenario and want my two cents on how I would handle it!

If you enjoyed the practical tips in this article, please consider sharing this post!

Share

Putting oneself out there is great, but it can also be nerve-wracking. And yet, it’s one of the surest ways in which to develop as a product person and grow into leadership.

Leaders have to learn to become comfortable with speaking and presenting to, and communicating with a broad array of people.

Communication skills are one out of many unfortunately described soft skills, unfortunate because there is truly nothing soft about them.

In my talk at ProductCamp Europe 2023, I went in depth on leadership and how to become a product leader by treating your career as a product, a significant part of which is learning how to communicate.

Check out the slides I used during the talk below.

You Are The Product

944KB ∙ PDF file

Download

A talk by Mirza Besirovic at ProductCamp Europe 2023

Download

IN OTHER NEWS

It’s been a really busy time, and I’m happy to share that I’ve launched a new online community for LGBTQ+ folks in product. Check it out and share!

In previous articles, I discussed the idea that in order to grow into product leadership, you needed to start treating your career as a product. In effect, you become the product. And that means your brand is a product portfolio of sorts.

Your brand consists of your career as a whole, the various ways in which you present yourself to the world (a resume, a LinkedIn profile, social media, a personal website, etc.), and how you interact and network with the product community at large (in person and online).

It’s a competitive world out there, and unless your resume can sing a song in the right key and with all the right words to it, it’s not enough to present a round picture of who you are, what your story is, and how you can excel at future roles.

Moving into product leadership requires being intentional and creating opportunity for yourself, rather than waiting for it to be handed to you.

Your Career is a Product

At the beginning of a career, it’s hard to think in time horizons spanning years into the future. My theory is that, when it comes to careers, we can only plan for about half the time into the future we’ve spent in a given career. Practically speaking, after 10 years in tech, that would mean being able to imagine at least the next 5 into the future.

It’s just a theory — tell me if it works for you or not.

Few people know what their five-year-plan is in their twenties, even thirties. I certainly had no idea. But after 11 years in tech, I now know where I want to go (for the most part). But more importantly, I (think I) know how to get there.

The thing is, as you gain more experience, you start noticing patterns. You see the mistakes of your past in context, and they become an important learning tool. It’s possible to model a personal growth trajectory by correcting or amending the mistakes of yore. Best case scenario, our mistakes teach us how to strategize.

Importantly, however, a strategy is not a list of ambitions, but rather an actionable plan that leads to desired outcomes.

In career terms, it’s the set of tactics, moves, activities you intend to undertake to get you to a desired position or outcome in your career.

Let’s say you are a Senior Product Manager. You feel like you want to move up into a role with more responsibility, but you are unsure of whether that’s an IC role or a people management role. In this case, your best bet is to try out for a Group PM role, which is designed as a player-coach position allowing you to get a taste of people management while not giving up your IC focus.

Beware, this is a grueling job. Player-coach roles are IMHO the toughest in product management. There’s a lot to juggle, but you learn an incredible amount as you go.

Personal Vision

Some of us aren’t born with a unique, undying passion that we’ve known we wanted to pursue all our lives. I find this to be common among product folk because we are by nature of our work generalists to at least some degree.

Your career strategy should be based on a personal vision, a vision you have for yourself, and while it may address your mistakes from the past, it ought to be aspirational.

It should be introspective, too.

• Do you want to be a leader?

• Why do you want to be a leader?

• Do you want to be a people manager? Why?

• What kind of leader do you want to be?

If you know the answers to all of these, you’re probably already a product leader or you have no intention of ever becoming one.

If you don’t have immediate answers to some of these questions, there’s a few truths of which you should be aware.

The path to leadership is full of stumbles, uncertainty, obstacles, and doubt:

• Working hard to succeed

• Learning how to present your work

• Being recognized at work for your hard work

• Gaining the respect of your peers, both at work and beyond

• Gaining credibility and legitimacy as a product person in the world out there

None of the above is easy.

Creating Opportunity for Collaboration

But being intentional about becoming a leader is likewise very rewarding and can help you develop into a more confident individual in all walks in life.

It can help you become more empathetic, express solidarity, approach others with compassion, and accept and encourage collaboration as the foundation of all relationships.

You will learn quickly, if you haven’t already, that collaboration rules supreme. And collaboration demands mutual respect, professionalism, constructive conflict, and healthy competition for the benefit of all. It means celebrating our successes and each other. It means treating each other as equals at all times. All voices deserve to be heard and have a seat at the table.

The next generation of product leaders must commit to creating opportunity for workers from underacknowledged, underserved, and underrepresented groups. As an aspiring or current product leader, you should actively seek to enable diverse voices to express opinions, participate in decision making, and help shape product philosophy, ethics, workplace policy, and user research to ensure we unravel implicit biases.

This means a commitment to diversity and inclusion that is shown in every decision, representation, pay, parity, and opportunity.

When we think of leadership, and its offspring product leadership, we should consider its ever-evolving nature, and the consequent need for us to continue to learn, develop, and grow.

Leadership is like school. You’re always due a term paper while new textbooks are thrown at you every month. What’s worse, you’re measured not only on your performance, but you’re also a teacher, measured on the performance of all those you lead.

Discovering Champions

A product leader has two jobs then: lead others to become product leaders and deliver business outcomes by empowering them to do their best work. If you’re blessed with a leader in your midst who you can learn from and is willing to teach you, avail yourself of the opportunity.

A fantastic HBR article I read said women shouldn’t look for mentors, but for Champions. Show what you are capable of to a champion who will fight for your cause.

Great leaders propel others.

Great product leaders help grow product people into leaders. But above all, great product leaders help budding product leaders build great product careers, well beyond the boundaries of the job in which they first met.

I love the concept of a mentor. I have mentors, and I am a mentor to others. But someone choosing to be your champion is a rare privilege, and a token of respect and friendship. It’s a wonderful human relationship.

Leaders who have privilege should use their privilege to champion those who they respect, but who otherwise might not be given the chance. Who might lack opportunity because of invisible biases, systemic obstacles, and a lack of awareness.

Your Resume is a Community Product

But a champion is not enough. You must give them something to champion. Start with your resume.

A resume is virtually organic, it has so much life. It changes continually, grows, adapts, presents a different face to different audiences. I often think of LinkedIn as an extension of my resume. Together, they are so much more.

A repository of experience. A network. A community.

Here’s the thing about communities: people sometimes only understand them to be built on a common interest. But long-lasting communities are also built on solidarity.

Communities are built on solidarity. You should use all the time you have to build community.

Community is about more than networking and finding opportunity. It’s about developing a mutual support network of peers who help you grow, who help you reflect on your practice, your career, and your job in a way that helps break you out of the confines of your day-to-day.

Community enables you to look through the looking glass, so to say, to the other side.

That helps bring your experience into perspective, it helps you understand how your current situation exists within the broader scope of the role, the industry, and the market in which you operate.

Existing between Communities

There are different types of communities.

During the pandemic, many of us developed and built close ties as we were all pushed online to communicate and build community.

The many different channels, mediums, platforms, even devices through which we communicate with each other have enabled a diversity and vibrancy of online communities like never before.

From this community, this platform, this medium, this device, we establish community by interaction.

It’s a meta-narrative of community. We build community by discussing building community. It’s really quite fascinating when you think about it. But not to get too philosophical, building community requires a lot of practical, hands-on work.

• Someone has to initiate contact.

• Someone has to share an idea.

• Someone has to make that idea come to life.

• Someone has to become many someones. A group. With a distinct identity, common interests, a desire to cooperate.

Substack is a community. A product conference is a community. Your social media contacts are a community.

Communities of practice.

Communities of experience.

Communities of interest.

Communities of peers.

Communities of teams.

Your Website is a Product

Communities help you refine your narrative as you discover and grow.

There’s a lot of us out there, and it can be hard to profile yourself to stand out from the crowd. To shine through.

We spend our days at work writing stories. We imagine the future, we hypothesize steps needed to create that future. We build products.

If you treat your own narrative as a product, you can start derisking its development, testing it out, understanding yourself as ever-evolving and presenting yourself to the world as such.

If back in the day you had to dress for the job you wanted, today you have to build the brand you want to become.

What this means is being deliberate about your career, your professional brand, your visibility, your network, and your community.

Building a brand is not an exercise in fake it till you make it.

Building a brand is intentional self-development and growth to arrive at a personal vision of the future.

It means putting your best foot forward.

But more importantly, it means telling the world your story. How you arrived to where you are and why. Your intention. Your purpose.

It brings your skills and competences closer and makes them more accessible.

Recently, product portfolios have become very popular. I think they are a good tool, even though I freely admit I don’t have one myself. But I’ve been considering making one.

I love a personal website. Or newsletter. Or interesting LinkedIn posts or comments. Or podcast appearances, webinars, talks.

The product community is so active nowadays, it’s easy and fun to connect with others.

Let’s Get Down to Business

Alright, that’s the theory of it all. But how do you get all of this done?

Write a personal narrative

Describe who you are, what your journey has been so far, what knowledge and skills you’ve gained, and what you are currently doing in a few paragraphs. Here’s a version of my own personal narrative, bits and pieces of which you’ll see spread across the interwebs.

I’m a product leader with 11 years of experience in hypergrowth tech, including a couple of German unicorns and a Danish scaleup. Currently I work as Director of Product Management at Dixa, focusing on conversational AI, automation, and messaging products.

Over the past decade, I’ve worked in a number of different industries and companies at various growth stages — from early stage B2C social networks, growth stage B2B2C travel tech, fintech/insurtech, streaming, data, and lately B2B SaaS in the CX space.

As a maker, I’ve shipped backend / API, data, and growth products, consulted on the development of platform products, and built products end-to-end as a venture architect.

As a product leader and people manager, I spend most of my time focusing on organizational alignment, product vision and product strategy, and actively coaching and training my reports.

I’ve likewise been a mentor for the past couple of years, most recently as part of ADPList.org and also 2hearts, a community supporting young immigrants working in tech.

My work experience is mainly within multicultural, global companies that value diversity. In addition to product management, I’m very passionate about inclusion, social justice, and work culture.

Now condense that into a single paragraph that you can use as a blurb or bio.

Product leader and mentor with 11 years of experience in hypergrowth tech, including 2 German unicorns and a Danish scaleup. Expert in B2B SaaS with a focus on automation and ML/AI. Previous experience in (B2)B2C and a range of industries (fintech, travel tech, streaming, social networks). Passionate about training the next generation of PMs & diversity and inclusion.

I use the shorter version on my LinkedIn profile and on my actual resume

Make your online presentation consistent

Make sure your LinkedIn, social media profiles, resume, personal website tell the same story, using the same language.

Limit the amount of information you present. You don’t need to show everything you’ve ever done.

While it may be interesting that you do more than one thing in your career and free time, don’t forget that recruiters, hiring managers, and generally people out there have short attention spans. If I’m honest, many people won’t make it to this paragraph in this long long article. You must be really motivated to make it all the way down here, so kudos to you on that!

Describe not only your goal, but also how you intend to get there

Many roads lead to product leadership. Here’s a few concrete methods you can try out, depending on what you are willing and ready to do. Quoting from a LinkedIn post I wrote last year:

The tried-and-tested method of working hard in one place and moving up the corporate ladder.

If you’re lucky enough to be in the right kind of environment. The downside of this approach is you can easily get stuck in the wrong company and never move into a leadership role.

Job hopping until you land into a leadership role.

Usually at a smaller company, perhaps an early stage startup, especially if you’re moving from a larger business. The downside of this can be on the learning side, because you might end up missing out on executive product coaching.

If you have a manager who cares, you can try to structure a plan for how you will move up into leadership.

A great manager won’t care whether that’s happening at your current company or somewhere else — the important part is to help you grow. Because that’s what great managers do.

Starting your own company or side hustle.

You want to build a product and grow it large enough to make you a leader? What better way to do so than to build your own. This of course comes with great risks, but the rewards could be even greater.

Joining an early-stage startup as the first PM.

While this move might be as risky as the previous, it can also be a great opportunity for growth and creating a real, lasting impact on a new product and company.

Last but not least, get ready to fail

I’ve failed many times trying to move up and get promoted. I was deemed too green, or simply wasn’t in the right environment. Rejection never feels good, but it teaches you something every time, if you’re willing to learn.

That lesson is two-sided. You probably have more to learn. But sometimes the lesson is that you need to get out of a stifling environment.

Be ready to fail. But be ready to leave, too.

Leaders not only recognize and grab opportunity, but they create it for themselves and others around them.

And that’s that.

A forever work-in-progress. But if you adopt the right mindset, moving up to product leadership can be the most fun you’ll have in your career.

To recap:

• Your brand is a portfolio of products: your career, your online presentation, your community

• To move into product leadership, you ought to develop a personal vision and strategy to test different approaches that help you grow your brand and achieve your goals

• Your strategy needs to be an actionable plan, not a wishlist of personal ambitions

• Community and collaboration are crucial to getting you there and helping you stand out from the crowd

• Write a personal narrative and stay consistent with your messaging

Next time I’ll talk more about how to position yourself, and what you might need to do to navigate office politics and land that coveted promotion.

ON A PERSONAL NOTE

It’s been a busy personal month, so I missed the February edition of this newsletter.

In a couple of weeks I’ll be speaking on the Zeda.io product management podcast about DEI in tech and how so much of it is cosmetic.

A week ago, I launched ✨ productqties.com ✨, a community for LGBTQ+ folks in product, and I’m happy to share we’ve already got nearly 50 members and a scheduled first event tackling the topic of Queer Product Leadership and the unique benefits and challenges of being an LGBTQ+ leader in product.

Lastly, I’m happy to share I will be speaking at ProductCamp Europe 2023 in Cyprus talking about growing into product leadership and how treating your career as a product can get you there.

I had a great time on the Technology Leadership Podcast with Jake Whitby from Tech Source talking about how to upskill as a product manager and move into product leadership.

Listen to the episode here:

• [01:42] How I got started in tech

• [06:36] Understanding leadership and management

• [11:08] Advice for people moving into leadership

• [13:37] The importance of up-skilling yourself

• [18:23] Advice for Senior Product Managers

• [22:14] Breadth of experience vs. depth of experience

• [24:47] Advice on how to hire for a leadership role

• [29:52] The importance of speaking to your manager

• [34:15] Advice for people who want to become Product Managers

Find the episode on your favorite podcast app:

• Apple Podcasts

• Amazon

• Spotify

• Google Podcasts

From the podcast website:

Key Takeaways

• Learn about different routes into Product Management and how many people find themselves in the role by accident or recognition of transferable skills.

• Understand that there are two tracks in Product Management: as an individual contributor or a manager.

• Consider why moving into a leadership role in Product Management requires different skills and focus than working as a product manager.

• Get tips on how to find a mentor, be part of a community, and educate yourself to improve in a Product Manager role with a zest for learning and growing, not only in Product Management, but in life in general.

• Understand why strategy and metrics - for example financial metrics such as annual recurring revenue and net retention rate - are important for Senior Product Managers to understand.

• Learn more about how a business develops a strategy and how it trickles down to each department and how it impacts Product Management.

• Hear why due to the current economic climate, companies may be hiring less and being more selective in their hiring process and in this context how to move into a leadership role at your current company by being proactive and explicit about your career goals and growth plans with your manager.

• Find out how to seek mentorship from networks such as ADPList, the Mentoring Club, MentorMesh, and My Mentor Path to get value input in how to evolve into leadership roles.

• Understand how to be proactive and intentional in communicating and working cohesively with other teams such as sales and marketing.

Subscribe now

I got my first job in tech while still in grad school. After over 50 applications, a lot of ghosting and many rejections, I finally landed a part-time gig in a tech company.

And I thrived. In mere months, my part-time student gig became a full-time job. They made me team lead. I dropped out of grad school, and there I was, 20-something and managing a team of 60 people. It was beyond anything I could have imagined.

“It’s Just Business”

Several months later, the company had decided to downsize, and I was asked to let go 50% of my team.

People I had worked with as peers, coworkers, and friends. And many more who I had hired.

I had three months to execute a redundancy plan that I had to develop on my own.

It was my first full-time job. I had never worked in tech before. I had no idea what the words “layoffs” and “redundancy” even meant.

Like many first-time leaders, I was thrown into the deep end without much guidance.

“They promoted me and then left me alone.”

Sound familiar? I hear this from product leaders often.

I had no idea what to do, but I knew that I wasn’t going to do it alone. So I organized a meeting with my team, sat everyone down, and told them the truth.

I told them that, while there was nothing I could do about the fact that some of them would lose their jobs, at the very least we could make the process fair and transparent.

Most of the work the team was doing was measurable, so we agreed to focus on a number of metrics that were the strongest indicators of performance and added clear value to the business.

But a lot of the work was research-based and included writing, tagging, and classification tasks that were subjective value judgments. Our QA process had included verification by an additional two or three team members. (For context, we were building training sets for machine learning experiments.) So we decided we would apply the same peer review mechanism to each other’s work.

Two or three peer reviewers would rate anonymous work. It was both transparent and ensured fairness.

I designed a dashboard showing overall team performance, which was public, and individual performance dashboards for all team members, which we reviewed in one-on-one meetings.

Tears, Thank Yous, and Truths

Although this was the best possible version of events, it still sucked.

My first big call as a leader was to choose which 30 of my friends and colleagues to fire.

One person cried. Many said thank you. One person was upset for a while. But no one was mistreated.

We spoke to each other at eye-level, and every decision was based on data, peer review, and supervisor feedback. Everyone received a performance assessment and was shown where they stood compared to the rest of the team, with reasons why they were chosen to be let go clearly and explicitly spelled out.

Leaders have to fire people.

Those of you becoming product leaders should be made aware of this.

It’s not always possible to fire people quite so transparently and openly as in my story.

I use the word fire because we try to mask the truth about this by calling them layoffs, redundancies, downsizing, etc.

At the time, this seemed like the most awful thing I would ever have to do. The truth is, I would see much worse over the course of my career.

In this scenario, I was given full authority and control over the process.

I had three months to develop and execute a redundancy plan for the team I was running.

I could ask for help internally, and I did run my plan by people for a sanity check, even if it was me who had to do the dirty deed at the end of the day. Luckily, they were overwhelmingly supportive of my plan.

In most other circumstances, layoffs happen quickly, you have a limited amount of time to make big decisions, and you don’t always have editorial control of the messaging and the process.

Nothing will prepare you for it. It will suck every single time.

But you will become better at communicating to your team about it. And managing your management to ensure that the process is handled the right way.

How to Fire People

As practical advice goes, this is not my favorite to give. But it’s important we talk about it because it makes all the difference in the world.

Communication

Your employees deserve to know why you are firing some of them. This is not a time to mince your words or beat around the bush.

Layoffs are a failure of leadership, but the unfortunate truth is that it’s rarely leaders who are affected by them. There is a cognitive dissonance in that. Some companies are able to look inwardly and realize that it’s really a change in leadership that they need. But in most cases, it’s the same leaders who would need to change who are the ones deciding on layoffs.

As a product leader, you might find yourself in the position to execute on this decision.

This might be a good time for you to revisit whether your company is still the right fit for you. Does it have a future? Are layoffs a symptom of a greater problem?

The hard truth is that firing people can help turn around a business. As much as I hate to admit it, I’ve seen it happen.

Tech has been growing like mad for more than a decade, and we’ve made companies bloated and inefficient.

At the same time, your job is to look at the organization and its design.

As a product leader, you regularly find yourself in the situation to structure teams, move folks around, realign their work around product strategy.

Objectively speaking, this is no different. It’s a realignment of team structure based on strategy.

So approaching this task should start with strategy, the circumstances of your business and the market you find yourself in, and then trickle down onto org design.

You should consider individual ability, past performance, importance for your culture (because culture bearers are vital employees), and do your best to understand and account for further potential attrition (i.e., which people may choose to leave because someone got fired).

Never keep your team in the dark, and make sure that you are communicating what’s going on throughout.

Of course, you won’t have the luxury to discuss individual decisions, but don’t keep your team waiting for weeks. In most cases, you won’t have the luxury of months on end to decide what to do. At best, you’ll have a couple of weeks. At worst, days.

Compassion

Don’t be confused by the corporate speak: we are talking about human beings with private lives, families, dreams, hopes, and fears, and you should never forget that not only your employees, but also their dependents will be affected by your decisions.

Approach your people with compassion, kindness, and solidarity.

We are all workers in the corporate meat grinder, and our destinies are intertwined.

Beyond that, we are all human beings who have ourselves been fired and gone through tough times. At least most of us have.

Some leaders choose to behave like automatons and detach from their feelings because this is in many ways a traumatic event for all parties involved. But what that does is both damaging to employees and leaders alike.

I advise you to sit down one-on-one not just with the people made redundant, but also with everyone on your team and explain what is going on — throughout.

Keep talking, as much as you need to.

Meet regularly and often, and create many opportunities for people to express their feelings.

Accept that some of this will hurt. There will be vitriol, anger, disappointment, and sadness.

You need to accept that, and you need to be prepared to handle that.

Some schools of thought on this argue that it’s better to limit communication and provide only a selection of forums in which to discuss things. Some leaders prefer to make a quick cut and move on.

But layoffs have an extremely detrimental effect on morale, performance, retention, and a host of other company success and employee experience metrics. Great leaders do not underestimate the cost this bears.

So do your best to help your team air out their feelings, vent, and collectively heal. Don’t ignore the psychology of this situation in order to avoid conflict.

Care

Giving someone bad news is best done directly and without hesitation.

Sit down one-on-one, tell them what the decision is, and explain why.

Give them a chance to process the information, and offer to answer questions.

Accept that some people will react badly. Accept that some people will react really badly.

Do not lose your temper.

Do not raise your voice.

Do not moralize or become judgmental.

Be kind, be compassionate, and offer your help. Write them a recommendation, share their profile with your network, advise them on their next step. Offer mentorship or coaching.

This may all depend on your previous relationship. If you’re firing a person you would have fired otherwise, this may be harder for you. But try to look at it from their perspective.

This works entirely on a case-by-case basis, of course. You also need to be comfortable with anything you want to offer.

Some people will reject every offer. And that’s OK. Don’t force anything on anyone.

This isn’t about you.

But you are allowed to acknowledge that you have feelings about it, too. So reach out to your peers to talk about it. Don’t ignore how it makes you feel.

Now take a deep breath.

I know, this was not a pleasant text to read. It wasn’t perfectly pleasant to write either.

But it’s the truth. Leaders have to fire people.

And to become a leader, you have to be prepared for all that that means.

Subscribe now

If you asked me to give you a personal summary of my 2022 work year, it’d go something like this:

• a new job,

• a company merger,

• layoffs,

• starting to write about product online,

• people starting to engage with what I write,

• starting this product newsletter,

• guest appearances on a few podcasts,

• a couple of promotions, and

• many many new product acquaintances and friends.

2022 was nothing if not busy. A year full of personal and professional growth and unique challenges, it taught me lessons I believe are worth sharing.

So grab a cup of something hot, get cozy, and read on…

Volatile Times

You could say I started 3 jobs in the middle of the pandemic.

In 2021, I joined a company whose product I continue to admire, but we simply weren’t a match. In that sense, jobs are a little bit like relationships. Sometimes you can respect and see the value in each other, but still decide it’s not the right fit.

9 months later, there I was again, moving to another job, starting to worry a bit about job hopping quite so often, if for no other reason then that some employers don’t seem to look too kindly at that.

Nobody judges companies for rotating through staff. But we readily judge employees when looking for better opportunities, trying to find a win-win fit for all sides involved.

But I was lucky, and in the end found a great fit. In the process, I learned (or remembered) the importance of company culture.

A few months later, my company merged with another business, and the rollercoaster started again. Soon, like many others, we experienced a round of layoffs and several challenging months learning to adjust to our new collective reality. We made it in the end and came out stronger for it in some ways, but not without first earning a few battle scars.

Lesson #1

In times of volatility and change, a company’s culture is the most important predictor of your success at the company.

After three years into a pandemic, followed by an economic downturn that suggests another 2-3 years of instability, I’ve learned that understanding how a company might respond to change is now more important than ever before.

How likely are they to lay people off? Will they expect you to do more work for the same pay? What are the chances you will move up the career ladder?

The truth is, it doesn’t matter what the cause of crisis in your company may be — the company will often react in the exact same way.
— Field Guide to Organizational Change

I’ve explored this and more in a recent article discussing how organizations handle change and what employees can do to manage this risk.

On Product and Silly Business

Field Guide to Organizational Change

As the past week has demonstrated yet again, only one thing in tech is constant to a degree such that it’s become a worn out cliché — change. We live and work in dynamic environments that are subject to external and internal stressors, an increasingly complex world that inundates us with information, and an ever evolving socia…

Read more

3 years ago · 1 like · Mirza Beširović

In fairness, this was not the first time I had lived through an M&A and layoffs. I had had the experience several times over in previous companies, so I felt better prepared for it than others.

Still, what struck me was how emotional the journey was, for me and others, because we put so much stock in our jobs. After all, we spend a third of our lives working, so it’s of little wonder extreme changes affect us outside of work and can impact our personal lives as well.

Which got me thinking about the role that my career plays in my life.

Writing About Work

As product people, we already spend so much of our time thinking about work. With a job that requires you to be as plugged in as most of us are, it can be hard to disconnect at the end of the day.

I realized I was already spending a lot of my free time reading, writing, and thinking about product, but I wasn’t sharing that with others. So I started to post more regularly on LinkedIn.

At first, my posts were like a lot of the product writing out there: bubblegum content chewed so many times over, they added little original value to the product and tech community at large.

But writing these posts helped me process my work life, think about my work in a more structured fashion, and eventually led me to a few nuggets of gold that helped me make forward strides professionally.

Lesson #2

Writing about product will make you a better product manager.

Writing about product on social media got me thinking about product in new ways and helped unblock me on work challenges.

Eventually, folks began to engage with my posts, and I started gaining followers, mainly on LinkedIn where I invested the most time and effort. What really got things going was the 30-day PM writing challenge I agreed to, where I pushed myself to write about product daily.

It didn’t start out as a quest for likes and followers. But I don’t deny they’ve become a booster that motivates me to continue writing.

Followers create a sense of accountability and responsibility for the content you are producing, as you suddenly realize you’re no longer writing into the void.

Followers mean community. And community means belonging. There is more to it than vanity metrics or dopamine hits that feed the ego.

This increased visibility has likewise led to more job offers, partnership pitches, podcast invitations, getting featured in product management newsletters, and a lot of new contacts alongside some professional friendships.

Lesson #3

Making yourself visible online will make you more employable.

In a world saturated with product folks just made redundant, making yourself more visible is the surest way to stand out from the crowd.

It’s both the toughest and the best time to be a product manager. Competition is fierce, but the field has never felt as mature as it does today.

The proliferation of product content creators is a sign of that.

In my opinion, people’s motivation to share product content online is a combination of reasons that range from survival (get a job, make yourself more employable) to reputation (feel respected) and personal growth (go deep and wide within your field).

I support everyone’s decision to write about product.

While I’ll scroll past the occasional pithy post (including some of my own), I try to look at it as people growing and learning in public, sometimes awkwardly so. I respect them for putting themselves out there.

Career Diplomacy

Writing product content is yet another part of developing and growing yourself and your career.

We are in a new era of personal branding in which we have more control over the image we send out to the outside world than ever before.

Social media has amplified our voices, for better or worse, and we are now able to not only represent certain versions of ourselves, but also engage in ongoing dialogue with a global community of product people.

In a sense, we are career diplomats, navigating the complex waters of the global tech industry.

For a lot of folks, this online footprint has become another trust signal with prospective and current employers. It has become possible to show another side of yourself as a professional that for this or that reason is not possible to show at work.

Lesson #4

Promotions are as much about merit as they are about career diplomacy and grabbing the opportunity in front of you.

If back in the day you had to “dress for the job you wanted,” today you have to build the brand you want to become.

That’s not to say that merit and hard work won’t get you places. I still believe in hunkering down and getting the job done. In product management, nothing else can teach you how to be great other than actually getting your hands dirty. No certificate, no coach, no listicle.

But lessons of old still apply. Promotions are not something to be given to you, something you should wait for and expect as a result of your hard work. You need to recognize and even create opportunity for yourself, and grab it when it’s in front of you.

It requires a bit of confidence, perhaps audacity even. But it ultimately comes from a place of humility. Why is it even important that we continue to grow and move forward in our careers?

This has never been in doubt for me — it starts from the basic human need to survive, but as you grow, it morphs into the human need to thrive.

Promotions and upward career mobility are about so much more than money and titles. They are about fundamental human needs, and when looking at it all from that perspective, you learn there is a lot to be humble about.

Mentoring and Pacing Yourself

One of the most rewarding and humbling experiences of the past year has been mentoring others.

Over the course of the past year, I’ve become a member of a few groups and networks dedicated to helping young folks from all over the globe thrive and develop:

• IEEE Innovation Nation, a fellowship program providing training and funding for young Bosnians & Herzegovinians with startup ideas, with whom I worked as mentor in 2021 and startup advisor in 2022

• ADPList.org, a global mentorship network, where I became a product management mentor in July 2022

• 2hearts, a network offering resources and mentoring for young immigrants in tech, where I joined as a community member in April 2022

Offering my time to mentor budding product managers, people looking to break into product, and young people with startup ideas, I’ve learned that mentorship is one of the most valuable activities product leaders could afford themselves. There is so much to teach, and yet more to learn from these brilliant minds.

But after dozens of sessions and thousands of minutes spent talking to mentees, I’ve learned it’s important to pace yourself.

Lesson #5

Mentorship is a two-way street.

While I enjoyed the time I spent with many of the people I’ve met, there were a few whose minds and ideas sparked my own imagination. And if I make only one resolution for 2023, it’s that I want to spend more time with those people.

This will inevitably mean that I need to limit the time I have to offer others — until now, I didn’t discriminate, and I accepted pretty much anyone’s request to meet me.

But time is a precious resource in a product person’s busy life, and I’ve learned that for me to be a great mentor to, I need to be able to learn from them as well.

I think that’s the difference between a mentor and a coach.

Ready for 2023

To wrap this up, I'm quoting a LinkedIn post I wrote a few weeks ago, as I think the the lessons I learned talking to mentees might help others to adapt to the current economic climate as a product manager. Perhaps some of these will make you more prepared for the next year:

I've spent close to 2,000 minutes over the past 6 months talking to mentees from all over the world looking to develop as product managers, break into product management, or move into product leadership roles.

Most of these conversations were about how to land jobs in the current economic climate.

If you are job hunting, here are a few things to keep in mind.

The job market is currently flooded with product managers who were made redundant.

That means there's a lot of highly qualified folks out there looking for new homes. This makes breaking into product more challenging currently than has been the case for many years past.

Companies are not hiring decisively, and they seem to be spending a lot of time weighing their options, delaying the process, and then offering packages below candidate expectations.

Some mentees told me this caused them to reject offers, which itself is slowing down hiring and has also made things economically more precarious for candidates as they continue to interview.

Companies are experiencing decision paralysis due to unpredictable market conditions and little guarantee of low volatility.

This has spooked boards and investors, VCs and private equity firms, and other institutional investors who are holding on to their cash.

Companies have instead shifted focus on reducing cash burn and extending the runway, often at the expense of hiring or employee retention.

The advice I've given jobseekers is to decide on companies carefully, do their due diligence, and spruce up their resumes to tell a narrative and showcase their skills and successes.

Breaking into entry-level product roles, however, is going to be harder for some time to come.

I'd advise those who are willing and interested to consider starting out in roles adjacent to product (such as marketing, growth, product analytics) and make a lateral move when the time is right.

Look for companies whose product managers managed to do the same while working there.

Other approaches are to build your own product, develop a personal brand and share experience online, or analyze existing products in posts to discuss things that interest you.

Growth, platform product management, and machine learning are three high-growth areas I would consider, depending on your affinity for data, technology, and experimentation.

It's a tough time out there, so stay aware of developments. You need to monitor the market and make yourself discoverable and visible online.

For budding leaders, the advice is the same — invest in developing strategy, communication, and people management skills. Find a mentor. Plan and commit, and experiment. In this situation, you are the product.

Good luck out there! You've got this!

To recap:

• Lesson #1: In times of volatility and change, a company’s culture is the most important predictor of your success at the company.

• Lesson #2: Writing about product will make you a better product manager.

• Lesson #3: Making yourself visible online will make you more employable.

• Lesson #4: Promotions are as much about merit as they are about career diplomacy and grabbing the opportunity in front of you.

• Lesson #5: Mentorship is a two-way street.

And perhaps the most important lesson of all: Never forget, you are the product.

I wish you happy holidays and a joyful, successful start to the New Year!

Hey there! 👋 I’m Mirza, and you’re reading On Product and Silly Business, the newsletter about the sometimes silly world of product management, leadership, work culture, and the silly business of working in tech.

Please like and share if you enjoy the articles, it helps spread the message!

In companies with underdeveloped product cultures, teams escalate issues too quickly. It can often happen that in such places, non-tech teams escalate fundamentally technical issues to management stakeholders. This puts a lot of additional strain on product managers, as now in addition to dealing with the technical problem at hand, you have to manage executives and leaders.

What to do in these situations?

Firstly, keep your cool and take a deep breath.

You’re probably already fuming or stressing out. It feels like a person is threatening to rat you out to teacher. I know, it’s hard to unlearn being a child when working with other former children. We’re all in it together.

Secondly, try walking in the shoes of the person who is escalating the issue.

They probably don’t understand your situation, and they themselves are likely merely trying to solve a problem. Perhaps you didn’t communicate proactively or clearly enough, and there was confusion. Or someone in your leadership made promises without involving you. Maybe a HiPPO ran their mouth.

Thirdly, offer to speak with them and understand their context better.

It’s possible all of this is a misunderstanding. Sometimes a short one-on-one is enough to resolve what seems like even the gravest of problems when writing about it on Slack.

Sometimes, however, people escalate issues needlessly, without consideration for the impact of their actions and the stress that they cause.

If speaking with them privately doesn’t help, then you need to involve others.

In this situation, you sometimes have to become a go-between while standing your ground firmly. Bring that person and the relevant management stakeholders or others involved in a room (or, well, video call) together, and air out the dirty laundry. Do it without pointing fingers. But discuss the issue without hesitation.

Talk about your culture of escalating issues, and try to agree on some rules around how, when, by whom, and to whom issues get escalated.

Some folks hide behind the C-level and abuse the power those folks have over others. Don’t let them.

But make sure you understand them first. And only if it’s clear you’re being treated unfairly, react.

As the past week has demonstrated yet again, only one thing in tech is constant to a degree such that it’s become a worn out cliché — change.

We live and work in dynamic environments that are subject to external and internal stressors, an increasingly complex world that inundates us with information, and an ever evolving social and cultural landscape.

It’s no wonder we’re all so tired.

Plus, it’s November, and the year seems like it’s already done, even though I know you know there is still much left to do.

The past three years have been particularly hard. When the pandemic hit in early 2020, we were all scared, a scenario out of a film playing out before our eyes and on a global scale. The immediate result for most people working in tech was that work was now from home on a full-time basis, without any previous preparation or adjustment allowed.

This was perhaps easier for tech startups and scaleups, and larger tech companies with a history of WFH (or “Home Office,” as they call it in Germany).

Other businesses had a harder time adjusting, especially those unused to video meetings, remote work, and a distributed workforce.

Boards and investors got spooked, too. Tech companies froze hiring, and many decided to reorganize and restructure, which inevitably meant layoffs.

The reason companies opt for redundancies is because in times of crisis, where private equity and VC money dries up, they have to extend their runways by reducing cash burn, protecting existing revenue, and generating new revenue through new business or upsell on existing customers.

It’s easier to keep money in the piggy bank than it is to add to it in a pinch. The operational cost of employee salaries, bonuses, and benefits is too great a chunk of the pot to ignore.

The Company Playbook

Great businesses use a time such as this as an opportunity to reassess their complete strategies top-down, bottom-up. When executed the right way, involving employees in figuring out what the next strategic move should be for the company can both help save jobs and engender a sense of trust and belonging during a difficult period.

Great businesses are transparent about their intentions upfront. This provides their employees the chance to decide whether they want to go through the motions, state their case for why they should be retained, and involve themselves in the task ahead. The reality is, of course, different. Gergely Orosz breaks it down neatly:

Transparency enables employees to leave on good terms. I’ve been through several major reorgs and layoffs in my career, and I’ve often seen that the folks who are let go first are often the folks who would leave anyway. Being transparent about your intentions creates a win-win. Mind you, I’m not advocating for transparency for the sake of a company’s interest, but it would be silly to ignore the upside that it creates.

Great businesses understand that letting go X% of staff means that there is that much fewer people to do things. It is both inappropriate and ineffectual to demand people work more to pick up the slack so the business could continue as if nothing happened. Great businesses will reduce scope, work leaner, and pause or drop all the initiatives and side quests not pertinent to present survival.

Many businesses went through these processes in 2020, some in 2021.

You’d think the shock of a pandemic would be enough for companies not to want to relive this experience again, and that they would have learned a lesson or two about the implications and consequences of doing the opposite of what great companies would do.

But lo and behold, most companies do not respond to shock like the imaginary great companies. Few are truly able to keep a clear head and work together to overcome crises.

So it came at no surprise whatsoever that many companies wound up doing the exact opposite when in 2022 the economic downturn managed to scare boards, investors, VCs, private equity firms, banks, lendors, creditors, institutional investors, Wall Street, Main Street, and just about every financial institution on the planet.

The truth is, it doesn’t matter what the cause of crisis in your company may be — the company will often react in the exact same way:

• Pivoting because it failed to find product-market fit;

• Or you were very successful and acquired a business, so now you’re going through a merger;

• Perhaps your company was sold to another, larger one, and you’re figuring out how to integrate;

• Or there’s a shake-up at the top because you’re not delivering the results your shareholders expect;

• Or, you know, there’s a pandemic and a recession.

Congratulations to you if your company is experiencing more than one of the above. You’re in for a rollercoaster experience that I’m sure will make a great story some day and hopefully leave no lasting scars.

What’s a Worker To Do?

Alright, now that we’ve painted that pretty little picture, what can one do to survive this? How do you navigate change? What is the appropriate way to respond to it? And provided you do survive it, how do you make sure to get the most out of it?

Understand your company’s risk appetite

Not every company responds to crisis with downsizing. Some businesses take the opposite approach and use crisis moments as opportunities to invest, buy assets or entire companies on the cheap. They’ll expand their workforce at a time they know the market might also accept lower salaries because of a dearth of competition out there and a general hiring slowdown or outright freeze.

Other companies are much more risk-averse, and they would rather save cash-on-hand and extend their runways for as long as the economic forecasts dictate. They won’t all go into layoffs, however. Some companies will look to cut cost elsewhere.

Look for signs you’re about to go through layoffs

You can usually detect where things stand in your company if you look for telltale signs.

There’s a hiring freeze, and you started canceling tooling subscriptions. Operational overhead is the first to go. Your supervisor might ask you for a list of all the tools you use daily. There’s spreadsheets going around with monthly and yearly cost, and an assessment of how badly the team needs something. All the nice-to-have tools are the first to go. Engineering is probably looking into cloud providers, and anything with high variable cost.

Management is quiet, and the rumor mill is spreading. While this can simply be a sign of bad leadership, layoffs are also a legal nightmare, and companies are often not allowed to discuss anything until they’ve got the legal “A-okay!” to discuss plans with employees.

You’ve had layoffs before. In my experience, companies that have laid off once — and haven’t gone through a change of management or significant realignment of their strategy and processes — are more than likely to downsize again. This isn’t necessarily a bad thing as, objectively, laying off a certain percentage of staff might save jobs for everyone else by extending the company’s lifeline. It’s not a question of fairness, because none of this is fair, but it does help us understand how to position ourselves as workers. Jason Knight of One Knight in Product Fame talks about layoffs from the company perspective in a recent edition of his newsletter — it’s a worthy read.

One Knight in Product newsletter

Moving to Substack, thinking about lay-offs, and swearing about the design industry

If you’re trying to sell a Now/Next/Later roadmap, make sure you get the narrative right! Things might look a little different around here Unless you’ve been living under a rock, you know that Twitter has been acquired and half its people have been laid off…

Read more

3 years ago · 1 like · Jason Knight

Spruce up your resume and LinkedIn profile

Don’t wait for the Fates to come get you. Take charge of your situation and freshen up your resume and LinkedIn profile, especially if that’s something you don’t do often. I do a lot of resume reviews, and I can condense the majority of the advice I give into the following:

• Make your resume one page. Recruiters have to scan hundreds of these documents a week. They don’t have time to read about all the courses you took. Keep it crisp, avoid wordy prose, and make it easy to read and to scan for relevant keywords. If the world’s most senior execs can cram years and years of experience onto a single page, so can you. Remember, it’s about relevant experience and (transferable) skills, not any random experience.

• Use bullet points and try to limit length to one line. Again, consider readability and how easy it is to understand what you’ve done.

• Describe your impact. Sentences like “Led product development for X with a team” or “Launched feature Y that does this or that” are vague and don’t describe what you achieved as a product manager or leader. Instead, talk about the value you captured for your company:

  • Launched feature X which generated a 20% uplift in signup CVR, or

  • Led product development for X and increased retention rate by 10pp
    

  I recommend reading Diego Granados’s advice on how to write your resume to showcase impact and skills.

• If you’re applying to big cos, make sure you have an ATS-friendly Word version of your resume. Most startups won’t run applications through ATS software without human intervention, but corporates will. Make sure your resume is formatted appropriately.

• If you have little previous product experience and are applying for a product role, focus on transferable skills. Make a separate list of all of your previous projects, everything you’ve done, and everything you’ve achieved. Now connect the dots between that work and the products you worked on. Look for skills that are relevant to product management, or experience that is equivalent to product development. Ask a product manager or mentor to review your list and help you break transferable skills out. And then punch up your resume focusing on those.

Accept things for what they are

And don’t forget to take care of yourself. Take time off, be with your loved ones, go for long walks in nature.

A lot of folks use these occasions to reinvent themselves. So think about whether you might want to start a side gig, or maybe even want to go into a completely new field.

You’ll get through this.

If you ever need to talk and feel stuck, feel free to reach out through my website at mirza.tech or my ADPList mentor profile

In September, I took on a 30-day writing challenge with daily prompts with questions about product management. Daily writing is a great way for product managers to share their knowledge and experience and help others upskill.

The posts below originally appeared on LinkedIn. I’m sharing them here with minor modifications.

Enjoy reading!

• 1/30: The Best Thing about Product

• 2/30: The Greatest Challenge about Product

• 3/30: Top Skillsets for Product Managers

• 4/30: Writing Is a PM Survival Skill

• 5/30: Technical Skills for Product Managers

• 6/30: Empathizing with Your Users

• 7/30: Effective Time Management for PMs

• 8/30: How to Craft a Product Vision

• 9/30: Difference between Mission and Vision

• 10/30: On Roadmaps (turned into a blog post)

On Product and Silly Business

On Roadmaps

A product roadmap is a list of features presented in a visual Gantt-like timeline with exact delivery dates that the product org updates on a quarterly basis so sales and marketing can sell the product. Right? Right?! No? … Maybe sometimes?Subscribe for free to receive new posts and support my work…

Read more

4 years ago · Mirza Beširović

• 11/30: Writing Compelling User Stories

• 12/30: Top Five Product Success Metrics

• 13/30: Love Letter to FigJam

• 14/30: Key Elements of Product Discovery

• 15/30: The Superpower of Product Managers

• 16/30: Product Management Is a Tough Job

• 17/30: Product Leaders to Follow

• 18/30: How to Keep Your Energy Levels High

• 19/30: Embracing Business Metrics

• 20/30: Understanding Sales as a PM

• 21/30: Understanding Marketing & GTM Strategy

• 22/30: Mastering Business Communication

• 23/30: Handling Stress as a Product Manager

• 24/30: Comfort Zones and Happy Places

• 25/30: Allies and Allyship (turned into part of a blog post)

• 26/30: Networking for Product Managers

• 27/30: Product Management Career Ladder

• 28/30: What Product Managers Are Not

• 29/30: Saying "No" Constructively

• 30/30: The Benefits of a Daily Writing Habit

Let me start with a disclaimer.

Human rights and social justice activism is not equivalent to for-profit organizing in the form of companies. If anything, they are often at odds ideologically and politically. This text is not an attempt to bridge that gap and pinkwash product management, or an attempt to let companies leverage the activist struggle to generate more profit.

But work is an integral part of our lives. Most of us have to work to earn a living, and until we’re all living the fully automated luxury communism of internet lore, or the singularity takes over, figuring out how to improve labor conditions and organize our work lives remains highly relevant.

What Is a Product Team?

The classic answer is that a product team is a durable, cross-functional group of people working together to develop a product and deliver value to customers in a way that sustains a business.

Product management, product design, engineering, sometimes product analytics, data science, quality assurance, and other functions come together to build and ship software products.

The reality is, of course, much murkier than that. Product managers are often confused with product owners, product designers can be more focused on user interface (UI) or user experience (UX) skills — not to mention interaction design or service design — while engineers come from a vast array of functional focuses, tech stacks, frameworks, and programming languages.

It’s a hodgepodge of folks assembled to serve the needs of an organization and their assembly much depends on the level of product maturity within that org. In brutal honesty, it depends largely on how outdated the organization’s practices are.

But above all, product teams are groups of people working together and collaborating on a shared goal. Group and power dynamics apply. In a tech startup context especially, the group is more likely to be at the very least ethnically diverse, but often also diverse in every other sense. While that’s a beautiful thing in and of itself, it also creates the kind of positive tension and healthy conflict that ultimately makes everyone a better team member and member of society.

What Is Queer Activism?

LGBTIQA+, or sometimes queer, activism is the organized struggle against the discrimination of lesbian, gay, bisexual, transgender, intersex, queer, and asexual people, and others who self-identify outside cis heterosexuality.

Activism brings people from all walks of life to unite in making a collective stand against injustice and inequality.

This manifests in many shapes and forms: from organizing protest marches over lobbying for human rights legislation, outreach and counseling centers, to social work, community organizing, and other activities.

Queer activists often act side by side with other civil rights and human rights groups, and their approaches and methods can be similar or the same.

How Does Activism Fit into Product?

As a former queer activist and organizer, I often think about all the techniques I learned working with a group of committed individuals on a shared goal often in high-pressure (or downright aggressive) environments.

Sound familiar?

Let’s explore some of the basic precepts that product teams can learn from activists.

Solidarity

n. unity or agreement of feeling or action, especially among individuals with a common interest; mutual support within a group.

A job is a job is a job, and most people work because they have to, not because they want to. For a lot of people, the choice of what they can do is limited. In many ways, those of us working in tech are privileged. That’s not to say that a great deal of tech folks haven’t offered blood, toil, tears, and sweat to get to where they are, particularly if they belong to an underacknowledged group.

Ultimately, you’re doing a job because it’s a matter of survival, financial security, access to opportunity, healthcare, etc. Activist groups arise out of various reasons, but fundamentally out of the need to survive in an often hostile society.

For a team to be successful, they need a shared agreement and a feeling that they can rely on the others around them. They need to express solidarity with each other in both formal and informal ways.

Activist groups will sometimes co-design an internal working agreement. In a product team setting, this can be achieved with a team charter workshop.

A team charter can be developed in an interactive workshop by answering the following questions:

• PEOPLE: Who are the people on the team? What are our roles?

• VALUES: What do we stand for? What are the common values we want to place at the core of our shared work?

• PRINCIPLES: What principles guide our work?

• PURPOSE: What is our purpose as a team?

• AGREEMENT: What do we agree we should always do? What should we never do?

I’ve created a handy template you can use with your team here: Team Charter Workshop 🔗

It’s good to start a workshop with an icebreaker to ease any tension and help people relax before they get started going into the specifics of their collaboration. My recommendation is to activate multiple centers of the brain. Ask people to draw what as kids they wanted to grow up to become or do. Turn it into a small gallery and exhibition of each other’s works. It doesn’t matter if you draw well or not — the point is to get to know each other and have a bit of fun.

A document such as this makes the act of mutual solidarity intentional and formalized. Each group is different, so these documents will vary greatly from one team to the next, but the activity of collaborating on their development tends to improve the quality of the relationships, and consequently the work the team is doing.

Conflict Resolution and Mediation

Working with other people will inevitably cause conflict. There is no avoiding it. But there is a difference between healthy and unhealthy conflict.

Healthy conflict opens up space for constructive disagreements that can be beneficial for product teams. The discussion that this engenders leads to new ideas, new perspectives, and innovation.

Unhealthy conflict, on the other hand, only brings harm. And as such it requires conflict resolution.

Queer activists often find themselves in public conflict with a great many different people and groups. Sometimes they are under attack, verbally and/or physically. It’s not always possible to resolve conflict. But where there is an opportunity, where the conflict hasn’t turned violent, there is always the chance of — mediation.

Mediation exists in many forms and formats. It requires a neutral party to help two or more groups find a way in which to constructively communicate. A mediator directs the conversation by asking questions, or creates space for the parties to engage with each other, reminding them of their purpose if they lose their temper or their cool.

For product teams, mediation can happen on several levels.

There is interpersonal conflict. Two members of a product team, or two individuals on separate teams, can find themselves in disagreement, especially after a difficult period at work. Perhaps they are delayed, or the product is failing. Maybe adoption is low, or usage metrics are disheartening. And as problem solvers, members of product teams are simply trying to move things forward. Of course, unless for this or that reason, they’ve become disengaged, demotivated, and sometimes frustrated.

There is conflict between groups. Perhaps one team launched a feature that undercut the metrics owned by another team. Maybe they introduced dependencies that slowed down another team without warning the other team upfront. There are many opportunities for conflict to arise in fast-moving tech environments. Tech, after all, likes to move fast and break things, and that sometimes breaks people, too.

In a product team context, a mediator can be any of the members of the team if the conflict is between two team members. If more people on the team are involved, it can be a trusted member of another team.

The mediator does not need to be a leader.

While any good leader has to be a good mediator and someone who actively develops conflict resolution skills — and hopefully has developed the same by virtue of having become a leader — the best way to resolve conflict is to do it between peers, without the introduction of hierarchical authority figures. The power dynamics inherent to that situation can strip the effort of its legitimacy in the eyes of those affected and their broader community of colleagues.

Mediation is complicated, and there is no canvas I can share that will help you achieve it. You have to adapt to your unique context. And identify allies for individuals and teams who can help navigate a complex emotional situation.

Allies and Allyship

There are no solo acts in product management. Successful product managers are integrators who understand their environment as a series of interlocking systems. This involves a great number of people. So it's crucial you meet your allies.

For LGBTIQA+ folks, that can mean people who support the struggle for human rights.

But an ally is also a benevolent coworker, colleague, and sometimes friend with whom we develop a candid rapport. A person with whom we can discuss work events, relationships, and spar on a number of work-related topics.

An ally is a fellow problem solver. We support each other in order to do our best work and grow personally and professionally.

An ally can sometimes be a mentor. The greatest mentors are the truest allies.

Allyship is a flavor of human connection and friendship. A mutually supportive relationship that rests on a foundation of openness, vulnerability, and camaraderie.

So to build allies, we have to open ourselves up to those around us. It requires taking a step into candor, with all the awkwardness and vulnerability that that may require. With our acts of friendship, we create opportunity for friendship in return.

An ally is somebody we support as well. We are a friendly ear interested in their stories of success and of trouble. Sometimes we’re a shoulder to cry on. Occasionally we are mentors. But then we are also mentees.

Working with people brings the chance to get to know humans you might not have otherwise met. It expands horizons. And forges new and unusual friendships that can last a lifetime.

Some of my work allies have become close friends. Collaborators. Partners in crime. And they come from all areas of life and work.

Don’t limit yourself to your small world. Branch out.

There’s a whole universe of allies out there.

What Does It All Mean?

Let us recap.

Product teams are cross-functional and diverse, and they work with many people within and beyond their team. Product management is not a solo act.

Queer activism works in groups, based on explicit agreement, consent, and mutual support.

The tenets of activism that can help any group — and thereby product teams — are:

• Solidarity

• Conflict resolution and mediation

• Allies and allyship

Does all this now mean you and your product peers are turning into company activists? Will all this make the world a better place and solve all of its problems? No, it probably won’t.

But it can make your day-to-day more honest, open, and pleasant. It can give you tools to handle and manage conflict in and out of work in a healthy and productive way. And it was help you build better communities of workers, colleagues, and ultimately, friends.

READ NEXT

26/30: Networking for Product Managers

Listen to it here: WebJoy Podcast S1 E16: It's Like Walking a Tight Rope 🔗

Mirza joins the show to talk about their origin story, how they started by translating poems, which led into working as a full-time translator. Eventually, they stumbled into product management while at university for their master's degree. Now they manage people who work on Product Strategy.

We discuss how they view product management and product strategy, using Miro versus FigJam, and about their experience being gay in the tech industry and more recently coming out as non-binary.

Here’s a typical scenario in many early-stage startups.

A small-to-medium sized company has only one product team. Sometimes that also includes product design and engineering. Occasionally they are separate from engineering. Design sometimes doesn’t exist.

All product planning and decision making is centralized. Even in environments where the team does its own planning, either the product lead or a senior engineer calls the shots. Prioritization is an exercise in convoluted framework exhaustion, with much decided by consensus until overruled from above.

The team is doing an exceptionally rigid version of Scrum, but in the process performing Waterfall-style product development. Specs are handed down from function to function, and feedback loops are slow. Strategic interaction is irregular. Although there are daily standups, they operate as status reports, so little strategizing happens. That usually comes once every 3 months, if at all.

Shipping is hard, slow, cumbersome, and often results in a lack of adoption. This steers it in the direction of fulfilling every customer desire, but the org takes months to ship even the simplest of optimizations or improvements. Rudderless in the storm, the product grows feature bloat, and slowly but surely becomes unusable. There is no concept other than obeying the customer.

RANDOM THOUGHT #1

What Do Customers Know?

The truth is — more than some product folks like to admit. But as product people, we have the luxury of examining all the possible solutions. It’s our job to understand the diversity of options. That gives us a critical advantage.

While listening to customer desires is vitally important, working out how to solve the underlying problem they themselves are seeking to overcome in a novel, unexpected way that perhaps additionally solves an adjacent problem — that’s when the “wow” factor of great product management converts even the B2C skeptics or B2B saboteurs.

Because we created value.

The unusable product causes churn. Revenue is lost, cash position threatened, and burn rates are high. The product has failed. The business is on the verge of collapse. What to do?

What I’ve observed many companies do immediately after that is — rationalize. They let go of some staff, cut down on cost, and restructure their organization.

They break out their large centralized product, engineering, and design team into several product teams. They all start doing Scrum individually. Everyone owns features or product areas. No one is clear on what their product outcome is supposed to be.

The increase in focus for smaller groups of people produces initial results.

Teams coalesce around domains. They are able to move faster and make decisions more quickly. They feel free to experiment, which they do. Some of these experiments work better than others.

RANDOM THOUGHT #2

Experiments without Experimentation

New product teams often engage in experiments — once. But if they lack the appropriate training and guidance, their experiments are prone to failure. Hypothesis-driven experimentation is part of science and demands relative rigor. Failure leads many teams to give up after one go.

While we can often simplify how we approach experiments, one thing must always be true — and that is continued experimentation. We must keep trying and learning until we get it right. Or at least get close enough.

For teams that experience failure and give up on experimentation as an approach, it can be hard to bounce back. And some will give up.

The org gives up on the attempt altogether. Teams are no longer encouraged to experiment.

What Happened Here?

What we are talking about is not a mere feature factory. It is a process-driven environment governed by ruling bureaucrats on multiple levels of the corporate and product hierarchy.

Centralizing a product org means consolidating power and decision-making ability on the top. Bottom-down input may be heard and sometimes considered, but the design of the organization makes it easier to flow information downstream. This creates a communication imbalance.

Rigid interpretations of various development frameworks and methodologies stifles innovation, as it overfocuses product teams on the process of development instead of the product.

Bureaucrats introduce administrative hurdles, as the direct outgrowth of process is documenting process and introducing process steps, checks, gates, and unavoidable approvals.

In a struggling org, everything demands approval, thereby slowing down movement and making teams sluggish and unable to quickly solve problems. Teams become less responsive, which in turn creates frustrated customers.

It’s a snowball effect that can be hard to stop from swallowing the entire organization.

Light at the End of the Tunnel

But there is a way out of this situation. It requires some radical changes to an org, but above all — collaboration.

The organization needs to collect all knowledge, research, insight, opinions, questions, problems, and ideas and analyze, structure, and categorize them. This can be done through a series of workshops and interviews that result in a summary of the data.

This summary (and ideally visualization) of the findings should be shared with the entire organization. Findings can also be shared progressively as the research continues.

At one point, functional leaders and most senior individual contributors in all departments should come together and discuss how to transform their findings into a product strategy.

They will agree on a hypothesis about the overarching problem they are trying to solve — a unique business problem.

They will then transform that into a product outcome they need to generate in order to solve that problem. They’ll agree on a way to measure success on that product outcome beyond a binary “achieved/not achieved.”

They’ll break that down into a series of bets:

We bet that by doing [this], we will achieve [outcome], because [condition or situation].

A talent management system:

“We bet that by enabling users to filter their candidate management view by location, we will achieve greater daily usage of the view, because our users need to confirm applicable candidates in locations where they are looking to hire.”

A travel booking site:

“We bet that by decreasing the latency of our search page by 10ms, we will achieve a booking conversion rate (BCR) uptick of +5pp over a 28-day period, because we observe lower BCR during latency spikes.”

Teams will co-design the bets and own one each, at the beginning. They will engage in product discovery activities to try to validate the problem and prove the hypothesis behind the bet.

They will rally around this singular goal. By focusing on one problem at a time, teams become serial success creators.

ON BUREAUCRACY

The German sociologist Max Weber (1864-1920) argued that bureaucracy constitutes the most efficient and rational way in which human activity can be organized and that systematic processes and organized hierarchies are necessary to maintain order, to maximize efficiency, and to eliminate favoritism. On the other hand, Weber also saw unfettered bureaucracy as a threat to individual freedom, with the potential of trapping individuals in an impersonal "iron cage" of rule-based, rational control.

(Source: Wikipedia)

How Did We Get Here?

What we’ve actually done is remove layers of bureaucracy by decentralizing the product org into discrete teams, all with a unique outcome of their own to pursue. We’ve moved decision-making into the domain of actual, on-the-ground expertise.

Through a shared planning process, we’ve created common ground. By involving everyone equally, we’ve distributed power, shared knowledge, and engendered a renewed sense of ownership, and hopefully ambition and drive.

This approach drives teams to succeed. It empowers teams by enabling individuals and giving them space to experiment, but within boundaries, and with a clear goal in sight.

Process is differentiated and made much smaller, and therefore less overwhelming. Distributed decision-making makes it easier to simplify process, particularly in smaller groups.

Any framework or methodology will do as long as these basic conditions are met.

The rest is up to you.

A product roadmap is a list of features presented in a visual Gantt-like timeline with exact delivery dates that the product org updates on a quarterly basis so sales and marketing can sell the product. Right? Right?! No? … Maybe sometimes?

“Ah, if it only weren’t for those pesky product kids and their roadmaps, we’d be selling all the features!”

Let’s clarify a few things.

A product roadmap is not a list of features with delivery dates

That’s called a release plan (sometimes also a delivery plan or a release roadmap). The timeframe for a release plan is typically not longer than 12 weeks (i.e., a quarter) because software development is notoriously unpredictable, and we generally avoid promising delivery dates up until the point in time when it’s reasonable to do so.

Product roadmaps are not necessarily updated quarterly

Companies vary greatly in how they approach their strategic planning. Some roadmaps are quarterly, others are much longer and can extend up to 18 months in the B2B world. Some places have rolling roadmaps.

Product roadmaps are not laundry lists of customer requests

While we do absolutely listen to our customers’ needs and problems, and work on building solutions that address them, what we build has to work for many customers. Sometimes that means that we end up building a solution that a customer never asked for, one which ideally solves their problem even better than their original request would have.

Product roadmaps are not customer-facing, public documents used by Sales teams to close deals

While a lot of companies do share a public version of their roadmap, product roadmaps are used primarily for internal communication.

“Okay okay, what IS a product roadmap then, and what PURPOSE does it serve?”

I thought you’d never ask…

Internal Communication and Alignment

A product roadmap is an internal communication artifact that serves to align product, engineering, and design with other departments, so that the entire organization understands how the product org is tactically approaching the various bets we are taking as part of our product strategy.

Tactics

Product roadmaps specify tactics that execute a product strategy. This could mean listing one or more initiatives that feed into a strategic objective. But it could also mean describing a set of outcomes we hope to achieve through said initiative. Some product orgs prefer to describe the problems they intend to solve so as to not limit themselves to any specific outcome or solution. At any rate, neither of the above is a list of features, as we often don’t yet know what or even whether any feature is the right solution to a problem.

Sequencing and Prioritization

Time is of course a factor, but the value of product roadmaps is not in delivery dates, but in the sequencing — and therefore prioritization — of the tactical initiatives we plan to undertake, so that a product org and other departments know how to organize and what to rally around. When a roadmap item (the tactic) comes closer to becoming realized, we describe it in more specific technical and other detail as part of a release plan.

Let’s recap.

• A product roadmap is an internal communication artifact listing the sequencing of tactical initiatives designed to execute on a product strategy. 

• Its purpose is to align internal teams and provide clarity on what problems we are solving and what outcomes we hope to achieve through those efforts.

• A product roadmap is not a list of features with delivery dates, as that is a release plan, another important communication artifact.

In B2B, product roadmaps are planned for 12-18 months, and are ALWAYS subject to change, of course with a lot of advance notice, as sales teams may use the public versions of these roadmaps to sell prospects on the future vision of a product.

READ NEXT

11/30: Writing Compelling User Stories

What is Product Strategy?

Alright, this is a tough one.

The word “strategy” has been misused so frequently that its meaning has become murky and unclear for most of us. I was lucky enough to first learn about strategy through debate teams.

The concept is the same: you are trying to predict the behavior of those in the immediate environment around you, and make a set of educated guesses, or hypotheses — ultimately bets — that a certain action will result in a chain of events that will lead you to a goal, and make explicit how (and possibly when) you intend to get there.

That’s a strategy.

In debate, you and your team have to prepare to argue both the argument pro a motion and the argument against the motion. You need to examine all the possibilities, to prepare the best defense of a claim you wish to make about the motion.

In product, you have to examine all the possible options regarding what you build, how you build it, to whom and how do you ship it, for whom do you build it in the first place, what problem does it solve, what need does it address — and how do you balance other needs, like architecture, legacy systems, codebase silos, and knowledge transfer and sharing?

This is a complex problem.

You have to decide what you’re against, and what you choose to be for, based on an educated guess and subsequent validation. You then have to decide how you intend to do that, based on a collaborative process with cross-functional team members. You have to agree on a sequencing of events. And you have to consider whether some problems require a commitment to a deadline, for commercial or other reasons.

Product strategy is, therefore, a collaborative, cross-functional effort by a product organization and the business within which it operates that results in the development of a coherent, validated set of tactics by which to execute a series of strategic goals.

Product Vision

Just when you thought there was nothing more confusing than product strategy — enter product vision. The arena where good ideas come to die.

I’m being facetious, of course, but product vision statements are often the purple prose of product: fluffy, feel-good, mean-nothing affirmations.

Now, I’m not trying to be dismissive. Developing a product vision and crafting a statement to encapsulate it is genuinely difficult. So it’s little wonder we sometimes get it wrong. What’s going on here?

While strategy is often mistaken for ambition, product vision is confused with what a product itself is supposed to become. But a product vision should describe the change our product brings about for its users and the environment around them, and ultimately our business, too. It’s not enough to describe a future product.

Product vision should focus on:

• Who we are solving a problem for

• Why we are solving the problem to begin with

• What exactly we intend to do about it

• How we are going to influence the environment we set out to change

A product vision is, therefore, a statement about an imagined future world where we’ve solved our users’ problem though our product. It should include an understanding of the what and the why behind that effort. 

And it should imagine the environment we’re creating and the effects our work has on our users, not just the product itself.

The Product Strategy Triplets

A company vision and its product vision are typically the same in a product-led business, especially in SaaS.

This is, however, different in larger orgs with many product lines, where the product vision for a line or portfolio(s) feeds into but is distinct from company vision.

A company mission statement, on the other hand, is a singular expression of a company’s core purpose, both as it relates to its product and beyond. It expresses the high-level strategic goals a company wishes to achieve through its product development, sales, marketing, etc. — essentially the operations of its entire business.

On a product org level, we usually speak of a product team’s mission, that’s subject to change more frequently than the overarching company mission. Team missions typically spell out the plan for the product domain or area that is in the ownership of the product team. It focuses on all the products, components, services, and users that the team’s work develops or affects.

You can think of company vision, mission, and strategy as the triplets of business strategy — all related, but not the same.

Product vision, product strategy, and product team missions then are the product strategy triplets, and an integral part of overall company strategy.

In June 2022, I started offering 2 hours per week of my free time to folks interested in breaking into product management or further developing in their current roles.

Since then, I’ve spent a little under 1,000 minutes talking with 12 mentees in 10+ countries over 20 separate sessions, mainly via ADPList.org, but also other networks like 2hearts, and my buddy Nicole Daines’s Product Mentoring Program.

Each and every one of these has been an absolute thrill & motivated me to continue mentoring others and seeking mentorship for myself.

But a lot of my mentees are based in Europe, and I’m starting to notice a distinct set of challenges, some that I’ve observed firsthand working in European tech for the past 10 years. These may very well exist elsewhere, too, but my impression is they are prevalent in Europe:

• It’s harder to break into product in European tech companies. There are very few APM or internship programs, and the few that exist are extremely competitive.

• A lot of companies don’t differentiate between “product managers” and “product owners,” which creates additional issues for folks looking to move from one role to the other, usually from PO to PM.

• Product managers don’t receive on-the-job coaching & unless they themselves are very proactive about L&D budgets and further education, they mostly learn product management on the job, by themselves. This ends up creating some bad habits.

• The product management career ladder is a hellscape of random titles with little uniformity and confusing progression. It is often unclear which positions are ranked higher in a company hierarchy.

• Product management is not understood as a business function, but as a “software delivery” job, both by companies and some product managers themselves. This is connected to the PO problem referenced above, but also extends onto understanding the role of product in generating desired outcomes and value.

• We have an underdeveloped culture of measuring success and working with metrics. This may come as a shock to some, but I’ve both myself seen & regularly heard through mentees that a lot of product teams in European tech companies don’t measure the impact of their work or monitor for success in any way other than — “it got shipped.”

With this in mind, I’d like to start a conversation about what it would take to improve this!

Have you observed any of these challenges yourself?

What other challenges have you identified particularly in a European tech context?