TeamApart Blog

At MeetCast, we try to build software that helps make working together from afar simple and effective. Working and collaborating in disparate teams remains a challenging and often frustrating experience. We should know: MeetCast is based out of Seattle, but I live in Santa Cruz, California, which is about 800 miles south as the crow flies. As such, I work remotely just about 100% of the time. In fact, I’ve never worked a full day in person with the rest of the team!

Living so far apart definitely runs contradictory to the standard startup practice; most would advocate living and working together day and night. However, in our case, the distance provides us with a unique opportunity: we’re forced to utilize our product on a daily basis to get things accomplished. Since working remotely is our only option, we use MeetCast to work on, well, MeetCast!

Using your product internally is commonly referred to as ‘eating your own dogfood’, and companies use it to vet out new features, discover bugs, and to test products from the perspective of an end user. To not do so is potentially disastrous; I’ve worked at places where the product we were building was not intended for anyone in the company, and we often found ourselves re-implementing features to fit requirements we had never even considered. Who eats their own dogfood? Google and Microsoft, for starters, so you can be sure there’s some merit to it!

So how do we do it at MeetCast? Each morning we start a live conference to go over our goals for the day, discuss bugs and issues, and to make sure everyone is on the same page. Having a few minutes of face time in a conference is a good way to keep us connected and focused, but more importantly, it forces us to experience MeetCast as a user would. Regularly using our product makes the least developed areas of functionality glaringly obvious, since each time we meet we’re forced to work around things that are still missing. New features are also prioritized quickly; the features we find that we need the most are implemented first.

So far, we’ve found and fixed a lot of issues thanks to this technique. A few good updates:

• We’ve fixed an audio glitched that was severely hampering our conversation flow
• We added sound level controls to help reduce the annoying echo we kept hearing when someone didn’t have headphones
• We created a module that allows for shared note-taking and code editing, so that we could keep a running to do list while meeting or work on coding together.

Of course, it helps that our product is built for collaboration. MeetCast helped us quickly tackle issues as we came across them. We’d discuss an issue or potential feature in real-time, share photos of bugs or designs, and keep a running to-do list that everyone could edit, all within the same conference.

We would never have discovered what our product lacked had we not spent so much time using it. The end result is that our product is better, and we’re having quicker and more productive remote meetings. I would encourage anyone rapidly iterating on a product to spend as much time as possible using the product in real-world usage scenarios. The strategy seems to be paying off for us, and with a bit of luck we’ll be turning our dogfood into a fine steak dinner soon enough!