alt Hacker NewsThis job is really the stepping stone to product management - and it's the role that's going to really grow with LLMs. A mini-PM with Fable can solve tons of customer needs.
Edit: I guess I'm not surprised to see the downvotes on this; I get that a lot of people on HN don't really understand product management, or don't value it. The path from engineering to product management can really start with getting closer to the customer - putting more time into understanding their needs.
The reason this shifts a lot with LLMs is that a sales engineer / forward deployed engineer can tackle customer needs much more quickly with Claude Code than they could have themselves, which means these feedback loops can become a crash course in customer experimentation and understanding.
Teresa Torres wrote an amazing book about continuous discovery that I use with my teams (https://www.producttalk.org/continuous-discovery-habits/), and a third of the book is about talking to your customers every week if you can. Someone in a customer facing role who can also build code has a huge leg up compared to someone coming at product from an academic setting. Case studies in an MBA are great for strategy, but they're usually fixed points in time. Getting that nimble feedback to hone your product sense is the hardest part of getting good.
Replies
If fable can solve the customer’s needs then why is the PM needed at all?
Pressing needs like AI responses to questions on HN to promote themselves.
LLMs don't really have anything to do with this, other than LLMs being useful for pretty much any (tech) role.
What’s a mini-PM? Something Apple offers?
I don't understand why you're getting downvoted.
In East Asia, 'SI' is looked down upon, but one of the strengths often mentioned about SI is understanding the client's business, that is, the domain. It's true that in the industry, which is based on job-hopping and career building, it gets a lot of criticism. But from a startup perspective, it's often evaluated positively as having strong business insight. So I think your opinion is valid.
In fact, from what I've observed on HN, most people seem to be obsessed with 'programming purity' rather than 'product cycles.'
When you're doing product-focused or delivery-oriented development, there are inevitably black boxes you don't understand, points you can't control, and product management isn't about 'perfection.' It's about whether you can get fast feedback from customers and iterate. But here, it seems like most people assume that everything should be ideally perfect.
I agree with your opinion. Because if you go to the field rather than just dealing with services, you can clearly see how imperfect domain modeling really is. If a business is large enough, you can reshape the domain with capital power to fit your service, but as you know, most of the time when you go on-site, there's a conflict between an imperfect domain, most clients don't really know their own requirements, and implementation capabilities.
Actually, I think your post is more high-level. Don't worry too much about the downvotes.
At that point what's the value add of the PM (and maybe even the consulting company entirely), if the PM is just doing doing custom stuff? How many of those can the customer solve themselves with Fable? OR the support agent at the vendor without needing to take it to a PM?
PM in this sort of company—where there's no grand unifying vision vs just responding to customer requests—is the sort of almost-entirely-paperwork role that starts looking less necessary when you can have LLMs summarize all those comms and "analysis."