I've been on the other side of this as a PM, and it's tough because you can't always say what you want to, which is roughly: This product is used by a lot of users with a range of use cases. I understand this change has made it worse for you, and I'm genuinely sorry about that, but I'm making decisions with much more information than you have and many more stakeholders than just you.

> What majority? The change just shipped and the only response it got is people complaining.

I'll refer you to the old image of the airplane with red dots on it. The people who don't have a problem with it are not complaining.

> People explained, repeatedly, that they wanted one specific thing: file paths and search patterns inline. Not a firehose of debug output.

Same as above. The reality is there are lots of people whose ideal case would be lots of different things, and you're seeking out the people who feel the same as you. I'm not saying you're wrong and these people don't exist, but you have to recognize that just because hundreds or thousands or tens of thousands of people want something from a product that is used by millions does not make it the right decision to give that thing to all of the users.

> Across multiple GitHub issues opened for this, all comments are pretty much saying the same thing: give us back the file paths, or at minimum, give us a toggle.

This is a thing that people love to suggest - I want a feature but you're telling me other people don't? Fine, just add a toggle! Problem solved!

This is not a good solution! Every single toggle you add creates more product complexity. More configurations you have to QA when you deploy a new feature. Larger codebase. There are cases for a toggle, but there is also a cost for adding one. It's very frequently the right call by the PM to decline the toggle, even if it seems like such an obvious solution to the user.

> The developer’s response to that?

> I want to hear folks’ feedback on what’s missing from verbose mode to make it the right approach for your use case.

> Read that again. Thirty people say “revert the change or give us a toggle.” The answer is “let me make verbose mode work for you instead.”

Come on - you have to realize that thirty people do not in any way comprise a meaningful sample of Claude Code users. The fact that thirty people want something is not a compelling case.

I'm a little miffed by this post because I've dealt with folks like this, who expect me as a PM to have empathy for what they want yet can't even begin to considering having empathy for me or the other users of the product.

> Fucking verbose mode.

Don't do this. Don't use profanity and talk to the person on the other side of this like they're an idiot because they're not doing what you want. It's childish.

You pay $20/month or maybe $100/month or maybe even $200/month. None of those amounts entitles you to demand features. You've made your suggestion and the people at Anthropic have clearly listened but made a different decision. You don't like it? You don't have to use the product.

I know product managers in particular hate it but, especially with professional software, when you gave lots of users you have to make things configurable and live with maintaining the complexity.

The alternatives are alienating users or dumbing down the software, both of which are worse for any serious professional product.

I don't think it's fair to say that product managers hate it. There are a lot of product managers and a lot of kinds of software. I've worked on complex enterprise software and have added enormous amounts of complexity into my products when it made sense.

> The alternatives are alienating users or dumbing down the software, both of which are worse for any serious professional product.

I disagree that this is universally true. Alienating users is very frequently the right call. The alienated users never feel that way, but it's precisely the job of the PM to understand which users they want to build the product for and which ones they don't. You have to be fine alienating the latter group.