Your post strikes me as very emotionally invested. My first piece of advice would be to take a step back for a moment and look at the problem from a different perspective.
Sure, the voice may sound ugly - but as UX professionals, our responsibility is not to the aesthetic beauty of a project. Rather, our responsibility is to ensure that a project efficiently serves its intended purpose.
In a situation like this, you need to take the qualitative judgements out of the equation for a moment and ask a few questions.
1.) Does the voice prohibit people from efficiently completing their tasks?
2.) Does the voice affect the number of users who would use or buy your product?
3.) Does the voice affect the length of time someone would use the product?
If you’ve answered “no” to all of these questions, the chances are very high that you do not have a UX problem.
This is the important distinction between UX and UI work, and what sets us apart from visual designers in general. A UX professional, at their core, should care less about style and more about function and efficiency. For us, the point at which aesthetics matter is when it begins to affect usability.
If there is no affect on usability, there may be an aesthetic issue, but not one that needs to be addressed from our perspective.
From what you’ve told me so far, none of these seem to be the case - or at least you didn’t test for them. It sounds like you may need to do some additional testing to see what effect - if any - the voice is having on usability.
If you discover there is an effect on usability, you need to ask a few additional questions before pushing for a change.
4.) Does the technology exist to support other voice choices?
5.) Does the budget exist to implement the changes?
6.) Does the bandwidth exist to work on the changes?
If you answer “no” to any of these questions, you’re done. Pack it up. Walk away until the situation changes.
From the information you’ve provided, it sounds like you may have a “no” that you haven’t uncovered to one of these three questions. The type of pushback you describe is very common in these situations, and I’d encourage you to do more digging on these three questions before you jump back into more testing.
As a startup, I think it’s important to remember that your company is likely building a Minimum Viable Product (MVP). The truth about MVPs is that while almost nothing about them is ideal, a successful MVP identifies the most important areas for future product improvement while also allowing the user to accomplish their task.
Your role in all of this is to identify what those areas for improvement are, so that the business side of things can work on prioritizing those requirements with other business demands. You won’t get everything you want, and this is a great example of that.
