Que mettez-vous dans votre PRD, et qu'est-ce que vous en laissez délibérément dehors ?

Dedans : le problème, la preuve qu'il est réel, l'utilisateur et son contournement actuel, les métriques de succès avec un seuil d'échec, des non-objectifs explicites et les questions ouvertes. Dehors : la conception de la solution et l'implémentation. Si votre document spécifie l'interface ou le schéma, vous avez retiré les décisions intéressantes à ceux qui sont les mieux placés pour les prendre, et vous récolterez de la conformité au lieu d'idées.

Mon PRD est court et c'est surtout des preuves. Le problème, qui l'a et à quelle fréquence, ce qu'ils font aujourd'hui à la place, pourquoi maintenant, la métrique avec un seuil d'échec explicite, et une liste de non-objectifs. La section non-objectifs gagne sa place à chaque fois, parce que c'est là qu'on désamorce le scope creep qui débarquerait sinon en semaine trois. Ce que je laisse délibérément dehors, c'est la solution. Je n'y mets pas de wireframes ni de schéma, parce que dès l'instant où je le fais, les ingénieurs et le designer arrêtent de résoudre et se mettent à implémenter mon idée à moitié formée. J'ai appris ça à la dure après avoir écrit une spec très détaillée une fois et obtenu exactement ce que j'avais demandé, ce qui était pire que ce que l'équipe aurait construit d'elle-même. Je garde aussi une section questions ouvertes en haut et je la mets à jour au fil de l'eau, pour que le doc montre ce qu'on ignore encore plutôt que de faire semblant d'être fini.