As a first PM, you will need to be very judicious with how you allocate your
time and resources. In fact, I think that’s true for larger companies as well.
There are always going to be more ideas than resources available.
As a product manager, you are responsible for translating the company’s vision
into a roadmap so your first priority should be internalizing the company’s
goals. Is it to drive sign-ups? Increase retention? Increase MRR? Or something
else altogether? Narrowing in on that top goal helps to weed out work that may
be less relevant.
Once you’ve identified the top goal (there may be more than one), filter out any
initiatives that do not map to this goal. The exceptions being pressing
engineering initiatives (i.e. a platform upgrade, reducing technical debt etc.)
or time-sensitive projects.
Hopefully, you’ve been able to narrow down your list through this process of
elimination. This is where a prioritization framework will come in handy. My
go-to is the impact/effort matrix. It is very similar to ICE and RICE but
simpler and more visual. For each initiative, assign an estimated impact to a
measurable goal and a level of effort. Make sure to collaborate with your
engineering and design counterparts when evaluating each initiative. This will
reduce the chance of your own bias getting in the way and lead to better
prioritization.
For those initiatives left on the cutting room floor, think of a way you could
still make some progress—is there an MVP you could run to learn something while
the teams are working on the selected initiatives? There might be a low-cost way
to validate assumptions via user research or data deep dive so that by the time
you go through this exercise again, you are able to make a more informed
decision.
Product Management Career Path
12 answers
Sr. Director of Product, The Knot Worldwide | Formerly Trello (Atlassian) • February 1
VP Product Management, Networking and Security, Cisco • February 23
Honestly, the first product manager for a company is probably not ready to
establish a prioritization framework. The first PM probably needs to focus on
customer discovery, market discovery, MVP intuition, and experimentation. Until
you have established product-market fit with enthusiastic customer demand,
rigorous prioritization is probably bikeshedding.
Once you have that fit, that's when you'll start to get inbound
requests/ideas/complaints from current customers, potential customers, new
market segments you hadn't considered, and sales teams eager to displace
competition. Then you can start thinking about a model to trade off product
vision, addressable market expansion, competitive threats, technical debt,
quality & reliability, scaling bottlenecks, and so on. The question you'll ask
is: What can the team work on today that maximizes short term opportunity
without hobbling long term viability?
Product priorities more often resemble a Bayesian decision network than a flow
chart.
VP, Product & Operations (WooCommerce), Automattic • March 22
There are many great approaches to this question – and to some extent, it will
depend on what the company values. If you're a first Product Manager, it is most
important that customer needs / expectations are at the forefront of any
framework.
With my teams, I sometimes like to use a graph, where one of the axes represents
customer impact (how much does this product or feature postively improve their
lives?) and the other maps effort or investment. That will give you an easy 2x2
where there is a clear set of high impact, low effort/investment things that
represent quick wins. You'll also have a category that points to high impact,
high effort/investment that require deeper exploration.
Another approach I've seen popular in some areas is defining features as table
stakes, nice-to-have, or surprise-and-delight – and scoring from there where
current offerings stack up, compared to market. While there is no question we
must offer table stakes, how the company approaches the other tranches of value
will depend on the company's point of view on the market, the team's
capabilities, differences or nuances in the customer base, and overall ambition.
Director of Product Management, Fintech, HubSpot | Formerly Segment, WeWork, Airbnb • April 12
The great thing about being the first hire is something that is also great about
Product Management: there is room for interpretation. My philosophy has always
been more heavily focused on understanding how things operate current state,
finding out pain points as well as the more successful parts of a product, and
leaning on those insights to form your next steps.
In certain scenarios, what a team may need is for someone to roll up their
sleeves and do the work to keep the lights on for a product. It may be months
before you can get the product to a comfortable enough place to think about
weeks, months, or quarters ahead; however, that time allows you to gain
knowledge of the product itself.
In other scenarios, a product may be operating just fine, and your task will be
to understand where it can go next. Your time will be spent with customers,
stakeholders, engineering and others to understand the areas of opportunity that
exist. You don't always need to reinvent the wheel or start from zero just
because there was not a product team in place.
Group Product Manager, Airbnb • June 7
First PM in a company! I have not done it, nor have anyone in close network to
have a good understanding. My guess is that they have to establish right
roles/responsibilities on what to carve out from the CEO. Perhaps focused on
scaling up product for next million users (or take on next set of enteprise
clients), or execution focsed. Do take this with a grain of salt as I am
guessing based on when should a CEO hire their first PM.
Head of Product, Retailers, Faire • June 15
When you are the first PM, you are straddling several priorities:
1. Finding product market fit
2. Scaling the team
3. Scaling the product
The biggest failure mode is trying to do 2 and 3 before you do 1: As the first
PM, your foremost priority should be to establish product market fit.
Distibuting that effort across more people dilutes the effectiveness because
information gets lost along the way.
Once you enter scaling, things become more complicated. Here the biggest failure
mode is becoming your own bottleneck and entering what I call the doom loop of
hiring: The less time you spend on hiring, the more you become a bottleneck, and
therefore it becomes harder to spend tie on hiring.
So the crux is: Figure out if you have product market fit (many great posts
about how you know) and then dive into hiring before spending too much time
scaling the product - even if it hurts.
VP Product, CookUnity • June 18
In my experience a prioritization framework is foundational to establishing a
great working relationship within your own team and stakeholders. I'd also argue
that if executed well in the beginning, the framework may not change much
regardless if you are the first or 10th PM at a company. In fact, it may be a
bit more straightforward as a solo PM since the prioritized list of needs and
deliverables is a direct negotiation between you, stakeholders and your delivery
team(s). As the product organization grows you'll notice that blockers,
dependencies and enablers exist within your own product peer group as much as
your business and engineering partners. Product teams even become each others'
stakeholders along the way.
As the first PM, you should always establish ways of working and a framework for
how the prioritization process will run: how you collect and understand
requirements, validate impact, align on definitions of done, agree on and then
communicate a prioritized delivery plan. I've used different versions of the
RICE and MoSCOW methods in the past, which I suggest you look into.
Don't skip out on doing things in a documented and structured way because you
are riding solo, trust me it'll pay off in the end :)
Senior Director of Product, Central Technology, Zynga • August 1
There are a few different vectors to consider here. There is the effort/impact
matrix, which is pretty good at helping identify low hanging fruit - essentially
mapping out potential workstreams on a 2x2 matrix (High effort/high impact, low
effort/low impact, etc). This can help cut through the noise as a good first
step, but isn't the only thing you should be considering. Other lens I apply are
things like:
* Customer - how many customers does this serve? VIP customers? Is this a want
or a need? This gets to the "impact" part of the 2x2.
* Urgency/timeline - how flexible is the schedule for this? Is it immovable
(like compliance/legal requirement) or can we work to create space on our
roadmap (perhaps deliver a smaller milestone, negotiate a different delivery,
etc).
* Scope - can we potentially cut scope or re-scope to help move quicker
(example: do a proof of concept to answer effort questions, running an
experiment to get an early read on impact, etc), or is there potentially
another way to solve the problem that we haven't considered. Change we change
the "effort" calculation?
* Expected outcomes - this gets back to the impact, but you will be surprised,
especially in an org that may not have a product presence, that there may not
be a clear definition of success or outcomes a project is trying to achieve.
Part of the role is to apply process and discipline in this area.
Keep in mind that in organizations where Product is nascent or does not exist,
oftentimes there is no one defining the "why", and potentially there is a lot of
discussion on the "how" and the "what." One of the biggest impacts you can have
as a product manager in an organization is being very clear on the why. You may
find that the team is focused on the wrong things (e.g. focusing on building
"bright and shiny" features rather than things that customers may actually care
about, or doing custom work for a particularly vocal customer, etc). Part of the
hard part of product management is saying no to things/pushing back, making
tough choices and potentially killing projects that don't provide clear business
value.
Group Product Manager, Google • August 17
Thank you for the question and I'm sure this is exactly not the answer you're
looking for which is, "it depends"
You're balancing building trust and relationships, understanding your users and
the business, and likely an evolving company strategy. So the question you need
to ask yourself is what are you optimizing for?
The runway of your company is critical to consider, but I always lean towards
how might we prioritize learnings and building trust to build out a strong
product roadmap
Director of Product Management, Aurora Solar • October 17
The fundamentals of prioritization are not too different when you're the first
at a company. But in the early stages of a company or product, it's even more
important to focus.
At an early stage company, or a new product at an existing company, chances are
you're finding product-market fit. When thinking about prioritizing work in that
context, you need to be crystal clear on the metrics that matter, and laser
focused on moving them.
In my experience, developing and testing hypotheses is a great framework for
this stage. You simply can't afford waste, so understanding what you're trying
to achieve, and then explaining to yourself why your proposed
feature/deliverable/problem will achieve that outcome, is worth spending time on
up front.
For everything that you're planning to build, take the time to create a test
plan. And always look for the fastest way to disprove your hypothesis.
Here's a simple example plan:
1. Hypothesis: "if we do x, we will achieve y" is a good format.
2. Method: How will you test this? If you can do it without building any
software, so much the better.
3. Metrics: How will you know if this passed or failed? Be rigorous here!
Failing an idea early can save you later.
4. Results: What happened? Document and analyze the actual against your
hypothesis.
5. Call it: Did it succeed or fail? Invest in the successes, learn from them,
and keep repeating the cycle.
Director, Product, GitLab • December 2
This is a great question about how to pave the way for two things: product
strategy and product management execution. I can see this being applicable to
not only first Product hires at start-ups, but new product areas a company has
never pursued before. There are a few mechanisms/processes I would establish as
a first priority:
1. Establish a feedback loop with the top customers, internal users, and market
analysts (product mgt execution)
2. Identify the top 1 or 2 business metrics you are looking to influence
(product strategy)
3. Create a cadence for a roadmap to release notes that can be published
publicly for internal and external audiences (product mgt execution)
4. Review the existing competitive landscape and understand your product market
fit (product strategy)
Sr. Director, Product Management, Mezmo • December 13
The product manager's primary responsibility is to ensure that the right product
is delivered to the market at the right time. In order to do this effectively,
you will need to establish a framework for prioritizing needs and deliverables.
This framework should take into account the company's overall goals and
objectives, as well as the needs and wants of your customers and stakeholders.
There are a number of prioritization frameworks available with RICE, Value
versus Effort, and Kano Model being the most popular ones. You can pick any of
the popular prioritization frameworks or even create your own. What matters is
using a systematic and structured approach to prioritize your needs and
deliverables, so that you can deliver the right product to market at the right
time. Another thing when picking a technique to keep in mind is to pick one that
is easy to use and will fit with your company's culture and can eventually scale
as the product team grows.
3 answers
Director of Product Management, Carta | Formerly Salesforce, MuleSoft, Apple • February 3
To make this decision, I think of opportunity, ambitions, passion, and time:
1. Opportunity - obviously there is a matter of compensation, but there is also
an opportunity for professional growth. For example, joining a startup
allows you to grow much quicker -- you will be wearing different hats and
working much closer to the company leadership. You will make a lot of
mistakes, but the learnings will be much greater.
2. Ambitions - depending on where you at in life, different things might take a
priority and it's important to keep that in mind e.g. you are starting a
family or want to work remote from an island in Hawaii. If you are ambitious
and feel that you can do more, you can tell your manager you want more work
or go to another company or start a project/your own company.
3. Passion - you can gain your initial experience in one company, but if your
heart is in the other place e.g. music, you probably want to consider
getting a job at Spotify or Apple Music. That is where you will have the
most fun.
4. Time - from my experience, it takes ~2 years to get up to speed with a new
product area and make significant contributions. That is why it's common to
see PMs going to other companies or seeking other roles within the same
company. This allows you to grow and shift gears a little. In my 5 years at
MuleSoft for example, I worked on 3 different product areas -- I've learned
how to build marketplaces, identity products, and API platforms.
Sr Director II, Product Management, Walmart • October 3
There are some absolutes, which may be self-evident, but I'll still mention them
for the record: disrespect, discrimination, excessive stress, unreasonable and
unhealthy workload, workplace toxicity in all it's forms, the company is
unethical or is visibly tanking...and many more.
Otherwise, I suspect the most common reason to leave might be simply put as: a
better opportunity elsewhere. Now, this is a very personal calculus that becomes
harder if things are not exactly terrible. Perhaps you are holding out for the
promotion and it is taking longer. Perhaps the economy is too "risky" at the
time. Perhaps you feel like you have something more to learn in the current role
that you want to then leverage in the next job search. On some level, any reason
is a fine reason to stay, as long as you know that you are consiously making the
choice and it is a choice that in your best estimate takes you to where you want
to be in the long-run. Most importantly, you don't want someone else to be
making that choice for you. It is easier to get a job while in a job vs. when
out of a job. And how do you ever know what is a better opportunity elsewhere?
So network, look passively, field exploratory calls. From that perspective, it
is never a bad time to be passively looking and neither is it necessarily time
to leave.
In my own career, I've had situations where I started looking into a new role
within a few months, due to some of my "absolutes" above being violated. In
practice, I stayed on for many years, despite getting viable offers roughly
every 6 months, i.e. it wasn't innertia, but a consious choice taking into
account an ever-evolving org, company, and economic backdrop.
Senior Director of Product Management, GitHub • November 30
There are a couple of factors to consider here:
* Are you learning anything new in your current role? If not, would staying
with the company, even if it is in a different role, or a more senior role
(be that IC or management), satisfy your learning?
* Do you enjoy the domain, vertical, and business model of the company that you
work for?
* What are the company's growth prospects (or if a startup, prospect for
success -- however you define success?) Be very honest and don't just take
company management's word for it.
* Are you excited and passionate about the product that you're currently
working on?
* Do you enjoy the people that you work with? (your manager, your peers in
engineering/design, your peers in product management, etc.) If not, is it
likely to change over the next 6-12 months or whatever is your window of
tolerance?
* Are you and your ideas respected and given a fair shake? How much autonomy do
you have versus how much do you want?
* Does the company's appetite for risk match your appetive for risk? (e.g. are
you working on a horizon 1 product when in reality you would rather be
working on a horizon 3 product)
There is no right or wrong answer to these questions but I hope they will spur
an honest assessment about what is tolerable (and also if currently intolerable,
is it likely to change to tolerable within period of time) versus what is a hard
red line for you.
Something that you didn't know you would need to do that you only realized later.
3 answers
Director of Product Management, Carta | Formerly Salesforce, MuleSoft, Apple • February 3
Typically, promotions are the result of an individual's performance and business
needs. In other words, it's hard to make a case for becoming a Director if your
area can be covered by a single Sr PM, so both you and your product area need to
grow.
PM Directors are also people managers who hire and build a team of other Product
Managers. Having good people skills is important but you also need to be a great
PM, so you can lead and help your team of Product Managers grow.
Finally, shifting to be a Director shifts your time allocation -- you spend more
time in meetings working with your team and less time creating content, PRDs,
etc.
Senior Director, Product Management, Headspace Health • August 23
This is a mix of both seniority as well as working at a high-growth private
company but clarifying R&Rs to ensure teams are built to maximize impact while
minimizing management overhead is something I have a much deeper appreciation
for now vs. earlier in my career when I focused more on getting a launch across
the finish line.
Senior Director of Product Management, GitHub • November 30
A few of things:
* Know what, when and how to delegate. Delegation has such a negative
connotation in industry (being seen as letting garbage flow downhill) but I
believe this is because so many managers are poor at the mechanics of
delegation. As a PM director, you have to learn how to delegate problems to
be solved and not orders to be fulfilled (a/k/a solutions) and be comfortable
with the ultimate solutions even if they weren't what you would have built as
an IC in the shoes of the delegate. You must also learn to see delegation as
the manner in which you are granting autonomy and growth opportunities to
your direct reports and not as the way to hand off dirty work that you would
rather not do to "underlings".
* Frequent contemplation of organizational design and areas of responsibility.
Every week I am thinking about organizational design and at least quarterly I
am having discussions with my peer leadership team in engineering and design
to talk about whether we are a) staffed appropriately in the areas we need to
be; b) whether we have the right skillsets and mix of seniority on our teams;
c) whether we are optimizing for the strengths of PMs/eng leads/design leads
while also giving them opportunities to stretch and grow in their current
roles.
* Employing a variety of communication styles with a wider range of
stakeholders. We all have our default, natural communication styles (for
example, my management style with my direct reports defaults to Socratic) but
a director has to know when to switch styles based on the recipient of the
message, their level of seniority, their personality, etc. -- and be able to
intuit this very quickly in the course of delivery. I have had to force
myself to be more direct ("Crucial Conversations"-style) when a softer
message isn't making it through, for example. A corollary here, particularly
when dealing with senior stakeholders: knowing what to spend one's political
capital on, and when to pull back.
4 answers
Head of Product, Enterprise Agility, Atlassian • February 17
1. Storytelling. You need to be able to tie many disparate pieces of product
work - user needs, business goals, technical limitaitons, competitive landscape,
innovation opportunities - into a coherent, compelling narrative. A director can
fill in the blanks in the following sentences with ease: "This year, my team is
trying to achieve _____ because our comany needs to _____. In order to reach our
goal, we need resources of ______ , focus on ______ and ______ and support from
______."
2. System thinking. A common mistake I see in PMs is trying to get *their* work
done without thinking through the impact it has on adjacent teams - think, I
need to meet MY goal and have MY feature on the home page, without consideration
for a global optima. Directors need to think at least one level of abstraction
about their own area. Who else will be impacted by your work? Is that impact
good? Does it add up to greater good, or is it a local optima?
3. Inspire others. The difference between a manager and individual contributor
PMs is that the goal of individual controbutor is to "get sh*t done", and goal
of manager is to "make sh*t happen". You need to be able to achieve goals
through your own work AND the work of others on your team. This is only possible
if people can be inspired by your vision, integrity and leadership.
Senior Director, Product Management, Headspace Health • August 23
1. Exemplary people leadership (ability to bring people along)
2. Strong relationships across various functions (including non-R&D teams) -
get done what's needed to solve a problem, and get products launched.
3. Maturity to know when to switch course for a product line, drive tough
decisions, and leverage #1 to bring your team along with you in that
decision.
Sr Director II, Product Management, Walmart • October 6
Senior Director of Product Management, GitHub • November 30
My answer to this depends a lot on whether the "director" title includes people
management or not. Personally, I believe that it should, and that the IC
(individual contributor) track should only use the titles PM 1-3, Senior PM,
Staff PM, Principal PM, Distinguished PM, etc. But I don't make the rules for
the industry :-) and I recognize a lot of organizations use "director" to mean
IC as well.
I am going to answer the question assuming you mean that it includes people
management. Accordingly, the top skill you want to have is a) knowing that you
want to manage (a/k/a model, coach/mentor, care) other humans and that you don't
just want to be an IC with more influence, and b) learning how to do that, or at
least walking into it having some kind of a philosophy about management. I don't
believe it's necessary to have prior experience as a people manager before
becoming one (otherwise it's a chicken & egg situation and there would never be
any people managers!) but demonstrating coaching / mentoring / feedback
behaviors with your peers is a great way to gain these skills before you manage
other people.
I can't emphasize the foregoing enough because if you do not truly care about
understanding human beings in general, what motivates the specific humans on
your team, and how you can coach them to being better PMs, then you are going to
view the "process" of managing people (HR reviews, hiring / separation duties,
compensation management, 1:1s, etc.) as drudgery rather than tools to build an
amazing team.
I would say that the other two skills that are critical are:
* Being able to drive change through your team, representing both their plans
and their achievements to senior management and advocating for them, and
* Executive presence and gravitas, including the ability to remain level-headed
and confident no matter the obstacles in front of you, to give both your team
and your management the confidence in you as a leader.
4 answers
Head of Product, Enterprise Agility, Atlassian • February 17
The biggest struggle I have observed is related to transition from an individual
level product craft growth to growing that of a group. Andy Grove in High Output
Management said "Managers are responsible for increasing the output of their
organizations and neighboring organizations they influence". Read this sentence
again and again. The learning curve is in learning how to optimize for the
outputs of your team vs. your own. This means that you need to make trade-offs
across your teammates and their areas, as well as help each of them grow as much
as possible.
My recommendation is to read up on team management in all contexts - business,
military, sports have great writings on it; there are also many articles and
videos from leaders of all kinds. Then, ask yourself (before you were to manage
a team), how would I change my prioritization frameworks, rituals, interactions,
communication style if I were to optimize for an output of a team of PMs. You
can even hypothsize about it using your existing team - if you are a manager
tomorrow, what would you do differently to optimize for the greatest output?
Simply thinking and writing your thoughts down on this topic, as well as honing
in on skills I mentioned above in the "director level" answer should help you
prepare for the transition.
Senior Director, Product Management, Headspace Health • August 23
Love the proactive thinking and the desire to excel :)
Not sure if the learning curve is any steeper but there are a few things that
can support career growth:
* Master the craft for what is required of you in the current seniority.
* Get exposure to delegating more work, creating leverage across different
teams, and see if you are able to 'let go of the detailed tasks' but still
bring a beautiful product to life with your team.
* Get exposure to market maps, strategy documents, start asking thoughtful
questions in various forums with leadership - not to be the loudest voice but
more to build the sharpest brain.
* Invest and re-invest in building relationships with cross-functional partners
across the company. Learn how they think about their work.
* Try unblocking others - what does it take to pinpoint what is holding back
someone and how can you help them be successful? What is your personal style
as you do that?
Sr Director II, Product Management, Walmart • October 3
In my experience, the learning curve happens in the current role, as a
prerequisite to transitioning into the next. You have to be operating at the
next level already and there really isn't an easing of the transition beyond
that. For example, managing wider scope, solving harder problems, navigating
trickier interpersonal dynamics, connecting more "dots", communicating with more
clarity on more complex matters, and influencing more people and outcomes, are
among some of the skills needed at every PM level, but to different degrees. As
you showcase these skills you are already solidifying the foundation for the
next level. One of the biggest learning challenges can however come at later
levels - when transitioning from IC to manager (irrespective of the accompanying
title), partially because it is a binary situation. You are either a manager of
people or you are not; there is not much preparing or gradual transition.
Relatedly, many PMs are seeking that check-list, that when done, spells
promotion. Consequently, one of the most frustrating and non-actionable things
that managers can say is "you are not ready yet", perpetuating a bit of the
feeling that there is some transition or steep learning that one must overcome.
Often it means the manager is not ready to do that for you but is uncomfortable
giving you specifics. Or it is not possible in the current org strucure.
Sometimes, they just don't know themselves, but they'll know it when they see
it. Perhaps, that is a big hint. Observe how others at the next level are
operating as preparation. How big are their projects? How much more do you have
to know or do? The criteria can be very different by company, that's why it's
important to know any published leveling criteria. But generally, even then,
there aren't a lot of clear-cut check boxes. Sometime the criteria are only in
your managers head. I once had a manager tell me that if I grew my product to
$50M or $100M in revenue it would get me promoted. (My answer was to remind them
that we were working on 5-year incubation, hence low likelihood of multimillion
dollar outcomes on any reasonable timelines, and that this criteria should have
been articulated a lot earlier in the job decription. Plus there were plenty of
examples of promotions without that criteria - so the aforementioned criteria
disappeared from our conversations.)
In all cases, cross-reference everything official with what you actually see
happens day-to-day and what behaviors or results are rewarded at the next level.
Perhaps, the steepest learning curve is learning what specifically gets you
promoted at your particular company and with your particular management chain.
Senior Director of Product Management, GitHub • November 30
It can definitely be a steep learning curve, because at Staff+ PM level you are
expected to have strengths in one or more areas of product management that
aren't often exercised at lower levels. Some examples:
* Having a much wider aperture and being able to develop and sell
portfolio-level (not just product or feature-level) product strategy that can
touch other areas of the company
* Assessing and making build vs. borrow vs. buy recommendations & understanding
how to work with a channel/partner/business development team
* Coaching and mentoring other PMs and reviewing their work
* Portfolio-level goal setting and roadmap management
* Organizational design (how to do it, when to change it, influencing your
engineering & design peers to restructure their org structure as the product
evolves)
* Preparation of executive-level communications (how to convey only the most
important information in the most concise manner possible)
The good thing is that you are not expected to be excellent in each of these
areas right out of the gate. But it helps to do a couple of things if you are
aiming for Staff+ IC in your career:
* Pick one of these areas and figure out how you can proactively pick up
opportunities to learn and improve now. If you plan to stay at your current
company, it helps to pick something that is a gap/weakness in the
organization to make yourself more valuable.
* Focus your reading / learning / professional development / networking in the
PM community towards that topic, so you gain some outside perspective on it.
* Be transparent with your manager about your career aspirations and what you
are doing to level up in at least one of these competencies -- and hopefully
align that growth with something that your manager needs in the group.
I will mention one exception to all of the above. It is possible at some
companies to become Staff+ PM simply by having more historical and domain
knowledge than anyone else such that you become the "product oracle" for that
area. In these situations, a breadth of skills outside of that domain knowledge
is less necessary. Just remember that there can only be one oracle; once you
choose that path, it is hard to get a Staff+ PM job elsewhere unless that
company specifically needs the same wealth of knowledge.
I'm the first PM in a startup that used to be sales led. I'm trying to set up the proper discovery processes, prioritization tactics and strategy, but I find that extremely hard to do as I'm getting carried away in the day-to-day tasks around requests, issues reported and project management.
4 answers
Head of Product, Enterprise Agility, Atlassian • February 17
Startups are all about speed. To move fast, you need to know where you are going
(aka what to be ruthlessly focused on) and allocate the most of your time/energy
to that. Easier said than done, right? One thing that helped a lot in my early
startup days was my framework of "One thing I am going to fail today".
Once you establish together with your team what you are focused on this week,
month, quarter - write that down and look at it every day when planning out your
work. Then, notice things that either don't help you move there, or things where
your quality of deliverables will not be critical to the area of focus. Then,
tell yourself (and the team, if you so prefer) - I am going to focus on nailing
X today. I will do an okay job on Y, and I am going to drop the ball (or fail)
Z.
Breath out, and go stay focused.
Senior Director, Product Management, Headspace Health • August 23
In a startup, the R&R is faintly defined at its best. You naturally get pulled
into 1000 different things - that is both fun and a challenge :) A few things
that you might find helpful:
* In the beginning, it is good to get exposed to a variety of different topics.
It can be overwhelming for sure.
* Once you understand the organization's needs, ask yourself "What can I do to
make our company successful?" (and I hope your equity motivates you to ask
this question each step of the way).
* The answer to that question will help you in 1) Defining more R&Rs across the
company 2) Seek the resources for the stage your company is at (e.g. do you
really want to add another project management layer or would rather just do
it yourself if communication lines are easy?) and 3) Act like the owner for
the areas where you can make the most impact!
Some tactical things to do:
* Set a goal/theme for the week - if there is one thing you could accomplish
that week, what would it be?
* Proactive and recurring calendar blocks to get that one thing done.
* Consider even setting a target for the day-to-day requests that you feel good
about - e.g. personal SLAs for when can you get back to an email request.
One thing that I like always coming back to is that day-to-day tasks will never
get over. One task will simply get replaced by another. It is so important to
have your boundaries, prioritize and create focus time for what will help your
company the most.
Sr Director II, Product Management, Walmart • October 6
Actually, no differently than managing the 1001 questions and tasks shot at you
in a large company :)
A PM wears many hats. If any one area takes over disproportionately, the risk is
that you are no longer doing the job of a PM. Some common blurring of the
boundaries is when PM is acting to fill gaps that are normally entirely
different functions:
- Project manager
- QA
- Technical Support
- Technical Writer
- Trainer
- Solution Consultant
- Marketer
- Data Analyst, etc.
Write down the CORE PM responsibilities, that should NOT be owned by another
function. This is how in theory your PM role is meant to drive value. Write down
how much time you are currently spending on each and what your total is on core
PM activities. Next, list all the other things you do that should be owned by
someone else. How much time do you spend there beyond a reasonable amount that
PMs would normally have to dedicate there? The difference between time spent
elsewhere vs core PM dilutes your role and masks gaps of equivalent or greater
magnitude in other departments.
Estimate, if resources were not a limitation, how many additional people would
need to be in these stakeholder areas such that end-to-end things run smoothly
without you filling the gaps. Articulate what would get done, if you were not
filling this gap, but were instead focusing on product management. This is your
recommendation and ask of your management chain to rebalance things such that
you can do the best possible PM job.
You may hear that resources are in fact a very big limitation and the status quo
remains, but at least you now have a clear indication of the company's
priorities - e.g. all hands on deck for new sales over new product development,
bug fixes, or launches. That is OK, but then the decision is for you, if you
want that for yourself. Chances are, however, that it will give leadership some
pause and potentially drive some change. I've been through 3 companies (startups
and large companies alike) who all swore up and down that they were
philosophically opposed to having a project management function. That is until
we repeatedly showed how 30%-40% of PM time was spent on project management and
no product acceleration could be had unless we either added more PMs operating
at partial capacity (expensive) vs getting 1 technical project manager (less
expensive). I even had a startup founder snipe about how PM was tied up with eng
in expensive meetings without asking what the meetings were about - they were
about tickets, bugs, backlog grooming, and status reporting. We got new
ticket/bug management tools and a TPM shortly thereafter :)
Senior Director of Product Management, GitHub • November 30
I've definitely been there! As you correctly intuit, your first order of
business is to buy yourself some time to develop a strategic point of view and a
roadmap that supports that it. Obviously that means you're going to need to
spend time meeting with customers, prospects and customer-facing teams inside
your organization, synthesize the learnings, and develop that roadmap &
strategy. In a startup, you have to do this at a much higher tempo than at a
more established company, but it's essential that you convince your direct (and
indirect) management that investing in these things is going to pay off down the
road in time saved / lower risk for the startup / more satisfied customers /
whatever rather than just continuing down the feature factory path.
What's important when you have that conversation is to be explicit about the
things you are going to drop or do less of, like literally saying, "I am going
to do less tactical project management, status reporting, etc." Invariably, some
of your peers who have expected PM to do these things are going to be
disappointed at the lower level of "service" which is why you need your
management to buy in on your shift towards becoming more of a strategist rather
than a tactician. This may need to be a shift that happens over a couple of
iterations particularly if the organization is not used to strategic product
management (you can't "big bang" stop doing project management if the company
doesn't trust you to deliver high-quality strategy yet).
You don't mention the reasons behind why the startup has become less sales-led
and more product-led. Whatever those reasons are (e.g. we are good at bookings
but our churn is really high when customers find out our product falls short of
the promises), you want to be clear-eyed in understanding them and tying any
communication around your shift in focus to those issues. Also, there will
obviously be one or more individuals at the company driving that change from
sales-led to product-led. Ally yourself closely with those individuals, get them
on board with your plans, have them amplify your strategic work products, and
(particularly if they are more senior to you) use them to deflect the noise from
folks who wish you would just spend more time doing project management.
2 answers
VP, Product & Operations (WooCommerce), Automattic • July 26
Having worked in Product in completely opposite contexts, the most valuable soft
and hard skills depend on several factors, including product maturity,
organizational maturity, availability of supporting functions (e.g., Product
Operations, Product Analysts, etc.), and company cultural norms.
At WooCommerce/Automattic, the expectations I set for PMs are:
1. Drive the creation and execution of product strategy for your focus area.
2. Lead multi-disciplinary teams through the development process.
3. Cultivate direct connections with our customers.
4. Increase our success in aiding our customers’ success.
5. Contribute to good business unit leadership decisions.
With this context, I would say the most important soft and hard skills for PMs
at WooCommerce are:
Soft skills
* Proactive internal communication – up, down, sideways (to peers and
cross-functional collaborators).
* Spearheading cross-functional collaboration – from defining an inspirational
"why" to project-managing a variety of stakeholders toward getting things
done.
* Deep listening to customers – this includes taking a genuine interest in
their feedback, and sometimes hearing what is not said but implied between
the lines or in non-verbal cues.
Hard skills
* Functional expertise – most PMs come from marketing, engineering, or design
backgrounds; being able to draw from an area of mastery will inform your POV
(and give you one less area to ramp up on!).
* Goal setting and accountability – this one is a bit operational, but being
able to translate product into measureable impacts will be essential to
prioritization and making a solid business case with your teams. This has,
implied in it, analytical skills, or at least confidence in quantifying
outcomes.
* Industry or subject matter expertise – Another thing that will inform your
POV and reduce ramp time.
Group Manager, Product Management, GitLab • November 16
* Soft skill: Great product managers can seamlessly adjust their communication
to match their audience. As a product manager, you'll speak with people in
different roles and varying levels of expertise in your subject area. It is
essential that you can communicate your ideas and exchange information with
everyone! I really love the perspective shared by Camilla Boyer in a recent
talk at GitLab about communicating with emotional intelligence
https://www.youtube.com/watch?v=3pZoNORrDjU. Product managers should approach
conversations with the mindset of providing the information their audience
needs instead of focusing on what they need to say.
* Hard skill: Iteration is one of the hardest things to master, but it is
essential for providing value quickly and getting feedback to improve your
product. GitLab has great resources to help improve this skill. Check them
out https://about.gitlab.com/handbook/values/#iteration! One thing that has
really helped me improve my iteration skills is to think of my product as
ever-evolving and that what we release is not the final version. If a set of
changes are an improvement to the current experience and there's a clear
roadmap to build upon that experience, then we should release it even if we
are not done!
1 answer
Head of Product, Enterprise Agility, Atlassian • November 10
As a general manager, I own specific business goals and outcomes that I need to
achieve, and am responsible for on an organization level. Those goals are very
specific and measurable, so I always know where I stand on them. As a team
leader, I measure success through my team's happiness, proficiency, ability to
grow their careers, and our ability to scale the team (e.g. we can quickly and
effectively onboard new team members and set them up for success). As a product
manager, I tie my own evaluation of success to value I deliver to my customers
(measured both qualitatively and quantitatively) and to learning - I love to
learn as most product people do, and how much have I learned and whether I have
gotten a better as a PM, teammate, team leader and general manager is the lens I
see my succes thorugh. Those success measurements have been fairly consistent
over time, but I started practicing them in "chunks" - first the PM set when I
was an individual PM, then the leader one when I started managing a team, then
the GM one when I started running a business unit.
5 answers
Director of Product Management, Asana • May 17
At Asana, we don't use leveled job titles to indicate seniority (e.g. Product
Manager III or Senior Director of Marketing), but that doesn't mean that we
don't have management structures in place. Instead, we use Success Guides for
every team that help employees understand what success looks like for each role
level at Asana. Another way we demonstrate ownership and growth in role is Areas
of Responsibility, key areas of the business that have one designated owner who
is responsible. AoRs act as a directory so employees easily can understand who
does what, and they offer employees additional ways to stretch and grow outside
of a traditional role structure.
* As a more junior PM you are working on a well-defined initiative driving the
backlog of a single program team or large workstream within a program team.
You contribute to the strategy for a program, while the high level elements
are largely defined already. You drive work with end-to-end responsibility
around execution in a problem space that is fairly well defined. At this
stage you are open and curious - your growth mindset is a career accelerant.
* As a more senior PM you have a lot of autonomy in running a program team or
large workstream within a program team, and are thinking boundarylessly
outside your program to drive a seamless customer experience. You may be
contributing to multiple backlogs and your work likely touches experiences
that are owned by others. You are expected to set the strategy for your
program or workstream based on the broader pillar strategy. This strategy
must help Asana win. The work that you tackle is difficult, ambitious,
ambiguous, and does not have a clear solution from the outset. You coach
other PMs informally, and may seek out a more formal mentorship opportunity.
Once someone is demonstrating all the competencies at their current level, we
then start giving them extra responsibilities. It is only after demonstrating
those new competencies consistently do we decide they are ready to be promoted.
Senior Director, Product Management, Headspace Health • August 23
This varies so much from company to company but my general lens while moving
from PM to SPM:
* SPMs have had at least one meaningful product launch in their career.
* SPMs are able to cut across product lines, reach out to multiple PMs to
identify dependencies, get buy-ins, and manage timelines for complex launches
that touch various parts of a product ecosystem (vs. focusing on one siloed
area).
* SPMs establish a relationship with various stakeholders (including non-R&D
folks).
* SPMs can outline a broader business strategy and define a long-term vision
for their areas (vs. PMs focus more on execution or on what's next in the
near term).
It is hard for me to define the stages of different SPM levels. Generally
speaking, you can either start going deep into one specific product area (to get
set up for an IC/Principle PM path) or continue working across various PMs to
solve problems (to get set up for a manager/GPM path). In my opinion, as closely
as companies can tie this to impact and the craft of execution, the more
objective this becomes for promotions.
As you progress from PM to senior PM, competencies in these 3 areas should grow:
Autonomy💪🏽, Scope 🌫️ and Leadership 🙋 . There are a few clear indications
that someone is ready for the senior level, like increased scope, being a
reliable partner and being results driven. Here are some less obvious ones:
#1 You recommend initiatives based on your strategic evaluation, instead of
waiting for them to be handed to you. You are influential in your field and feel
confident putting forward these initiatives.
#2 You leverage relationships across the org. You can drive results from
partners outside of your immediate team. You are fully entrusted to tackle
complex, multi-team problems with little necessary supervision.
#3 You are seen as an available and trustworthy mentor and actively seek out
opportunities to help others be their best. This is my favorite by far.
What are the key stages that distinguish the different levels of PMs? I think a
little bit of this depends on the problem space and company. In my mind, PMs are
professional collaborators, strategic assassins and bring out the best in their
peers. If you can look yourself in the mirror and say you’re doing these things
at scale, well, I’d say you're on the right track.
Sr Director II, Product Management, Walmart • October 5
In general, the progression from any level to the next is a matter of
demonstrating increasing levels of skill in product definition, technical or
domain expertise, ability to navigate and project manage increasing levels of
complexity, communication, and ability to influence amonst others. Another way
to think about this is that you are increasingly moving from "learning the
ropes" to "knowing the ropes" to eventually "having invented the ropes". Much
depends also on how formally the company defines the boundaries between roles,
how flat the org is or conversely, how much title inflation there is. Most large
companies have formal definitions of what the expectations are for each level
because that ensures a common set of criteria for promotion. The criteria may
not be well- publicized but they are not meant to be secret, so you should ask
for them either way.
In a traditional PM hierarchy the PM and the Sr PM levels are typically early
career levels. A PM typically receives a lot more prescriptive direction on
tasks, they may cover one or more projects, and the scope is narrower. For
example, running one experiment at a time, defining one feature as a subset of a
much bigger system. While decisions are often made by more senior PMs and
engineering partners, the PM is documenting the requirements, filing the
tickets, and helping project manage.
A Sr PM has shown good judgement and is both able and trusted to operate more
autonomously. This holds true for a progression to Principle, Director etc. The
Sr PM is still focused on a specific area but takes on more complex
functionality, is more actively defining the features and driving the full
product lifecycle. They know the processes and support systems, they are able to
navigate the org and increasingly more complex converations. They are
increasingly self-aware and aware of context. They know when to ask for help or
to check-in that they are on the right track. Both roles are focused on
execution. In some orgs there are additional gradations within a level: Sr PM I,
Sr PM II etc. Unless defined somewhere, a good proxy for any level progression
is as mentioned above: growth in scope, increasing ability to influence and
drive projects of increasing complexity, ability to communicate effectively,
which means both the ability to drive alignment but also to diffuse conflict.
Head of Product, Enterprise Agility, Atlassian • November 10
Check out my other answer in the AMA outlining the difference in skills between
different PM levels. As for how do I know that someone is ready to take on a Sr.
PM role, the answer is I can see them operating with a mastery of skills that I
expect from a senior product manager, while their title may still not have a Sr.
in it. Best folks always uplevel themselves a little faster than the title,
because if you are a growth mindset person who always likes to learn, you will
most likely outpace your title at some point. My recommendation is also to work
with your manager as well and establish what are their expectations for a Sr. PM
- they may have a different idea in mind. But getting to a clear list of what
you'd need to do to get to a Sr. PM title in your org, and then checking in with
your manager consistently on your progress is a path to get there.
1 answer
Head of Product, Enterprise Agility, Atlassian • November 10
Check out my other answer in this AMA to a question asked by someone from a
construction industry. You can repurpose the steps I outlined in that answer to
your situation. The key parts to figure out will be the WHY behind your interest
in SaaS, a list of skills you have today that are transferrable into product
management, and updating your resume/profile/interview practice accordingly.
Good luck!