Relentlessly reduce scope

Your time is the most expensive and useful resource at your company. There is a fundamental tension about how you should spend your time. Allow me to paint with broad strokes. Business teams (executives, sales, customer success managers) want to ship more features, faster. Engineers want to be thoughtful, avoid tech debt, and build things to a high standard of quality.

This is a healthy tension, and you should embrace it — both sides are legitimate and necessary. You'll need to continually negotiate between these competing interests. Without a Product Manager, you’ll need to broker this negotiation for yourself. Depending how small your company is, you might need to advocate for both interests at once!

The most powerful way to resolve this tension is to reduce the scope of every project. Do less. Ship features that are as small as possible. This is the fastest way to ship more features, and the best way to avoid tech debt and code complexity. It is a true win-win. And by pushing for reduced scope, you win the trust of users and business teams. They will see that your goal is to ship features fast, without introducing new problems.

We had a strong hypothesis that our users would be willing to give us useful data via an optional in-app survey. We asked ourselves a lot of difficult questions:

• How should we design survey questions? Turns out survey design is hard.
• Should we have a call to action in the UI to ask users to fill this out?
• Should we have some notification for us when a users submits a survey?
• How do we display summary statistics of survey results?

We got bogged down answering these questions, and more. We designed around the hardest edge cases. The scoping process took me dozens of hours of discussion with designers, engineers, executives, users, and other product managers. We ended up building something grotesque. It was over-engineered, complex, and frankly, a bit confusing for users. Worst of all, it took way too long to build.

We launched and learned that many users were not interested in filling out an in-app survey. If we had shipped a minimal survey form, we would have learned this months earlier.

To summarize our problems:

• We wasted a lot of engineering hours (our most precious resource).
• We have a huge, over-engineered feature that users don’t like.
• Since this took so long, we went months without delivering things users actually wanted.
• We created a lot of extra “surface area” and complexity to our code. Since we don't look at this feature often, it is likely to be buggy, difficult to understand, and annoying to maintain. It’s like we built a huge, disused wing of our house that no one wanted, and now we’re on the hook to maintain it.

The solution to this problem is to build Minimally Viable Products (MVPs). MVPs deserve a post of their own, but here are the basics:

1. Establish a hypothesis, “User X has problem Y, and feature Z solves it."
2. Design the smallest, simplest feature that would prove or disprove the hypothesis.
3. Ship that minimal version fast, and measure your results.
4. If it worked, build on this feature using this same method.

The most successful feature I ever shipped was a simple one. We had a hypothesis that our users wanted to send SMS messages from our app. Like before, we had difficult questions:

• If the recipient replies to the SMS, how do we notify the user? Does the response go to their phone? How do we set up a two-way chat for them?
• Wouldn’t the ideal UX be to have in-app chat where you can optionally send some of your chat messages via SMS?
• Wouldn’t it be cool to also set up SMS notifications across the whole app?
• Couldn’t we also enable phone calls and video calls?

Good, legitimate questions. I investigated two-way, in-app chat and the project started to become very complicated. We said no to all these hard questions. We were on a mission to prove or disprove our fundamental hypothesis that our users want to send SMS. We shipped a minimal version, and it immediately became the most popular part of our product.

As we got real feedback from users, we formed new hypotheses of how to build around this core feature. It turned out that once they used the minimal feature, our users did not care about 2-way, in-app chat at all. The hardest problem we almost solved would have been a huge waste of time. Better ideas surfaced.

Here’s why this worked:

• We validated our initial hypothesis fast. Then, we had better information for our next hypotheses.
• Users got what they wanted fast. We built trust with our users and the business teams because they saw us shipping fast. We embraced the negotiation between speed and quality, and they noticed.
• If our hypothesis was wrong, we would have been able to change course quickly without introducing a lot of code complexity and tech debt.

It’s not always so simple. And MVPs often fail. But here are some questions that can help you be more rigorous about reducing scope for a project:

• What is the absolute smallest version of this feature that we could ship?
• Is the amount of polish I’m putting on this feature actually necessary for it to work well?
• Does this extra scope actually solve a problem for customers? Or is it just nice to have?
• Is this solution designed around gnarly edge cases? How much smaller could this project be if it solved just 80% of cases, instead of 100%?
• What are the hypotheses we have made about this feature? Have we written those hypotheses down? How will we determine whether those are true?
• Does this feature depend on one hypothesis, or a string of interdependent hypotheses? Can we boil down the feature so that we test one big hypothesis at a time?
• If our core hypothesis is wrong, is there any need to work on these other tertiary features?