This is a guide for product/engineering executives to get their teams to ship the right stuff, faster. For the purpose of this post, let’s imagine we are leading teams with dozens of engineers and designers working on shipping a new product or major product improvement.
TL;dr #
- Know the Minimum Actually Viable Product.
- Cut the right scope.
- Use smart deadlines.
- Never block your teams.
Minimum Actually Viable Product #
The fundamental key to shipping great products is to have a very clear idea as to what your Minimum Actually Viable Product (MAVP) is. I’m using Actually Viable, because the MVP term is often used for things that are so minimal they’d never Actually Work–more like a first milestone. The MAVP is what you are going to market with to be successful.
The MAVP often includes features that aren’t technically needed to do the job users need done, but these features may raise the delight-level to a degree where folks would actually use the product. It’s difficult to know what the MAVP is, but it is literally our job to know.
Cutting Scope #
The reason that we need to know the MAVP is that we will need to cut scope. If you don’t cut scope, you don’t ship. The secret lies in cutting the right scope that doesn’t pull the product out of being in Actually Viable territory. Cutting scope itself is something you can be smart about. It is often a multidimensional trade-off space of scope size (impact on shipping time when cutting) and how the interaction of the various features impact Actual Viability. As an example: Maybe you can cut a major feature that you thought was absolutely needed if you add 2 small delightful features making users love the product and you increase marketing spend to get sufficient hype for critical user mass.
Smart deadlines #
Next, we’ll have to go into unpopular opinion territory: Deadlines are great. You need to set a date or you don’t ship. Without the deadline you aren't going to have the scope-conversation that you need to have.
Deadlines really are low-cost organizational devices to align multiple teams to get stuff done together. If you don’t know when you want to ship, you need to massively increase micro-managed inter-team communication for the smallest things. With a deadline everybody has a reference frame in which they can work more independently. As a concrete example, think about how cross-functional teams (docs, marketing, billing, etc.) need to all be ready when you want to ship. If your ship-date is TBD then they will likely deliver last minute, and the respective reduction in quality might actually make the product Not Actually Viable.
So, what happens when the deadline approaches and it becomes clear that not everything will be done in time? There are two options: You cut scope, or you move the deadline. If you assess that you can cut enough scope to achieve MAVP, then you ship–but importantly if you cannot achieve MAVP, then you move the deadline. Again: You don’t ship when the product isn’t Actually Viable. It’s fine! (well, I hope the deadline was soft and not something hard like a conference) It is never the right call to ship something that isn’t Actually Viable.
Software estimation is hard, but it is also our job. The part that is severely under-discussed is that software estimates should have error bars (as in confidence intervals). It’s impossible in practice to estimate project duration to a precision higher than a month or 2 when you are setting the deadline 6 months in advance. But it is also malpractice on our side, if we need to move the deadline by 3 months a few weeks before the planned shipping date. As we are approaching a deadline the error bars of our estimates need to tighten, and we need to adjust plans accordingly. For more on this and the cascading impact of missing a launch date, see my post on viral software deadlines.
Never block your teams #
There is one final “hack” you as the executive can do to get your teams to ship. It is both obvious and not really a hack, but in my experience the biggest lever many of us can improve: Make sure your teams aren’t blocked on you.
At Google it was part of my job to approve launches based on written reports. This was an offline process. I could get back to teams within an hour, or a week–both would have been completely acceptable within the culture. But just imagine the efficiency losses that result in teams waiting for feedback for days on end–doing nothing in the worst case, or pipelining many projects (which is better but still not efficient) in the best case. My teams shipped because they weren’t waiting for me. Maybe this is an extreme example, but I think it is common in the industry that teams are waiting for decision makers to make decisions–and minimizing or eliminating these cycles is the biggest lever the executive has as their personal contribution to improve efficiency.
Let's ship it #
The basics are:
- Deeply understanding the Minimum Actually Viable Product.
- Not blocking our teams–dozens of teams waiting on us is an incredible waste of resources.
Pair that with smart deadlines and cutting the right scope, then we can ship.
Published