You’ve just joined as the new PM, and you’ve already spent some time getting aligned with your manager, and you have a plan for managing stakeholders.  Great!  Especially if your manager has given you clear directions for what to tackle first, you’ll be well-positioned to start contributing.

What should you do, though, if priorities are unclear?  What if you don’t have a manager?

What problem are you going to tackle right away, so that weeks and months don’t go by without you having shipped something of value?

My third recommendation for a new PM’s first 30 days is to focus on getting a win, ASAP.  Let’s get shipping.

Playbook for shipping your first win

I hate procrastinating.  I view the end of my first ~30 days as a self-imposed deadline for delivering value (any value).  It’s a “must do”.  After a month or so, you’ll feel pressure (whether self-inflicted, or from peers) around your complete lack of shipping.

Here’s how to pick up your first win.

Step 1) Make a list of pains

Compile a candidate list of “pains” felt by your customers.

Important: We’re not trying to be comprehensive with our list; limit this step to 1-2 days, max, then move on.  Remember, we want a quick win.

Quick ways to find pains:

• Read reviews
  • Check app stores if your product is a mobile app.
  • Read Facebook, Reddit, Twitter, etc. to see what people say about your product.
  • Filter for reviews marked as “helpful”, or upvoted by the community
• Check surveys
  • If your company conducts surveys, such as for measuring NPS, there’s usually a solid trove of feedback to make you shed a tear or two.
  • The founder of Superhuman wrote a great article about his framework for finding Product-Market fit.  If your product is not yet mature, ask around the company to see if anyone has conducted such surveys, then get that data and devour it to understand what your biggest fans want.
• Talk to someone from customer support
  • They know your customers much better than you do at this point, so I highly recommend you get to know them.
  • What are 2-3 quick wins for improving the product?
  • Has something in the product been neglected, or overlooked as an opportunity to help customers?
• Assess the pain extent and impact
  • Try to gauge the extent of the pain (i.e. “core product flow” vs. “edge case”) and the potential impact (i.e. if the pain were removed, how might customer’s behavior change?)

Step 2) Consolidate pains

Aggregate the pains you’ve researched into a single list, removing any duplicates.  Look for pains that manifest in different ways, but actually have the same underlying cause.

Try to get your list down to 10-15 items, max.  Again, this is not a comprehensive exercise, and we’re not building a roadmap.

Step 3) Rank by Impact vs. Effort

• Assign an “impact” score (Low/Medium/High)
  • Keep this simple by focusing on
    • Customer acquisition (growth)
    • Engagement (usage)
    • Retention (stickiness)
  • Essentially a guess, based on what you’ve gleaned in your research / heard from support, but think about how customer behavior would change if the pain was reduced.
  • Data is great, but not necessary
• Assign an “effort” t-shirt size (Small/Medium/Large)
  • This can be a WAG (wild-ass guess)
  • Calibrate such that “Small” -> doable in less than 20-30 days

Step 4) Find the low effort, high impact pain to solve

Now sort your list, first by effort, then by impact.  The lowest effort, highest impact item should be at the top.

The first 2-3 items are your “short list” of candidates.  Write a brief user story, and sketch out a few bullet points for what you’d like to do to improve each item.

Step 5) Review with Eng+UX, then execute

• This may not be how you’ll typically work going forward (I almost always spend time with UX before getting Eng involved), but for your first attempt at shipping, and in the interest of speed, set up time for a sanity check on your short list with your Eng and UX partners.
• Share your methodology
  • Help them understand how you think about prioritization.
  • You need to get your partners aligned with your priorities, so make sure they understand that you’re interested in actually solving a real problem (i.e. this isn’t just an exercise to make the new PM look good).
• Tell them you’d like to address item #1 as soon as possible.
  • If nothing seems doable in <30 days, re-examine your “pains” to consider whether a smaller improvement makes sense.
  • Don’t fall into the trap of biting off a big piece of work – get the quick win, build your credibility.
  • Once you’ve identified the “what”, discuss next steps to get work scheduled.

Build momentum and keep going

Go execute!

(I’m conveniently glossing over what “go execute” entails, since it might vary wildly across companies.  Ask or comment if you have specific challenges.)

• Again, focus on your discrete problem – don’t allow feature creep.
  • Say no to enhancements or changes that will extend your shipping date (as long as you’re still making the problem better).
• As you make progress and it looks like the team will deliver, make sure to inform stakeholders so that they know you’re a PM who ships.

This is really all about two things: building momentum for shipping value, and establishing your credibility within the team.  In addition, you’ll learn a lot about how the development team works (roles, responsibilities, and shipping cadence), as well as your users’ pains.  This is just the beginning…good luck!