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.
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.
"you never have to find the documentation, or learn how to use your API."
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.
this is not about classic QA, this is about "design bugs", that one extra annoying step in a workflow or missing safety dialog that doesn't warn you of a irreversible change.
of course this works particularly well as that product fits into our workflow. dogfooding becomes a bit unrealistic once it is about a product only your customers will really use.
There was a submission a while ago  about why you'd just read the code is documentation is not good enough or simply inexistant. When working with your company's product you often have direct access to the source code or the developers, and you can solve in minutes problems that would cause days and days of pone/email back and forth with the support team.
You'll understand there is a problem, but you may not have the same sense of urgency since it was so fast to solve.
Dog food is not dangerous, you just have to include other foods in your diet to complement it.
That's why Microsoft doesn't use it's own source control solution (SourceSafe) internally. It just doesn't cut it.
That's why Apple doesn't design the next iPad on an iPad.
That's why McDonald's executes don't hold their business meetings in a McDonald's, to close important international deals etc.
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."
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?
That is a formula for disaster.
But the very same argument (for not using a disastrous tool) applies for the continual marginal improvement that better tools can give you.
It makes ZERO sense to 'bootstrap' any tool using that tool except for some special exceptions.
That doesn't mean you shouldn't test it :)
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.
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.
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.
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.
I thus consider all dogfooding unethical that is not done by somebody who has, or is provided with, a lot of influence on the product.
Apple doesn't use it's most mass-market product, the iPad, to develop the next iPad. But it does use Macs, probably even where they're slightly worse than PC's. If some kind of developer at Apple really needs a Laptop with 64 GB of RAM they probably can't get away with it without a very good justification.
This does, however, have objective benefits as far as company image, esprit de corps, promotion, etc.
But Apple might be a special case.
I guess it comes down to whether you're building just a tool or a lifestyle image.
If you're building a lifestyle product, then sure homogeneity or self-promotion has a huge objective value to the company.
They _really_ should. I have a feeling they dont use it at all for actual task (except for testing out if something works)
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.
I think the point of the article was that that is impossible. Your real consumers have issues you yourself simply cannot have. Whenever something about the product is bugging you, you fix it. The customer is depending on you for everything.
Hell, you probably don't even have 50 employees, let alone a reason to have all 50 tax codes in your time charging system.
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.
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.
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.
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!)
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 is 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.
Reaching out to the right people here means free advertising and loyalty, in addition to fixing the problems you don't come across internally.
"would we pay for this?".... and as a cash strapped startup we said no.
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.
But remember that the rare and beautiful insight is of a problem they didn't know they had.