What's your framework to prioritizing needs/deliverables when you're the first Product Manager at a company establishing the function?

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.

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.

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.

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.

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.

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.

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.     

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 :) 

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

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.  

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) 

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. 

• Know your customer - Often this can just be the investor in the company/company owner. Meet their basic expectations from the product first, and win their confidence.
• Aim to build a functional prototype / MVP even before attempting to build a fully functional product - It is always important to be able to showcase your product and always be demo ready - Else we run the risk of being dismissed as vapourware
• It's easy to get carried away by all the great ideas, Identify your core product USPs early on and stick to them until they are ready in some form. One of the toughest jobs as a PM is the ability to say 'NO' and prioritize mercilessly.
• Know your work boundaries, and be prepared to go beyond the ask when the situation demands initially, but do not hesitate to ask for help - Asking for help is not a sign of weakness, rather demonstrates your capability.
• Prudently set up a structure to delegate non-PM work early on - such as documenation, UX/design and leaving enough space for market / competitive research, formulating a go-to-market strategy, and processing customer feedback - these functions cannot be filled by anybody else.
• Finally, have a clear path to support product growth worked out and do not be caught off-guard by early success.

Good luck, this is one of the most exciting phases of being a PM! 

Great question, and I'll make some assumptions before I answer. I'll assume that the PM function is new but that there is an engineering and design team already established at the company. 

In this case, my first goal would be to find out what is being built and how well it resonates with the target market. The primary objective would be to avoid wasting engineering rescources by not knowing what to build. If the engineering rescources are occupied with high value work, I'd move on to my second objective. If they weren't working on high value work, I'd synthesize the information from competitive and customer feedback to determine the most high value opportunity for the team to work on.

The second objective would be to look at the backlog and make sure we have at least 2 months worth of high value work for the eng teams to execute on. If that is the case, I'd move on to my third objective, if not, I'd spend time in this stage partnering with cross functional groups to feed the backlog with the next set of most important work. 

Once the backlog is in a good place, I'd be working on the short to mid term strategy for the product and making sure there was a clear and efficient process for ideas to go from idea to experiences in the product and be prioritized by the expected impact. Once that's working well, I'd expand my focus into a fourth objective. 

The fourth objective would be to make sure we have a solid long term strategy in place. Do we have a good sense of how the industry and market is shifting? Do we have clarity on our competitive strength and how we are going to differentiate on those, etc. 

This is also the stage during which I'd be working towards systematic efficiencies. Do we have a consistant process for getting customer feedback? Do we have a framework for evaluating priorities? Do we keep tabs on competitors? + more 

Prioritization is hardest and most important problem to solve when you are Product Manager #1 in a company.

Because in early stage startups, it can be really choatic with changing needs and market conditions, I don't recommend following RICE or any other standard prioritization framework. In my opinion, Product Manager with most product sense will succeed the most here. Product sense is a combination of deep understanding of jobs-to-be-done for users, continuous user interviews and deep market knowledge. That can help you decide what to build and when to pivot. In addition, working closely with visionaries ( mostly CEO or CPO) in our company who are driving long-term differentiation and strategic advantage is crucial.

Listening and Learning / Re-learning skills are most important. Pragmatic approach rather than going by the books is what I recommend in this scenario. Outcome I look for is delivering small iterative features that are received well by users ( i.e. there are indications that features are adding value ) and that team is learning more about user behaviours/interactions in relation to the product at hand.

In a more mature product or company, I would recommend more structured approach such as RICE framework to prioritize product features / intiatives.

Taking a step back, I think the 1st PM needs to act a lot like a head of product in the early days. The ones I see that do well for their company (and themselves) typically focus on doing 3 things well, where others only do 1-2:

1. PM Execution

   • Typical activities you expect from a PM i.e. research, talking to customers, ideation, roadmap

   • This is foundational, but I think you will likely fail or at least get overlooked for leadership opportunities if you only spend time on this

2. Building the PM playbook

   • A key part of establishing the function is to determine the stage-appropriate processes, tools and people (hires) needed to achieve our goals

   • By owning the execution piece, you have an unfair advantage (and incentive) in shaping what the playbook should look like

   • If you can take most of this off your founders' plate, IMO you almost instantly distinguish yourself in the top performance quartile

   • You will also have greater control of your own destiny i.e. who joins the team, how prioritization decisions get made

3. Stakeholder management and education

   • Expect to spend 1/3 of your time (ideally not too much more) aligning with key stakeholders not just on what will make it in the roadmap and be shipped when, but also on how decisions should get made, and why there is a business justification for certain resources to achieve your goals.

   • In a startup, your leadership and key stakeholders probably have a limited understanding of PM best practices. In fact, they may have a (somewhat biased) view that a lot of it is unnecessary red tape that will slow down execution. Know when to push back and when to optimize for speed of execution and document learnings later.

   • I think the best founding PMs think like mini-CEOs: they scrutinize the business value of features (output) as well as the inputs (imagine this is your own $ or resources). They push back and say no when it's needed, and they're flexible enough to update the playbook and processes as teams grow.

To answer your question more specifically, here's a simple sequence I'd use to prioritize my startup product roadmap from first principles:

• Align on north star goals:

  • Where do we need to get the business metrics to be in the 6-12 months in order to raise our next round of funding? (or whatever the company north star is e.g. reach profitability)

  • As a result, where do we need the product metrics/behaviors to be in the 6-12 months in order to raise our next round of funding? (or whatever the company north star is e.g. reach profitability)

• Work backward from north star goals to your current reality:

  • What are the 3-5 key jobs to be done that our customers come to our product to achieve?

  • How well does our product help customers complete these jobs to be done today?

  • What customer behaviors do we need to see in the product for us to know this is true? What product KPIs/metrics can we use to measure and back up that these behaviors are really happening?

  • Which business metrics (e.g. revenue, retention) will this impact?

• Other first principles I'd think about:

  • Leverage the fact that your team is smalll to talk to more customers. You should become the expert on your customers 'jobs to be done' and current workflows. This will give you all the ammo you need when having to confidently decide, slice, and justify your roadmap.

  • >50% of the time, in the early days, doubling down on features or a product area that already works (i.e. has usage) will yield better results than shipping a shiny new feature. Communicate this accordingly to your stakeholders.

  • Be very clear about whether a feature is to play offense or defense (i.e. filling a gap with a competitive product.) There's nothing wrong with either, but a large lack of either signal you are either focusing too much or too little on the products you are evaluated against.

When I search the internet for "Product management prioritization frameworks" I get back 3.2M results so the options are nearly limitless of what to choose. MoSCoW, RICE, Value vs. Effort, Kano, etc. find a method that makes sense to you and the data is mostly available to apply to the framework.

Now comes the hard part, sharing that list. Start with some friendly faces, share the context of what you knew for sure, what you had a good idea about and what you totally made up to find out where you were wrong. From there you can start to expand the audience to share not only what the priority is but why it is what it is.

This turns a list of features you want a team to work on to a list of outcomes they will commit to deliver together because they had input into the priority and know why they are doing the work.

Now you can iterate on what worked for data gathering, synthesizing and presenting that data for the version because telling people in and outside of the company what you are working on and why is a daily todo for Product Managers.

The framework doesn't change whether you are the first PM or the 100th PM IMO.

Understand what business goals need to be achieved (which will most likely be be set top down) and then determine what product outcomes will help you achieve those business goals. Based on those product outcomes determine where you need to invest.