[Jemaclus]

I think you're taking my post a little bit literally. The "customer" doesn't always have to be the end-either. If a QA member comes to me and says they found a bug, I also should not just go back to them and say "It works for me" and then not proceed any further. (Although, in defense of the literal interpretation of "customer", for small startups, devs often double as customer support for engineering-related issues.)

[mak4athp]

There's a real difference between a Customer and a QA member, though. You can't demand leave the responsibility to make a good report on a customer because they're external to your organization. But you can do exactly that with the QA member because it's precisely their job to identify and describe defects.

You can indeed say "it works for me" to the QA member, and it's their responsibility to identify the environment or series of steps that reliably produce a failure. From there on out, you can no longer say "it works for me" because it doesn't: you finally know how to make it fail and now it's your job to figure out why.

And like I said, nascent startups with just a few founding engineers are a necessary exception. But the QA or Customer Support hire should come very early! Too many organizations stall on that, and they waste tons of opportunity and productivity by doing so.