[Schiendelman]

This 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.

[majormajor]

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."

[Schiendelman]

I edited my comment to make my point more clear, since I think a lot of folks don't know what a PM does.

If your PM isn't defining a clear strategy, your PM is probably inexperienced and/or overloaded. It sounds like you might have experiences like that.

I think a good PM needs three big skillsets: Customer discovery, Strategic planning, and leadership alignment. The second and third are easier to learn academically. This kind of role is ideal for learning the first.

[cweld510]

The PM’s job in this situation is to articulate some sort of high level strategy generalizable across customers, based on information gathered from customers, which includes feature requests but is more than just that.

[fmajid]

Good PMs are more than ICs, they are also a force multiplier for the engineers they work with.

[paxys]

If fable can solve the customer’s needs then why is the PM needed at all?

[Schiendelman]

What do you think a PM does?

[paxys]

What do you think an engineer does?

[Schiendelman]

You asked why the PM is needed. I'm trying to understand what you think a PM does so I can help answer your question.

[indoorfish]

Pressing needs like AI responses to questions on HN to promote themselves.

[Schiendelman]

I don't use AI in any comments I make.

[stingraycharles]

LLMs don't really have anything to do with this, other than LLMs being useful for pretty much any (tech) role.

[Schiendelman]

What makes you say that?

[stingraycharles]

Well for full disclosure, I lead a team of forward deployed engineers at a database company. The role typically means that our engineers are embedded within the customer for extended period of times, and they work on basically devops, software engineering + some more traditional solution architecting, which is basically what the article describes.

They use LLMs in similar ways that regular engineers use. This is an engineering role, not a product / project management role. I don’t think this role is anything super special that will be revolutionized in any different way than that other engineering roles are affected.

In the end their value add is that they’re both embedded within the customer’s and our company, they’re our eyes and ears within the customer. Their purpose is not to make sales demos, their purpose is to make our software actually work properly for the customer’s needs.

[Schiendelman]

OK, we both have the same understanding.

I'm saying giving an FDE the ability to significantly modify code for customer needs using a powerful frontier model will make their job more about customer discovery and strategy than about engineering, a big shift of ratio of where they spend their time. It will make the feedback loops tighter, let them experiment faster.

[jdw64]

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.

[Schiendelman]

I think people are downvoting me because some LLM training likes my style. ;)

And thank you! It is higher level. I'm not worried about product management as a field at all now, because software engineers will have more trouble upleveling their thinking to the business than product managers will building high quality software with an LLM.

[tclancy]

What’s a mini-PM? Something Apple offers?