If a user is finished with your app and their next step is to download a file so it can be emailed elsewhere, that’s a meaningless step. If it’s to export their expenses to CSV so that file can be down- loaded and re-saved as XLS then mailed to their accountant, that’s a meaningless step. If complet- ing a project then means downloading all the files, zipping them and emailing them to the client for safe keeping, that’s a meaningless step. Emails are almost always a source of meaningless steps – they rarely carry enough information (“Someone posted a comment”), or they don’t link up the obvious actions (confirm, mark as resolved etc). Any time your user is clicking through a defined series of steps, adding no insight and making no decisions along the way, it’s a sign there are steps to be killed. Future iterations Always fill in the gaps before expanding the product. The shift from shrink-wrapped to SaaS rewards products that are reliable and complete, not buggy and bloated. Expanding your product to solve a larger problem can work wonders, but can only be done on a solid foundation. If your fundamental product isn’t holistic, then adding more features only makes things worse. So much is written about the pursuit of simplicity these days but often there is a confusion. There is a fundamental difference between making a product simple and making a simple product. Making a product simple emphasizes removing all unnecessary complexity so every user can solve their problems as efficiently as possible. Making a simple product, however, is about scoping down and choosing the smallest subset of the workflow where your product delivers value. This minimum viable product approach runs the risk of being labelled a point solution, or worse, “a feature but not a product”. When shooting for a “simple product”, be careful where you draw the line. 27