> That’s it. “Read 3 files.” Which files? Doesn’t matter. “Searched for 1 pattern.” What pattern? Who cares.
Product manager here. Cynically, this is classic product management: simplify and remove useful information under the guise of 'improving the user experience' or perhaps minimalism if you're more overt about your influences.
It's something that as an industry we should be over by now.
It requires deep understanding of customer usage in order not to make this mistake. It is _really easy_ to think you are making improvements by hiding information if you do not understand why that information is perceived as valuable. Many people have been taught that streamlining and removal is positive. It's even easier if you have non-expert users getting attention. All of us here at HN will have seen UIs where this has occurred.
Product management might be the worst meme in the industry. Hire people who have never used the product and don't think like or accurately represent our users, then let them allocate engineering resources and gate what ships. What could go wrong?
It should be a fad gone by at this point, but people never learn. Here's what to do instead: Find your most socially competent engineer, and have them talk to users a couple times a month. Just saved you thousands or millions in salaries, and you have a better chance of making things that your users actually want.
Good PM's are extremely good at understanding users, and use soft-skills to make the rest of the org focus on users more. I've worked with a couple, and they've added an enormous amount of value, sometimes steering teams of dozens of engineers in a more productive direction.
The problem is, it's hard to measure how good a PM is, even harder than for engineers. The instinct is to use product KPI's to do so, but especially at BigTech company, distribution advantages and traction of previous products will be the dominant factor here, and the best way of raising many product KPI's are actually user-hostile. Someone who has been a successful FAANG engineer who goes to a startup might lean towards over-engineering, but at least they should be sharp on the fundamentals. Someone who has been a successful FAANG PM might actually have no idea how to get PMF.
> Here's what to do instead: Find your most socially competent engineer, and have them talk to users a couple times a month
This is actually a great idea, but what will happen is this socially competent engineer will soon have a new full-time job gathering those insights, coalescing them into actionable product changes, persuading the rest of the org to adopt those changes, and making sure the original user insights make it into the product. Voila: you've re-invented product management.
But I actually think it's good to source PM's from people who've been engineers for a few years. PM's used to come from a technical background; Google famously gave entry-level coding tests to PM's well into the '10s. I dunno when it became more fashionable to hire MBA's and consultants into this role, but it may have been a mistake.
> Voila: you've re-invented product management.
This is a names vs. structure thing. For a moment, taboo the term product manager.
What I'm suggesting is a low risk way to see if an engineer has an aptitude for aligning the roadmap with what the users want. If they aren't great at it, they can go back to engineering. We also know for sure that they are technically competent since they are currently working as an engineer, no risk there.
The conventional wisdom (bad meme) is going to the labor market with a search term for people who claim to know what the users want, any user, any problem, doesn't matter. These people are usually incompetent and have never written software. Then hiring 1 and potentially more of the people that respond to the shibboleth.
If you want the first case, then you can't say "product manager" because people will automatically do the second case.
> What I'm suggesting is a low risk way to see if an engineer has an aptitude for aligning the roadmap with what the users want. If they aren't great at it, they can go back to engineering. We also know for sure that they are technically competent since they are currently working as an engineer, no risk there.
It doesn't have to be the most socially competent engineer to gather feedback. Having the engineering team sit with the target users gives so much insight into how the product is being used.
I once worked on an administrative tool at a financial institution. There were lots of pain points, as it started as a dev tool that turned into a monstrosity for the support staff. We asked to have a meeting with some reps who were literally 2 floors below us. Having the reps talk as they worked with the tool in real time over 1 hour was worth more than a year's worth of feedback that trickled in. It's one thing to solicit feedback. It's another to see how idiosyncrasies shape how products get used.
Putting on a PM hat is something I've been doing regularly in my engineering career over the last quarter century. Even as a junior (still in college!) at my first job I was thinking about product, in no small part because there were no PMs in sight. As I grew through multiple startups and eventually bigger brand name tech companies, I realized that understanding how the details work combined with some sense of what users actually want and how they behave is a super power. With AI this skillset has never been more relevant.
I agree your assessment about the value of good PMs. The issue, in my experience, is that only about 20% (at most) are actually good. 60% are fine and can be successful with the right Design and Engingeering partners. And 20% should just be replaced by AI now so we can put the proper guardrails around their opinions and not be misled by their charisma or whatever other human traits enabled them to get hired into a job they are utterly unqualified for.
I have worked with some really really good product managers.
But not lately. Lately it’s been people who have very little relevant domain expertise, zero interest in putting in the time to develop said expertise beyond just cataloguing and regurgitating feedback from the customers they like most on a personal level, and seem to mostly have only been selected for the position because they are really good at office politics.
But I think it’s not entirely their fault. What I’ve also noticed is that, when I was on teams with really elective product managers, we also had a full time project manager. That possibly freed up a lot of the product manager’s time. One person to be good at the tactical so the other can be good at the strategic.
Since project managers have become passé, though, I think the product managers are just stretched too thin. Which sets up bad incentive structures: it’s impossible to actually do the job well anymore, so of course the only ones who survive are the office politicians who are really good at gladhanding the right people and shifting blame when things don’t go well.
There are individuals who have good taste for products in certain domains. Their own preferences are an accurate approximation for those of the users. Those people might add value when they are given control of the product.
That good taste doesn't translate between domains very often. Good taste for developer tools doesn't mean good taste for a video game inventory screen. And that's the crux of the problem. There is a segment of the labor market calling themselves "product manager" who act like good taste is domain independent, and spread lies about their importance to the success of every business. What's worse is that otherwise smart people (founders, executives) fall for it because they think hiring them is what they are supposed to do.
Over time, as more and more people realized that PM is a side door into big companies with lots of money, "Product Manager" became an imposter role like "Scrum Master". Now product orgs are pretty much synonymous with incompetence.
Taste is pretty transferable, I think what you're talking about is intuition. The foundations of intuition are deeply understanding problems and the ability to navigate towards solutions related to those problems. Both of these are relatively domain-dependent. People can have intuition for how to do things but lack the taste to make those solutions feel right.
Taste on the other hand is about creating an overall feeling from a product. It's holistic and about coherence, where intuition is more bottom-up problem solving. Tasteful decisions are those that use restraint, that strike a particular tone, that say 'no' when others might say 'yes'. It's a lot more magical, and a lot rarer.
Both taste and intuition are ultimately about judgment, which is why they're often confused for one another. The difference is they approach problems from the opposite side; taste from above, intuition from below.
I agree with your assessment otherwise, PM can be a real smoke screen especially across domain and company stage.
> There is a segment of the labor market calling themselves "product manager" who act like good taste is domain independent
That’s definitely one of the biggest problems with product management. The delusion that you can be an expert at generic “product”.
We used to have subject matter experts who worked with engineers. That made sense to me.
The proportion of "really good" PMs on product engineering teams has to be less than 0.1%.
The counter to that is "the proportion of 'really good engineers' to product engineering teams has got to be in the single digits," and I would agree with that, as well.
The problem is what is incentivized to be built - most teams are working on "number go up?" revenue or engagement as a proxy to revenue "problems." Not "is this a good product that people actively enjoy using?" problems.
Just your typical late-stage capitalism shit.
> Hire people who have never used the product and don't think like or accurately represent our users
In most of my engineering jobs, the Product Managers were much closer to our users than the engineers.
Good product managers are very valuable. There are a lot of bad ones carrying the product manager title because it was viewed as the easy way to get a job in tech without having to know how to program, but smart companies are getting better at filtering them out.
> Find your most socially competent engineer, and have them talk to users a couple times a month
Every single time I've seen this tried, it turns into a situation where one or two highly vocal customers capture the engineering team's direction and steer the product toward their personal needs. It's the same thing that happens when the sales people start feeding requests from their customers into the roadmap.
I've worked with some really good product managers, as well as some total duds. They all talked to customers on a regular basis. There is so much more to the job than that. Every time I think I understand a product manager's job completely, I see one fail in a way I hadn't thought about.
For example, I had one product manager who made themselves irrelevant because they wouldn't work with sales. The company needed to sell the product to pay us, and sales talked with potential buyers about what might swing their purchase decision and what they would pay extra for. Since the PM only talked to users and ignored sales when doing product design and product roadmaps, the way sales input got integrated into product development is that we frequently got top-down directives from management to prioritize one-off requests from sales over the roadmap. Needless to say, this didn't lead to a cohesive and easy-to-understand product.
Before I saw that PM failing, I hadn't thought about the relationship between product and sales.
This sentiment is going exactly against the trend right now. AI coding is making technically minded product manager's MORE powerful not less. When/if coding just because your ability to accurately describe what you want to build, the people yielding this skill are the ones who understand customer requirements, not the opposite.
> Find your most socially competent engineer,
These usually get promoted to product management anyway, so this isn't a new thought.
> This sentiment is going exactly against the trend right now.
It's not.
Engineers are having more and more minutia and busy work taken off their plate, now done by AI. That allows them to be heads up more often, more of their cognitive capacity is directed towards strategy, design, quality.
Meanwhile, users are building more and more of their own tools in house. Why pay someone when you can vibe code a working solution in a few minutes?
So product managers are getting squeezed out by smarter people below them moving into their cognitive space and being better at solving the problems they were supposed to be solving. And users moving into their space by taking low hanging fruit away from them. No more month long discussions about where to put the chart and what color it should be. The user made their own dashboard and it calls into the API. What API? The one the PM doesn't understand and a single engineer maintains with the help of several LLMs.
If it's simple and easy: the user took it over, if it's complex: it's going to the smartest person in the room. That has never been the PM.
> if it's complex: it's going to the smartest person in the room. That has never been the PM.
Yet the PM always has the last say on what goes in the product, NOT the engineer. Funny how that works...
None of your conclusions are consistent with experience (interviewed 900+ SaaS management teams)
> people who have never used the product and don't think like or accurately represent our users
I agree completely that these are the important qualifications to be setting direction for a product.
> Find your most socially competent engineer, and have them talk to users a couple times a month.
This doesn't necessarily follow from the above, but in Anthropic's case specifically, where the users are software engineers, it probably would have worked better than whatever they have going on now.
In general, it's probably better to have domain experts doing product management, as opposed to someone who is trained in product management.
> your most socially competent engineer
Unfortunately, he’s already two of our SEs and the CTO and we’re starting to run low on coders.
What are we going to do when we need a customer success manager or a profserv team?
Product managers are fooling themselves if they think they can "improve the user experience" for developers -- developers can't agree on the simplest things such as key bindings (vim, emacs) or identation (tabs, spaces).
Make the application configurable. Developers like to tinker with their tools.
> under the guise of 'improving the user experience' or perhaps minimalism
I think we can be more charitable. Don't you see, even here on HN, people constantly asking for software that is less bloated, that does fewer things but does them better, that code is cost, and every piece of complexity is something that needs to be maintained?
As features keep getting added, it is necessary to revisit where the UX is "too much" and so things need to be hidden, e.g. menu commands need to be grouped in a submenu, what was toolbar functionality now belongs in a dialog, reporting needs to be limited to a verbose mode, etc.
Obviously product teams get it wrong sometimes, users complain, and if enough users complain, then it's brought back, or a toggle to enable it.
There's nothing to be cynical about, and it's not something we "should be over by now." It's just humans doing their best to strike the balance between a UX that provides enough information to be useful without so much information that it overwhelms and distracts. Obviously any single instance isn't usually enough to overwhelm and distract, but in aggregate they do, so PM's and designers try to be vigilant to simplify wherever possible. But they're only human, sometimes they'll get it wrong (like maybe here), and then they fix it.
Every single website on the internet just says "whoopsie doodle, me made an oopsie" instead of just telling me what the problem is. This so-called mistake is so widespread that it has been the standard for at least a decade.
I agree it's a mistake, but I don't believe that it's viewed that way by anyone making the decision to do it.
You dont expose error details to the user for security reasons, even though it does indeed make the user experience worse.
I understand not exposing a full stack trace, but I don't see any excuse to not even expose a googleable error code. If me having an error code makes your product insecure, then you have a much bigger problem.
I show the stack trace on AGPL projects. Why hide what they can already see for themselves?
The reason I see is that it might expose the value of secret keys or other sensitive variables. But if you are certain it won't happen, then yes
This also shifts over time - new users, especially people sophisticated in the field your tool is addressing, need to be convinced the product is doing what they believe it should be doing, and want to see more output from it. They may become comfortable with the product over time and move further up the trust/abstraction ladder, but at the beginning, verbose output is a trust-building mechanism.
We are currently extremely blessed on the companies new product, because they have placed a curious and open-minded product manager and a curious and open-minded ux-designer in charge of the administrative interface. Over half a year, those two have gained the trust of several admins within the company, all of them with experience of more than 10 years.
We have by now taught them about good information density.
Like, the permission pages, if you look at them just once, kinda look like bad 90s UIs. They throw a crapton of information at you.
But they contain a lot of smart things you only realize when actually using it from an admin perspective. Easy comparison of group permissions by keeping sorting orders and colors stable, so you can toggle between groups and just visually match what's different, because colors change. Highlights of edge cases here and there. SSO information around there as well. Loads of frontloaded necessary info with optional information behind various places.
You can move seriously fast in that interface once you understand it.
Parts of the company hate it for not being user friendly. I just got a mail that a customer admin was able to setup SSO in 15 minutes and debug 2 mapping issues in another 10 and now they are production ready.
> Many people have been taught that streamlining and removal is positive.
Over the past ten years or so the increasing de-featuring of software under the guise of 'simplification' has become a critical issue for power users. For any GUI apps which have a mixed base of consumer and power users, I mostly don't update them anymore because they're as likely to get net worse vs better.
It's weird that companies like MSFT seem puzzled why so many users refuse to update Windows or Office to major new feature versions.
What in Office has been a degradation? Just curious. I mostly agree about Windows.
I am so glad to hear there are working PMs who are aware of this (and if you’re hiring it makes me more interested in considering your employer).
Well, some who start as developers don't truly see users as stakeholders, sometimes not even remotely, and they often aren't assisted to change that view. While it feels astonishing in direct encounters, on the sliding scale of "are you a person that sees other people as stakeholders in general", many developers can be close to the "no" end of that scale. So not necessarily an institutional view.
I think it might also come down to UI churn. Sprint over? What to do next? Everything is always moving because people have nothing meaningful to do.
> Cynically, this is classic product management: simplify and remove useful information under the guise of 'improving the user experience' or perhaps minimalism if you're more overt about your influences.
Cynically, it's a vibe coded mess and the "programmers" at Anthropic can't figure out how to put it back.
More cynically, Anthropic management is trying to hide anything that people could map to token count (aka money) so that they can start jiggling the usage numbers to extract more money from us.
Fairly cynical indeed. Though I must admit that Anthropic's software - not the models, the software they build - seems to be generally plagued by quality issues. Even the dashboard is _somehow_ broken most of the time, at least whenever I try to do something.
Or is this PM and executive management aiming for the no and low code users? That would fit the zeitgeist especially in the tech C level and their sales pitch to non-tech C levels.
Also product manager here.
Not at all cynically, this is classic product management - simplify by removing information that is useful to some users but not others.
We shouldn't be over it by now. It's good to think carefully about how you're using space in your UI and what you're presenting to the user.
You're saying it's bad because they removed useful information, but then why isn't Anthropic's suggestion of using verbose mode a good solution? Presumably the answer is because in addition to containing useful information, it also clutters the UI with a bunch of information the user doesn't want.
Same thing's true here - there are people who want to see the level of detail that the author wants and others for whom it's not useful and just takes up space.
> It requires deep understanding of customer usage in order not to make this mistake.
It requires deep understanding of customer usage to know whether it's a mistake at all, though. Anthropic has a lot deeper understanding of the usage of Claude Code than you or I or the author. I can't say for sure that they're using that information well, but since you're a PM I have to imagine that there's been some time when you made a decision that some subset of users didn't like but was right for the product, because you had a better understanding of the full scope of usage by your entire userbase than they did. Why not at least entertain the idea that the same thing is true here?
Simplification can be good---but they've removed the wrong half here!
The notifications act as an overall progress bar and give you a general sense of what Claude Code is doing: is it looking in the relevant part of your codebase, or has it gotten distracted by some unused, vendored-in code?
"Read 2 files" is fine as a progress indicator but is too vague for anything else. "Read foo.cpp and bar.h" takes almost the same amount of visual space, but fulfills both purposes. You might want to fold long lists of files (5? 15?) but that seems like the perfect place for a user-settable option.
> "Read 2 files" is fine as a progress indicator but is too vague for anything else. "Read foo.cpp and bar.h" takes almost the same amount of visual space, but fulfills both purposes.
Now this is a good, thoughtful response! Totally agree that if you can convey more information using basically the same amount of space, that's likely a better solution regardless of who's using the product.
> It requires deep understanding of customer usage to know whether it's a mistake at all
Software developers like customizable tools.
That's why IDEs still have "vim keybindings" and many other options.
Your user is highly skilled - let him decide what he wants to see.
There are a lot of Claude Code users who aren't software developers. Maybe they've decided that group is the one they want to cater to? I recognize that won't be a popular decision with the HN crowd, but that doesn't mean it's the wrong one.
I fully agree with you on almost everything you wrote in this thread, but I’m not sure this is the right answer. I myself currently spend a lot of time with CC and belong to that group of developers who don’t care about this problem. It’s likely that I’m not alone. So it doesn’t have to be the least professional audience they serve with this update. It’s possible that Anthropic knows what are they doing (e.g. reducing level of detail to simplify task of finding something more important in the output) and it’s also possible that they are simply making stupid product decisions because they have a cowboy PM who attacks some OKR screaming yahoo. We don’t know. In the end having multiple verbosity levels configured with granularity similar to java loggers would be nice.
Oh totally - I'm definitely not saying that they made the decision to cater to non-dev users, just that it's a possibility. Totally agree with you that at the end of the day, we haven't the foggiest idea.
Yeah, I made a similar point about the tone of ChatGPT responses; to me, I can't imagine why someone would want less information when working and tuning an AI model. However, something tells me they actually have hard evidence that users respond better with less information regardless of what the loud minority say online, and are following that.
100%. Metrics don't lie. I've A/B tested this a lot. Attention is a rare commodity and users will zone out and leave your product. I really dislike this fact
Then why is the suggestion to use verbose mode treated as another mistake?
The user is highly skilled; let them filter out what is important
This should be better than adding an indeterminate number of toggles and settings, no?
does claude code let me control whats output when?
verbose i think puts it on the TUI and i cant particularly grep or sed on the TUI
Developer> This is important information and most developers want to see it.
PM1> Looks like a PM who is out of touch with what the developers want. Easy mistake to make.
PM2> Anthropic knows better than this developer. The developer is probably wrong.
I don't know for sure what the best decision is here, I've barely used CC. Neither does PM1 nor PM2, but PM2 is being awfully dismissive of the opinion of a user in the target audience. PM1 is probably putting a bit too much weight on Developer's opinion, but I fully agree with "All of us... have seen UIs where this has occurred." Yes, we have. I personally greatly appreciate a PM who listens and responds quickly to negative feedback on changes like this, especially "streamlining" and "reducing clutter" type changes since they're so easy to get wrong (as PM1 says).
> It's good to think carefully about how you're using space in your UI and what you're presenting to the user.
I agree. It's also good to have the humility to know that your subjective opinion as someone not in the target audience even if you're designing the product is less informed in many ways than that of your users.
----
Personally, I get creeped out by how many things CC is doing and tokens it's burning in the background. It has a strong "trust me bro" vibe that I dislike. That's probably common to all agent systems; I haven't used enough to know.
> PM2> Anthropic knows better than this developer. The developer is probably wrong.
Nope! Not what I said. I specifically said that I don't know if Anthropic is using the information they have well. Please at least have the courtesy not to misrepresent what I'm saying. There's plenty of room to criticize without doing that.
> It's also good to have the humility to know that your subjective opinion as someone not in the target audience even if you're designing the product is less informed in many ways than that of your users.
Ah, but you don't know I'm not the target audience. Claude Code is increasingly seeing non-developer users, and perhaps Anthropic has made a strategic decision to make the product friendlier to them, because they see that as a larger userbase to target?
I agree that it's important to have humility. Here's mine: I don't know why Anthropic made this decision. I know they have much more information than me about the product usage, its roadmap and their overall business strategy.
I understand that you may not like what they're doing here and that the lack of information creeps you out. That's totally valid. My point isn't that you're wrong to have that opinion, it's that folks here are wrong to assume that Anthropic made this decision because they don't understand what they're doing.
> Personally, I get creeped out by how many things CC is doing and tokens it's burning in the background. It has a strong "trust me bro" vibe that I dislike.
100% this.
It might be convenient to hide information from non-technical users; but software engineers need to know what is happening. If it is not visible by default, it should be configurable via dotfiles.
They know what people type into their tools, but they don't know what in the output users read and focus on unless they're convening a user study or focus group.
I personally love that the model tells me what file it has read because I know whether or not it's headed in the generally right direction that I intended. Anthropic has no way of knowing I feel this way.
But you have no idea if they've convened user study or focus groups, right?
I'll just reiterate my initial point that the author of the post and the people commenting here have no idea what information Anthropic is working with. I'm not saying they've made the right decision, but I am saying that people ought to give them the slightest bit of credit here instead of treating them like idiots.
> You're saying it's bad because they removed useful information, but then why isn't Anthropic's suggestion of using verbose mode a good solution?
Because reading through hundreds of lines verbose output is not a solution to the problem of "I used to be able to see _at a glance_ what files were being touched and what search patterns were being used but now I can't".
Right, I understand why people prefer this. The point was that the post I was responding to was making pretty broad claims about how removing information is bad but then ignoring the fact that they in fact prefer a solution that removes a lot of information.
I'm sure the goal is that reading files is something you debug, not monitor, like individual network requests in a browser.
Product management --and managers-- can be, shall we say, interesting.
I was recently involved with a company that wanted us to develop a product that would be disruptive enough to enter an established market, make waves and shock it.
We did just that. We ran a deep survey of all competing products, bought a bunch of them, studied absolutely everything about them, how they were used and their users. Armed with that information, we produced a set of specifications and user experience requirements that far exceeded anything in the market.
We got green-lit to deliver a set of prototypes to present at a trade show. We did that.
The prototypes were presented and they truly blew everyone away. Blogs, vlogs, users, everyone absolutely loved what we created and the sense was that this was a winning product.
And then came reality. Neither the product manager nor the CTO (and we could add the CEO and CFO to the list) had enough understanding and experience in the domain to take the prototypes to market. It would easily have required a year or two of learning before they could function in that domain.
What did they do? They dumbed down the product specification to force it into what they understood and what engineering building blocks they already had. Square peg solidly and violently pounded into a round hole.
The outcome? Oh, they built a product alright. They sure did. And it flopped, horribly flopped, as soon as it was introduced and made available. Nobody wanted it. It was not competitive. It offered nothing disruptive. It was a bad clone of everything already occupying space in that ecosystem. Game over.
The point is: Technology companies are not immune to human failings, ego, protectionism/turf guarding, bad decisions, bad management, etc.
When someone says something like "I am not sure that's a good idea for a startup. There's competition." My first though is: Never assume that competitors know what they are doing, are capable and always make the right decisions without making mistakes. You don't always need a better product, you need better execution.
Replace the C levels with AI. The C suite is am impediment to innovation and progress. They are the office politics mentioned in this entire thread. The person with the vision and the strategy is a random person out there that doesn't even work for your company. Hell, you could have done it.
> The point is: Technology companies are not immune to human failings, ego, protectionism/turf guarding, bad decisions, bad management, etc.
They only accidentally succeed in spite of those things. They have those things more than existing businesses precisely because having too much money masks the pressures that would force solid execution and results. When you have 80% profit margins, you can show up drunk.
Paranoid schizo here: This actually seems to be a way to flag users into whales and fishes, and to treat the whales as marks to dumb down their entire needs of LLM value.
People who toggle debug will get "full" access and those who dont care, probably won't notice if their LLM us is degraded.
It seems a pure market segmenting prior to a "shrinkflation" approach to cost management.
[dead]
Product managers aren’t needed anymore.
First they came for the product managers, and I said nothing, because I was a coder, and we're invincible and can do everything and also deliver value unlike all those other slackers, so they'd never come for us.