Posted by tosh 7 hours ago
> The product changes are primarily additive... I think the reasons for this is that it's lot easier to add new capabilities, than rethink existing capabilities.
This is perhaps the biggest difficulty in Product, and the core of the Innovator's Dilemma. Changes or removals, fundamentally, fuck with how somebody uses your product. It is very, very rare to ship a feature - something that inspired somebody in Product, got all the internal stakeholders to sign off, including getting leadership to fund it - and have nobody use it, so that it isn't controversial to remove it; even then, removing it competes with resources for adding something else, so it's still controversial to remove it. When somebody uses something that you fucked with, you risk them churning, that simple.
Coming up with good features to add is not hard. Everybody and their grandma has ideas. A simple spreadsheet can count which ones are most popular and are proposed most often. This should not, in and of itself, dictate what you build next, and bad Product leadership looks like following mass diktat.
Good Product leadership is not afraid of the consequences of fucking with the user. Good Product leadership has both the courage to reformulate the offering and gets the reformation right, because they intuitively understand the user, the domain, and where they sit in it, better than anyone else. They ship stuff that fucks with you because they understand the difference between the bad kind of being fucked with, and the good kind. And if you churn, then you churn. So be it. You can't actually make everyone happy all the time, so focus on making happy the people who get it, and accept losing the rest. That's also easier to say when you have $100k in ARR with $1k ACV, compared to $5m in ARR with $2.5m ACV.
Good Product leadership is rare because good leadership is rare. AI has nothing to do with it.
I can count on one hand the number of PMs in my career who understood the platforms they worked on outside of their extremely narrow domain - and even then that narrow specificity was often a distorted lens that came from the customer interviews they did that they remembered or found evocative. And this just gets worse the further up the chain you go.
Engineering knows that the best way to improve a product is to dogfood it. Nothing beats regular lived experience long enough for the human brain to start its pattern recognition. But nobody wants to eat their own dogfood, they want the kibble from another brand that has all the shiny marketing attached.
If I had my way, I'd stick PMs into shadowing sessions with Support on the regular for sentiment analysis. No relying on Support management to relay upwards trends - there's far too few Support managers worth their salt.
But they burn out quick because the know the pain is there
I somewhat agree with you, and think you're right at least part of the time. The main disagreements I have are (a) dogfooding is not a panacea; it can result in products that are built for the user who pays the least rather than for the wider market, and (b) too often, Product is simply not hired from the market. Product rarely works when the person coming into the role was a software engineer who got an MBA, unless the product is also used by software engineers. I can't imagine trying to lead Product for, say, Excel, without a background as an accountant or banker, who lived with the problem day-in-day-out and has strong opinions about what the solution looks like.
Yeah, look at modern AAA games vs. small indie games.
It used to be taken as a given that the software houses one respected didn't actually work like that. Steve Jobs and Johnny Ive yelling at their minions about user experience. Even Bezos sending the dreaded question mark. Great software was the work of a team translating an auteur's personal vision into software... while the blue chips like IBM churned out useful but soulless software by the corporate method above
Somehow most people don't seem to believe this anymore, despite the repeated failure of corporate environments to produce better software.
As with most creative pursuits, the best things happen when there's a clear point of view.
Unfortunately, the best things aren't always the most commercially successful, because products are only a small part of what makes a company successful. I think we're seeing this play out in the software market.
JIRA might be objectively awful, but it still manages to print money!
He said the lifecycle of a program ends when the development team is disbanded or when knowledge transfer fails to happen. But these days, people develop with AI. Will that knowledge actually remain? There's a slightly tircky point here
Of course, even in the past, once a codebase got big enough, everyone was writing code on top of an incomplete theory. But when you delegate work to AI, the theory itself isn't yours anymore, which makes it even trickier.
While it is in some sense harder, there are also opportunities, because the reach of a person is bigger and one can refactor more frequently to align with the theory being developed without the cost that used to be associated with this. AI is also effective for producing materials to teach the theory, increasing the chance that others can contribute coherently to a product.