
Product Requirement Documents Must Die - cpeterso
http://www.mindtheproduct.com/2016/03/product-requirement-documents-must-die/
======
throwaway2016a
Tangent to that is... if you are a consulting firm your SoW must have an
unambiguous list of deliverables. Not having one is asking for trouble if the
client changes their mind or decides they interpret a deliverable differently
than you. Or worse, the client got the wrong thing because you didn't ask what
they actually wanted.

------
flukus
The worst I see is that the requirements come from management who are
"sponsoring" the project. The have no clue how their employees do their jobs
or even what their jobs are, yet they make crucial decisions on how the
software to do them works.

~~~
rurban
A PRD is not really required with a single team. A URS (user requirement spec)
is mandatory, which goes from the PM to the dev team.

A PRD might be useful with multiple, possibly remote teams. Esp. India or
China, because with problems they usually play hardball down to the spec and
nothing more. Right so. But it's the dev team management job to come up with
that.

------
typetypetype
A lot of the issues described here seem like they stem from a lack of good
project management. Requirement docs should never go straight from sales /
marketing to engineering.

------
kafkaesq
_1\. Waste. Very little in a product is actually required_

 _2\. They focus on solutions, not problems._

Sounds like he's been in too many environments completely lacking in adult
supervision, where no one seems to know the ABCs of writing good design
documents (of any stripe).

I find it's just that hard to teach the basics, and once people get points 1
and 2 (which, as he correctly identifies, are huge) things work out much more
smoothly for all concerned.

