When you’re building a product from scratch, you usually can’t look at existing usage data to help you make decisions about your product. However, even when I’ve worked with existing products in the past I’ve found that the way the product has been tagged has meant that I can’t always get all the data I need when making a product decision.

This is because at some point we probably couldn’t think of a use case to track that feature, but later on, one become important—and of course it’s more difficult to get retrospective data for something that wasn’t tracked.

While there’s a tradeoff to be made over how much you want to track—tracking every mouse movement or screen tap in a traditional analytics tool isn’t always practical—I’ve found leaning towards tracking more than you think is necessary at the time has paid dividends in the long run.

Managing stakeholder expectations is a big part of the role of a product person, and generally the greater the scope, the greater the chance they’ll be disappointed. Beyond simply not wanting to fall short of expectations, though, there are plenty of good reasons to keep things simple.

Unless the amount of time you allow expands with scope, the more you take on, the more you’re going to have to rush to get everything done. This will eat into the amount of time you can talk to users, iterate, learn and improve your product. If you’re frantically working to get through everything you’ve got to do, quality suffers, and the focus of the team will shift from building the right thing to just checking off a list of things to build.

It’s always hard to say goodbye to a feature you’ve spent time on, but clinging onto something that’s not working can easily become the time-based equivalent of throwing good money after bad.

If something changes—for example your understanding of the user problem or the constraints you’re working within—meaning that something you thought made sense no longer does, don’t be afraid to throw it away. It will save you time in the long run.

Beyond just having a definition of done, it’s important this definition is also comprehensive. You might think it’s fine to leave bugs to the end to keep up the pace of development, or just add in analytics further down the line—especially if you’re not sure what analytics tool you want use—but by putting these things off you’re just building up a big list of tasks you need to do before you can ship the product later.

While it can often be impractical to end each sprint with a product you would potentially ship (you can’t always build something viable in a sprint), the closer you stick to the goal of ending the sprint with something you could potentially ship, the easier it will be in the long run.

It’s tempting to think that certain common or simple interactions don’t need to be usability tested—that it’s obvious they’ll work. However, you don’t necessarily know that they will work in this scenario and with this audience unless you test it.

Think it’s obvious a “+” button will add something to a list? We found users thought this expanded the item. Think it’s obvious that a heart icon lets users save an item? They weren’t sure until they could see where it was saved to.

Of course, there will be many more things that work as you expected, but even if you’re sure the product you’re building is simple, taking the time to do some usability testing is a good investment.

----

I’ve found following these rules of thumb have helped out time and time again, on many different kind of projects. What are the rules of thumb that you follow?