פרודקט ופיתוח באותו צד: איך מפסיקים לריב ומתחילים לבנות

פרודקט רוצה “רק עוד פיצ׳ר קטן”. פיתוח עונה “רק אם נכתוב מחדש חצי מערכת”. מוכר?

בפרק הזה שחר פולק מארח את שיר עמנואל, Product Manager, ואת אופק בן דוד, Frontend Squad Lead, לשיחה על מה שקורה כשפרודקט ופיתוח מפסיקים לעבוד זה מול זה ומתחילים לעבוד על אותה בעיה. יש פה Discovery משותף, Scope שנחתך בלי רחמים, POC שמוציא סימני שאלה מהמערכת, ומוצר אחד שהצוות החליט לאהוב מספיק כדי לגנוז.

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

מה תקחו מהפרק הזה?

הוויכוח הטוב מתחיל הרבה לפני ה-Jira

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

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

Scope הוא לא קיצוץ. הוא אומנות הבחירה.

במוצר 0 ל-1 אפשר תמיד להוסיף עוד מסך, אינטגרציה או ״רק עוד משהו קטן״. העבודה הקשה היא להבין מהו ה-Core Value — ולבנות את המינימום שנותן אותו. אופק ושיר מספרות על פיצ׳ר שהתחיל גדול יותר, נחתך לגרסה ממוקדת, והצליח כל כך שלא היה צורך בחלק מהשלב הבא שתוכנן.

Scope טוב אינו רשימת ויתורים. הוא בחירה מודעת במה חייבים ללמוד עכשיו, ובמה אפשר לחכות עד שיש דאטה אמיתי. אחרת אתם לא בונים MVP — אתם בונים קופת חיסכון של הנחות.

POC טוב חוסך חודשים של “רגע, מה אנחנו בונים?”

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

POC טוב אינו מוצר מוקטן עם שם מתוחכם. הוא ניסוי שמפחית אי-ודאות סביב הערך, ההיתכנות והדרך להגיע אליהם.

מתי צריך ללחוץ על Kill Switch?

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

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

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