More thoughts on how “Good PMs” ship

More thoughts on ways that PMs can help ensure the team ships the product on time are below, in no particular order.  Patterning this like the famous Good PM, Bad PM article by Ben Horowitz.

Clarify the “what” with the builders

Establish a team meeting to review designs/functionality, upfront. 

Walk through what you’d like to deliver, and the various “stories”, or chunks of work you see to achieve those expectations.  Meetings usually aren’t fun, but for a team with a poor delivery track record, this is justified.

  • Good PMs will:
    • Think hard BEFORE the meeting about potential complications, document them, and raise them during the meeting (even at the risk of looking dumb).
    • Make the sequencing of work crystal clear, and will explicitly document any “long poles” or dependencies.
    • Own this process of bringing clarity to what’s being built.
    • Adjust the granularity of the discussion as needed.  Poor delivery track record means you need to get very detailed.
  • Bad PMs will:
    • Discuss sequencing of tasks once the work is underway.
    • Frequently be surprised by blockers.
    • Wait to discuss go-to-market and release plan with stakeholders until development is already underway.  Does it need to be behind a feature flag?  A/B tested?  Etc.

Expect the “last mile” to be a long one

I’ve been a part of several releases where the team got caught in a seemingly endless cycle of testing, finding, and fixing bugs.  There wasn’t much confidence that quality was being delivered.  Things felt brittle.

  • Good PMs will:
    • Take into consideration time needed to update test suites, and for bug fixing.
    • Ensure devs have time carved out to handle release tasks (merging, dealing with build issues, etc.).
    • Take both of the above into consideration when communicating dates to stakeholders.
  • Bad PMs will:
    • Not ruthlessly prioritize bugs found during testing.
    • Blame developers for delays.

More about scope reduction

I wrote about this previously, but creating a Scope Reduction Plan will go a long way toward helping you deliver on time.

  • Good PMs will:
    • Think hard about the core problem, and the minimum viable way to address it.  If you had just 25% of your current resources, what would you change?
  • Bad PMs will:
    • Be “reactive” when dates start slipping.  Make emotional decisions.
    • Surprise their stakeholders when reducing scope.

Your team should take pride in shipping

At the end of the day, building products is a team sport.  In the long term, having a culture where your team is proud to ship will result in people going the extra mile when needed, without burning out.

All of your processes and planning will result in more accurate delivery estimates, happier stakeholders/team, and a reputation for being a team that can execute.

  • Good PMs will:
    • Go the extra mile – be a PM who unblocks and helps the team focus.
    • Celebrate victories and publicly recognize strong contributions.
  • Bad PMs will:
    • Focus on one-off delivery dates, instead of shifting the team culture.

Get the Interview: Crafting your PM Resume

Note: This is a lightly edited email I sent to a PM who wasn’t having luck in his job search.  His resume was being rejected outright (no interview).  I gave the below advice.  In the end, he was able to get the job he wanted, and though I can’t take credit, I think he found my advice on how to tailor a PM resume useful.

10 seconds to the interview stage

My main advice for getting a PM job in a hyper-competitive market is to go narrow on a domain or problem you find deeply interesting.  Make your competition a smaller pool.  People change roles/companies all the time, so getting good experience working on problems that interest you, even if not in the role you wanted, is worth considering. 

For me, finding the problems I’m excited to tackle, naturally drawn to, is a precursor to the job search.  I won’t touch my resume until I know what I want to do.

As such, don’t think of yourself as having “one resume”.  

  For example, if you want to interview to be a PM at Uber, you should comb through the job posting (if one exists), and think hard about what you’ve done that demonstrates you’re capable of excelling at what Uber needs solved.  If you’ve previously worked on location-aware features, implemented new payment methods, tackled logistics problems, etc., those are likely to be worthy of highlighting to a company like Uber, in particular.

Don’t rush this step – know your own strengths and weaknesses as you see yourself in the role.  Ask an ex-coworker what they think about you in that role.

Go on LinkedIn and look up current and former Uber PMs.  What can you deduce about being a PM at Uber, based on their profiles?  Can you find similarities with your background?

I don’t know what Uber needs, but always tailor your resume to the role.  The person reading it should get a sense of whether you’d be a good fit, just from reading your Summary and your most recent experience (think within 10 seconds of viewing your resume).

I can guarantee you that you’ll increase your odds of at least getting a phone screen if you do this.

Don’t be generic – highlight specific outcomes

Secondly, the bullet points for your PM experience are basically just outlining certain generic aspects of what a PM is expected to do, without telling me anything about:

  • the results you drove (business/user impact)
  • how you demonstrated product leadership skills (did you “own” the roadmap?  did you drive the designers and engineers toward desired outcomes?) 
  • how you successfully navigated cross-functional relationships

I like the fact that you have some technical skills and can code.  What have you done with those skills?  Did you learn these through self-study?  How has knowing SQL/Python been relevant to your PM and Marketing work?  Has it helped you do analysis that others couldn’t do?  Has it helped you to work with developers?

In short, I would want to know the value and outcomes you’ve driven (making users happy and/or saving the company money), so that I can make a ballpark estimate as to whether you could potentially be a good hire for my team.  I just need to see a potential fit to help make up my mind about moving a candidate to the phone screen stage.

Would the hiring manager click on your PM “ad”?

Maybe think of your resume as the first piece of advertising you’re putting out for your skills.  If you were to run a campaign with your resume Summary on Google Adwords, what would get a higher click-through rate (the equivalent of moving a candidate to the phone screen stage)? 

Google does their best to target their ads; you should do your best to target your resume (your “ad” for your PM services). 

Going back to your Summary, it would also be good to hear what your high-level goal is.  Do you want to build consumer products?  Do you want to focus on a specific aspect of product management?  Again, tailor it to the role/company’s needs.

Hope this helps – let me know if you want to chat.  I’m based in Palo Alto.

Cheers,

Matt

What’s the most important skill a new PM should learn?

A PM connection asked me for advice on shipping.  Specifically, how to set achievable deadlines for the developers on his team.  Releasing late (“slipping”) is the norm at the handful of companies where he’s worked, and he’s frustrated with dev teams not delivering on time.  

This is not uncommon, and it’s why I’ve come to believe that the ability to ship is the most important skill a new PM (any PM, really) needs to be successful.

Customer empathy and delivering value matter greatly, and you should always aim to delight your users, but you’ll get nowhere without the foundational skill of consistently shipping product.

Anyway, I’ve dragged my feet on this article for too long, so in the interest of following my own advice, here are three levers a PM can pull to better manage slippage risk, and ship more product in almost any situation.

Tip #1: Make a Scope Reduction Plan (SRP)

Reducing scope means committing to deliver less, while still providing value.  It might mean releasing a partial solution, or launching something functional (but not pretty), so that you can ship in a timely manner.

And yet, PMs frequently do not wield this tool.  In fact, scope tends to increase once work is underway.

So why don’t PMs reduce scope more often?  One reason is that it feels like failure.  In my experience, though, conversations about reducing scope tend to happen far too late, when deadline pressure is about to boil over.  Who can think clearly and put together a coherent plan in such a scenario?  Not me.

I recommend creating an explicit Scope Reduction Plan (SRP), so that you can decisively and gracefully address unexpected delays. 

Here’s how I would create an SRP.

  • From the start, operate under the assumption that scope will have to be reduced, and create a plan with multiple scope reduction options, or “menus”.
    • It’s important to define multiple options, because you’ve no way of knowing how far along you’ll be when a decision is needed.  
  • Start with the “ideal” and work backwards to define your scope reduction options.  
    • Ideal solution: what you’d deliver to truly delight users (you could replace this with what your stakeholders and the CEO expect).
    • Good enough: solves the problem with a decent user experience.
    • Solution with warts: addresses, or partially solves the problem, but leaves a lot to be desired and/or is not intuitive.
    • Poor solution: only addresses part of the problem, is difficult to find and/or use, but still adds value for motivated users who can figure it out.
    • (It’s important to note that each of these options should be sufficient to launch as a v1.)
  • For each option, explicitly state what’s in, and what’s out of scope.
    • Call out functionality, features, or other aspects that are cut, because all implications may not be obvious to everyone.
    • Dev implications (e.g. dependencies), and design impact should be included.  Take a guess if you’re not sure.  Would your “solution with warts” allow you release even sooner?
  • Review your draft SRP with the appropriate people (maybe your manager, dev leads, and UX designer).
    • Make it clear that you’re focused on shipping, even if it means cutting scope.
    • Explain your rationale for each option, while being clear about which option you plan to deliver.
      • You’re managing risk in case things don’t go according to plan, and you’d like their input upfront so that the team doesn’t waste time if a decision is needed.
      • After review, incorporate their feedback and get their buy-in.  This doesn’t need to be a formal process; just focus on vetting the options.
  • Document your SRP decisions publicly.
    • For teams really struggling to ship, consider marking your calendar (and your public SRP) with clear deadlines. 
    • For example, if the feature is not “code complete” and ready for testing by a certain date, then you will strongly consider shifting down to a reduced scope option.
    • The goal is to not surprise people…  
      • Make your intent clear: scope will be reduced if X, Y, and Z components aren’t ready for testing by the target date, and it will be further reduced, if necessary.
    • …but don’t be a dictator
      • At the end of the day, you need your team’s buy-in for the plan to work.

 

 

 

 

Seriously – the next time you’re planning a feature, sketch out your SRP.  You can do this with a low-risk feature to see how your team reacts.  Share your plan with your team and talk to them about it.  Do the same with your stakeholders.

Tip #2: Gracefully say “no” to more

Sometimes I love saying “no”, in all its various incarnations: “we’ll add it to the backlog”, “not a priority now”, “let me talk to the team”.

As much fun as it is, though, I’ve learned the hard way that you need to say “no” gracefully.

When my three year old son asks if he can have chocolate cake for breakfast, I know that telling him “no” outright without acknowledging his point of view will result in a meltdown.  I don’t want that.  I want a peaceful breakfast and a smooth morning.

Here’s how you can gracefully say “no” to late-stage improvements/requirements (usually not absolutely necessary) without upsetting your stakeholders.

Acknowledge the other person’s perspective.

  • Try: “I think I understand – you’re saying the new price alert feature should support alerts based on price percentage changes, in addition to price levels, is that right?”
  • Avoid: “No, sorry, that’s not in scope.”

Explain your situation.

  • Try: “The dev team is at max capacity right now trying to get code complete so that we can hit our OKR of delivering price alerts as a way to improve retention.”
  • Avoid: “We don’t have bandwidth.”

Confirm their request is received.

  • Try: “I like your suggestion, and I think it makes sense as an improvement once we’ve launched our MVP.  I’ll add it to our backlog; right now it looks like we could tackle this at the end of the quarter, but because it will likely require design, server, and client changes, I can’t commit to a date right now.  I’d also like to launch our MVP and get customer feedback before committing to enhancements.  Let me know if we need to discuss with the Head of Product.”
  • Avoid: “I’ll add it to our backlog.”

Tip #3: Include your stakeholders

As hard as you and your team might try, you will inevitably miss some deadlines, and it will have a negative impact on your stakeholders.  This is a fact of life for PMs.

The best way to deal with disappointed stakeholders is to deliver the bad news early, with a clear explanation.

If you’ve read my post on how to manage stakeholders, you’ll know that I strongly encourage regular information sharing with stakeholders as a way to build allies. 

If you’re doing that, and you’ve created a Scope Reduction Plan (see tip #1), then you should absolutely share your SRP with stakeholders.  Make it clear what you aim to deliver vs. what a reduced scope option(s) would look like, so that it’s no big surprise if scope is reduced later.

Treat your stakeholders’ input as valuable, because it is.  If there is a legitimate concern (for example, a new legal requirement came in), tell them you’re happy to discuss with higher-ups, if necessary, but they need to know that the shipping date could change if scope isn’t reduced, or the team will need to work weekends and nights.

Recap

  • Tip #1: Make a Scope Reduction Plan (SRP)
  • Tip #2: Gracefully say “no” to more
  • Tip #3: Include your stakeholders

Releasing a 2- or 3-star feature today is usually better than waiting three months to release a 4-star feature.  Ship, learn, iterate.

Is there anything you’ve put into practice that helped improve your shipping throughput?  Leave a comment below.  Thanks for reading!

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”.

How should a PM Prepare for an Executive-level Presentation?

An important component of becoming an effective Product Manager is strengthening your ability to communicate your ideas to executives and senior-level people.  It’s not uncommon for PMs to deliver a presentation, in some shape or form, to senior staff.

Examples:

  • Quarterly product roadmap review
  • Presentation at a business strategy offsite
  • Review of high-visibility features, or a/b test results

While presenting to executives can increase visibility of your team’s accomplishments and ambitious future plans, there’s always a chance you’ll get grilled.

Many executives are skilled at asking tough questions to expose weak arguments.  Sometimes your perspective and/or recommendations will simply be at odds with a highly-paid person in the room.  

In order to be seen as a true product authority and effectively present your ideas to get the outcome you want, preparation is key.  Below are a few principles to follow when preparing an executive-level product update.

Principle #1: Be purposeful.  

Imagine you’ve spent the past week preparing for your presentation.  You’ve gathered the exec team and started going through your slides.  After a few minutes the COO interrupts to ask, point-blank, “What is the problem you’re trying to solve here?”.  She just short-circuited your entire presentation!

Consider spending a moment at the start of your presentation to briefly cover your agenda BEFORE getting into the meat of your delivery.  It should be clear who you are, why you’re in the room, and what you’re going to discuss.  What is the outcome you need to move forward?

Principle #2: Be aligned with your boss’s priorities.

You should understand your boss’s priorities in the abstract (e.g. “growth”, “retention”), as well as specifically for your team, or slice of the product. 

For example, if your boss has asked you to build tools to help Marketing acquire new users via a paid referral program, don’t tell the CEO that you believe organic growth should come first.

Your presentation should be consistent with your boss’s directive and strategy, unless otherwise cleared in advance.

Principle #3: Keep it high-level, problem-solution oriented.

Let’s pretend that the goal of your presentation is to get buy-in for your proposed product next-steps from company leadership, or stakeholders.  A decision is needed.

Your presentation will provide value if it takes all of your nuanced learnings about customer preferences, product friction, competitors, etc., and boils them down into key points.  Think about what actually matters to customers.  Is there a story you can tell, or data you can surface, to make that clear?

Executives typically do not need to grasp every nuance, and an exec update is usually not the appropriate time to deliver such detail.  What’s important is that your audience understands the problem (decision to be made), the short list of solutions (costs), and what you, the product expert, recommend (strategy, tactics).

Listeners should gain an understanding of the priorities and tradeoffs involved in solving the problem.  Impact on KPIs, or other outstanding stakeholder requests, and development time/cost (t-shirt size works well) are examples of tradeoff discussions you might have. 

At the end of the day, you must provide a crisp, clear recommendation for what to do next that resonates with the overall company strategy/vision.  

Principle #4: Always bring data to the party.

It’s easy for discussions on product strategy to devolve into lofty theorizing, or, worse, full-blown arguments.

To guard against this, always bring data to the party to support your recommendations, but also anticipate and gather data relevant to opposing viewpoints.  Being empirical will help keep the discussion grounded in reality.

If you’re making assumptions about customer behavior, then clearly state them, and explain why they’re valid.

For example, if you’re an e-commerce PM with the goal of improving customer retention, maybe your presentation if to gain buy-in for rolling out a shopping cart feature to all users.  You might present a/b test data from a small user cohort showing that, even though you see a short term drop in order conversion, your test cohort has significantly greater LTV, or lifetime value.  Your assumption is that this cohort is largely representative of your user base’s behavior.

Why is your assumption valid?  Be prepared to defend it with data.  If push comes to shove, expanding an a/b test to a larger population is not a bad outcome.

For bonus points, I recommend having 2-3 variations of your assumptions, each with different values.  For example, in the above shopping cart example you might show three models, each with an increasingly worse order conversion rate, and the subsequent impact on revenue.  Or you might play with the LTV assumptions.  There are many possibilities, so think about the most important metrics, and keep these models in the appendix of your presentation so they’re available to the skeptics in the room.

By the way, qualitative feedback, such as from customer interviews, can also serve as empirical data.  In my experience, however, the crux of your argument should utilize business/product data and KPIs.  More so than driving business decisions, user feedback will help you sharpen your own product intuition.

Principle #5: Practice and polish.

Think about what you really want to convey, in terms of customer insights, the impact on your strategy (and hence, roadmap), and tradeoffs/costs.

Does your presentation articulate those points?

What would someone only reading your slides take away?

Show/present your arguments to a co-worker, ask for feedback, then iterate.  Practice until you can’t get it wrong!