רוב מסמכי ה-PRD נסקרים פעם אחת ולא נפתחים שוב. אלה שצוותים באמת בונים מהם חולקים מבנה, והוא נלמד. כך כותבים PRD ששורד מפגש עם הנדסה, עיצוב, ובעלי העניין שלכם עצמם.
אמ;לק
- PRD (מסמך דרישות מוצר) עונה על ארבעה דברים: מה אנחנו בונים, למי, למה עכשיו, ואיך נדע שזה עבד.
- המבנה שנשלח: הבעיה בקול של המשתמש, למי זה מיועד, למה עכשיו, מדדי הצלחה, היקף (בפנים ובחוץ), סיכונים, ושאלות פתוחות.
- שמרו על מסמך ברמת החלטה, לא רומן. עמוד אחד שמסיים את הוויכוח עדיף על עשרה שפותחים חדשים.
- תבנית מביאה אתכם ל-80%. ה-20% האחרונים הם שיקול דעת: מה להשמיט, ומה לסמן כסיכון אמיתי.
- רוצים שהמבנה ייאכף עבורכם? PRD-in-a-Pocket לוקח רעיון גולמי ל-PRD בר-מסירה תוך כמה דקות.
PRD מצדיק את עצמו רק אם הצוות יכול לבנות ממנו בלי פגישה נוספת. רובם לא, כי הם נקראים כמו ערימת דרישות במקום סדרה של החלטות. התיקון הוא לא עוד פירוט. זה המבנה הנכון, ממולא בשיקול דעת.
כתבתי, שכתבתי, ופירקתי הרבה כאלה לאורך שתים עשרה שנים במוצר. הגרסה למטה היא זו שבאופן עקבי מסיימת את הוויכוח ומאפשרת להנדסה להתחיל. היא מבוססת על קרפט ששווה לצטט, לא משהו שהומצא במקום.
מהו PRD, ומי בעצם כותב אותו?
PRD, או מסמך דרישות מוצר, הוא מסמך משותף קצר שעונה על מה אתם בונים, למי, למה עכשיו, ואיך תמדדו הצלחה. התפקיד שלו הוא ליישר את הצוות על הבעיה ועל ההימור לפני שמישהו כותב קוד.
חשוב לא פחות מה PRD אינו. הוא אינו מפרט טכני שמונה כל שדה ונקודת קצה, זה המסמך של ההנדסה. הוא אינו קובץ עיצוב, והוא אינו תוכנית פרויקט. PRD הוא ה"למה ומה". ה"איך" שייך לאלה שבונים אותו.
ומי כותב אותו? מנהל או מנהלת המוצר, כי ה-PRD מתעד החלטות מוצר, ואלה שלהם לקבל ולהגן עליהן. ההנדסה מחזיקה במפרט, העיצוב בקבצים. בצוות בלי מנהל מוצר, מי שמחזיק בהחלטת המוצר כותב אותו. בדרך כלל זה פאונדר, וזה בדיוק המצב שבו מבנה ברור מצדיק את עצמו.
PRD מול BRD מול MRD: איזה מסמך אתם צריכים?
אלה מתבלבלים כל הזמן, והבלבול גורם לאדם הלא נכון לכתוב את המסמך הלא נכון. הנה החלוקה הנקייה.
| מסמך | עונה על | בבעלות |
|---|---|---|
| PRD | מה אנחנו בונים למוצר או פיצ'ר, למי, ולמה | מוצר |
| BRD | המקרה העסקי והצרכים העסקיים ברמה גבוהה | עסקי / בעלי עניין |
| MRD | השוק: הזדמנות, סגמנטים, תחרות | שיווק מוצר |
| מפרט טכני / מסמך עיצוב | איך זה נבנה | הנדסה |
| עמוד אחד / פיץ' | המכירה, לפני שה-PRD קיים | מוצר |
אם תיקחו רק דבר אחד: BRD הוא על העסק, MRD הוא על השוק, PRD הוא על החלטת המוצר, והמפרט הוא על הבנייה. בספק, אתם כמעט תמיד כותבים PRD.
כמה ארוך צריך להיות PRD?
קצר ככל האפשר, כל עוד הוא מסיים את הוויכוח. בפועל זה עמוד עד שלושה, וההעדפה החזקה שלי היא עמוד אחד. PRD גמור כשההנדסה והעיצוב יכולים להתחיל בלי פגישה נוספת, לא כשהוא מגיע למכסת עמודים. אם שלכם ממשיך לצמוח, כנראה שאתם כותבים לתוכו את המפרט, את מסמך העיצוב ואת תוכנית הפרויקט, ואלה שייכים לאנשים אחרים.
איך לכתוב PRD, שלב אחר שלב
שבעה חלקים, לפי הסדר. המבנה הזה שואל מהקרפט המתועד ביותר: תבנית ה-PRD של לני רחיצקי, ארבעת סיכוני המוצר של מרטי קייגן, הכתיבה של שריאס דושי על בהירות, ושיטת ה-Working Backwards של אמזון. אתם לא צריכים לזכור את כולם. אתם צריכים את שבעת השדות האלה, עם תשובות כנות.
1. הבעיה, בקול של המשתמש. פסקה אחת. לא "משתמשים רוצים כפתור סינון", אלא הכאב האמיתי: מה הם מנסים לעשות, איפה זה נשבר, וכמה זה עולה להם. אם אינכם יכולים לנסח את הבעיה בלי לנקוב בפתרון, עדיין לא הבנתם אותה.
2. למי זה מיועד. המשתמש או הסגמנט הספציפי. צר מנצח רחב בכל פעם. "קוראים שמגיעים מהתראה" שימושי. "המשתמשים שלנו" לא.
3. למה עכשיו. הטריגר. שינוי בשוק, יכולת חדשה, או העלות ההולכת וגדלה של אי-עשייה. זה השדה שרוב ה-PRD-ים מדלגים עליו, וזה זה שמנהלים קוראים ראשון.
4. מדדי הצלחה. מדד ראשי אחד שיזוז אם זה עובד, בתוספת מעקה או שניים כדי שלא תנצחו את המדד ותפסידו את המוצר. ציינו את המספר שאתם מצפים לו, או אמרו שעדיין אינכם יודעים אותו.
5. היקף: בפנים ובחוץ. מה נשלח ב-v1, ומה במפורש לא. רשימת "מחוץ להיקף" היא השורה החזקה ביותר ב-PRD, שם זחילת ההיקף הולכת למות.
6. סיכונים. השתמשו בארבעה של קייגן: ערך (האם ישתמשו בזה), שמישות (האם יבינו איך), היתכנות (האם נוכל לבנות את זה בזמן סביר), וכדאיות (האם זה עובד לעסק, למשפט ולמותג). נקבו בסיכון המפחיד ביותר בכנות.
7. שאלות פתוחות. מה שעדיין אינכם יודעים. רשימת הנעלמים שלכם לא גורמת לכם להיראות לא מוכנים, היא הופכת את המסמך לאמין ומראה לצוות איפה לחפור.
זה כל עמוד השדרה. כל השאר, ווירפריימים, מקרי קצה, תוכניות השקה, נתלה על שבעת אלה.
דוגמת PRD אמיתית
מבנה הוא מופשט עד שרואים אותו ממולא. הנה דוגמה קומפקטית בצורה אמיתית לעיצוב מחדש של שרשור תגובות במגזין דיגיטלי.
בעיה: תגובות קשות לקריאה ושרשורים ארוכים קשים למעקב. קוראים שמגיעים מהתראה לא נוחתים על התגובה שבשבילה באו, אז הם נוטשים.
למי: קוראים של מוצרים דיגיטליים ומגזינים שעוקבים אחרי שרשורי תגובות למאמרים.
למה עכשיו: תעבורת ההתראות עלתה ב-40% מאז ההשקה, והיא ממירה גרוע יותר מכל מקור אחר.
הצלחה: שיעור התגובות ועומק הקריאה בשרשור עולים; הנטישה מהתראה יורדת. מעקה: אין ירידה בזמן טעינת העמוד.
בהיקף: קישור עמוק מהתראה ישירות לתגובה המדויקת, עם השרשור מכווץ סביבה.
מחוץ להיקף: כלי מודרציה חדשים, צ'אט בזמן אמת, עיצוב פרופיל מחדש.
הסיכון הגדול ביותר: ערך. אם לקוראים לא אכפת מהתגובה הספציפית, קישור עמוק לא עושה כלום.
שאלה פתוחה: האם לכווץ את כל השרשור, או רק את האחים של התגובה הממוקדת?
שימו לב כמה זה קצר. כל שורה היא החלטה, לא תיאור. זה הרף.
תבנית PRD להעתקה
קחו את זה. הדביקו לכלי המסמכים שלכם ומלאו כל שדה במשפט או שניים. אם שדה ריק, זה סימן שנשארה לכם חשיבה, לא שדה למחוק.
# PRD: [שם הפיצ'ר] ## הבעיה (בקול של המשתמש) [פסקה אחת. הכאב, לא הפתרון.] ## למי זה מיועד [המשתמש או הסגמנט הספציפי.] ## למה עכשיו [הטריגר: שוק, יכולת, או עלות של אי-עשייה.] ## מדדי הצלחה - ראשי: [המספר האחד שזז אם זה עובד] - מעקה: [מה אסור שיתקלקל] ## היקף - בפנים (v1): [מה נשלח] - בחוץ: [מה במפורש לא] ## סיכונים (ערך / שמישות / היתכנות / כדאיות) [נקבו בסיכון המפחיד ביותר ולמה.] ## שאלות פתוחות - [מה שעדיין לא ידוע לכם]
איך כותבים PRD עם AI?
AI באמת טוב בחלקים של PRD שהם מבנה וטיוטה ראשונה: להציע את הסעיפים, לנסח הצהרת בעיה מהערות הגולמיות שלכם, להציע דוגמאות ספציפיות לתעשייה, ולתפוס את השדה שהשארתם ריק. הוא לא טוב בחלקים שהם שיקול דעת: להכיר את המשתמשים האמיתיים שלכם, לקבל את החלטת ההיקף הקשה, או להחליט איזה סיכון הוא זה שהורג אתכם. התייחסו אליו ככותב-שותף מהיר, לא ככותב.
התהליך שעובד: מסרו למודל את הבעיה, את המשתמש, וכמה הערות גולמיות, תנו לו לנסח את המבנה בן שבעת החלקים, ואז השקיעו את האנרגיה בליטוש החלקים שרק אתם יכולים לדעת. אתם עוברים מעמוד ריק לטיוטה אמיתית תוך דקות, ושמים את הזמן שלכם איפה שחשוב.
קיצור הדרך: כלי שבניתי בדיוק בשביל זה
בדיוק בשביל זה בניתי את PRD-in-a-Pocket, הכלי שלי, בונה PRD מבוסס-AI שפיתחתי בעצמי. הוא לוקח רעיון גולמי דרך אותם שבעה שדות שלמעלה, מבוסס על אותו קרפט (התבנית של לני, הסיכונים של קייגן). מה שמייחד אותו מתבנית גנרית: הוא מתאים לחברה שלכם:
- עובד מההקשר שלכם. העלו מצגת פיץ', עמוד אחד, או תקציר גולמי.
- מכיר את השוק שלכם. אמרו לו את התעשייה שלכם ואם אתם B2B או B2C, והוא מתאים כל סעיף. PRD של פינטק ו-PRD של רשת חברתית לא צריכים להיקרא אותו דבר.
- פרומפטים ברמת PM בכל שדה, עם דוגמאות מההקשר שלכם.
- ייצוא נקי ל-Notion, ל-Confluence, או ל-Markdown.
איך כותבים PRD שכלי קידוד AI יכולים לבנות ממנו?
שאלה חדשה יותר, והיא חשובה יותר בכל חודש שעובר. אם אתם בונים עם Claude Code, Cursor, Lovable, Bolt או כל כלי קידוד AI, ה-PRD מפסיק להיות מסמך יישור פנימי והופך לקלט המילולי של הדבר שכותב לכם את הקוד. כלי AI בונים בדיוק את מה שמתארים להם. תארו את הדבר הלא נכון בבהירות, והם יבנו את המוצר הלא נכון בצורה יפהפייה.
אותם שבעה שדות עובדים, עם שלוש התאמות:
- היו אכזריים עם ההיקף. "מחוץ להיקף" הוא הסעיף שכלי AI הכי מכבדים. בלעדיו הם מוסיפים בשמחה מסך התחברות, הגדרות ודשבורד שלא ביקשתם.
- כתבו בדיקות קבלה, לא תחושות. הפכו את מדדי ההצלחה למשהו שהכלי יכול לוודא: "מבקר לא מחובר רואה X", "שליחת הטופס עושה Y". כל אחת מהן הופכת לבדיקה שה-AI יכול להריץ על העבודה של עצמו.
- תנו לו את המסמך המלא, ואז הנחו בפרוסות. תנו את כל ה-PRD כהקשר קודם, ואז בנו פיצ'ר אחרי פיצ'ר. ה-PRD מעגן כל פרומפט לאותו מוצר, וזה בדיוק המשמעת ש-vibe coding נוטה לאבד.
פאונדרים מספרים לי שזה הרגע שבו הם מגלים שבכל זאת היו צריכים PRD. העמוד הריק הוא אותו עמוד ריק. ההבדל הוא שעכשיו המחיר של לדלג עליו מופיע בשעות, לא ברבעונים.
טעויות נפוצות ב-PRD
- לכתוב את ה"איך" במקום את ה"מה ולמה". ברגע שאתם מפרטים רכיבים, אתם במסמך של ההנדסה.
- בלי "מחוץ להיקף". בלעדיו, כל בעל עניין מוסיף בשקט את הפיצ'ר החביב עליו.
- מדדי הצלחה של יוהרה. אם המדד יכול לעלות בזמן שהמוצר נעשה גרוע יותר, זה המדד הלא נכון.
- רומן שאף אחד לא קורא. אורך הוא לא קפדנות. קצצו עד שכל שורה היא החלטה.
- ודאות מזויפת. אין שאלות פתוחות בדרך כלל אומר שלא הסתכלתם מספיק לעומק.
להפוך אותו למסמך שהצוות בונה ממנו
המבחן ל-PRD גמור פשוט: האם הוא מסיים את הוויכוח ומאפשר להנדסה ולעיצוב להתחיל? אם אנשים עדיין מתווכחים מה הבעיה, ה-PRD לא גמור, לא משנה כמה הוא ארוך.
קלעו נכון בשבעת השדות, שמרו על קיצור, והיו כנים לגבי מה שאינכם יודעים. אם אתם רוצים שהמבנה יטופל עבורכם, PRD-in-a-Pocket עושה את זה תוך כמה דקות. ואם המוצר שלכם צריך יותר ממסמך טוב, כיוון בכיר בלי גיוס משרה מלאה, זו הובלת מוצר פרקשיונלית. כך או כך: כתבו פחות, החליטו יותר.
נהניתם? קבלו את הגיליון הבא לתיבה שלכם.
הרשמה לניוזלטר ←