Eat Your Dogfood

sleeping-rottweiler-puppy

“Employees should use the products and services produced by the companies that employ them. They should be emphatic fans of their company’s products. Nothing less.”

— “How to Get People to Eat Dog Food” by Ethan Mayers at AlleyWatch.

I remember when I first heard the question “Are you dogfooding?” shortly after arriving at Microsoft in 2004. I was puzzled for a second about why anyone would not use their own company’s products, especially when they were on the product team that was building them.

Fast forward a few months to the mid-point of the Outlook and Exchange 2007 release. Our dogfood email environment would periodically go completely down for days at a time and we would resort to using IMs and our bug reporting system to exchange important messages. I remember that some of our execs were not in the dogfood environment, but when they heard about the issues we were having they asked to be moved in their with us. They wanted to see for themselves what was going on and to give us a little pressure by having their dogfooding right next to us. Want a quick way to get your day-to-day product stability in shape? Inject a few executives and put their real email on the line and you’ll get blunt feedback, ‘fo sure.

My point here is not that we were in terrible shape in early Office 2007 engineering (we weren’t), nor that we weren’t dogfooding (we all were), or that execs are the best way to do Q/A (they’re not). My point is that as a product manager it’s easy to get stuck staring at the trees and to forget about the forest when working on a specific feature in a larger product. It’s something that can happen more frequently as startup teams get bigger and product managers get more specialized.

In another example from that team, I remember being heads down working on a specific and critical issue in Instant Search in Outlook (one of my features), and I assumed that someone else was seeing the reliability issues I was having with sending email in this specific configuration. I remember bringing up one of those reliability issues to the team that owned Mail Transport, and they determined that it was the specific way that I setup Outlook that was causing the issue (it was having multiple POP accounts loaded into a profile while searching across profiles), and no one else on the team was seeing it because it was setup- and timing-related. It was a critical bug because many of our customers would eventually have a setup similar to mine and therefore could have been susceptible to the issue once we rolled out the new feature.

As teams get bigger and more specialized it’s critically important that product managers dogfood their specific feature or product. It’s equally important, if not more so, to make sure you are always dogfooding end-to-end experiences outside of your feature ownership and across the entire breadth of products you build. You should also look for unique ways to get a fresh perspective while dogfooding. For example, we found that by adding the execs in at a time of difficult product stability during Outlook 2007 development, we were able to inject some “new eyes” into our day-to-day work and get some great objective feedback. This also helped us get dogfood coverage on features like Delegate Access, a setup that only happens when someone else manages your inbox and calendar in Outlook (a setup very unique to VP-level and higher users). In another case, we asked the entire product team to unplug their mouse for an hour to try and use Outlook via the keyboard only, helping us find a bunch of good bugs in our accessibility code.

Here on the Contactive team at ThinkingPhones, as our products get more complex and our team grows, we continue to dogfood every day and constantly come up with new ways to get those fresh perspectives. One of our favorites are weekly team-wide dogfood bashes to help get fresh eyes on new areas of our code. One of our product managers puts up a whiteboard, cranks the music (usually 80’s workout montages from Spotify), and everyone writes the bugs they find up on the board. We sometimes award “most interesting bug” and other fun prizes. You’d be amazed by what you can find with that kind of intense focus. We also have a “Bugs” email alias that gets traffic at all hours of the day, as we have all adopted the habit of sending screenshots and bug reports the minute we see them. We find that these types of efforts help increase the focus of the whole team on the quality of our products.

Our goal at ThinkingPhones is to be proud of our products and deliver amazing experiences to our customers. We believe pride comes from quality, and quality comes from eating your own dogfood.

Yum.  🙂

Book Thoughts: “Zero to One: Notes on Startups, or How to Build the Future” by Peter Thiel

“A definite view, by contrast, favors firm convictions. Instead of pursuing many -sided mediocrity and calling it “well-roundedness,” a definite person determines the one best thing to do and then does it.” 

tumblr_inline_ni38b1OxhO1qbz19l

Thiel, Peter; Masters, Blake (2014-09-16). Zero to One: Notes on Startups, or How to Build the Future. The Doubleday Religious Publishing Group. Kindle Edition.

Last week I read Peter Thiel’s book “Zero to One: Notes on Startups, or How to Build the Future” (Amazon link). It was a surprisingly easy but very engaging read. It’s sometimes difficult to find inspiration in business books, but Thiel’s background and stories are clear, understandable, and inspiring (at least for me).

Amy and I don’t have kids and neither of us are in school, but I am eternally fascinated by how the U.S. education system is evolving (or not, depending on your perspective), and how it impacts the U.S.’s ability to innovate. Thiel’s hypothesis that our education systems somewhat systematic production of “generalists” feeds our overall corporate and government cultures’ aversion to risk. Having a broad-based education is important to encourage and drive critical thinking, but I wonder if parents (and schools) encourage their students enough to pick one area they love and to go super deep in them, relative to all possible ‘broad’ areas.

I also really enjoyed the depth of his analysis about the cleantech bubble, and how he used it to support his points about building scalable, defensible business that also have a chance to make a lasting, global impact.

4/5 stars.

Quote

It’s tempting to take the quick wins early on. But there’s nothing sweeter than winning that first true, unaffiliated deal. It took us 15 months. Yes, 15 months. The rigor and measurement they put us through made us go back to the drawing board again and again, but because of that, our technology works better, and each deal after that was easier to win.

Excellent article by the CEO of LatticeEngines about the importance of finding early customers outside of the Valley, helping to validate your product using more “real world” users (i.e. not early adopters).

http://venturebeat.com/2014/09/28/why-its-critical-to-find-early-customers-outside-of-silicon-valley/

Quote

In some respects, it’s a little like taking the red pill and getting ejected from the Matrix. Everything you do in a startup makes a difference. No longer are you surrounded by a safety blanket world where you’re a small cog in a large machine.

“5 Reasons You Should Work At A Startup At Least Once” via TechCrunch.

I don’t see working at an early-stage technology company as “better” than working at a big company, but it is definitely very different.

One of my favorite parts (besides working so close to the product) is being able to shape the culture at a very fundamental level. Early in Klink’s life I ran a Team Values workshop to create our ten “Leadership Principles”. It was wonderful (and scary) to create our values from scratch.

Quote

Another challenge with lean dogma is that all that testing and prototyping can feel aimless, even to key members of the team. At Iodine, we spent a lot of time brainstorming and prototyping various features to test, which left some staff members unclear what we were working toward.

“When to Break the Lean Startup Rules” via Inc.com

Thomas makes several great points about adopting the lean startup methodology. As the team at Contactive has grown we always try to make clear to everyone why we’re doing certain in-app experiments or customer-driven development exercises. Sharing with the whole team the reasoning behind the individual experiments and their desired impact has helped significantly with the team’s cohesion around our core mission.

Link

Many of my friends and colleagues know I’m a time management nerd; I love calendaring, tasks, and flagging emails more than is healthy for a single person. One of my favorites is using calendar colors to audit my time each Friday.

Entrepreneurs Need Time Management Accelerators