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!

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!

Thanks for joining me!

Good company in a journey makes the way seem shorter. — Izaak Walton