What happens to Product Specifications?
Software development is under-going a major transition due to AI.
How are Product Managers going to handle their side of the transition?
There have been provocative ideas on how vibe-coding is going to change everything. Recently, Google Gemini's Head of Product tweeted about how he is encouraging his team to move towards building prototypes over writing documents.
I don't agree with this at all (detailed later). However, I do think the availability of these tools changes how we think about Product Management.
For this discussion, let's only focus on a PM's role in the product development process.
A typical product manager execution flow would be:
- Build a product roadmap
- Detail out the features from this roadmap into a Spec
- Spec goes into the << AGILE DEVELOPMENT CYCLE!!! >>
- Release, monitor, iterate
The Roadmap
For building a product roadmap, you can of course ideate with AI, but in the end, the result is like asking it to write a grocery shopping list. It will give you an output based on what everyone else typically does, and it is usually boring without taking into account any complexities of the real world.
Spending time on strategy on roadmap as product managers becomes critical and will be a differentiator in this new world.
Once you start entering the execution stage, things start to change.
The Execution
There seem to be two schools of thought - one is from the screenshot above, where the Spec goes away, and prototypes become the new requirements. Devs can refer to these live prototypes while building for production.
I am really skeptical about this. As a developer, trying to click through the prototype to figure out all the nuances of the spec feels like a waste of my time. How does this does a better job than a Figma mockup of today? Unknown.
In the other school of thought, the Spec is the hero.
Developers now are being aided by AI, so the cycle times are faster. And honestly, AI is already close to being good enough to write production grade code under supervision.
So it is possible that minor line items from your spec are directly fed into the AI to create the feature.
The logical conclusion to this line of thought is from OpenAI's Sean Grove who says that spec the new code. He says that we would just be talking to LLMs via specs and building production grade applications.
There are challenges when we think of this extreme. One is that AI clearly is not good enough for that today. Two, as my friend Alex talks about in his blog, how English (and any other human language) is lossy. Words can mean multiple things and they are open to interpretation. Legalese exists because when it really matters we want to cover all our bases.
So thinking of communicating in ambiguous terms when we want certain outcomes might not be possible.
I found a middle ground that I mostly agree with in Ravi Mehta's blog, where he talks about doubling down on specs as a primary means of communications.
Instead of the prototypes replacing the spec, the prototypes will aid the spec writing process.
PMs can use these prototypes for early validation of their ideas, figure out corner cases and iterate. The learnings from these can go back into the spec, making it more nuanced and robust. This makes developers focus on writing really high quality production code and less throwaway POCs.
This situation is the most like in the current state of tech, and according to me, this is also pre-empting the future. To build websites, internal tools you do not need that dedicated programmers anymore. What started with no-code platforms is now supercharged with AI. It is probably not long before Mr. Grove's prediction is true, where most applications can be just written with prompts - or at least developers using these prompts.
When that happens, figuring out "what" to build, and communicating the requirements unambiguously will be the most important thing to do.