Not every company provides enough clarity about the product management tasks which are expected from their employees. That’s why this extensive guide will walk you through the general expectations on that role and which specific domains you need to master to become a successful Product Manager.
The Death of the Product Manager (as we know it)
When it comes down to responsibilities in a company or a team, the world of product development as we know it always provided a pretty clear structure: CEOs have to lead, designers have to design, developers have to code, and product managers have to…well, actually manage everybody. They are doing that by writing tickets, preparing presentations or thinking about new features and future product roadmap.
But it was sometime around 2013 when the web suddenly started to discuss whether designers should know/learn how to code or not.
The reasons for this question were obvious. Designers and developers work closely together but often really never understand each other which leads to pretty much waste in communication, mostly caused by missing knowledge about the work from the other.
Advantages would be that designers could, on the one hand, make an early reality check on their drafts and impress developers a little bit more on the other one while the developers would start to value design work more.
Though there were a lot of opinions for and against that statement and it sometimes also depends on what kind of designer you are and what you’re working on, I felt like the essence was: »Yes, designers definitely should know how to code.«
So, if designers learn how to code so they maybe don’t even need a developer to launch a product and developers would vice versa learn more about photoshop, who would need someone else to make excellent digital products? Depending on the size of your company or team you probably still need a project manager to structure the work with scheduled meetings and caring about some organizational stuff like reports or having an eye on the budget.
But do you then still need a guy who can’t design or code pushing wireframes around, writing tickets and testing the latest version all the day also?
But let’s take a closer look at this. Can’t we just put up the same question that rose last year on designers who code? Isn’t it time to ask: »Should Product Managers know how to design and to code?« – I think it is.
If product managers gained a deeper understanding of what’s happening inside “their” teams by having practical skills in both disciplines, it would be a massive win for the product itself. So, in my opinion, we should rethink the role of the product manager. He or she should become someone who’s involved in the actual process of building things.
As a consequence, skills in teams could become more concentrated on fewer people, and team size could be reduced to iterate even faster.
Seeing how small teams gain so much traction with their products without including a personal “overhead” like a product manager made me think about this role (which is what I do for money, too).
One of the key learnings I took away from a journey to the US in 2013 was that I just had to learn how to design and how to code (of course I know that don’t »learn« design). It would be a requirement if I wanted to stay relevant to the process of digital product development in the upcoming years.
The most important Product Management Tasks & Disciplines
Product Management is so much more than just writing tickets and sitting in meetings.
This guide wants to prepare you for the challenges in the daily business of a Product Manager to help your product management career to get going.
Your product vision should not be a specific plan that shows how to reach a goal. Instead, you should keep the product vision and the product strategy – the exact tactics to achieve the goal – separate. This process enables you to change your strategy while staying grounded in your vision.
A handy tool for describing both the product vision and the product strategy is the Product Vision Board by Roman Pichler. Its top section captures the vision, and the ones below state the strategy to realize the vision.
Product Management vs. Project Management
No other terms get more mixed-up in the daily job life but should always be separated from each other to keep things clear. It’s a confusion which maybe occurs to you during the early days of your product management career. Don’t get confused by it.
The best way to explain both jobs is probably the agile methodology (more on that later). If you apply their principles, a Project Manager is similar to a Scrum Master, and the Product Manager is considered as the Product Owner.
Applying the definition from any agile playbook, a Product Owner is responsible for the meaning of the product, and the Scrum Master has to ensure that the team can work towards the defined goal and for reporting on the progress and potential impediments.
These responsibilities can easily be extended to non-agile environments as well, as they’re not bound to specific job terms. Some companies though try to combine both roles in one position and then ask for primarily best of both worlds:
Someone with full product and developer responsibility who removes all impediments for a team and has a fully fleshed out project plan for the next months always ready to present – Something hard to deliver in reality and mostly one area suffers regarding quality.
An Agile Mindset
The most common understanding of Agile is probably the agile manifesto which was developed back in 2001 by 17 men who were back at the time unsatisfied how software projects were approaches. It states the following principles:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
But these values are giving you guidance for developing products in an agile way and leave a lot up to you and your team. Scrum or Kanban, on the other hand, are frameworks that are built upon these guidelines and are for precise in describing the way (software) development should happen.
But only applying agile values to your team or even using Scrum or Extreme Programming from a manual does not automatically solve all your problems. This acknowledgment is best summed up by the following quote from Bill Scot, Senior Director of UI at PayPal:
“Agile doesn’t have a brain.”
The Unofficial Scrum Checklist by Henrik Kniberg
Even though Agile is way more than specific processes and guidelines, this handy checklist from one of the most well-known Agile coaches is a great way to kickstart your team collaboration using Scrum.
As a product manager, you’re working at the intersection of multiple disciplines of your product. You always have to deal with people who own a particular aspect of your product without actually creating issues in your backlog or talking to the designers who are part of your team. This situation is part of almost every product environment, independent of their size.
One of the most critical factors for remaining actionable and accountable even in complex stakeholder environments is the degree of alignment you can create your product vision and your stakeholders. Depending on the variety of your stakeholders, multiple formats can do the job at this point.
The most critical aspects when communicating alignment are (as always) the why, what, how, who and when of your products roadmap. While there are multiple formats to create alignment, you should ever approach this matter before actual implementation starts.
One of the recent trends regarding this subject is based on applying military strategies from the Prussian army to modern product environments by Stephen Bungay. Based on those theories the product community at, e.g., XING has started to use a format called Auftragsklärung to align stakeholders before a project begins. It’s a result of some iteration and should be seen as a starting point for alignment among larger organizations.
Smaller products and less complex environments can quickly get along a simple kick-off meeting, a lean slide deck and a publicly available product vision and out-of-scope objects.
AB & Multivariate Testing
Testing is something every product person is looking forward to. It gives you the flexibility to try out new crazy ideas without the risk of breaking every key KPI of your product at once.
While it’s rather easy to come up with new ideas for an individual feature or product, you should take a look at these rule of thumbs before building your first test:
Define explicit hypotheses and KPIs before running a test
Instead, go for an AB test instead of a multivariate one (especially in the beginning)
Always test bold! 40 shades of blue are something for Google
Even if you think a test ran long enough, extend it for a few more days
Monitor your KPIs again 3-4 weeks after the full rollout of a winning version
Besides picking the right tool and defining precise hypotheses up front, it’s important to pay attention to the significance of your test results. This metric states if the difference between your tested variants just happened by accident or was caused by the changes you made. Visual Website Optimizer provides two convenient tools that can help you to plan and analyze your tests. While their Test Duration Calculator gives a rough estimation of the minimum time a test should run, the Split Test Significance Calculator tells you if your results are already significant.
Of course, you’re free to build such tools on your own using Excel or Google Spreadsheets if you’re firm with the concerning formulas. Besides that, it’s useful to have a personal or shared test calendar, so it’s easier for you to keep track of the tests you ran as time goes by.
5 Product Management A/B Split Testing Mistakes
A/B Split Testing is the most powerful tool of a product manager for getting from gut feeling and HiPPO driven product decisions to actual progress based on measurable outcomes.
But while it’s comparably easy to asses a tool and implements your first testing setup, there are a couple of meta mistakes I see being made from time to time among product managers (and which I’ve made myself).
Here’s my selection and how to avoid them:
Sharing Results too early with Stakeholders
While ‘too soon’ is measured in two dimensions (more on that below), let’s just says there’s a certain point in time during which you should not talk about the preliminary results of a running A/B test. Especially when you’re testing around a critical business KPI, there are just too many dreams and visions emerging from (mostly non-technical) stakeholders – even though the test result doesn’t stand on solid ground.
In the past, I shared ongoing progress of a test we’ve implemented with my engineering team, to make their efforts implementing it as transparent as possible. But when it came to upper management and marketing, I learned to wait a lot longer before I communicated a result. Best case is, you get approvals from two expert perspectives: A mathematical one (e.g., Digital Analyst/BI Manager) and a practical one (e.g., Director of Product or Product Management buddy).
A/B Testing for the Sake of it
While A/B testing is something to aim for because of the reasons mentioned above, you shouldn’t run any testing idea which is floating through your regular stakeholder alignment meeting. While the costs of implementing and cleaning an A/B test up are necessary, it’s more about the environment you want to test in.
Do you have enough traffic flowing through your area of the product to generate significant results within four weeks? Do you have the freedom to test variants which are differentiated enough from each other? Do you have the commitment from upper management also to implement the ‘unpopular’ version and they just let you A/B test in the first place because it’s a ‘modern approach’?
Solely relying on Significance Calculators
As I wrote earlier, the scientific expert view on your test setup and results is a crucial one. But don’t let numbers alone influence your decision when a test is finished. You’ll run into scenarios in which a significance calculator will spit out a significant result after two days or so. But seriously, two days? Common sense should tell you to at least run a test through every day of the week twice to balance-out ‘seasonal’ impacts.
Also, significance calculators don’t know every twist and angle of your product and its dependencies like you do. So only you will be able to spot outliers and potential bugs influencing your testing setup.
Confusing A/B Test Results with User Feedback
‘Version A won, so our users like this one more!’ While this assumption doesn’t seem far-fetched, it’s quite misleading. It’s the perfect example of why quantitative and qualitative testing (and research) need to go hand in hand for a complete picture.
Even though A/B testing tells you what users are doing (like clicking five times more likely on the yellow button instead of the red one), it doesn’t tell you why people are doing it. It’s the unfortunate discrepancy between what people say they do and what they do.
So, be happy about the measurable uplift your latest winning version has caused, but make sure to check back it’s mid- to long-term impact on your product by conducting some 1:1 user interviews digging into what users made them click more. E.g., in the worst case, you just locked the users tighter into a checkout process, and they had no other choice than to proceed. Again: Correct action to impact your target KPI, but it’s helpful to know the context around it.
Focussing on the wrong KPI to change
Speaking of KPIs: When setting up your test, it’s essential to only work towards an increase or decrease (e.g., when working on a churn topic) of the real metric you can directly influence with a test. Especially when implementing a test within a multi-step funnel, you can never be sure to impact the very last checkout metric when only testing improvements within the address data step.
It’s intriguing to assume that all conditions before or after your area of testing stay the same, but then again you perform an A/B test to stop guessing.
Actionable advice for A/B testing as a Product Manager
- Define explicit hypotheses and KPIs before running a test
- Instead, go for an AB test instead of a multivariate one (especially in the beginning)
- Always test bold! 40 shades of blue are something for Google
- Even if you think a test ran long enough, extend it for a few more days
- Monitor your KPIs again 3-4 weeks after the full rollout of a winning version
Why Retesting your Experiments is crucial for real Optimization Impact
Did you run AB tests before during your career as a product person?
Did you manage to achieve significant results with at least one of those tests?
Did you reject the same idea when a colleague suggests it as an experiment 6+ months after you ran it?
Not good. Wait. What?
What might seem counterintuitive at first, is one of the most common mistakes conversion optimizers make throughout their careers.
The primary motivation for testing hypotheses using AB tests is to gather data to avoid decisions which are solely based on gut feeling.
You also want to reduce waste by preventing colleagues in your company from putting effort into a testing idea you already invalidated.
But what if you’re causing more harm than good with this behavior? I recently had the chance to attend a talk from Willem Isbrucker, Senior Product Owner at Booking.com during our Product Tank Hamburg event and got a valuable lesson taught.
When he presented the audience with an AB test setup he ran and asked the audience for the winner, 80% in the room predicted the right version (variant). But then he revealed that 20% who considered the control version to win was also right in a certain way. The experiment also ran a year ago with the opposite result.
While you could assume a mistake in the analytics, the real reason behind it was that the environment around the testes element (a search box) evolved, and thereby the element itself performed better being visualized differently.
And while looking back at my own set of AB tests I ran throughout my career, I also rejected ideas of retesting because…well, we already proved the hypothesis to be wrong or right.
So, whenever you get presented with a testing idea which ran 6+ months in the past, look again at your product and check the situation:
Did you make changes to the main navigation in the meantime? Did you test within a particular segment or across the user base? Does it maybe make sense to target the change in a specific user group? What if the recently introduced new pricing tier would impact the test again?
Try to find a balance between reducing waste and embracing retesting of known hypotheses. You might be surprised regarding the impact you can generate.
While there’s almost no better feeling for you as a product manager to ship a thing you and your team have put a lot of effort into it, it’s mostly not worth a rush.
We unfortunately often tend to make too many compromises on our initial vision, to get something through the door and the term »MVP« becomes an excuse for bad quality.
And even though de-scoping what you wrote down several weeks or months before often is very reasonable due to a changed competitive landscape or different requirements from your stakeholders, you should be careful with stripping your product down to its bare skeleton.
There’s often quite a discussion going on within a team if a Minimum Viable Product or a Minimum Delightful Product should be built. But in the end, the most important thing for you to consider is, that even what you ship in the very first iteration should fulfill enough needs of your users to make it worth using it compared to the status quo.
Data-driven vs. data-informed decision making
Decisions on whether to roll out a new feature of cut-off/extend a test are often based on analytics numbers. But sometimes the right metric for a product is not measurable (e.g., is customer delight) or you’re firmly convinced of the opposite from what the data tells you.
There are times when intuition makes sense, but caution and an awareness of the limitations and pitfalls of this process are suggested here.
It’s always important to double-check generated reports with your personal experience on the product and a sane human mindset. That’s the way how to avoid wrong decisions if, e.g., incorrect implementation of tracking is in place or the analytics tool of your choice is broken.
Don’t forget you are a human. Keep using your brain and don’t rely entirely on provided data. Your reputation as an expert should qualify you to overrule data-driven assumptions from colleagues from time to time.
How to nail it as a non-technical Product Manager
When I started my product management career in 2010, I sometimes felt just overwhelmed with technical discussions, challenges, and expectations of tech stakeholders. I considered myself a non-technical Product Manager back then and was a bit what this would mean for my career.
But after significantly leveling up my tech knowledge over the years, I think it’s worth to look at the general technical vs. non-technical PM topic of our industry.
First of all, it’s important not to get intimated by missing knowledge. While social skills and values are pretty much given, learning about pretty much any topic can be build up by putting in honest work. It’s totally fine to raise questions regarding outlined technical constructions, details and ideas. After all, that’s our job anyways: To ask questions. Even more often there’s an often undiscovered advantage of looking at the complex with a youthful naivety (something Erik Kessels tackles extensively in FAILED IT!).
So, instead of being ashamed of your missing knowledge, appreciate it as a strength to look at things. You’ll become professionally blinkered soon enough.
It’s also motivating to keep in mind that even some of today’s most recognized Product People in the world like Hunter Walk started as a non-technical Product Manager background and worked their way into this field.
A nice quote from Ken Norton sums this (often controversially discussed) topic up from my perspective:
Too often PMs try to impress their engineers with their technical acumen, but in my experience engineers are much more impressed with PMs who are willing to ask questions and say ‘I don’t understand that.’”
Embrace your current set of skills and use them in the best possible way. When you’re comfortable doing this, become uncomfortable again and level up your (technical) skills.
Do’s and Don’ts for a Technical Product Manager
- Do focus on the business side of the role.
- Do use your technical skills to improve prioritization and planning.
- Do leverage your technical skills to close the communication gap between engineering and the rest of the world.
- Don’t design/solution the product yourself.
- Don’t take on non-Product Management deliverables.
- Don’t get caught up in Agile, or whatever methodology you’re using. (Annotation: I don’t share the opinion on splitting the Product Owner and Product Manager role)
Do Product Managers need a Portfolio?
It’s almost funny how much focus the specifics of individual projects get during the hiring process of a designer. A CV on the other side is not much more than a necessity to check for some known names.
And in the end, everything boils down to their portfolios. It’s, on the one hand, the perfect place for the designer to put some love into the representation of the work one has done. On the contrary, it’s ‘perfect’ for judging the capabilities of a person based on pixels.
The situation is then often, that most design portfolios look pretty, but lack context or outcome of a project entirely. And because everybody (involved in the hiring process) of course has a (healthy) opinion on design, the portfolio gets judged subjectively as shit.
That’s a real problem as at least I favor an approach to the application process which removes subjectivity and focuses on outcomes (read this book for more input on this topic). So, if portfolios, in general, are already an established part of the hiring process for designers, shouldn’t a more outcome-oriented version of the portfolio play a significant role in an application process of a product management career as well?
To me, the answer is yes. At least, if you’re beyond the junior job level and have a couple more projects to talk about under your belt.
Way more important than the actual medium you’ll use to showcase your work (since there’s no Behance for Product Managers yet) is the real content to put in.
As a Product Manager, your success is often measured by the numbers/impact your product has generated. It’s a bit unfair to say, but while designers can hide behind beautiful pixels and bouncy animations, you need to come up with the naked truth and objective facts.
That’s probably the primary differentiator when compared to the current state of design portfolios being part of the hiring process. As outcomes should be a part of a Product Manager portfolio, you won’t hear that many ‘opinions’ on that part. And it’s probably not a matter of taste on how to judge it.
While I currently don’t maintain a product portfolio myself, I made a weak attempt back in 2014 on my website. If you’re looking for a better example, I highly recommend the way my fellow product superwoman Petra Wille is presenting her work (German only).
So, when you’re assembling your product portfolio as a continuous representation of yourself or for a particular application process, I recommend something loosely following this structure:
- What was the objective of the project/product?
- Which stakeholder environment did you face?
- How did you structure the discovery and delivery process?
- Building upon that: Which frameworks & tools did you choose to apply and why? Would you pick those again (for the same context)?
- What was the measurable outcome?
- In hindsight, what was your most significant personal learning from the project?
Some additional thoughts on the criteria of a Product Manager’s portfolio are included in this neat article by Sachin Rekhi.
Product Management Consulting vs. In-house Product Management
For those of you who have been following my writing for quite some time now, this shouldn’t come as a surprise: I don’t believe much longer in the differentiation of domain product managers.
Instead, I believe in the power of deploying (product) skills in whichever domain is necessary and staying close to some core values (e.g., relentless customer focus).
But there is a particular distinction I want to point out to pay attention to when deciding whether you want to move in or out of working in an agency context: End-to-end responsibility for product outcome.
This all comes down to individual motivators you or team members of you are driven by, and it’s something I urge every people manager to pay close attention to when hiring.
A common motivator I heard about when talking to people which wanted to move into a consultancy/agency domain was the need for more variety of the product challenges they (which was also one of the motivators for me to give consulting a try).
While this is often the desired primary goal, a second one comes into play when it comes to shaping and shipping products for clients: You (can) give up end-to-end responsibility for your decisions.
As a product manager in a consultancy context, you may be responsible for the inner processes to build the product, but you’re not enabled to take full ownership for wrong decisions, mistakes, and potentially fame.
You might be able to push for decisions and initiatives but will always have to rely on the faith, trust, and patient of your client to see things through. While this may sometimes feel frustrating, it can be somewhat convenient for certain types of (product) people. It lets you focus on the upper part of the product funnel. Like the development and discovery of ideas instead of having to deal with hard facts down the road (e.g., ongoing backlog refinements, resolving delivery dependencies and organizing go to market).
When you work in a product company on a product you can (hopefully) entirely own, nobody and nothing will rescue you from dealing with those hard things. It’s part of the overall deal of working on your product with full responsibility.
So, when you’re currently working in an agency/consultancy context and are looking for the next step out of your comfort zone, I encourage you to join a product company and try owning the end-to-end responsibility of a product without the comfy possibility to put mistakes on irresponsible client decisions.
On the other side, when you’re currently part of a product company and consider switching into a consulting role, I’d like to challenge your critical drivers for this switch.
Which Schedule should a Product Manager be on?
You may have heard of Paul Graham’s Makers vs. Managers Schedule paradigm. And while most Product Managers would probably place themselves in the ‘Makers’ bucket (despite the contrary job title), I’d bet that most of you are actually on the Managers schedule.
Product Managers are typically the connection between multiple departments and even business units. This almost automatically implies that you’re discussing a bunch of different topics across the day – perfect for structuring your calendar the Manager way.
And here’s the conflict: While this is an often to observe status quo amongst PMs, the most critical challenges for Product Managers can most likely only be solved on a Makers schedule. Finding the jobs your customers want to hire your product for and drilling deep into customers needs and problems is not something you can quickly pack into a handy chopped calendar slot. I only manage to crank in foreseeable ticket work into slots like this.
So, here’s the deal: Don’t only try to be a maker during your next job interview or when you’re a guest on a podcast. Be a maker when it comes to planning your daily schedule and only occasionally switch back into the Managers schedule when it’s necessary. Not the other way around.
Product Managers need to be micro Pessimists but macro Optimists
I recently heard about this attitude in a podcast interview with Raylene Yung, reporting that it reflects overall company values at Stripe.
But instead of ‘only’ applying it on a business level, I think it’s also quite a suitable framework for the split of perspectives product managers face regularly.
It’s kind of an analogy to the discovery and delivery separation every product manager needs to handle. While the one (delivery) focusses on execution in regards to ongoing sprint routines, details of backlog items and hitting milestones on time, the other one (discovery) focusses on customer problems worth solving and what to build next.
From my experience, optimism is essential for going into a product discovery. That doesn’t necessarily mean to be overly enthusiastic about a specific feature.
Furthermore, you should be looking forward to the digging into customer or business problems and the creative journey that you’ll identify something valuable you can build upon with your team.
On the execution side, I found the ‘right’ degree of pessimism helpful for staying on track. That doesn’t mean that you should doubt the success of your team regularly, but challenging (your own) priorities and decisions at least during every sprint planning.
Don’t take yesterday’s decisions for granted – As long as corrections still fit into the overall product vision.
Remain, skeptic, that the path you chose for the next sprint will still be the right one when looking back at it into the retrospective. This way, you’ll stay hungry for ongoing improvement and avoid a ‘now we just need it to build it’ attitude.
Your macro perspective should always be mostly positive. This will give you the confidence to question decisions on a micro level more regularly without becoming scared that you’re losing touch with the big picture.
Measuring success in a Product Management Career
When I started in Product Management, the role, in general, was considered to be a bit more stakeholder-focussed project manager. It was all about facilitating requirements and keeping the (mostly outsourced) ‘IT department’ busy for a low daily rate.
The main success criteria to measure Product Managers again back then was basically to ship a particular feature (mostly determined by a HiPPO) in a given time and extremely budget. How essential or even reasonable a feature was, leave alone measuring the impact it may generate, were seen as unimportant factors.
Thanks to the influence and popularity of product-centric companies like Facebook, LinkedIn, Airbnb or XING, this perspective is now dismissed from modern product development.
Instead, Product Managers are empowered to honestly take responsibility for that they were building in active collaboration with design and development teams.
Comparing the guidance provided to Product Managers for moving forward with the “time-quality-budget“ approach, it’s now more something like:
Build the right feature for proven user needs with the leanest approach to generate a significant impact which is in line with pre-defined KPIs.
This lens of looking at the success of a product manager is not only crucial for individual people managers but also the product manager herself.
Don’t get caught up in “time-quality-budget” madness when it comes to reflecting your performance. Take a smarter approach looking at your work.
Product Management Career Paths – Building Products vs. Building People
At one point in time, every PM will arrive at the point at which she has finally gained enough professional experience at her current or past job to climb the corporate ladder. Promotions become a thing, and product management career paths need to be discussed.
And thereby it’s not about leveling from which level, but about the act of leveling itself.
While this may seem natural at first sight and was the de facto only way to gain recognition of a good performance, things have changed a bit in the past.
Growth trajectories of people are no longer only focussed on the vertical direction but the horizontal axis in a product management career.
In the context of product management, this means that you have to choose between continuing to build products yourself compared to instead focus on making people who then develop great products.
When you arrive at the point in time mentioned above in time, I strongly advise you to take a moment to check your real inner motivators instead of immediately jumping on having a new business card entitling you as Team Lead Product/VP Product, etc.
This also the very first thing I check with applicants. By focussing on motivators of someone in the first place you can avoid a couple of uncomfortable situations to find yourself in 6 months down the line:
A great product manager joins your small team with already clear leadership ambitions, which you didn’t check in the first place and only discover a couple of months in. One of 3 things will happen:
- You’ll have to put him off again and again when he’s asking for a leadership opportunity. His excellence in building products will decrease, and he’ll eventually leave.
- You give him the title he wants, without a team though. The title will delay the disappointment, but he’ll eventually leave.
- You give him the title and start unplanned hiring to create an artificial team for him. He may be happy, but you created weak growth (and thereby financial burden) for your company and put way too much on the line. Only to satisfy the needs of one employee. On whom you didn’t do your hr homework.
You promote a magnificent product manager for a leadership position who accepts out of politeness but has no leadership ambitions at all and is more than happy in an executive role. Here’s what’ll happen:
- She’s leading people based on the corporate hr playbook but remains at the same time way too involved in operational details of daily product building because that’s way more interesting (and challenging) for her.
- Her team grows frustrated and eventually starts to quit.
- She discovers her right motivation based on building products instead of building people and quits as well.
- You have to re-hire a product leadership position and the individual contributor roles of that team just because you didn’t check the real motivators of your initial hire.
So, whether you’re a product leader hiring for a team or a PM who is approaching a ‘critical’ level of experience: Check your true motivators and whether you’re more driven by building products (and want to continue to deepen your knowledge around that) or making people (with all the trade-offs of being involved continuously in the daily product details.