Your first 30 days (3/3): Get a Quick Win

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!

Your first 30 days (2/3): Managing Stakeholders

Most PMs spend very little time pondering how to deal with their stakeholders.  With so many other priorities, it’s usually an afterthought – something we react to, and, consequently, a source of much psychic pain.

What if, instead, we could transform our stakeholders into assets (not liabilities), while boosting our reputation as “product authority”?

In this post, I’m sharing a framework for how PMs can establish a healthy communication channel with their new product stakeholders, and how they can find trusted allies throughout the company.

Stakeholder management is a “must do” for PMs

Think of it as basic hygiene for a product manager. 

You bathe and take care of your teeth; PMs talk to customers and make sure the rest of the company knows the “why” behind their roadmap.

Failure to tend to one’s stakeholders will cause pain.  Poorly managed stakeholders:

  • Complain about being out of the loop
  • Misunderstand/misrepresent your priorities
  • Pester you about the status of XYZ feature
  • Go over your head and complain to your boss…

Ask any veteran PM if they’ve ever had something forced onto their roadmap.  Maybe the CEO was pitched a shiny new feature.  Maybe the Sales GM complained that a key client will walk away if a request isn’t delivered, and derailing weeks of in-progress work.  It happens all the time.

As PMs, we strive to paint a clear picture of our product strategy and roadmap for anyone in the company to understand.  We’ve got to be disciplined and proactive about communicating with stakeholders, but we don’t want a calendar full of “1:1” or “Status update” meetings.  What should we do?

“Rhythm and Relationship”

In our first 30 days, we’re going to focus on establishing a “rhythm” and a “relationship” with our stakeholders, so that we set the information sharing cadence, instead of reactively responding to inbound requests.

I learned this approach from the VP of Product when I became the first Mobile PM for Groupon’s International business.  Based in Palo Alto, California, I faced the challenge of managing dozens of stakeholders across Asia, Europe, and LatAm.

With relationships and businesses across the globe, each with their own feature wish-list, I needed a scalable communication channel.  I needed to train my stakeholders on “the right way” to share their needs.  I also needed to make it clear that I was the person to get their requests on our roadmap (vs. directly speaking with, say, the head of APAC). 

In other words, my stakeholders would learn to receive product updates on my terms.

How a new PM should get started

Here’s how I would get this framework off the ground as a new PM.

Step 1) Identify key stakeholders to invite

You should already have a short list of stakeholders from your manager (see Part 1).  If not, compile this list.

If you’re in a large, global company consider reaching out to each regional head’s executive assistant, or chief of staff, to introduce yourself and ask if he/she has any suggestions for who to invite to your meeting. 

Your note could be something like:

“Hey, I’m Matt, I just joined Alice’s team as the new Product Manager for X.  I’m running a bi-weekly, APAC-focused Product meeting to share our roadmap and recent learnings, as well as to learn about APAC needs and strategy.  I want to ensure our  roadmap reflects the APAC business strategy.  Are there any people from the region that you think I should definitely invite?”

Step 2) Put meetings on calendars

Put a bi-weekly (adjust frequency as needed) update on the calendar, inviting stakeholders from Step 1. 

Position the meeting as a forum to:

  • Review the Product team’s strategy and roadmap
  • Share feature/experiment results
  • Give status updates for business planning

Make it clear that this will be a general product update driven by you (PM), but with an “office hours” feel.  Also make it clear that this is a public meeting – they’re welcome to invite anyone. 

Regardless of who shows up, you’ll need to prepare content, so the marginal cost of more attendees is negligible, and you’ll benefit from increased visibility.

Step 3) Prepare

When I run this meeting, I prepare slides.  I assume the CEO will show up, but I’m also happy just answering attendees’ questions or brainstorming.  You’ll eventually understand what gives the most value to your participants.

Creating polished slides every two weeks will require discipline, but in my experience it will pay dividends.

  • Forces you to clearly articulate what you’re doing and expected impact
  • Serves as a reference for people who can’t attend the meeting, or need data you’ve previously shared
  • Catalog of your achievements (problems solved, metrics impacted, etc.)
    • Useful when updating your resume
    • Useful for your performance review and/or (re-)negotiating compensation

Note: If you’re in a global company, you might want to run this meeting 1x per region at a time convenient for attendees.  Re-use your slides to the extent possible.

Make your slide deck a living, publicly available document.  Keep a private copy of the deck for preparing updates.  Before each meeting, add new slides to the start of the master, public deck.

Craft your message to your stakeholders (your slides) carefully.  It might be wise to ask your manager for feedback before delivering the first update.  Focus on delivering crisp, distilled insights, and try to be data-driven.

Sample content outline:

  1. Follow up from previous meeting
  2. Pending feature or product releases
  3. Current roadmap, and development focus – what’s coming
  4. Review experiments (hypothesis you’re testing, status, results)
  5. Other news / free discussion

Put a link to slides in the calendar invite, and update the deck before each meeting.

Step 4) Run the meeting

Since you’ve done your prep, you should feel confident and ready to build rapport with your stakeholders.  

People outside of the product and engineering org might not be used to getting into the mind of a PM, so think of this meeting as an opportunity to delight them

Make them think “Gosh, this new PM is a breath of fresh air“. A little effort can go a long way, especially when the bar is (sadly) often quite low.

Some things to keep in mind:

  • Be open to feedback.  This will ultimately make your product better.
  • Remember this phrase: “I’m not sure right now, let me follow up
    • If you utter this phrase, actually follow up!
  • Train stakeholders that you are the product authority.
    • Do this by delivering, consistently, on your commitment to keeping them in the loop, and following up on their asks.
  • Find your “allies”.  It will take time to find them, but they’re likely the people who consistently attend your meeting and positively engage. 
    • Allies build your credibility throughout the company,
    • Allies strengthen your professional network, should you later leave the company.
  • Don’t sweat it when some topic derails your agenda/slides – let the conversation flow!
    • Your slides are public and can be viewed by curious parties after the call.

Be an advocate for your stakeholders

By running your meeting consistently, you’ll have a solid “rhythm” (bi-weekly, established cadence), and “relationship” (two-way communications, good reputation, allies) with your stakeholders.

In closing, I think this framework will help you to shift from viewing stakeholder management as a burden, to a skill that you enjoy sharpening. 

Likewise, your stakeholders will come to see you, not as a gatekeeper, but as a trusted consultant and advocate.

Questions?  Feedback?  I’d love to hear about your challenges!  

Your first 30 days (1/3): Getting Aligned with your Manager

As the new PM on a team, you’ll be expected to start owning product outcomes almost immediately.  You’ll probably start feeling pressure to move the needle, and “prove yourself” (hello, imposter syndrome).  Were you really the right person to hire?

What should you focus on during your first 30 days in a PM role?

The next few posts will cover some tactics I recommend to any PM when joining a new team.  I’ll share specific tips for how to cultivate strong relationships with your manager, teammates, and stakeholders, so that you can start focusing on the important work of delighting your users.

Here are my three tips:

  1. Strongly align with your manager
  2. Build the rhythm and the relationship
  3. Get a win ASAP

To kick it off, let’s talk about how to get strongly aligned with your manager.

Shared goals, shared understanding

It’s obvious that you’ll need your manager’s support and guidance, so what does it mean to be strongly aligned?

To be strongly aligned is to have shared goals, and a shared understanding of how you will achieve them.  It means that you grasp, across various dimensions, what truly matters to your manager (metrics, key initiatives and deliverables, and stakeholder relationships).  It means that you’re a force multiplier for your boss, rather than someone who needs to be managed.

That said, odds are that you’re new to the product, and there’s a ton you don’t know yet.  Luckily, as the new PM, now is the perfect time to ask questions and be a sponge.

Let’s get into some specific steps you can take.

Step 1: Set up an informal product strategy discussion 

Explain to your manager that you’d like to get in sync on:

  • state of the business
  • product strategy
  • roadmap sequencing and execution

Expect this to be a wide-ranging conversation, from the 30,000 ft view (CEO vision level), down to the ground floor (how product gets built and shipped). 

Anything is on the table, but your main objective will be to understand what success looks like to your manager, and how you can start to contribute.

Step 2: Topics to cover in your meeting

Below are topics and questions to bring up in your chat.

(IMPORTANT: take notes!  You’ll be receiving a lot of information from your manager and not everything will stick, or make sense at first.)

  • Product strategy for the next 1-2 quarters
    • What are the critical initiatives currently underway, and how do they fit into a longer term vision?
    • Has the strategy been documented and articulated to the broader team of builders (product/UX and engineering)?
    • Are there any worrisome execution risks?  Hard deadlines?
  • Outcomes
    • What are the key user problems the strategy will solve?
    • Which business metrics will be improved?
  • Tradeoffs
    • What are the important problems you will NOT tackle in the next 1-2 quarters?
    • What has been de-prioritized, and why?
  • Stakeholders
    • Who are the key people you should get to know from other teams?
    • Are these stakeholders all aligned with your product strategy?
  • Wrap up
    • Thank your manager for the insights.
    • Explain that you’d like to follow up with a summary of the chat for your manager to review to make sure you didn’t miss anything important.

If you were unable to cover each of the above topics, I highly recommend scheduling another session.

Step 3: Follow-up

Now that you’ve gotten a peak into what’s in your manager’s head (goals and fears), how do you make sure your manager knows that you’re strongly aligned?  Follow up and take ownership.  The way to do that now is to send a follow-up note explaining what you’d like to do next.

This is how I would structure my follow-up note:

  • Summarize your takeaways from the conversation.  
    • Demonstrate your understanding by taking the time to compose a few crystal-clear sentences summarizing each bullet point from Step 2.  This is where having detailed notes is super handy.
    • Set a goal for yourself of articulating these points more clearly than your manager ever has.
    • This is also an opportunity to ask any follow-up questions that weren’t addressed in the meeting.
  • Make a backlog document which captures the top 5-10 important problems to solve.
    • A google spreadsheet or shared wiki is fine, as long as it is viewable by others.
    • Prioritize the problems by using a combination of “outcome” (metrics your manager cares about) vs. “development cost” (use t-shirt sizing like S/M/L/XL).
    • Dev cost estimation takes time to refine, but start now.  Think of it in terms of complexity, as opposed to time to build.
    • Write down any assumptions you’re making around outcomes.  For example, if the outcome is x% revenue growth, explain that it will come from y% increase in transaction frequency.
    • Share the document with your manager and ask for feedback.  Use the feedback to better calibrate your prioritization process.
  • If you haven’t already received marching orders, propose what you’d like to do next.
    • Keep the product strategy, and execution risks in mind. 
    • What can you take off your manager’s plate?  Does he need help bringing stakeholders up to speed?  Does he need you to write some specs/tickets?
  • Finally, since you’re new, indicate that you’d like to meet key stakeholders
    • You will schedule 20-30 min. with each individual to intro yourself, hear their goals and concerns, and ensure you’re in sync re: strategy.

It may not yet be clear how you can best leverage your skills to improve and grow the product, so be flexible and ready to help.

Up next:

Think of the process outlined above as the bedrock upon which your relationship with your manager will flourish.  Like any relationship, it will require attention and maintenance, but being strongly aligned with your manager is incredibly valuable and should ultimately make you a more effective PM.

Now, being strongly aligned with your manager is just the beginning.  Next, I’ll cover ways to get aligned with the broader organization, and your key stakeholders via what I call “the rhythm and the relationship”.