Engineering time is the most expensive and useful resource at your company, and there's a fundamental tension baked into how you spend it. Business teams want to ship more features, faster. Engineers want to be thoughtful and avoid tech debt. Both sides are legitimate. Both sides are necessary. Embrace the tension instead of trying to resolve it once and for all.
The single most powerful way to make peace between those two camps is to reduce the scope of every project. Do less. Ship features as small as they can possibly be and still prove something. This is simultaneously the fastest way to get more out the door and the best way to avoid accidental complexity. It's a genuine win-win, and it earns trust on both sides — everyone can see you're trying to ship fast without making a mess.
Test hypotheses with smaller MVPs
The fix is to build minimally viable products. A real MVP is a specific thing:
- State the hypothesis: "User X has problem Y, and feature Z solves it."
- Design the smallest, simplest thing that would prove or disprove it.
- Ship it fast. Measure the result.
- If it worked, build on it using the same method.
The most successful feature I ever shipped started as a minimal SMS-sending feature. We resisted all the tempting adjacent questions — replies, in-app chat, notifications, calls. We shipped the smallest version that would test the core hypothesis. It immediately became the most popular part of the product. Better ideas surfaced once real users were using it, and the hardest question we almost answered turned out to be something nobody wanted.
Questions to ask before you commit
- What's the absolute smallest version of this feature we could ship?
- Is the amount of polish I'm putting on this actually necessary for it to work?
- Does this extra scope solve a real customer problem, or is it just nice to have?
- Am I designing around gnarly edge cases? How much smaller could this get if it solved 80% of cases instead of 100%?
- What hypotheses am I making, and how will I know if they're true?
- If the core hypothesis turns out to be wrong, does any of the rest of this work still matter?
If you can't answer these cleanly, you're not ready to build yet. You're ready to cut.