Yes, you do need Product Management

 

The massive rise in GenAI-based coding tools has created a huge amount of discussion and debate in engineering circles.  Of course, this also affects product managers (PMs) in new and interesting ways also.

Wild claims are being made that PMs are no longer needed to build software, such as this one by Lovable:

The reason why Lovable doesn’t need PMs is not because of AI.  Lovable doesn’t have PMs because they are building a developer product with a very small team.  This means that the developers on the team already know the user persona.  Thus, they don’t need persona development, use case research, etc., etc., etc.  They are also very small.  Smaller teams don’t need some of the cross team alignment work that PMs do.

However, the bulk of what PMs do will not and cannot be replaced by AI.

The PM team is the team that decides what to build and why.  AI can help you with analysis, but someone still makes the call.  The person who makes that call is called the product manager, regardless of what their actual job title is.

Google on the other hand has made a conscious decision to stop writing documents.  I’m not sure if this is a good idea or not, but it has nothing to do with the PM job going away.  Just the opposite.  What Google is saying is that they expect PM to produce prototypes.  That is to say, PMs will add more value by taking their ideas to prototype instead of just writing requirements.  This is all about AI.  

While I am a big fan of long form writing, the entire point of things like PRDs or PR/FAQs is to help engineering understand the business requirements from PM.  The actual documents are not really important.  What is important is making sure that engineering understands you.  This means that it cannot be a PM decision alone to decide if the team should use a PRD or not.  It must be a joint decision between engineering (the consumer) and PM (the producer).  Just like any other customer, you need to really understand your engineering organization’s needs so that you can meet those needs.

This takes us back to AI-based prototypes.  The decision to move to AI-based prototypes needs to be a joint decision between PM and engineering.  If your engineers feel that the prototypes would be more helpful than PRDs, then they are probably right.  Go try it.  If engineering tells you they really prefer PRDs, you need to accept that preference.

I’ve worked in both very writing-heavy and very mockup-heavy organizations.  If your engineering team has zero interest in PRDs but loves Figma, then AI-based prototypes are probably a good idea.  In most ways a prototype is better than a mock up because it’s actual running code.

Of course, there are requirements that you can’t describe with a prototype.  Especially non-functional requirements like performance and security—you will need to write those things down.  They can be relatively short, but they do need to be formalized. 

In the end, this is about outcome.  Focus on helping engineering understand what needs to be built.  Focus on them and their needs, not on you and your preferences.  Once they understand the requirements, you’re done.