I work at an HR/Payroll company with a phenomenal app that we put our blood, sweat, and tears into every single day. And every single day I clock in with Oracle Time and Labor. There's a legal reason for this and we do it for compliance. I'm guessing Stripe is in the same boat with this product despite its flaws.
When dogfooding, you have to be very careful that you don't end up in a bubble and only see your own needs as the priority.
There's a propensity for developers to start using their own products then changing it to suit themselves thinking that the regular users use the same product the same way. You end up with this mismatch of expectations and it can even get so bad that the developers don't believe the users who tell them that things need to change.
That gets repeated a lot but I have observed the opposite when you have a diversified company dogfooding an internal product that isn't strategic in their portfolio, or is targeted at a market segment that the company doesn't belong to. I have seen companies hamstring themselves by using a product that isn't the best offering for them or a poor technical fit, only because it is their own offering. Also, in the worst case, companies become develop tunnel vision in the market, because they don't regularly use the competition.
If you have a large, international software company targeting small to medium business customers in the US, dogfooding would be counterproductive. It would probably harm their strategic customer base by overcomplicating their product with features they don't need at the same time it slows the parent company down by using a product that's poor fit.
The idea behind dogfooding is that you get more/better feedback and more internal pressure to fix problems.
But the product team should already be getting feedback from a diverse set of customers. And if they're not, that's what needs to be fixed.
Dogfooding can also result in overprioritizing only your own company's product needs, and at worst the ultra specific issues that one particularly vocal VP is having, to the detriment of the overall customer base. (I've seen it happen way too many times.)
Companies should use the best tools for the job, not necessarily the ones they make themselves. If those are the same, then great. If not, then also great.
Maybe alternate between the leading product and your own so you can experience the same pain users do when they are forced to use the inferior choice after becoming accustomed to best-in-class.
Google has invested heavily in sound management in their rooms, and issued noise cancelling headphones to everyone awhile back they got to take home. That might explain some things.
But isn't Google Meet's background noise cancellation far superior to that of Zoom's? Or maybe I misunderstood your comment.
EDIT: I see above that others have claimed the opposite, but my experience has been different. I simply cannot take a call from a cafe in Zoom without complaints, but Meets is regularly tolerable, according to those I meet with.
If you use Zoom & Google Meet in the browser, the audio processing is likely pretty much the same (most of the filtering is built-in to the WebRTC stack). Zoom's native app has noticeably worse audio, but pretty much everything about it is worse anyway — it's just a pity you have to click through the "download the app" dark pattern to get to their better browser experience.
It makes sense to me - if Twilio undergoes a massive outage, do you want them to be unable to communicate as they try to fix it? So they use Zoom and Slack.
That can also work - but backups that aren't used can atrophy - and market segments could mean that what "works" for the company isn't what the company is selling.
It might be a goal to move everything internal (I believe Google is now using Google Apps internally, but they didn't for awhile, even after other businesses were).
However, I find it can get tiresome / has potential compilations.
Customer's can be terrible with incomplete, bad idea, and nonsensical requests. But sometimes internally you get the worst "Someone spilled some words into email that don't sense / no you don't actually want that / bro this is accounting software not Photoshop." situations that folks who are more familiar with the origination might make, but customer's might not make.
It takes an extra level of internal discipline to deal with dogfooding side effects at times IMO. Still, a good idea none the less.
A salesperson that I worked closely with like to use: “Drinking our own champagne.” I liked it enough I started using it though the engineer in me tends to be fine with “dogfooding”.
Oscar is the same. They no longer offer Oscar insurance to their employees. It's a liability to mandate that your coworkers information is stored in Production and accessed by Client Services.
The company where I work disallows us from using our own product because it would be considered a conflict of interest. Some co-workers say it's a federal regulation, but I've never seen that anywhere in print, so I suspect it's just a workplace rumor/justification.
I've had customers complain to my face that we tailor the products to our needs, and are surprised (and sometimes vocally disbelieve) that we don't use it, ourselves.
In certain industries, dogfooding is considered bad, and sometimes illegal.
Yeah most of the time I hear conflict of interest I don’t believe it at this point. Conflict of whose interest? If you used your own product wouldn’t you learn some issues that exist within it?
> If you used your own product wouldn’t you learn some issues that exist within it?
Isn't that the worry? Say a bug in your timekeeping software underreported hours worked and that lead to workers not being paid their agreed upon rate. When it goes to court you now have to prove that you didn't maliciously introduce the bug to save on employment costs, whereas if it is a third-party providing the software it's their problem. "Conflict of interest" is ultimately just another way to say "I don't want to assume the liability when things go sour". Nobody cares about conflict of interest when things go right.
>"Conflict of interest" is ultimately just another way to say "I don't want to assume the liability when things go sour".
No, it's not.
It's "malice is not a reasonable explanation for things going wrong". It only changes liability when it follows malice, what is much rarer than you seem to think.
It is also a way to assure people that you won't do something bad.
I'm not familiar with that definition. On the other hand, the Department of Defense explicitly says it happens "if the particular matter will have a direct and predictable effect on that interest". Predictable being "a real, as opposed to speculative possibility, that the matter will affect the financial interest".
The topic is centred around off-hand remarks made by someone as to why they aren't doing something (such as using their own product) and how, as pointed out by willio58, "conflict of interest" is used where there is no actual demonstration of conflict of interest. We're not talking about military rigor, as interesting as that subject may also be.
Again, "conflict of interest" is what people often say when they don't know if it will affect them, but don't want to take the risk. "Regulation requires it", as illustrated in the first comment, is what people say when caselaw actually demonstrates that they would be liable.
The fun thing about language is that it is fluid and can take many forms.
I'm working on the iOS/WatchOS app(s) for a major bank, and fortunately of course most of our staff uses it; too - because of course we bank with the bank we work for. (There's tangible benefits to a staff account, even those who have accounts elsewhere I'm willing to bet still do their primary banking with us.)
I've actually had an instance or two over my four years there where I discovered a bug in our PROD/App Store version myself; simply from using the software enough.
It's really unfortunate that this isn't the case for a lot of dev shops. Dogfooding is incredibly important to QA.
If the system happened to break in a way that was opportune for the employer but ripped off the employee, it's better to point fingers at Oracle than your own company.
The risk is the appearance that the company was deliberately ripping off employees. When the employer has created their own labor tracking software, it's easier for mistakes to look deliberate.
Maybe not a legal reason per se, but even if you have production data access appropriately locked down there will be some people who hold the keys to the kingdom. There's a lot more risk of people peeking at things they aren't supposed to when the data in question is about their own company, friends, coworkers.
