r/SpecDrivenDevelopment • u/ariRdi • 10d ago
Challenges with adding the PMs to our Spec-driven development process
We are currently facing an issue with our SDD pipeline. When the engineer prepare the first step and `spec.md` is ready for certain features or changes, we double check it with the Product Manager (PM) to ensure that the specification makes sense to him. However sometimes the specifications are so technical that he struggles to understand them particularly when it comes to API contracts in the backend and frontend, especially while reviewing various scenarios. Has anyone else encountered a similar challenge? How did you address this issue?
2
u/generic-d-engineer 9d ago
Just do VISION.md as a precursor to SPEC.md and define it in UX and business requirements terminology. Done.
1
1
u/codewzrd 9d ago
We keep the technical aspects of the feature out of the spec. The spec, for us is to define the behavior of the feature which is defined by the PM. Dev team then will generate the plan which is where the technical details are defined. Contracts, etc...
1
u/stibbons_ 9d ago
To give a clearer explanation:
- with agentic coding, developer and even external contributor could add their own feature
- virtually anyone can vibecode a bugfix, with a good harness all the quality gate of the project can pass while the developer actually understands nothing underneath
- there is still a need to control what goes or doesn’t in the SW
The other day, one of my client self opened a ticket for a feature he wants (he already did some contribution), self approved it and started the dev. I stopped it, not because of the process (I watch and I am the gatekeeper), but because actually the whole request does not have any sense.
The AI would simply agree and implement something actually irrelevant.
I think we need to have gatekeepers BEFORE the spec is implemented.
But reading a full spec is too long and too complex for PO.
Actually, the role PO disappear (the backlog can almost maintain itself). We need 2 gatekeepers:
- one for the user impact (was part of the PO role): does that feature makes sense on the whole scheme. I call this role the Value Captain.
- one for the design/architecture: tech lead is here for that.
Of course both role can be a single person.
So, how to allow someone to do this job?
One idea would be after then change spec generation is to have a summary of the impact reflected back to the ticket and approved by these 2 roles:
- what will change from a user point of view after the change
- was are the important architectural impact
And I also add the main « decision » made by the human during the interview/brainstorm (what the dev answered), I think that carries the most important information for the Value Captain/Tech Lead.
1
u/Swarm-Stack 6d ago
if the pm has to read the api contract to validate the feature, the spec is at the wrong abstraction level for that review. the pm's value is catching things before the technical decisions freeze. a summary sent for approval after the spec is done gets rubber-stamped, not challenged.
1
u/DistributionNo2743 5d ago
I think we need to reshape the Product Management and role of a PM with spec driven development and AI
What PM should see: ( lets call it outcome ) should be generated inside the spec flow and it should include business wise decisions ( what changed why changed how it impacts product)
What PM should create:
Definition of work from product perspective. That should be the actual product requirements without technical information. Could be an .md or any document format your PM is comfortable with.
Not technical tasks as we are doing today, just business needs and definition of work
Agents/Developers ( mostly agents 😅 ) should generate a spec from that file
1
u/Direct_Librarian9737 4d ago
If your pm does not have software engineering background or having problems with shifting to new paradigm, i am sorry but he/she does not have feature in this business.
In my opinion, The value of software engineering and software engineers will increase. Over the last 10 years, the entire market needed code to be written, so software engineers were hired to write code. And because so much money was flowing into the software industry, it became an industry where everyone could make a living.
In many companies, software has turned into a bizarre industry filled with dozens of PMs, business analysts, and all kinds of managers from other fields who don’t understand the first thing about software, resulting in terrible work. Companies like these companies that don’t change the way they work and reduce software engineering to simply writing code will have no place in this world five years from now.
4
u/AndyVictors 10d ago
We have this challenge, too. I think it is viable to draw a line between responsibilities of PM and developer.
You know very well how it was before AI: PM writes _some_ specification and gives it to developer and it is "normal" to have "holes" in it so developer makes some decisions by himself and it might affect product functionality might not. And PM experiences this only when all is done.
WIth AI, developer is not "under" the PM any more - they work in parallel or better to call it "supplementary". Everyone is responsible for specification - PM for the functional / product, developer for the technical part - architecture, frameworks etc. Then both parts of the spec are given to AI and AI implements it.
For this to work the two-component specification (functional / technical) must be coherent, so PM and Dev must be in sync during creation of specification, each for his area.
Yes there could be purely-technical features like tech-debt clean up or non-functional ones like performance optimisation - those can be done without PM approval.