5 טעויות בין ניהול מוצר לפיתוח בעידן האגנ׳טי

היי כולם, אני רוני ארניב. הפרק של היום הוא פרק מתוך הפודקאסט פרודקטיבי. פודקאסט ניהול המוצר של סטארטאפ פור סטארטאפ בהגשת אושיית המוצר, רן ערז. בפרק השבוע רן מדבר על טעויות נפוצות במפגש בין מוצר לפיתוח בעידן האג'נטי. מזמינה אתכם לעקוב אחרי פרודקטיבי שיוצא פעם בשבועיים בימי רביעי. חוץ מזה, מחר יש לקהילה אירוע הפנינג מדהים שאולי נתקלת בו בלינקדין, מחר, זאת אומרת, ה-11 ל-11, הקפה של סטארטאפ פור סטארטאפ. מהשעת 9 בבוקר ועד 5 אחר הצהריים, אנחנו מזמינים אתכם לבוא, להיפגש וליצור קשרים עם אנשים שתמיד רציתם לפגוש. מאות יזמים, יזמיות, משקיעים, משקיעות ועובדים בתעשייה כבר אישרו הגעה. נשמח מאוד לראות גם אתכם, כל מה שצריך זה להקים פרופיל באתר שלנו, להירשם ולהגיע. אז עכשיו לרן, פתיח ומתחילים. פרודקטיבי, פודקאסט המוצר של סטארטאפ פור סטארטאפ. שלום לכולם, אני רן ערז ואתם הכתבים לפודקאסט שבו אנחנו מדברים עם מנהלי ומנהלות מוצר, על אתגרים מוצרים שהם נתקלו בהם, איך הם ניגשו לפתור אותם ומה שיום שהם לונדו בדרך. ובפרק של היום אנחנו נדבר על 5 התאויות הנפוצות שמנהלי המוצר עושים בעבודה עם צוותי פיתוח בעידן האג'נטי. אז נתחיל, תאות מספר אחת, תאות הקונטקסט. אנחנו יודעים בעבודה עם כלי AI כמה חשוב לתת קונטקסט מדויק ואפקטיבי כדי שלא נקבל תשובות גנריות. אבל איכשהו שאנחנו עובדים ביחד עם צוות הפיתוח, אנחנו עושים את התאות הקלאסית, שבו אנחנו נותנים לפיתוח את המסקנות שלנו ולא את ההוכחות. מה הכוונה? ניתן לכם דוגמה, נגיד אני עכשיו רוצה לעבוד על איזשהו פיצ'ר מסוים. אז אני יכול לבוא לצוות הפיתוח ולהגיד לו דיברתי עם 20 משתמשים וכולם רו שאנחנו חייבים לשנות את מסך הבית. זה להביא את המסקנות ממחקר מה אני רוצה לעשות בצורה הרבה יותר אפקטיבית זה להביא את ההוכחות לדוגמה, דיברתי עם 20 משתמשים בוא תר מה הם רו על מסך הבית פה אנחנו נותנים לצוות הפיתוח לגבש לבד את המסקנה מהמידע, אבל אנחנו אלה שמחליטים איזה מידע רו למה זה כזה חשוב כי בעידן שלנו אנחנו רוצים כל כך מהר שאסור לנו להיות סבר הבקבוק של הפיתוח אנחנו לא יכולים להחזיק, את כל הקונטקסט המוצרי ואנחנו צריכים לאפשר למפתחים שלנו את היכולת לזוז בצורה עצמאית אז אנחנו רוצים להביא להם את המידע הזה, מבלי ללעוס להם אותו אנחנו רוצים לעזור להם להבין איפה להסתכל אבל לא מה לראות לטיפ הזה אני קורא קיורייטד בתן פילטרד מה זה אומר, אני אעזור למפתחים להבין שהם צריכים לראות עכשיו סרטון של דקה שמסכם הכל המשתמשים רו אבל אני לא אגיד להם מה להבין מהסרטון הזה, זאת אומרת אני עושה את הקיורייטד אני מחליט מה הם יראו אבל אני לא אומר להם מה המסקנה שהם צריכים להבין, ובהקשר הזה אחד הדברים הנוספים שמאוד משמעותיים בעולם של קונטקסט זה איך אני מביא את המפתחים כמה שיותר מוקדם לתהליך הדיסקאברי, אנחנו רוצים להביא למפתחים שלנו הרבה יותר קונטקסט מוצרי ולכן במקומות שמספיק פשלים לזה אני אביא את המפתחים איתי לשיחת הדיסקאברי, כדי שהם ישמעו בעצמם את הכאב של המשתמשים ולמה זה כזה חשוב כי עוד רגע הם רצים לאלף פיצ'רים ואני לא יה בקונטקסט אני לא יכול להיות בקונטקסט של כל הפיצ'רים, אני רוצה לוודא שהם מקבלים את ההחלטות הנכונות גם אם אני לא נמצא בחדר כי הדבר הכי גרוע זה שאני פוך להיות סבר הבקבוק של הקונטקסט הזה. טעות שנייה ספק של 70 עמודים. אני נשבע לכם שהייתי בטוח שעולם הפי ארדי הולך למות לפני כמה שנים ב ת הקונספט הזה של לכתוב מסמך של 70 עמודים, ידעתי שאין שום סיכוי שמישהו יקרא את המסמך שאני כותב אבל עכשיו נהיה כל כך קל לכתוב מסמך של 70 עמודים, שאני רו מנהלי מוצר בצוותים השונים כותבים מסמכים על גבי מסמכים זאת אומרת זה לא הם שכותבים זה כלי יש להם שכותבים כלוד כותב נהדר כמה עמודים שנרצה. אבל הקטע הדי מטורף הוא שבצד השני גם אף אחד לא קורא את המסמך זאת אומרת 70 עמודים שהיא כתב נקרא על ידי 70 עמודים של הפיתוח. וכל התהליך הזה של להכניס את הסלופ למערכת גורם למה שיוצא בקצה השני להיות בינוני. והטעות הזאת שלייצר 70 עמודים של מסמך פי ארדי שלא אני בתור פרודקט קראתי ובטח ובטח שהמפתח לא קרה. גורם למצב שבו כל מה שייצא מהמסמך הזה זה דברים גנריים בינוניים שלא רלוונטיים ואני רו את הטעות הזאתי חוזרת פעם אחרי פעם אחרי פעם. שאנחנו פשוט לא מסתכלים על מה שאנחנו מייצרים ושולחים את זה ישר לפיתוח מישהו משלם על הדבר הזה מישהו הזה זה מפתחים בצד השני. אם לא מפתחים זה המשתמשים שלנו שעכשיו חווים משהו שיצא ממשהו שאף אחד לא קרה מקצה לקצה אז איך אנחנו ניגשים לה לתקן את הטעות הזאתי. אנחנו מבינים שמה שחשוב הוא לייצר את הסיפור ואת האליינמנט על מה אנחנו רוצים לבנות מבלי עכשיו לכתוב מסמך של 70 עמודים. אז איך דפאקטו עושים את זה אני רוצה לשתף אתכם.

כלי שלימדה אותי תמר שולט שהייתה מנהלת שלי בעבר, והוא כלי שנקרא ה-One Pager Feature Kickoff. זה כלי פנטסטי שעוזר רגע לייצר אליינד בין פורודק לפיתוח, מבלי להיכנס עכשיו ללכתוב 70 עמודים. אז מה אנחנו עושים בכלי הזה? אנחנו עונים על 4 שאלות פשוטות. שאלה ראשונה, מה הבעיה שאנחנו באים לפתור בעולם ה יתי? שאלה שנייה, בהנחה שפתרנו את הבעיה בצורה מושלמת, מה השתנה בעולם ה יתי? מה המוטיבציה שלנו? מה אנחנו מצפים לראות שמשתנה? דבר שלישי, זה מה אנחנו בפועל רוצים לבנות? תיאור היי-לבל של מה יהיה הפיצ'ר או מה יהיה היכולת שאנחנו בונים. וארבע, וזה בעיניי השאלה החשובה ביותר, למה זה ייקשל? לא למה הפיתוח לא יצליחו לבנות את זה, אלא למה למרות שהפיתוח בנו את זה בצורה מושלמת כמו שביקשנו, זה עדיין ייקשל? אני יודע שזה נשמע קצת באוויר, אז בואו ניתן לכם רגע דוגמה קונקרטית. אחד הפיצ'רים שהובלתי במנדי הייתה משימות אישיות, מייטאסקס, איך אנחנו יכולים לעזור למשתמשים, לתפוס את המשימות הקטנות האלה שלא שייכות לאף פרויקט, ובכל זאת לנהל את זה. עשינו מחקר וגילינו שהיכולת הזאת לתפוס את המשימות האישיות, או חוסר היכולת הזאת, גורמת למשתמשים לא להשתמש במנדי בארגונים גדולים, והם מרגישים שהם צריכים להדכן את המנדי, כדי להדכן את המנהלים שלהם, וזה גרם לבעיות באדופט'ן, אז הבעיה שבאנו לפתור הייתה, איך אנחנו עוזרים למשתמשים לתפוס במהירות את המשימות הקטנות האלה, שלא שייכות לאף משימה צוותית. עשינו מחקר וראינו שמשתמשים שבכל זאת תופסים את המשימות שלהם במנדי, משתמשים בעשרות אחוזים יותר ברמה השבועית במוצר, ו רנו שבמידה ונצליח לפתור בצורה מושלמת את הבעיה, נצליח להגדיל את כמות המשתמשים החוזרים, בבין 15 ל-25 אחוזים ברמה החודשית. מעולה. עכשיו, שאלה שלוש, מה אנחנו בונים? אז תיארתי בצורה מאוד פשוטה, אנחנו בונים רשימת משימות, שאפשר להקפיץ אותה מכל מקום במוצר, למלא את המשימה, את העדיפות, את התאריך, ולסמן אותה כבוצ או כלא בוצ . מאוד מאוד פשוט, זה הגרסה הראשונה. ועכשיו לשאלה האחרונה, למה זה ייקשל? הבנו שגם אם נפנה את הדבר הזה בצורה מושלמת, משתמשים עדיין אולי יפחדו להכניס את המשימות שלהם לעולם העבודה, לכלי של עולם העבודה, אז שמנו תגיעות שאומרות, אל תדאג, המידע הזה פרטי רק עבורך, וככה בעצם עזרנו להם להתמודד עם בעיית הטראסט. הדבר הזה אפשר לנו לייצר אליינמנט עם הצוותים, עוד לפני שנכנסתי למסמך של 70 עמודים שאף אחד אחר לא יקרא. או בציטוט שאני ממש ממש אוהב, לא היה לי זמן לכתוב מכתב קצר, אז כפתבתי מכתב ארוך, וזאת הטעות השנייה. טעות שלישית, לייצר פרוטוטייפ ולחשוב שסיימנו. כולנו מייצרים פרוטוטייפים, זה פצצה, זה מעולה, זה עוזר לנו לייצר את ההבנה של מה אנחנו מנסים לבנות, וזה דרך נהדרת לתקשר את הכיוון שלנו. אבל יש בעיה אחת עם פרוטוטייפ, והבעיה היא שזה נר גמור. ומה שקורה זה שכשאנחנו בונים עכשיו פרוטוטייפ של הפיצ'ר הבא, או של היכולת הב שאנחנו רוצים להכניס למוצר, אנחנו נכנסים לפיצ'ר. פיצ'ר הבא או של היכולת הב שאנחנו רוצים להכניס למוצר, אנחנו מרגישים שאנחנו במרחק רק של עוד כמה ימים של עבודה וזה כבר בפרודקשן. אבל יותר גרוע ממה שאנחנו מרגישים, זה מה שההנהלה מרגישה. ההנהלה רו את הפרוטוטייפ הזה שהוא 80% גמור, ואומרת יאללה בוא נדחוף את זה כבר, בוא נשחרר את הדבר הזה, ואז כל הלחץ עובר לצוות הפיתוח שלכם. הם מרגישים שהם צריכים לדלבר עכשיו בכמה ימים משהו, שבפועל צריך לקחת הרבה יותר זמן, כי מה שאנחנו רואים בפרוטוטייפ זה רק קצה הקרחון של כל התשתיות וכל העבודה שצריך לעשות, ומה שלנו היה מאוד מאוד מאוד קל לעשות במהירות, פתאום הופך להיות משימה מאוד גדולה ואז קורים אחד משני דברים, או שהפיתוח נלחצים, ועומדים בזמן ומייצרים תוצר שהוא לא מספיק טוב שמגיע ללקוחות שלנו ואז הפלב הפלב צריך לתקן, או שבמקרה שני הם מבינים ומשקפים לנו שהעבודה הרבה יותר ארוכה, ואז כולם מתאכזבים מלמה אנחנו לא מספיק מהירים בעולם הזה של AI, וכל המתחרים שלנו כבר מזמן עקפו אותנו. פה הדגש הוא שגם אם אנחנו עושים את הפרוטוטייפ אנחנו צריכים להיזהר, אנחנו צריכים להבין שהפרוטוטייפ הזה הוא מעולה לתקשר את החזון, אבל הוא לא גמור, ובהקשר הזה אני רוצה לשתף אתכם קיי סטדי עם אחד הלקוחות שעבדתי איתם אלה מנטור, שבהם זיהינו שאחד האתגרים הוא ב ת בפרוטוטייפ הזה לדבר בדיזיין סיסטם של כל החברה, אז מה עשינו? עשינו טאסק פורס עם מנהלי מוצר ודיזיינרים, ויצרנו מעטפת של סקילס שמאפשרת לוודא שכל פרוטוטייפ אחד נכנס בדיזיין סיסטם והוא מדויק, ושתיים שהוא עונה לכל המצבי קצה כמו למשל error state, empty state, כל הדברים שקלנו לשכוח בפרוטוטייפ, והדבר השלישי זה לוודא שהוא לא מנופח סתם, שלא סתם נכנסנו יכולות שלא היו בתכנון הראשוני שלנו. הדבר הזה מאפשר לנו רגע להיות מאוד מאוד מדויקים ואם אנחנו כבר בונים את הפרוטוטייפ, אנחנו רוצים לבנות אותו.

בצורה כמה שיותר שלמה כדי לוודא שלא הפכנו את זה לקל מדי ולא דפקנו את הצוות פיתוח שלנו עם פרוטוטייפ שנר גמור אבל הוא רחוק שנות אור ממה שהלקוחות שלנו מצפים. גם אחרי שבנינו את הפרוטוטייפ לפי הדיזיין סיסטם שלנו זה לא מספיק אנחנו רוצים לעזר בפיתוח ולבנות את הפרוטוטייפ על הקודבייס הקיים במקומות שבהם אפשר, לא בכל ארגון אפשר לחבר ושאפי ים יוכלו לרוץ על הקודבייס אבל במקומות שכן אפשר כמה שיותר יתי על הקודבייס הקיים מאפשר לייצר שפה משותפת, אני לא מצפה שהמפתחים השתמשו במה שבניתי בפרוטוטייפ הזה מבחינתי שזרקו אותם אבל זה שבניתי את זה לקודבייס עזר לי להתמודד עם כל האתגרים ולראות, מה אפשרי ומה לא אפשרי והוריד את החיכוך ואני חושב שאחת התובנות המרכזיות מהדבר הזה היה בעבודה עם צוות אינג'נירינג ש ר לי, אני לא רוצה לעשות ריברס אינג'נירינג למה שהפרודקט עשה תנו לי לעשות פשוט את האינג'נירינג וזה בדיוק מה שהייתי רוצה תשתמשו בפרוטוטייפ כדי לתקשר מה אתם רוצים לעשות מקצה לקצה, אבל אל תספרו שהפיתוח ישתמשו בזה אם הם משתמשים והם רוצים יופי זה בונוס אבל זה לא ההישג הנדרש. טעות רביעית אנחנו מתבלבלים בין ownership לבין קריישן. מה זה אומר אנחנו עכשיו בצוותי המוצר פרודקט דיזיין ופיתוח כולנו מרגישים שהגבולות התשתשו. המפתח עושה קצת פרודקט הפרודקט עושה קצת דיזיין והדיזיינר עושה קצת פיתוח ובמקרה הזה נהיה בלבול אוקיי. כולנו עכשיו יצרנו דברים אבל מי ב ת אחראי על מה שיצרנו ופה אני רו הרבה מוצבים מוצר נופלים הבלבול הזה של בן. אם אני יצרתי האם זה אומר שאני אחראי ופה אני בא להגיד לא בוא נגדיר קודם כל את ההבדל. יצירה זה מי יכול להשתמש וליצור את מה שרצינו מי יכול ליצור את הפרוטוטייפ בדיזיין סיסטם מי יכול להגדיר את עולם הבעיה. אבל אונרשיפ זה מי קם בלילה כשיש בעיה אם עכשיו אני בתור פרודקט דחפתי קוד לפרודקשן. אני הקרייטור אבל אני לא אונר מי שהאונר זה הפיתוח לעומת זאת אם אני עכשיו המפתח עבד ועשה פיצ'ר והשתמש בדיזיין סיסטם. הוא הקרייטור אבל מי שהאונר על החוויה העיצובית הוא המעצב ובהקשר הזה זה משנה קצת את התפקיד שלנו כלומר אני לא רוצה שכל אחד יישאר בגבולות הסגורים שלו ולא יזוז אנחנו ממש מפספסים. את כל היתרון שהיה עם מאפשר לנו אני רוצה את התזוזה הזאת אני רוצה את הגבולות המורבבים אבל הדרך לתקן את זה. זה להבין איך אנחנו יכולים לעזור לשאר הצוותים ולשאר אנשים בצוות לייצר ברמה מספיק גבוהה. עדיין הבעלות היא שלי אז אני אתן כמה דוגמאות למשל דיזיינר ייצר לי עכשיו כמה סאב אייג'נס שיעשו לי ריוויו לחוויית המשתמש הוא עדיין יהיה אונר של מה שיצא אבל הוא מאפשר לי את הכלים. לעשות ריוויו בעצמי כאילו הייתי יושב איתו או לדוגמא עכשיו הפיתוח אם אני רוצה עכשיו לדחוף משהו בקודבייס הקיים אז בפיתוח יהיו כל מיני רולים שיבדו שאני לא אורג את מה שיש עכשיו בפרודקשן. יהיו לי כל מיני טסטים שאני צריך לוודא שאני עומד בדבר הזה וגם בעולם של המוצר אם אני מאפשר עכשיו למפתחים לרוץ עם הפיצ'ר לבד. אני אתן להם את הסקילס כדי לוודא שהם יודעים למדוד הצלחה גם אם אני לא ישבתי את המחדר אני עדיין האונר שלי מהצלחה קראתה או לא קראתה. אבל יכול לשחרר את היצירה לאנשים אחרים בצוות ואני רוצה להרחיב את זה מדוגמה ששמעתי ממנהל המוצר מסטרייפ. הם נכנסו לעולם של מיניון שזה בעצם אגנטים קטנים שיכולים לבנות להם את הקוד ואחד הפעמים שמה רץ בטירוף בנה ובנה ובנה. עד שיום אחד אחד מהחברים באנג'יניארס עצר אותו לא תקשיב זה לא מה שאני צריך ממך אני כבר יודע להרים 10 20 50 אגנטים ולבנות מה שאתה רוצה במהירות האור. מה שאני צריך ממך שתעזור לי להבין לאן ללכת וזה בדיוק ההבדל בין מי יוצר לבין מי האונר. אני יכול ליצור אבל זה לא המקום שאני צריך להתמקד בו אני צריך להיות האונר של עולם הבעיה ושל איך נדע שהצלחנו ולא להיות זה שכותב את הפיצ'רים בכך. טעות חמישית האבלים שאנחנו בונים בודקים את התוצר ולא את האימפקט של המוצר שלנו מה זה אומר. כולנו עכשיו בונים מלא מלא מוצרי איי וזה מבורך וזה מצוין וכבר כולנו עברנו את המדרגה שאנחנו מבינים שאנחנו צריכים לבנות כלי איווליאציה כדי להאריך את התוצאות של איי. למה כי היה לא דטרמיניסטי ואנחנו יודעים כל פעם התוצ יכולה להיות אחרת. אנחנו מבינים למרות שהתוצ היא כל פעם יכולה להיות אחרת היא עדיין קונסיסטנטית, אני לא רוצה שאם משתמש אלי פנה לסאפורט אז פעם אחת הוא יקבל תשובה על הטיקט שלו ופעם שניה הוא יקבל מתכון להוגה, זה לא מה שאני רוצה אני רוצה שבכל פעם הוא יקבל תשובה לה תקת שלו אבל.

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