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!
Strategies, Tools and Tips for Product Managers 