PRD(Product Requirements Document)について調べる

minispec = [PRD] の簡易ver.みたいなドキュメント。
minispecは主にstartupで利用される資料で、作成したい機能はどの様な理由や経緯で提案されているのかを示すもの

minispec には、主に why と what を記載

why と what から how に繋げるために、認識を共有する仕組みがあるとよさそう

エンジニアは、what が定義された minispec から DesignDoc に how を定義します。
DesignDoc にはアーキテクチャや、API インターフェースの定義や、 DB のテーブル定義や、場合によってはシーケンス図などを書き込みます。
DesignDoc に設計をする際に、まれに minispec のままではないがより良い方法を見つけることがあります。そのような場合には minispec にフィードバックを行い、minispec をアップデートします

PRDっていうらしい

PRDはEpicの単位で作成する

数値目標を設定する
開発したMVPは、ユーザーに使ってもらい、仮説の検証結果を判断することになります。
この時、どのような値を元にして判断するのか、その仮説が正しかったと判断するための目標値を決めておく必要があります。
目標データはできるだけインタビューなどの認知データではなく、ユーザーの行動データで検証する方が蓋然性も高く、望ましいでしょう。
開発するMVPにそのデータを収集する機能が必要であれば、それは開発時に盛り込んでおく必要があります。

PRD(製品要件文書)で何を作りたいか決める際に、その根拠がはっきりしない場合、データを見ることは非常に有効なアプローチです。以下のポイントを考慮してみてください:
-
ユーザーのニーズと行動の理解
ユーザー行動データ: ユーザーがどのように現在の製品を使用しているか、どの機能がよく使われているか、どの部分で離脱しているかを分析します。
フィードバックとレビュー: ユーザーからのフィードバックやレビューを収集し、どのような課題やニーズがあるのかを明確にします。 -
市場と競合の分析
市場データ: 市場のトレンドや競合製品の動向を分析し、どのような機能や特徴が求められているのかを理解します。
競合分析: 競合製品がどのような機能を提供しているか、それがどの程度ユーザーに受け入れられているかを確認します。 -
事業目標との整合性
事業データ: 売上や顧客満足度などのビジネスKPIを確認し、新しい機能や製品がこれらの指標をどのように向上させるかを検討します。 -
技術的な制約と可能性
技術データ: 現在の技術スタックやリソースを考慮し、実現可能な範囲での開発を検討します。

割とこれがしっくり

感想

仕様提案はお決まりのフォーマットがあった方が書き手によってブレないしよさそう