All related (26)
Clara Lee
VP, Product & Operations (WooCommerce), AutomatticMarch 21

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.

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.

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.

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.

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.

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

Savita Kini
Director of Product Management, Speech and Video AI, Cisco
This is not a simple question. There is no such thing as a "traditional PM" because PM roles and responsibilities differ by industry segment. There are substantial differences in PM roles from consumer app to enterprise app to hardware and enterprise infrastructure.  Fundamentally the role of the PM is still the same - to consider customer problems, potential solution approaches, and lead them from concept to launch and facilitate a continous innovation lifecycle. The only difference here in AI/ML PM is a new approch to solving the problem with AI/ML tools and frameworks. So anyone with a ...
Veronica Hudson
Director of Product Management, ActiveCampaign
Everyone is going to make new mistakes coming into a PM role depending on where they are starting from. For me, my biggest mistake was letting my own imposter syndrome take over. I had worked so hard to move from a CSM role into product and once it finally happened, I couldn't get rid of the voice in my head saying, "Wow you are so lucky they *let* you move into product, don't screw it up, because you definitely have no idea what you are doing!" While this was kind of true (I really didn't know what I was doing at the beginning), I should have trusted the fact that I would not have been giv...
Clara Lee
VP, Product & Operations (WooCommerce), Automattic
One way to get Engineering excited about customer focus is to invite them to listen in on interviews. We post all customer interviews on a shared calendar and use webinar settings that ensure observers hopping on / off are not disruptive to the participant or moderator. We also run an internal back-channel where observers can discuss responses or suggest follow-up questions. Often, I see that hearing directly from individual customers drives a level of engagement for Engineers that is much higher than if they were merely reading a written summary of aggregate responses at the end of a study...
Tamar Hadar
Sr. Director of Product, The Knot Worldwide | Formerly Trello (Atlassian)
Speaking to your cross-functional teams is the best way to gain a deeper understanding of your company’s goals, its processes and challenges. It’s also an excellent way to get to know your new coworkers! I like to start by telling the person a little bit about myself, the parts that don’t show up on my resume. Beyond forming a real connection with the person you’re speaking to, sharing something about yourself will lead to greater trust. In your conversations, make sure to include members of your team as well as other teams such as Support, Marketing, Sales and Data Science. Here are a f...