How to scope product features
Thoughts on one of the product manager's great challenges: how do we scope what to build?
Product teams are continually faced with the challenge of scoping. When you build something directly for a customer, for a fee (consulting), the scoping process is explicit and has built-in constraints — customer expectations, funding, timelines, deliverables. Even in the vendor-client scenario, agreeing on a firm scope for an effort isn’t simple, but it’s even harder when building your own product.
The same constraints still exist, but in a more nebulous, undefined form. Constraints aren’t imposed and enforced on you by a single client dangling the paycheck. The demands are dispersed among thousands of users with sometimes-competing desires, paying varying amounts for your product.
That means it’s on you to define hard edges based on your own goals and objectives.
When you have an idea for a new feature, the vision for it always outstrips what you can commit to building in the short term. If we want to build fast and ship often, we need to draw a box around what we're building. We need a milestone to hit, a basecamp on the way up the mountain where we can regroup, gather feedback, and ultimately figure out where to proceed from there.
This is one of the hardest parts of product design: you must knowingly ship something incomplete according to your vision, but directionally aligned. It also must capture a logical "whole" that handles a use case start to finish. A waypoint on a longer journey.
When setting your own objectives, you have no one telling you exactly what to ship, how much to spend, or when to be done. In consulting, but the incentives and constraints are much clearer; you’re unlikely to commit massive resources to a hazy and overzealous goal, and the customer isn’t likely to pay you what it’d take to commit, so you compromise. You develop a proposal with a scope and a fee, they say yes, you deliver. Thumbs up or thumbs down.
When it’s your own product, you still have end users, but their individual wishes and needs are so distributed that it’s on you to synthesize a mass of feedback into a clear whole you can break down into parts, and to enforce your own boundaries. No one is forcing any particular constraint; you could spend months crafting and polishing the most perfect version of the feature until the final day you get it out there.
Ship “just enough”
But good products come about through savvy incorporation of market feedback into the development process. It's best to work in thoughtful increments that are each valuable enough to earn committed investment from customers, which is where you'll get the feedback you need to validate the direction and make the right course-corrections along the path to the vision. As clear as your vision might be, it’s still not proven until it intersects with reality.
As the old adage says: “No plan survives first contact with the enemy”. Or the customer, as it were. Real-world feedback is what separates a vision from a hallucination.
You need to create a trail toward your vision with release points along the way that each are whole enough to use and validate.
That’s where the core problem lives in product development, the tension between:
shipping enough to consider a feature useful
but soon enough that you can start measuring the impacts that will inform your next waypoint
Once you’ve established a vision for what you want to achieve, you then carve away at it until you have essential stages that work as milestones. In the best cases, each milestone can be a defensible stopping point for a feature. You could ship v1, never revisit the idea, and still have something whole and useful.
Setting the appetite
The scoping process is a painful, but critical step to getting a useful enough product feature soon enough to close the feedback loop and begin iterating. There's an idea from Shape Up that I love, which is choosing your "appetite" — a useful metaphor for selecting milestones:
Whether we’re chomping at the bit or reluctant to dive in, it helps to explicitly define how much of our time and attention the subject deserves. Is this something worth a quick fix if we can manage? Is it a big idea worth an entire cycle? Would we redesign what we already have to accommodate it? Will we only consider it if we can implement it as a minor tweak?
The appetite is the time box. Given the problem we're solving and the value of solving it, what amount of time is worth it? The ability to generate a summary report of critical issues might be worth 3 months of our time to come up with, but what if it's 6? Every problem has a limit, diminishing returns to investment.
Scope is not for committees
It’s tempting to make scope and appetite setting process a group exercise, to fold in product management, design, engineering, ops, or even marketing. A wider aperture of company buy-in makes sense at a macro vision level, but once you get down defining specifics, you need fewer people involved to be able to drill in on what’s most important. If possible, it’s best to involve only those directly responsible for defining and building the thing in question. Too many heads involved generates too much freeform “ideation” and not enough brass-tacks horse trading. Products live and die in effective trade-offs.
I have a two-part theory on scoping:
Projects scoped by large committees tend to get larger — the average contributor knows it’s unlikely the next idea tossed into the hat will fall in their lap to execute; lots of people get to be the “idea person”; incentives to both signal “big thinking” and define concrete goals are in conflict with one another
Projects scoped by individuals or small groups tend to get smaller — because each person is clearly on the hook to build every detail defined, everyone's got skin in the game; incentives are aligned on making things tangible and reachable
Landing somewhere in between is ideal for product scoping. Removing things from the vision (or deferring) requires honesty, commitment, and focus, which are all much easier to guarantee in small groups.
We’re often too idealistic with scoping and think we can squeeze in that One More Thing. The right stretch goals are motivators, but too far-fetched of an objective can set the wrong expectations across the company.
If you’re not more aggressive with the hatchet than you think you need to be in the early stages of feature planning, the whole team (and your customer) will be worse off.