Don’t Be Afraid to Ship Something Simple…
One of the (many) great things to come out of the software industry’s adoption of Agile methodologies in the early 2000s is the behavior of shipping early and often. From the Agile Manifesto principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
– Agile Manifesto,https://agilemanifesto.org/principles.html
You don’t wait for a “big bang” release; you don’t perfect every aspect of your product—you release valuable software out to users as soon as it’s ready, and you update it continuously. Some of the ways that this principle is often violated in modern software development are:
- You want to add just one more feature before you think the product is ready
- The marketing team wants to wait until the campaign is ready to promote the feature
- Your competitor offers more features and you need to match them
Trust me—your users don’t care about these reasons. Your product doesn’t need to be a whole new category of product; it just needs to help users get their shit done. Fewer, better features are better for the user experience than trying to cram too much in, pushing deadlines and developers until your user ends up with 100 half-baked features instead of 25 excellent ones—and a later release date.
Try to remember that, in most cases, most users will only use your app for 1% of their day—you work in it all the time so it’s easy to lose objectivity. Ask yourself: “Do we really need Y? Would users be happier with a better X?”
Create a well-researched, well-defined scope for your first version, so that—when stakeholders inevitably get the fear about missing features compared to competitors—there is justification and strategy for continuing with the minimal version release and then iterating later based on what you learned.
Learning points
- Keep it simple; don’t reinvent the wheel
- Ship early and often, delivering valuable features
- Don’t chase competitors’ feature sets; sometimes less is more
