יסודות ותכנון מוצר · מתחילים

לבחור מה לא לבנות

בשורה אחת: היכולת לומר לא היא מה שמפריד בין מוצר ששוחרר לבין מוצר שמפותח לנצח.

למה זה כל כך קשה

כל בקשה נשמעת סבירה בפני עצמה. הבעיה אינה בפיצ'ר הבודד אלא בהצטברות: כל תוספת מוסיפה קוד לתחזק, מסך ללמוד, ומקרה קצה שישבור משהו אחר בעוד חצי שנה. עלות הפיצ'ר אינה שבוע הפיתוח, אלא כל השנים שאחריו.

שלוש שאלות סינון

מי ביקש? לקוח אחד בקול רם אינו שוק. שאלו כמה משתמשים ייגעו בזה בשבוע.

מה קורה בלי זה? אם התשובה היא "קצת פחות נוח", זה לא נכנס לגרסה הראשונה.

מה זה מחליף? אם רשימת המשימות קבועה באורכה, כל כניסה מחייבת יציאה. זו שיחה בריאה יותר מ"נוסיף גם את זה".

איך אומרים לא

לא נאמר עם סיבה ועם מקום: "לא בגרסה הזו, כי המדד שאנחנו רודפים אחריו הוא זמן הטיפול, וזה לא משפיע עליו. נחזור לזה אחרי המדידה הראשונה." מי שמבין את סדר העדיפויות מפסיק להתווכח עליו.

שמרו רשימה גלויה של דחיות. היא מונעת את השאלה החוזרת, והיא המקום הראשון להסתכל בו כשמתפנה זמן.

לעומק

מוצר שנשלח עם עשר יכולות שעובדות מצוין מנצח מוצר עם ארבעים יכולות בינוניות. גם בקוד: כל ענף לוגי מוסיף מסלול לבדוק. צמצום היקף אינו רק החלטה עסקית — הוא ההחלטה הארכיטקטונית הזולה ביותר שתקבלו.