Release Early And Listen

DevBBQ, another company that I am a part of has just entered the beta phase for our first consumer product CoffeeDash. CoffeeDash is an iPhone app that makes sharing coffee with friends easier, whenever you’re going to the coffee shop and want to pick up something for people, you no longer need to walk around and talk to people. All you need to do is fire up CoffeeDash, broadcast where you are going, then just sit back and wait for the requests to start rolling in, no need for that pesky face to face social interaction! As part of this release, I was amazed by the differences in what we thought the users wanted vs what they actually wanted.

There is a trend in development right now where people are screaming things like “Release Early and Release Often!” and “Minimal Viable Product!” It’s easy to read about this in blogs and nod in agreement saying “Of course, that makes perfect sense. Why wouldn’t I do this, it’s so obvious?” But when it comes down to releasing something, will you have the stones to actually release early and listen, or will you wait until you add that one last feature, and than that one other improvement?

This is something that I thought I knew and understood, until it actually came time to release my own product. We had a meeting after our basic prototype was ready, it worked and accomplished the main purpose of the app. The three of us reviewed it, and figured out what we we ‘needed’ to get done before we could release it to some beta users. These were going to be our peers, people we knew and would be judging us, we needed to make sure it was pretty good before anyone touched it! Unfortunately that list ended up being pretty long and after being excited about almost being done, this felt pretty discouraging but I could understand why we needed each of these things.

The next day, my frame of mind had changed slightly, yes I could understand why we needed everything, but what if I could justify why we didn’t need any of it, then what would happen? I went through our list and looked for an excuse to push back each item on that list. A solid reason why it would be ok to not include it in our Beta release and I was pretty successful. I managed to push back all but a couple items to a future milestone, and as a result, I realized how important those few remaining items were. No matter how hard I tried, I couldn’t justify pushing those things back because it became even more clear how important they were. I convinced the rest of the team, and after finishing the much shorter list, we sent it out to some users.

That covers the release early part, but once we had some users, things became even more interesting. We thought we knew what our users wanted and where they would find value with the app. We had some really cool features planned out that weren’t necessarily part of the core functionality but sounded really cool, of course our users would love them too. Our initial feedback from our beta users was confusing though… asking for weird additions and features that sounded boring and didn’t quite make sense. After receiving feedback from a few users, we stepped back to process the requests and realized that there was something very important that the users wanted even though none of them actually asked for it. They wanted to make sure that they could easily and accurately make, update and maintain their social connections within the app without having to give it much thought. We needed to make sure that all of this happened with ease and often times without the users actually having to worry about being accurate themselves, or focusing on keeping their connections up to date. This is where the real value is added with our application and if we kept pumping out cool features, we never would have realized this until it was too late!

It’s easy to think you know what your users want but until you think you’ve released too early but get surprised by what your users really want, you probably still don’t quite understand.

After all that… We still polished too much and didn’t release early enough. We’ll work on that for next time.