AvailCal surfaces all of your available times in one place, alongside your scheduled events. This makes the potential for a conflict very apparent. You’re basically seeing a double-booking before it happens. You’re Tom Cruise in Minority Report, stopping scheduling crimes before they’re committed!

Your product is a tool for your users. They want to use this tool to solve problems in their life. The first step in using a tool is understanding how it will behave. We don’t tend to use tools if we can’t predict how they will behave, so we must understand them. When building your product, your job is to make it make sense to the end user. The most impactful way to do that is to reduce complexity.

If you wanted to build a sailboat, you’d want to understand the types of things that cause them to capsize. Let’s say that 75% of sailboats fail because of two main causes in their first 10 years of life. You wouldn’t even consider building a sailboat unless you felt confident that you could solve for those two main causes of boat-death.

Transparency, flexibility, trust, productive working relationships, and effective tools. All of these proved integral to a making this project a success.

Automated Tests alert you to problems before they negatively impact your users. Without this, users would have to report bugs to your support team, the support team would have to triage these reports, QA would vet the bug reports and then Engineering would have to fix the bugs. You can see the inefficiency with this approach, not to mention the frustration felt by your users. Automated Tests allow Developers to work much more efficiently and limit the impact of mistakes, shielding everyone else. This means that a QA team becomes much more optional, and the Customer Support team can be leaner as well.

Changing your data structures in a database (or any data store) involves a lot of hidden issues. There are race conditions to deal with and steps needed to introduce data validation that were not in place before. It can be a little daunting to some, and others might not give it enough thought. With the right understanding, it can be trivial indeed, but having that understanding is key.

Your goal is to disprove your assumptions, not to prove them. This means that you will both double check the accuracy of your assumptions, as well as the value of them. You won’t stop at one solution because you’re not convinced that it’s the best one until you evaluate others. You’ll do more experiments than seem necessary in the prototyping phase and you’ll measure as much as possible in the MVP product.

This concept of “keeping up with success” is what makes software uniquely challenging and forces a stronger decision-making discipline.

It's acceptable if a small percentage of users seek additional details. However, if a significant portion does, the UI is failing them. And if new users must be trained by your staff before using the product, it's time to rethink the design from the ground up.