All related (30)
D Matthew Landry
VP Product Management, Networking and Security, CiscoFebruary 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.

Patrick Davis
Group Product Manager, GoogleAugust 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

Suhas Manangi
Group Product Manager, AirbnbJune 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.

Clara Lee
VP, Product & Operations (WooCommerce), AutomatticMarch 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.

Rosa Villegas
Senior Director of Product, Central Technology, ZyngaAugust 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.     

Zeeshan Qamruddin
Director of Product Management, Fintech, HubSpot | Formerly Segment, WeWork, AirbnbApril 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.

Tamar Hadar
Sr. Director of Product, The Knot Worldwide | Formerly Trello (Atlassian)February 1
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.

Janet Brunckhorst
Director of Product Management, Aurora SolarOctober 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.  
Luca Beltrami
Head of Product, Retailers, FaireJune 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.

David Cutler
VP Product, CookUnityJune 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 :)