"With great speed comes great responsibility ... or something"
It's now so much faster to build garbage features that no one needs or can even find in the product. Your path 1 is where PMs have lived for years. PMs are intentional friction to make sure you are building the right thing aligned to your company business goals.
Yes the cost to build has gone down, so that means you can use some of that regained time to focus on quality. This is your differentiator because your product probably doesn't need the 100 different things people have asked you for this week. Plus there is still a complexity cost down the road to building all of these frivolous features. Don't get fooled into thinking you aren't just baking in the tech debt.
Use your new speed to lean into quality outcomes, not speedy output.
“PMs were the original vibe coders. We wrote the spec, and the engineers were our LLMs.” I love that line, however I know a few engineers that would scoff at that. I had retired just before my company started converting Business Analysts into PMs, and right before AI took off. Back then, it felt like the funnel was already squeezing out BAs who focused solely on requirements.
As a BA, I treated requirements written clearly enough to stand alone, sometimes almost executable. When PMs moved toward strategy and engineers absorbed more product ownership, that standalone requirement's role seemed to be fading into product management. But with LLMs now turning well-formed specs directly into working systems, I wonder if this actually revives the BA craft. If AI can build from clear intent, then producing precise, validated requirements may become more valuable again not less.
Perhaps it’s better to think of emerging roles from the perspective of who owns which outcomes - revenue, user growth, UX, quality, reliability, etc. That is what matters anyway.
"With great speed comes great responsibility ... or something"
It's now so much faster to build garbage features that no one needs or can even find in the product. Your path 1 is where PMs have lived for years. PMs are intentional friction to make sure you are building the right thing aligned to your company business goals.
Yes the cost to build has gone down, so that means you can use some of that regained time to focus on quality. This is your differentiator because your product probably doesn't need the 100 different things people have asked you for this week. Plus there is still a complexity cost down the road to building all of these frivolous features. Don't get fooled into thinking you aren't just baking in the tech debt.
Use your new speed to lean into quality outcomes, not speedy output.
I'm not convinced that PMs will be the people making those decisions going forward. Why can't engineers make that?
“PMs were the original vibe coders. We wrote the spec, and the engineers were our LLMs.” I love that line, however I know a few engineers that would scoff at that. I had retired just before my company started converting Business Analysts into PMs, and right before AI took off. Back then, it felt like the funnel was already squeezing out BAs who focused solely on requirements.
As a BA, I treated requirements written clearly enough to stand alone, sometimes almost executable. When PMs moved toward strategy and engineers absorbed more product ownership, that standalone requirement's role seemed to be fading into product management. But with LLMs now turning well-formed specs directly into working systems, I wonder if this actually revives the BA craft. If AI can build from clear intent, then producing precise, validated requirements may become more valuable again not less.
It is simplified!
Seems path 1 is already a big part of the role for many PMs. I spend have a lot more time in these areas then writing requirements or specs.
Perhaps it’s better to think of emerging roles from the perspective of who owns which outcomes - revenue, user growth, UX, quality, reliability, etc. That is what matters anyway.
That could be a great framework!