The dangers of eating dogfood

<i>"Dog fooding makes you lazy, and makes you less likely to understand your customer."</i><p>I don't understand how dog fooding makes you lazy. Using your own products doesn't stop you from talking to your customers. If the company leadership cares about what the customers think, then someone will find the time to talk with them.<p>And using your own products has many advantages, such as forcing you to confront bugs and annoying user interfaces and performance problems and poor documentation. It's definitely something that you should do, assuming your products can serve some useful function in your company.<p><i>"you never have to find the documentation, or learn how to use your API."</i><p>Documentation is an issue you'll face even with your own products. Unless your company is very tiny, there will be employees, even developers, who aren't intimately familiar with how to use all the advanced features of your products to solve real-world problems.

I think this article makes a good point, but the way it's worded makes it easy to disagree with. Using your own product is better than nothing, but alone it's not enough to understand the relationship customers will have with it.<p>Dog food is not dangerous, you just have to include other foods in your diet to complement it.

The points are good, but missing the elephant in the room: when you are competing with the best companies in the world in software (where the marginal cost is 0), you simply can't afford to compete using anything less than the best stuff. You need to go 'deep' (specialist), rather than 'wide' (mass-market) when it comes to the tools you yourself use. (Even though what you're creating is probably itself wide.)<p>That's why Microsoft doesn't use it's own source control solution (SourceSafe) internally. It just doesn't cut it.<p>That's why Apple doesn't design the next iPad on an iPad.<p>That's why McDonald's executes don't hold their business meetings in a McDonald's, to close important international deals etc.<p>You just can't afford to. This guy says "At BugHerd, we build a project management tool for web projects. BugHerd is, itself, a web project."<p>Imagine you just wrote the first version, and you realize that it sucks. How will you track the transition to the second, non-sucky version? If you're using project management software - the one you've just written - that by your own admission sucks?<p>That is a formula for disaster.<p>But the very same argument (for not using a disastrous tool) applies for the continual marginal improvement that better tools can give you.<p>It makes ZERO sense to 'bootstrap' any tool using that tool except for some special exceptions.<p>That doesn't mean you shouldn't test it :)<p>--------<p>Some exceptions:<p>1) The tool is the only one that exists. Even a buggy version that takes 10x longer to produce a halfway decent result would still be the only thing that exists.<p>Perhaps the first compiler was like this: i.e. the first time someone translated paper into a compiler, it made sense to use that buggy version to recompile itself with optimizations. But that's because it was the only one to exist.<p>2) if you are now the best on the market, period. So, if you so happened to create the best tool on the market, sure, go ahead and use it.<p>3) if you are on par with the best. This is tricky. You can learn a lot from the competition. It hink in this case you should use both. Gimp might be 'on par' wtih photoshop, but I really think that Gimp developers should use both on a daily basis. It's amazing what kind of a perspective access to being an occasional user of your competition gives you.

And that's why you only buy human-grade dog food if you care about your dog. (Yes, I read the article)<p>I disagree with the article and think this is one of the best ways of actually understanding your product and how well it works in the real world. Don't test it like a developer. Use it like a consumer.

Insipid.<p>Myopic view of your product? Then also use competing products to see what they do. And talk to customers. A lot. Golly, understanding that all of your customers aren't you seems like it's not a huge leap.<p>Figuring out pricing models? Well, I'm just a dumb engineer so I assume someone else knows about that but I'd guess that "not free" is a good starting point and you can probably haggle and talk with people from there.<p>I would hazard a guess that everyone wants a better bug tracker/project manager/et al. I would also hazard a guess that what everyone wants is a totally different thing than what everyone else wants. We've had these technical "solutions" for decades now and they all suck.<p>They suck because the actual problems aren't technical. They're people problems. How should you track all tghe whatzits in a way that makes everyone happy enough to work effectively but also accountable? That's an ape problem and not a technical one. The solution is in ape-space and not tech-space. Look to Skinner and not Knuth for those answers. (And please don't look to Skinner - creepy!)

By the last paragraph, I get what he's saying (too many companies build something they'd never pay for in hopes that there's an audience that will), but I think he's arguing two different - but vital - aspects of testing.<p>There's dogfooding and there's finding users at all levels of experience (both in internet proficiency and experience with the type of software/service you've built) who have little/no incentive to use your platform over the competition. The best apps I have come across have had their community managers leverage me and ask repeatedly for my feedback and how to make things better. What else am I seeing going on in the market? How intuitive <i>is</i> that action? If this tool didn't exist tomorrow, where would I go and why? If a user isn't willing to take the time to answer these questions, move on to the next person.<p>Reaching out to the right people here means free advertising and loyalty, in addition to fixing the problems you don't come across internally.

<p><pre><code> "would we pay for this?".... and as a cash strapped startup we said no. </code></pre> Thank you! I'd come to the same conclusion myself - it's reassuring to hear someone else say it.<p>The important thing is to see from your customer's point of view. Dog-fooding is just one technique that helps that. There's also: listen to them (and facilitate that); imagine a day-in-the-life; work in their industry; visit them; watch them using your product.<p>But remember that the rare and beautiful insight is of a problem they didn't know they had.

"using some small slice of functionality" Knowing when your code breaks is invaluable and trumps any potential big picture problems. You can have the big picture correct but it is worth nothing if your product doesn't exist because your code doesn't work.

I totally agree with your article.