r/ProductManagement • u/Mobile_Spot3178 • 5d ago
Tools & Process Software development, the role of developers and product management as bottleneck
I work in a very highly regulated industry where domain expertise is king. About 6-12 months ago the general feeling with AI was that it's here to stay, but it isn't quite taking any jobs because developers need to constantly supervise and do a decent amount of manual corrections and supervision. Sort of like a new power tool that makes things way faster, but doesn't change the game totally.
Today, I honestly am not sure where this is going. I'm hearing too many jokes from developers saying "you could've just given AI your specs to get the same result, don't need me" or "AI one-shotted it, don't know where I'm needed". The newest models with a very good infrastructure makes it possible for AI to fix almost any bug or create any feature based on specs you give it. The scary part is, it's starting to get things right almost all the time. This wasn't the case just 6 months ago. Not only does it get the requirements right, there's very little code changes anymore.
I'm trying to get requirements to devs at a speed never seen before. Some devs are finishing work in a day that used to take weeks or even months.
- Testers are getting so busy they have no time for anything else but try to validate all the new stuff coming out.
- Product management is so busy trying to get quality requirements so that devs have work on their list.
- Designers are too slow and we can't wait for designs for every case.
We've had many refinement meetings which make us question refinement as a whole, because AI has already built the stuff for refinement so it becomes more of a demo than a refinement.
I actually raised an idea to the team:
- What if anyone can create requirements and specify what needs to be built? why does it have to be product people only writing requirements and improving the product? What if a dev, tester sees an improvement area, they ask PO or PM for a green light, but they can improve the product just as well?
- Some immediately answered they can only know there is a problem to be solved, but they don't want to write what the solution should be. Especially testers or more junior devs.
- The more senior developers, who have vast domain knowledge, are thriving with the idea. They continue to build, test and provide value for the users at high speed. The more juniors have no domain expertise yet, which really makes me think about where the roles are going.
Have you seen the change as well if you work in domain-specific products as well? Any predictions about how product teams will look like in the near future? Any good ideas?
19
u/AnteaterEastern2811 5d ago
I'm in the same boat as what you describe and don't have an answer yet. Two recent changes I've started making with the team are as follows.
- Product - Simplify requirements and specify less. Focus on desired outcome + context and less about how to achieve it.
- Design - Reinforce the design system instead of feature specific design. So if an engineer has an idea mid execution I'm ok running with it as long as it fits within the system.
The reason I'm doing this is because I'm trying to create a good system in the world of AI development where creativity can thrive to come up with better solutions. Efficiency is no longer the bottleneck.
1
u/perceptionad 4d ago
Great points. Basically all 3 functions have to get comfortable letting go of the control.
9
u/IniNew Designer 5d ago
Imagine if a sales person did what you described. That’s why product people are still needed.
3
u/Mobile_Spot3178 4d ago
There will always be the need for product vision, limitations, strategy and decision making.
9
u/GeorgeHarter 4d ago
The risk is adding to your product faster than clients and their users can adopt those changes.
Healthcare, finance and other regulated industries are often Very Slow to implement new versions of the SW they use. Their bureaucracy around implementation is often time consuming, so they time/gate changes.
In the long run, faster development means we need fewer people building each product, to avoid burning out users.
1
u/Mobile_Spot3178 4d ago
All our users are always in one version and the version is updated daily or weekly. But it's true especially users who use products in regulated areas are slow to adopt anything new. Luckily usually we're building everything almost always based on known customer needs. Users always get automatic notifications when something they requested is live. So at least those might use it :)
But in the long run I don't know what will happen with this speed of development. Competitors are doing it too I assume, so it's a game of who makes the best decisions.
4
u/AV_SG 5d ago
I feel there should be weightage given to their own expertise, may it be the subject matter expertise or the technical advantage, for the PM and the Engg team respectively. In this way, we reap the benefits of AI as well as do justice to the responsibilities. By every means, each of them should be encouraged to embrace/try out the lateral skills but ownership remains with those with experience.
2
u/jnorion 5d ago
I'm still working through this myself, so I don't have any certain answers yet, but so far where I've had the most luck is essentially treating the devs' first pass as the initial brainstorming.
Here's an example: a couple of weeks ago I got a feature request that was a very good idea and not super detailed. My old process would have been to spend a fair amount of time on discovery, figuring out the nuances of the problem, then come up with a proposed solution and at least initial designs (I don't have a dedicated designer so I mostly do that myself), solicited feedback from the important stakeholders and iterated if necessary, and when we got consensus that the solution was a good one, packaged it up with a lightweight PRD and given it to devs.
This time I copied and pasted the FR pretty much verbatim into a ticket, added a note that it wasn't top of my priority list but it seemed worth doing, and put it in the "grab bag" backlog which is standalone stuff that devs can work on when it fits in their schedule between bigger things. The next day someone had the new feature up on preview to look at.
It wasn't amazing, and definitely needed some tweaking both from me and from the person who originally requested it. But they had a working, usable version coded in barely more time than it would have taken me to think through the whole thing and make wireframes, and the amount of adjustment it took afterward really wasn't more than if it had been my mockup. Probably a different sort of adjustment, but just like with any sort of design work, it takes a lot less effort to evaluate and edit something that already exists than to start with a blank sheet of paper and decide what to put on it. In the end, I think I put about two hours total into that feature, the devs spent barely more time on it than they would have if I'd given them complete requirements in the first place because most of the first round of code came from Claude unattended, and we shipped it at the beginning of this week. I spent most of the intervening time focused on a much bigger project and the work went out the door anyway.
So for big strategic things, I still spend my time focusing on the planning and details up front. But for smaller things, I'm trying to shift the process so I'm a reviewer more than a planner. We still get the benefit of the product sense that I'm good at, but without me having to be the bottleneck all the time.
2
u/WeakSupermarket5354 5d ago
What's the scope of the PMs role at your org? I'm seeing a lot about writing requirements but as I see it, that's a small and fading part of the job. PM's need to gather and distribute context to make sure only things that are actually likely to move the needle get delivered - which ends up meaning that you invalidate most assumptions and avoid building most things that won't move the needle.
1
u/Mobile_Spot3178 4d ago
Depends on the team. Some PMs are both PM and PO, so they write requirements and do all that stuff. Some PMs that have multiple products have a PO as well.
2
u/SportNo2720 4d ago
I am a product designer in enterprise software, my primary focus has shifted toward rapid co-prototyping directly with customers. However, bringing product managers and engineers into every validation session risks overwhelming clients and causing decision fatigue. Implementing a "forward-deployed designer" model, where design drives direct, bottom-up customer collaboration streamines the feedback loop while keeping customer sessions targeted and high-leverage.
2
u/SamfromLucidSoftware 4d ago
Been giving this a lot of thought too. Interesting that you raised the idea of broadening who can write requirements.
What’s probably changing is that the product manager role moves further toward decision quality and away from documentation. Knowing which problems to solve, why now, what a good outcome actually looks like, and whether the product that gets built actually matches the original intent. That kind of judgement, unlike execution, doesn’t necessarily get faster with AI. If anything, it may need to slow down, because the cost of pointing AI at the wrong problem compounds much faster than before.
Going from a spec to agent-generated code is a different thing entirely, though. The review step becomes more important, not less, because AI can build confidently even when the requirements were incomplete or slightly off. Someone still has to catch that before it reaches users.
3
u/MrP32 5d ago
So the thing is, why do you need developers if product managers can do it themselves? Engineers suck at talking to users cause they see every problem as something that should be solved and don’t ever stop to think why or even if it should be solved.
I think you maybe have your thinking backwards cause it sounds like your developers are running out of things to do, not product management.
Also I don’t understand what you mean about refinement. In doing my own personal projects, I refine things with AI. The AI is my developer, sure it probably makes code that isn’t that good but I didn’t care for my personal projects.
1
u/Mobile_Spot3178 5d ago
I wouldn't mix personal projects or general software with this case, where the software runs things that simply should work or not-so-good things will happen. By refinement I mean checking if for example a Feature that has specs has all the things needed to even start building it. Refinement sometimes finds critical flaws in thinking or brings new, better ideas as well. It's like a checkpoint before building. AI is already part of refinement, AI has done a refinement check before humans refine it, but AI doesn't know your users, your system, your environment, your end goal.
1
u/MockStarNZ 5d ago
Our engineers have started doing all the tech debt and refactoring that’s been hanging around not getting done
1
u/Parking-Stress-3041 5d ago
The part that doesn't compress in deep-domain products is knowing which edge cases actually matter. In ERP workflows, most of my time never went into writing the spec, it went into working out that three customers describe the same problem differently, and only one of them sits in a flow where the exception is non-negotiable. Faster build cycles don't shorten that bit at all.
So letting anyone propose requirements is fine for local improvements, but keep the arbitration with whoever holds the cross-customer picture. Otherwise you end up with ten well-built features that each serve one account.
The other thing I'd watch: whether you can still say why something was built six months later. That trail is the first thing to rot when throughput jumps.
0
u/Mobile_Spot3178 4d ago
I think our product people are still focusing on the most important things. But smaller things, like clear bugs, typos, design flaws, adding smaller features is fine and usually they always ask product for the OK.
1
u/prodmaker 4d ago
I think it boils down to definition of what does product manager do and how they collaborate with the team.
I think it doesn't have to be the solo responsibility of a PM to write tickets. I'd say it's absolutely wonderful if whole team is capable and willing to contribute to create and maintain the backlog. Of course - at the end of the day the responsibility lies in PM's hands. But collaboration should be encouraged.
My approach is that at all times I'm happy to discuss with anybody who has an idea or observation. But I don't expect them to bring fully done reasoning or data behind that.
It does take a bit of extra work at times, but overall I believe it's good for the product to take all voices into consideration, but still have a single gate for prioritization and decisions - as the ultimate responsibility has to reside somewhere.
Lastly, my most recent idea was that product context (including future backlog) should live in form of a separate git repository where everybody involved can contribute and suggest things. But it should be regulated in terms of what's accepted. But this way in the agentic development age, I feel it allows to collaborate much more efficiently with the team on what's in the product. With git pull requests it's easy to have a discussion in public, document the reasoning for future reference and have an actual signoff moment before an idea becomes an approved backlog item.
1
u/Tsudaar 4d ago
"Designers are too slow and we can't wait for designs for every case."
So what do you do when you come to those areas? Wing it?
The process of designing for edge cases informs the main design, so if you're missing those you're essentially building from an unfinished design which may or may not be very different to what would have been the finished design.
And if you’re building faster than designing then I'm pretty sure you're not getting decent feedback on designs at all.
0
u/Mobile_Spot3178 4d ago
Currently we're trying to have our whole design system embedded with AI. This means that all the prototypes we make based on requirements can be prototyped with layouts that use our design system. We can then get quick approvals for those designs.
1
u/IllBeat7897 4d ago
There is a difference between "improving" a product and managing a product. Product Management has the domain and business analytic skills to understand both the overall business, how to prioritize features and what the market can bear in terms of product "improvement." PMs often can see the larger forest, while seeing the acorns that have fallen off each tree. PM resources are closer to the stakeholders typically, and are trained to avoid trawling for and analyzing requirements based on assumptions. Devs are downwind of this and wait for to be given the "what" so they can code "how" to fulfill it. If anything, AI will potentially readjust the historical resource model on teams that has always been, for example, 10 devs for every 1 pm person, will now be more like 2 devs for every 2 or 3 pm people. The take-away is not net positive if you pay attention to the numbers as the change will mean 7 or 8 fewer jobs per team (in a general sense of course).
2
1
u/vangeorgo 2d ago
As a PM I think the roles are merging in general and it's only about the personal traits - if you're experienced PM with some tech expertise, you can be very valuable because you probably are able to handle most of todays SW work (not big architectural decisions and developments, but the tiny iterations).
Same goes for developers, who are not afraid to touch the grass, see sunlight and talk to other people. If they are not sour and not interested in AI because it's just another trend (I've heard this multiple times), they can easily replace PMs in some organization.
In general I agree with what was mentioned here before - tandem of these two can be scary powerful and it's how we do things right now where I work.
1
u/Accomplished_Amateur 5d ago
We now have CX and Services team members writing tickets for dev. Product just gives a once over to make sure it’s not a bad idea. It’s select people who’ve been trained and are more product minded, but nonetheless it’s helping us keep pace with the dev pace increasing.
1
u/Mobile_Spot3178 4d ago
I think it's something worth trying at least. Would be nice to know how it worked out in 2-4 months time!
1
u/qwertykeith 5d ago
I would move some (or possibly all) of the devs to product management
1
u/Mobile_Spot3178 4d ago
I actually suggested we'd have some devs take responsibility of certain domains as product people / product engineer or whatever. It didn't get too much attention then, but it might soon.
1
u/Busy_Pear_834 5d ago
Product Management’s role should never be to simply keep developers busy or continuously feed the backlog with requirements. The more important responsibility is deciding where the product should go based on customer needs, market dynamics, business context and long-term product strategy.
If AI dramatically accelerates implementation, that doesn’t remove the need for Product — it changes where Product should spend its time. The real question becomes how AI can augment the entire product lifecycle rather than simply generate more features faster.
In regulated or domain-heavy environments, this becomes even more important. The speed at which AI has entered our individual lives is very different from the speed at which companies can responsibly adopt it. Data privacy, governance, regulatory obligations, auditability and architectural constraints mean we cannot simply delegate everything to AI overnight.
I think this creates a much broader change-management challenge. Companies will need to rethink how their technical architecture adapts, which decisions remain deterministic or human-controlled, where AI is allowed to act autonomously, and how roles and responsibilities across Product, Engineering, Design, QA, Risk and Compliance evolve.
That isn’t something a PM — or Engineering — can decide in isolation. It requires an organizational operating model for AI adoption.
Meanwhile, I do think AI will remove a lot of low-value coordination and documentation work from Product. But that should ideally free PMs to spend more time on customer understanding, product judgment, market direction, prioritization and outcome ownership — not simply producing requirements faster.
So my prediction is not “fewer PMs because developers can build faster,” but different product teams, with different boundaries and much more emphasis on judgment, governance and domain expertise.
0
u/Mobile_Spot3178 4d ago
Well in our business the requirements are very domain specific. You need to truly know the domain (either you worked there, studied it or been there for years) to understand the domain space. So the people who understand what things should or even must (legal obligations) be built next are often product people, feeding them to dev teams.
2
u/Busy_Pear_834 4d ago
That’s exactly the point I was trying to make. If AI is changing how we work rather than what needs to be done, this becomes more of a Center of Excellence question.
Product own the domain expertise around customer, market and regulatory needs, but how AI is embedded into the organization requires broader expertise — from architecture, privacy and governance to organizational design. It also raises bigger questions: what should be augmented or automated, do we need new AI-specific roles or should we reskill existing teams, and how should responsibilities evolve?
0
u/GroupThen2002 5d ago
Provide AI these skills:
PRODUCT REFINEMENT SKILL
When given a feature, epic, story, requirement, or rough product idea:
Inspect the actual repository before proposing implementation.
Identify the relevant:
- services/modules
- APIs
- data models
- permissions
- workflows
- UI components
- integrations
- configuration
- tests
- comparable existing functionality
- services/modules
Explain your understanding of the requested outcome and existing system behavior.
Identify:
- ambiguous requirements
- missing requirements
- contradictions
- unstated assumptions
- edge cases
- dependencies
- regression risks
- ambiguous requirements
Separate unanswered questions into:
PRODUCT DECISIONS
Questions requiring customer, business, workflow, regulatory,
UX, or product judgment.TECHNICAL QUESTIONS
Questions that can potentially be answered by inspecting the system.Investigate technical questions yourself. Do not ask a human
for information you can discover from the repository.Do not invent answers to product decisions.
Challenge the proposed solution:
- Can existing functionality be reused?
- Does it conflict with the architecture?
- Is there a simpler approach?
- What else will this change affect?
- Can existing functionality be reused?
Evaluate:
permissions, data integrity, migrations, APIs, integrations,
backwards compatibility, error handling, security, auditability,
accessibility, performance, deployment and testing.Finish with:
- Feature Understanding
- Existing System Behavior
- Affected Areas
- Existing Functionality to Reuse
- Product Questions
- Technical Findings
- Edge Cases
- Dependencies
- Risks
- Recommended Approach
- Proposed Acceptance Criteria
- Test Scenarios
- Readiness Assessment
- Feature Understanding
Classify readiness as:
READY
READY WITH ASSUMPTIONS
NOT READY
Do not start implementation until explicitly told to proceed.
TECHNICAL PLAN SKILL
Given an approved/refined requirement:
- Reinspect the relevant code.
- Propose the implementation approach.
- Identify affected files/services/components.
- Define API, data model, migration, permission and integration changes.
- Identify reusable existing patterns.
- Define test coverage and regression areas.
- Break implementation into ordered, reviewable steps.
- Identify risks, dependencies and unresolved technical decisions.
Do not write production code yet.
If the plan exposes a new product decision, stop and surface it.
IMPLEMENT FEATURE SKILL
Use this skill only after the requirement has been refined and the technical plan has been approved.
Your role is to implement the approved feature safely and completely in the existing codebase.
Re-read the approved requirement, acceptance criteria, and technical plan.
Reinspect the affected code before making changes.
Confirm that the technical plan still matches the current codebase.Implement the approved solution in small, reviewable increments.
Follow existing project patterns for:
- architecture
- naming
- error handling
- logging
- authorization
- validation
- APIs
- data access
- UI components
- configuration
- testing
- architecture
Do not introduce a new pattern when an established one already exists unless the approved plan explicitly requires it.
- Stay within scope.
Do not:
- add unrelated functionality
- silently change existing product behavior
- resolve ambiguous product decisions yourself
- expand the requirement because another approach seems better
If implementation exposes a new product decision, stop and surface it.
- Maintain system integrity.
Evaluate all changes for:
- permissions and authorization
- data integrity
- backwards compatibility
- migrations
- concurrency
- integrations
- security
- auditability
- accessibility
- performance
- error handling
- existing customer/configuration behavior
Add or update automated tests for:
- acceptance criteria
- normal workflows
- edge cases
- failure conditions
- authorization
- regression-prone existing behavior
- acceptance criteria
Run the relevant verification available in the repository, including where applicable:
- unit tests
- integration tests
- end-to-end tests
- static analysis
- type checking
- linting
- build/compile
- database migration validation
- unit tests
Do not claim a test passed unless you actually ran it.
- Fix implementation defects discovered during verification when they are within the approved scope.
If a failure reveals a broader architectural or product issue, surface it instead of hiding it with a workaround.
- Keep the implementation aligned with the approved acceptance criteria.
Before declaring completion, verify each acceptance criterion against the implemented behavior.
- At completion, report:
IMPLEMENTATION SUMMARY
What was implemented.
FILES / COMPONENTS CHANGED
The important areas of the system modified.
TESTS ADDED OR UPDATED
What coverage was created or changed.
VERIFICATION RESULTS
What tests, builds, linting, type checks, or other validation were run and their results.
ACCEPTANCE CRITERIA STATUS
For each acceptance criterion, indicate whether it is satisfied.
ASSUMPTIONS
Any assumptions relied upon during implementation.
DEVIATIONS FROM PLAN
Anything that changed from the approved technical plan and why.
REMAINING RISKS
Known limitations, untested areas, migration concerns, rollout concerns, or follow-up work.
- Do not declare the feature complete when:
- required tests are failing
- an acceptance criterion is not satisfied
- a required migration is incomplete
- an unresolved product decision remains
- the implementation differs materially from the approved scope without approval
- required tests are failing
CORE RULE
Implement what was approved, use the existing system as the source of truth for engineering patterns, verify the result, and surface decisions rather than inventing them.
2
0
u/LayerOnly1448 🌱 calmatwork[.]app 5d ago
You'd need some extrovert developers for your idea. But, that seems to be the trend in other software developing companies too: engineers who can understand very well the 'why' so they can describe the 'how' in such details that AI can implement it fast and reliable.
2
u/Mobile_Spot3178 4d ago
Not sure how extroversion would be the difference maker here. I've at least tried to build a culture where all ideas are welcome and very often ideas from the team overwrite the initial ideas from product. Lots of collaboration.
0
u/V_Ster 3d ago
I have been doing the bug fixing myself via a controlled AI environment. This has enabled me to test the fix and then get an actual developer to check for breaking changes and to see if there are no data migrations.
Concern I have now is that I am doing this on top of my usual work and its creating a break in my workflow. Dont get me wrong: every morning I open VS code and have a crack as a minor UI/feature for users and its nice to see it go onto prod within a week but I have 100% dropped things from other teams.
Testing and documentation/help sites are the current blocker. Its even worse when devs have been making new things every day and deploying them which makes it hard to track what has changed.
1
u/Mobile_Spot3178 3d ago
Our bug fixes are already pretty much automatic. There's little to no human interaction, except validating that the behavior is a bug.
2
u/Nik_Albato 1d ago
The bottleneck moved, it did not disappear. When building got cheap, the slow part became deciding what is worth building and describing it precisely enough that what comes back is what you meant.
On our side every PM now builds prototypes with agentic coding, and a few commit small fixes that engineers review. Nobody was replaced. What changed is that the argument about what we are actually building happens two weeks earlier, over something clickable instead of a document.
48
u/smashhuevo 5d ago
Vertical SaaS; domain specific product in enterprise software. The most efficient of our teams are 1 PM and 1 Engineer working in tandem to define requirements - sometimes for days - then one-shotting the thing. Both are needed; PM doesn’t have quite the technical depth and vice versa. Both are allowed to ship as well.