Book a Meeting – Post Mortem
Posted on April 30, 2014
On Friday (April 25th), Brian Hogg and I decided to shut down Book a Meeting after 8 months of active development and work on the project. I want to share what I learned through this process in the hopes it can help the next startup founder.
Book a Meeting was conceived in April 2013 based on a conversation I had with Ted Livingston where he told me to solve one of my own problems. As the Director of Velocity, I spend a ton of my time scheduling meetings with people outside of my organization including startup founders, startup community stakeholders, mentors, and many others. Unfortunately, there is no easy way to schedule meetings with people and inevitably use email to find the right day and time. We established Book a Meeting to solve this problem by making it easy to customize the available meeting times, connecting directly to your calendar and communicating directly with meeting attendees. The product workflow was simple:
- A startup founder emails me asking to find time to meet.
- I forward the email to email@example.com with my customizations on when to meet (e.g. next week for lunch).
- The service automatically emails the startup founder with my availability.
- Startup founder responds back with the day and time that works for them.
- Calendar invites are automatically sent to me and the startup founder.
1. Every single user manages their calendar differently. While the high level process is consistent across all users, every single person manages their own calendar differently. The slight variations in how people manage their time and consequently their calendars is a major reason we failed. We could not build a product that fit the needs for our users with the level of customization required to match everyone’s needs. Even if we could match their needs, most were not willing to invest time into the product for that customization to match them effectively. While the product worked well for me personally in my role at Velocity it didn’t match Brian’s needs as a custom software developer.
2. Not everyone is comfortable letting a computer book meetings. There are two sides to this challenge. First, some users expressed serious concerns with letting a computer book any time into their calendar. We had not yet implemented support for location causing potential challenges if meetings in different locations were booked back to back. We had users express concern with too many meetings being booked back to back to back causing a long day with no breaks. There are a large number of subtle assumptions that go into managing your time, which is really hard for a computer to manage. My favorite example was lunch. If you had booked in meetings around the lunch hour and had 30 minutes left between 12:30-1pm the human would never book in that time. A computer would though. Second, users were worried that the impersonal approach of a computer did not convey the importance of setting up that meeting. This was particularly important for people who felt the impact of social conventions to personally handle the meeting scheduling process rather than sending it to our service. Social conventions have made it acceptable for a human being (e.g. an assistant) to perform this process but not a computer.
3. Interest vs. usage. During our initial testing process, we had positive responses from potential users who expressed frustration with this problem in their own lives. We had users “blown away” by how powerful this could be in saving them time. However, once they started using the product the problems outlined above started to play a larger role. We likely ended up waiting too long before shutting down the service simply because we thought we could build around the issues above.
3. Email as an interface has pros and cons. One of the key differences with our service was that we worked hard to ensure the user could stay in their inbox for the whole process. At no point during the process did the user have to open a webpage or use an additional interface to book the meeting. The goal was to save time and make it easy to book meetings especially when users were mobile. However, we underestimated the disadvantages and the impact to the overall user experience.
(a) Every email client is unique. We spent countless hours both designing and testing our email template across the various email clients. There were some libraries that attempted to improve the layout of our emails in the different email clients but they also came with their own set of peculiar challenges. We underestimated the amount of effort involved in ensuring that our service would work flawlessly and look great in every email application including mobile devices.
(b) Mobile vs. desktop. Unfortunately, email clients do not support modern web standards and as such we were required to build email templates that would perform well on both mobile and desktop in a single template. This was particularly difficult and resulted in an “ok” experience on both platforms. Gmail was particularly hard for us to manage given that it only supported inline CSS (compared to almost all other email clients) and would automatically underline all dates. We spent a lot of time trying to obfuscate the dates in our emails to avoid Gmail underlining them since it created significant user experience issues for us. Here is an example of what our email looked like in Gmail compared to the one above.
(c) Hashtags. Our email only approach utilized the concept of hashtags to allow the user to customize what meeting times were presented in Step #2 above. For example, I would write “#60min #lunch #nextweek” in the email I forwarded to the service and it would automatically only send available times where I could make it for lunch next week to the startup founder. This type of concept appealed to software developers and technically inclined users because it was very similar to a traditional command line interface. It had the downside of requiring the user to remember what hashtags the system supported but also that non-technical users had yet another barrier to overcome.
4. Solving your own problem only works when you are “normal”. One of the biggest lessons learned is that solving your own problem fails miserably when you are solving that for a market of one person. While we received consistent feedback during the customer discovery phase that users had this problem, it turned out the subtle elements of scheduling time was different for each person. For example, my meeting parameters were very different from most people – I could dictate the location of the meeting (almost always at the Velocity Garage) and I wasn’t worried about someone being offended about me using a computer to book time. I also booked a lot of meetings (on average about 6 per day) such that I was using the system very heavily. The biggest power user on the system (outside of myself) booked less meetings during the lifetime of the system than I did in an average week. Brian had the same problem and during the initial stages of building the company he would use the system primarily for personal meetings. He just couldn’t come around to “trust” the system with his business clients.
Overall, I have no regrets with the time I spent on Book a Meeting. I learned a lot about challenges in the productivity space and it felt great to truly create something tangible again. We made some mistakes and there were certainly things we would do differently if we did it over again. It was great working with Brian and getting to know him better through the process.
One of the main reasons that I continue to build my own startup while working at Velocity is so that I can truly put myself in the shoes of the entrepreneurs I help every single day. Ultimately failing with Book a Meeting and shutting it down has been harder to accept than I expected. I found that quite surprising given that I only worked on the project part-time. Now, I am just looking for the next idea that I can get excited about it and apply all of the lessons I learned with Book a Meeting.