Right-sizing and Product Scoping

October 31, 2018 • #

In building new product you’re continually faced with the challenge of scoping. When you build something directly for a customer, for a fee (consulting), laying out the scope of the work has built-in constraints — customer expectations, funding, timelines. Even in that scenario, agreeing on a firm scope for an effort isn’t simple. When you build your own product, those constraints still exist, but in a more nebulous, indeterminate form. Constraints aren’t imposed and enforced externally, so they have to be constructed artificially based on your own goals and objectives.

When you set down the idea for a feature’s implementation, you always want your this new feature to be cooler and more complex than you’re ready to commit to. With even a touch of investigation, you discover that it’ll take a year to build the badass version of it. So you have to forgo your vision and erect some boundaries to be able to hit an interim target. This, to me, is the hardest part of product design. You have to knowingly ship something “incomplete” according to your vision.

Of course no one is making you ship anything on a specific deadline. You could spend months crafting and polishing the most perfect version of the feature. But you know this isn’t ideal, either. As clear as your vision is, it’s utility is still not proven through intersection with reality. Like the old adage says: “No plan survives first contact with the enemy”. Or the customer, as it were.

So still you’re compelled to create a trail toward your vision with release points along the way that each constitute something “complete” enough to use and validate. And that’s where I think the core problem lives in product development: the balance of between shipping enough to consider a feature useful but soon enough that you can start measuring impacts and informing your next waypoint. Once you’ve established your vision for what you want to achieve, your next mission is to carve away at it until you have essential stages that work as milestones. In the best cases, each milestone can be a complete stopping point on the feature. You could ship v1, never revisit the idea, and still have something whole and useful.

I have a working theory on scoping ideas with two parts:

  1. Projects designed by committees tend to get larger — perhaps because the average contributor knows it’s unlikely the next idea tossed into the hat will fall in their lap to execute
  2. Projects designed by individuals tend to get smaller — because you’re on the hook to build everything, you’ve got all the skin in the game

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.

When you’re still too idealistic with your scoping and think we can “squeeze in that One More Thing”, the irony is that you tend to change nothing about the end result. Experience teaches you that 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.