121: איך בונים פיצ׳ר מנצח - שלב אחר שלב (חלק 2)

אנחנו מדברים על שלבי העיצוב, תכנון טכני, execution ושחרור של פיצ׳ר - וכיצד עושים עליהם איטרציות ועובדים עם פידבקים. אורחים: שירלי באומר, Group Product Manager ואורון מורד, Group Engineering Manager במאנדיי.קום

How does a feature’s design impact its technical planning and vice versa? What happens when you release a feature before it’s ready? And how can we make sure our feature solves the problem we identified?

So you had a feature idea. You researched and planned it, defined the problem and even created an outline of how it will look like. Last week we talked about this process, and one might think you’re pretty much done with it, and now you can just - develop it. But to reach from this stage to actually having a fully working feature - you still need to go a long way.

This week, in part 2 of the episode, we move from the “trailer” to the real deal: design, technical planning, execution, release, and gathering feedback. In the episode, Darya Wertheim talks to Shirley Baumer, Group Product Manager, and Oron Morad, Group Engineering Manager at monday.com. They discuss all the mini-lessons we have learned from the advanced stages of building a feature - lessons that we gathered from all the mistakes and successes we’ve experienced along the way.

---

For more relevant episodes:

120: Building a winning feature - step by step (part 1)

4: step by step - how do we do product in monday.com

To all of our product episodes

Episode transcript

Automatically transcribed — it may contain errors.

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

את צריך לקבל מה שאנחנו קוראים לו ולידציה לפיצ'ר. בסוף עד מחר אתה יכול להביא פתרון ואני אגיד זה טוב, או אני אגיד זה לא טוב, מישהו שלישי יגיד אני אוהבת זה, אני לא אוהבת זה. אף אחד מאיתנו לא ב ת יודע. אז דיזיין טוב זה דיזיין שיש לו ולידציה. נגיד אני אתן את הדוגמה של ה-workload. ב-workload ב ת, כמו ש רתי, הרבה מהפתרון נשען ממש על הפיצוח הוויזואלי של הדבר הזה. נתנו איזשהו פיצוח ראשוני, ובהתחלה מה שעשינו זה כזה תפסנו כל מיני אנשים במשרד, ממש, כאילו מייג'ר מאופיריישן, אנשים שלא טקים כל כך ולא חיים ונושמים את המוצר, ו רנו תגידו מה אתם מבינים מפה. והם לא הבינו. אנחנו חשבנו שזה פתרון מעולה, הוא נורא נורא יפה, התלהבנו ממנו, נורא פשוט לא הבינו בסוף טקטית. לא הבינו מה צריך לעשות. מה זה אומר לי בכלל, והוא נורא נורא מבולבלים. לקחנו ועשינו על זה עוד כמה איטרציות. ואז אחר כך כשהגענו לפתרון שפנימית הרגשנו שהוא כן כזה דוקר וכבר התכווננו, השתמשנו בכלי שנקרא יוזביליטיאב. זה בעצם מוצר שאפשר לתת בו פתרון ולקבל מיוזרים או מיוזרים שהחברה הזאת מגייסת או מיוזרים שלנו, איזושהי ולידציה בסקייל. אז ממש תכננו איזושהי שאלה, היה לנו שלוש גרסאות. כל גרסה הייתה שונה במשהו אחד, אחת בצבע, אחת קצת כאילו בוויזואליזציה. ושמנו שאלות נורא חדות וקונקרטיות. כאילו נגיד בעיצוב הזה, סתם, בשביעי באוגוסט, מי הבן אדם הכי עסוק? ממש לראות אם הם מבינים איך להשתמש בפיצ'ר הזה. ממש. לא לשאול מה יותר יפה בעיניך. בדיוק, הכי הכי קונקרטי שיש. מי יותר פנוי, ג'סיקה או בוב? בסדר? ואז זה נורא מגניב, כי את יוכלה לראות ממש אחוזי הצלחה. כי יוכלה לעשות את זה פתאום בסקייל, את יוכלה לשלוח את זה ל-200 יוזרים פתאום. ולראות, הנה, בגרסה הראשונה, 60 אחוז הצליחו לענות על זה. בגרסה השנייה, 90 אחוז הצליחו לעשות על זה. מגניב, כנר שהגרסה השנייה היא יותר טובה. יש ב ת כמות מינימלית של אנשים שאנחנו חייבים לבדוק את זה עליהם, לפני שאנחנו משחררים? כלל האצבע זה שאם אנחנו מסתכלים על יוזרים, אנחנו נרצה להסתכל לפחות על חמישה. אבל שוב, בכלים כאלה חיצוניים שאפשר לקבל גם בסקייל, יש להם חסרונות אחרים. אפשר ממש לעשות בכיף על 100-200 יוזרים, ומקבלים תשובות תוך שעה. אז מה זה כיף? כאילו, אנחנו זורקים משהו, תוך שעה יש לנו פתרון. והדבר הזה הוא גם מאוד מפקס צוות, כי אחרת אפשר לעשות דיונים על דיונים, על דיונים עד אינסוף, אתה בלופ, כולם סובלים. זה יכול להיות שחזרת ש… זה נורא יפה כשזה עיגול, אבל אף אחד לא יצליח להבין איך משתמשים בזה, כי זה מבלבל את כולם, אז אתה חייב לשנות את מה שאתה חושב. כן, והדברים האלה פשוט גוזלים מאינסוף זמן. כאילו, גם כמו ש רתי בדיונים, וגם בסוף באקסיקיושן של פיתוח, כאילו, זה בדיוק הדברים, כאילו, הטוויקים הקטנים האלה של ה-UI, ששעה ללכת איתם הלוך חזור, הלוך חזור, הלוך חזור לפיתוח, ולבזבז עליהם שבועות רבות של עבודה, במקום בכמה דקות לקבל את התוצ וכבר כשהולכים ומפתחים משהו, אתה כבר שרפ, אתה כבר פוגע בול. יש איזה שהם pitfalls בשלב הזה? כן, אז לא לעשות ולידציה, כאילו, מה ש רנו, פשוט לחשוב… להחליט שמשהו נר טוב ולרוץ על זה. להחליט שאני אוהב את זה, יאללה, בוא נרוץ על זה. אני חושבת שמה שיכול לעזור זה לתת לפעמים שתיים-שלוש גרסאות, כדי להצליח להסביר את ההבדלים ביניהם. אני חושבת שיש לפעמים מעצבים שממציאים כל מיני התנהגויות UI שלא קיימות במערכת, ואז יוזרים לא מכירים אותם, סתם נגיד לנו במערכת, עוד עד עכשיו לא היה toggle. אז לעשות toggle זה לא טוב, כי אנשים לא מכירים אותו. לוודא שזה קונסיסטנטי עם המוצר. עוד pitfalls זה ללכת לאיבוד בולידציה, כמו ש רנו מקודם, וצריך לזכור שהוולידציה ממשיכה להגיע גם בשלבים הבאים. צריכים להגיע למשהו שנר לנו טוב, שעבר את השלבים האלה, ושפשוט נוכל לבנות עליו ולקבל עליו עוד צימוכין בשלבים הבאים. כן, זה נקודה מעולה, אנחנו אף פעם לא מפסיקים לבחון את הפיצ'ר ב ת. בדיוק. אוקיי, אז איך אני יודעת שאני יכולה, הגיע הזמן לעבור לשלב התכנון הטכני? אז בלי לשים לב, התכנון הטכני בעצם קרה לנו במקביל בזמן הדיזיין, דיברנו על זה עכשיו המון. זה שלבים שקורים ביחד, מזינים אחד את השני, ובדרך כלל כשאנחנו מסיימים, אנחנו מסיימים את שני השלבים האלה כמעט ביחד. כי בעצם לכל עיצוב יש משמעויות פיתוחיות שהן קצת אחרות. לגמרי. נכון, ולעומת זאת יש הרבה דברים שכבר אפשר להתקדם, זה לא תמיד שלב חוסם, זאת אומרת יש הרבה דברים שאפשר להתקדם בעיצוב הטכני, בלי לסגור את כל המיני מיני פינות של ה… לא חייבים להחליט באיזה…

זה היה האיגול של ה-workload, כדי כבר לתכנן שזה הולך להיות על התשתית של הדשבורדים, ואיך נפתור את זה וכו וכו. זה אפילו סימן של דיזיין טכניק טוב, שהוא לא משתנה על כל פרט קטן שמשתנה בדרישות או בעיצוב. אז בעצם לשלב התכנון הטכני, אתה מגיע אורון, שכבר יש לך, זה לא פעם ראשונה שאתה פוגש את הפיצ'ר הזה, נכון? למעשה כבר הרוב סגור בראש. אנחנו הזנו את התהליך הזה במקביל, וכשאנחנו מסיימים את התהליך הטכני, הוא בעצם ב-eye level יודעים מה אנחנו הולכים לעשות, באיזה תשתיות במוצר אנחנו הולכים להשתמש. דיזיין טכני שכולם יודעים בגדול איך הולכים לפתור את זה. הערכה כללית של הזמנים, יש לנו את הדברים האלה, ואפשר לעבור לשלב הבא. אז בואו ככה נסכם את שלב הפתרון, שהוא היה מורכב משלושה תתי שלבים, נכון? שזה השייפינג, הייצוב והתכנון הטכני. איך אני יודעת שכל השלב הזה נגמר והגיע הזמן ממש להתחיל לשבת ולכתוב קוד? אז ממש אפשר להסתכל על זה בתור הנקודה בזמן שיש לנו דיזיין או פיגמה שהיא כן כבר יחסית פיקסל פרפקט ומר את הדברים בדיוק איך שאנחנו רוצים לעשות אותם. דיזיין טכני שכולם יודעים בגדול איך הולכים לפתור את זה, אני פותר אותם בצורה שאנחנו חווים לקרוא לה לפעמים אפילו quick and dirty, אבל כשסיימתי אני יודע שבדיוק מה אני צריך לעשות, בדיוק מה האזורים שיקחו יותר זמן ופחות זמן ויש פיצ'ר שעובד שאפשר כבר להתחיל לשחק בו ואפשר להתנסות בו ומכאן כל שלב הוא הצלחה כי אני כבר לא דואג, אני כבר יודע שעכשיו בכל נקודה שאני הולך לפנש אותה ואני נהנה ממנה ומתקדם לשלב הבא. אבל למה לא ללכת בגישה הפוכה, למה לא לקחת את כל השלבים השונים של הפיצ'ר ולעשות דיב דאב ממש לתוך כל אחד מהם שהוא יהיה מושלם מבחינת ביצוע? כי בצורה הזאת אתה לפעמים פוגש unknowns בשלב מאוד מאוד מאוחר ופתאום צריך לזכור שאנחנו בכל שלב עושים ולידציה לשלב הקודם ופתאום אחרי אפילו שבוע או שבועיים של פיתוח מפיצ'ר ש ור לקחת שלושה שבועות אני ניגש למקום שמה לעשות פספסתי אותו, לא הבנתי אותו עד הסוף ועכשיו ייקח לי שבועיים של עבודה או שלושה שבועות של עבודה כדי לסיים אותו. אני מחזור אחורה ולתקן את מה ש… בדיוק. יש גם עוד יתרונות נלווים מעבר לפן הטכני אם אחזור שוב ל-workload אז היה לנו פה תהליך מאוד מגניב לדעתי התחלנו תכננו, חשבנו שזה ייקח לנו כמה חודשים טובים ואז יצאנו איזושהי פגישה עם טל, דניאל נחשבת, הטק ליץ וויפי ארניב וכאילו מין התגרו את הגישה שלנו, נכון? כאילו רו עזבו אתכם כמה חודשים, מה אתם יכולים לעשות עד הסוף שבוע? היינו ביום שלישי לדעתי וכאילו קצת נכנסו לשוק תכננתם פיתוח של כמה חודשים לפיצ'ר הזה? לגמרי. והם רו לכם עד הסוף שבוע יש משהו. מה אנחנו יכולים לעשות עד הסוף שבוע וזה ב ת קצת כזה שינה כזה, פתאום אתה צריך…

את חייבת לשנות לגמרי את המיינדסט ומה שיצאנו איתו זה הקטון של יומיים, שישבנו כל הצוות ובדיוק עשינו את הדבר הזה. הצלחנו להגיע לאיזשהו פתרון שהוא עוד לא מושלם, יש לו מלא בעיות, יהיה לו באגים וכו' וכו', אבל בסוף היומיים האלה, זה היה אחד היומיים הכי כיפים שהיו לי במאנדיה אני חושבת, בסוף היומיים האלה היה לנו מוצר שעובד. אגב, כבר להקטון הבאנו יוזרים. שתוך כדי שהחבר'ה מקודדים, כאילו הבאתי להם יוזר לתוך חדר שבא והסתכל ותה את רגלנו עדיין כי הקוד היה זה זה וזה וזה וזה, אבל כשכבר הסתכל, כבר נתן פידבקים וזה היה מדהים. אבל אני מתארת לעצמי סיטואציה שמביאים, אוקיי, יוצרים איזושהי גרסה שהיא מאוד רף, משחררים אותה ליוזרים ואז הם נותנים פידבקים ואני בצד השני מקבלת הפידבק ואני אומרת טוב אני יודעת אבל שאני צריכה לשפר את איקס, אני יודעת שאני צריכה עוד לעשות שינוי בעיצוב, אני יודעת שאני צריכה ככה. זה לא מוקדם מדי? אז זאת נקודה ממש טובה. בכל שלב כזה שאת רוצה לקבל את הולידציה את יודעת מה הדברים שאת רוצה לקבל עליהם את הפידבק ומה לא. ועל זה את שמה את הדגש. אז כששירלי הבי את היוזר הזה ביום השני של האקטון, שבאותו רגע זה היה נר כאילו זה היה בלי הכנה, רגע הוא מגיע. כן גם לא רתי להם שתביאתי אותו. בדיוק פשוט הוא הגיע. קחו. הנה אנחנו פה איזה כנס של היוזרים, האדם גם ה ריקאי. אבל הוא בא ותוך 20 דקות של שיחה היה לנו פידבק שהוא ממש משמעותי למה שאנחנו היינו צריכים, ידענו לכוון אותו. ובדיוק להגיד, מה מוכן, מה לא מוכן, איפה אנחנו רוצים את הוולידציה. וכשאתה עושה את השלב הזה אז מקבלים פידבק שהוא מאוד מאוד רלוונטי לשלב שאתה נמצא בו. אז לא סתם לוקחים יוזר ואומרים לו תגיד לנו מה אתה חושב. גם יש פה אגב אספקט של פשוט כיף ומוטיבציה. את כבר רו את זה גמור. יש לנו פה את הרכבת הקלה, אנחנו רואים אותה כל היום מחוץ בחלון. אז בדיוק לא לעשות את זה, זה לא לחפור את הבור ואז להניח את הסילות ואחרי שלוש שנים מתישהו, שלוש עשרים תהיה רכבת. אפשר להביא בינתיים, יש איזה רכבת מקרטט שאפשר לראות אותה נוסעת כל פעם במקום? אתה חושב שאתה תהיה רכבת ואז אתה תגלה שהיא לא נוסעת טוב. בדיוק. הפרקטיס של ההקתון הזה הוא עושה הרבה דברים טובים. קודם כל כל הצוות פשוט ישב כמה ימים ונגע בפיצ'ר וכולם מכירים כבר את הכל. אין איזשהו שלב של לעשות רמפאפ לכל הצוות. דבר שני זה ב ת הכיף והאנרגיות שתוך כדי ההקתון שולחים כל מיני סרטונים בסלק, מקבלים ככה את הרוח הגבית. וצריך לזכור שההקתון, זאת אומרת זה דברים שבסוף אנחנו עושים ונכנסים לפרודקשן וזה לא איזה קוד שאנחנו בסוף שורקים אותו, יש הרבה מחשבות על ההקתון של טוב, עשינו, נמחק את הכל אחרי זה נעשה את זה כמו שצריך. ממש לא, זה פשוט מפקס אותך, זה עוזר לך לגעת במקומות הכי רלוונטיים שאתה צריך לעשות אותם בהתחלה של הפיצ'ר. וכשאתה יוצא מההקתון אתה מתחיל לבנות את כל הריפוד ואת כל העבודה מסביב למקומות שנגעת בהם. זאת אומרת זה שאני בונה את זה רף זה לא אומר שאני בונה את זה לא טוב ואחר כך אני צריך לחזור ולתקן, אלא אני פשוט מתמקדת בדברים הכי הכי חשובים במוצר. מדויק, אנחנו אפילו כתבנו מעט טסטים תוך כדי ההקתון בשלבים שעזרו לנו. ובשלב של ההמשך הלכנו והבנו את זה ועשינו עוד כל מיני דברים שהיה צריך לתמוך בקוד שכתבנו בשבוע שלפני. וגם כל ה-state of mind, כאילו משהו נחמד שעשינו בההקתון הזה ומאז לקחנו לו עוד הרבה מאוד פרויקטים. ובתחילת היום היה מצגת עם סלייד אחד ש ר מה יהיה awesome אם נגיע אליו, מה יהיה unbelievable ומה יהיה mind-blowing. זה לא היה must have, זה לא היה היי פריוריטי. לא, זה יהיה מדהים, כאילו חשוב גם מה המסר שזה, גיאז, זה יהיה מדהים, זה יהיה awesome אם בסוף היום נגיע לזה אבל זה יהיה ויפוצץ את המוח אם בסוף נגיע לשלב האחרון וגס וואט, בסוף היום הזה הגענו לשלב ה-mind-blowing שאם היו אומרים לנו את זה בהתחלה זה היה נשמע הזוי ואנחנו לקח את חודשיים. אני כתבתי את המצגת הזה, זה היה נשמע הזוי שבכלל נגיע לשלב הראשון, ב ת אני אומרת. כשאנשים עם מוטיבציה ואנשים מבינים מה הם עושים זה בכלל לא באותו סקאלה של יכולות וקצב. במיוחד כי כולם היו חלק מהתהליך מההתחלה. בדיוק. אבל אני רוצה להתעכב על עוד צד של הדבר הזה שמעבר לזה שזה נותן מוטיבציה וזה מדהים לראות משהו שהוא מתממש, זה בטוח גם חושף מלא מלא ענון, זה סתם כזה במשפט אבל זה לדעתי ממש

זה משהו שמאוד מאוד חשוב להגיד, כי אני זוכרת מהחברה הקודמת שלי שתכננו משהו, והיה לנו ברור איך זה יר ורק ברגע שפיתחנו את זה, פתאום קלטנו על כמה דברים לא חשבנו, על כמה סנאריוז, שזה דברים שרואים רק אחרי שהם ב ת ניגשים לפתח, נכון? לגמרי, וזה היתרון בלעשות את הדברים בצורה הזאת, שכל שלב הוא אינקרמנטלי, והוא עושה ולידציה על השלב הקודם, והוא שנייה מאתגר עוד פעם את ההנחות יסוד. יש מצבים שבהם רגע הבנו שמשתנה סקופ, וכן החלטנו גם לשנות את האפתייט, ויש מצבים שהחלטנו גם אחרי איזשהו הקטון קצר, לעצור רגע לשנות כיוון ולעשות משהו אחר. תן לי דוגמה כשזה לא עבד. מתי נפלנו בדבר הזה? מתי עשינו את זה לא כמו שצריך? אז דוגמה לזה זה פיצ'ר אחר שנקרא סאב אייטמס, שהפיצ'ר הזה זה בעצם יכולת לעשות עוד היררכיה קטנה בתוך הבורד שלי, שלכל אייטם יכול להיפתח ויהיו לו עוד אייטמים קטנים, תת אייטמים קטנים שקשורים אליו. בפיצ'ר הזה הגענו ממש ממש מאוחר ליוזרים. עם הקוד ה יתי שרץ בפרודקשן עבדנו המון המון זמן, אפילו כמה חודשים, עד שהתחלנו לפגוש יוזרים. לנו היה בראש רשימת תעדופים שכבר ממש התחלנו לעבוד עליה, מה נר לנו יותר חשוב, מה פחות חשוב. כשהדבר הזה פגש יוזרים, קיבלנו רשימה אחרת לגמרי. ובאותה נקודה ממש היינו צריכים רגע לעצור, לחזור אחורה, לפתח דברים שהחלטנו לפתח אותם הרבה יותר מאוחר, והיו דברים שפיתחנו שאולי היינו צריכים לפתח אותם באותו שלב. וזה ממש העט ועריך את הזמן עד שהגענו עם המוצר הסופי לפרודקשן. אגב, סימן שיש איזושהי בעיה באקסיקיושן, איש שהוא פשוט נמרח על גבי המון המון זמן. נגיד הסאב אייטמים זה מוצר שפיתחנו במשך יותר משנה. זאת אומרת שוב, לא רק אקסקלוסיבית, עשינו גם דברים בנוסף, אבל הדרך הכי טובה לחשוב על זה זה ששנה ומשהו אחרי שיצאנו לדרך, שנה וחצי, עדיין יש בית אפלג על הפיצ'ר. זה סימן לא טוב, זה סימן שמשהו בתהליך בכבש. ומה, כי לא הגדרתם את האפיטייט כמו שצריך? אין סוף סיבות, כאילו מאיזה שלא הבנו נכון את האימפקט. פה דווקא דוגמה הפוכה למה ש רנו על הפילטרים. לדעתי, על הסאב אייטמים היה אימפקט מטורף על המוצר, ואם היינו מצליחים בצורה הטובה להסביר את זה לעצמנו ולעולם, היה לנו יותר לגיטימציה להמשיך לעבוד עליו, כי מה שקרה זה ששחררנו איזושהי גרסה, היא לא הייתה מספיק טובה, אז רנו טוב, די, כבר רשענו על זה כל כך הרבה זמן, בואו נעבור לדבר הבא. וזה המשיך לקבל ריקושתים ולהעלות לנו בהמון המון המון בעיות טכניות, באגים, פידבקים מיוזרים, מיוזרים מאוחזבים, מתוסכלים, ואם מראש היינו מצליחים להגדיר, זה הדבר הכי חשוב שאנחנו יכולים לעשות, בואו לא נשחרר עד שזה לא יהיה מעולה, זה היה נר אחרת לגמרי, וב ת זה מוצר שנמרח ונמרח ונמרח, אני חושבת שאחת המסקנות המשמעותיות שלנו כאילו מאז, זה להיות ב-state of mind יותר של כזה פוקוס, וגם אם זה אומר לקחת את כל הצוות על משהו, זה סבבה. אז בואו ב ת נדבר על זה, מתי מגיע השלב הזה שבאים ואומרים, אוקיי, פיתחנו מספיק, עכשיו משחררים. אז זה קצת מתקשר בעצם לדפינישן עובדן של שלב ארבע, כאילו שאולי נגיד מה זה לא, מה לא הדפינישן עובדן של שלב ארבע, זה לא מוצר מוכן, גמור, פגשת יוזרים, ואנחנו עוברים כבר למוצר הבא. אז מה זה כן? זה כמעט שם. זה פיצ'ר שההנחות יסוד הגדולות שלנו כבר ביססנו, הוא עובד, הוא טוב, והוא מוכן לפגוש יוזרים בסקל קצת יותר גבוה. שאנחנו מוכנים לזה שיכול להיות שהם השתמשו בזה ודברים לא יעבדו כמו שצריך? כן. תראי, כאילו את הפיצ'רים הטובים שלנו, פיתחנו לא בזבנג אחד וגמרנו, ישבנו כמה חודשים, יוצאנו ליוזרים, זהו, אלא בעשרים חלקים שונים. כאילו כל פעם עוד חתיכה, ואז עשינו תמידי שלבים האלה. מה הבעיה? מה הוולידציה? מה הפידבק? יאללה. לפעמים זה ממש קורה ברמה של היומיומית. עכשיו אנחנו, כמו שהורן ר, עובדים נגיד על פיצ'ר של My Work. החבר'ה יושבים וכותבים את הקוד. בינתיים הייצוב הולכים ועושים בדיקות יוזביליות, ומקבלים כזה פידבקים קטנים, והם משנים את המוצר, טיפה משנים את הקופי, משנים את ה-UI, כדי שהוא יהיה יותר ברור. זה כזה מין לופים נורא נורא נורא קטנים. ב ת הפחד הזה של לשחרר משהו שהוא יהיה לא טוב, ואז נקבל מלא פידבקים, כאילו בחברה גדולה זה לקבל, זה יכול להיות אלפי פידבקים לא טובים, בחברה קטנה זה יכול להגיד וואי, אני מאבדת פה את הלקוחות הפוטנציאליים הראשונים שלי. אין את הפחד הזה כל הזמן? יש את הפחד הזה, וזה מאוד אנושי.

אבל צריך להיות מודעים אליו ולהכיל אותו, כי הפחד הזה זה מה שגורם לנו לעשות מוצרים גרועים בסוף. ושוב, להישאר בראש של עצמנו ולעבוד אינסוף זמן על משהו, רק כדי לגלות שהוא לא מעניין אף אחד. ופה ב ת נכנס השלב האחרון הזה, או השלב הראשון בפייז הבא של הריליס והפידבק, שגם אותו צריך לדעת לעשות. אז שלב הריליס הייתי אומרת ביילבל, כאילו הפיטפולים המרכזיים זה ללכת לשני קיצונים שונים. אחד זה לא לשחרר משהו אינסוף זמן ולהגיע לשוק כמו שדיברנו, והשלב השני זה לפתוח את זה במכה ל-100% מהיוזרים, ואז כנר לקבל מלא מלא פיקושטים, יש לי מלא בגים, המערכת קורסת, זה גרוע, אתם גרועים. זה גם קרה לנו. אז איך עושים את זה? אני חושבת שהדרך הכי טובה שאנחנו מצאנו כדי להתגבר בדיוק על המתח הזה ש רת, זה מה שאנחנו קוראים לו gradual release, פשוט לשחרר את זה הדרגתית, ובכל אחד מהשלבים להצליח לקבל את הפידבק הרלוונטי. אז נחזור לדוגמה של ה-workload, כדי לקרקע את זה קצת. אז כבר דיברנו על זה קודם, נכון? אבל התחלנו לקבל את הוולידציה בשלב נורא נורא ראשוני, בשלב רק שהיה לנו איזשהו עיצוב, ואז כזה תפסנו אוריאל ב-vp operation שמתעסק בזה, פגשנו, תפסנו כל מיני אנשים בחברה, שלב ראשון זה ממש כזה. שלב השני, כבר פתחנו את זה ל-usability app לכל מיני לקוחות, כדי שיתנו פידבק יותר בסקל. אחר כך בדקנו את זה על יוזרים יתיים, בין אם זה מי שתפסתי באוזן והבאתי לחדר, ובין אם זה ממש אנשים שיעלנו לזום, תוך כדי שיש חבר'ה יושבים ומתכנתים, אבל ממש משהו מאוד מאוד ספרדי, שרק יודע לתת פידבק על הפונקציוניאליות הכי בסיסית, זה פתר לי את הבעיה או לא פתר לי את הבעיה, ממש ברמה הזאת. אחר כך היה לנו שלב של Alpha Users, שבעצם ביקשנו גם מהחבר'ה של ה-CS וגם מהחבר'ה של ה-Sales, להביא לנו לקוחות רלוונטיים. זה ממש אוספים לקוחות שהם יודעים שיכולים להשתמש בפיצ'ר הזה, ומבקשים להם לתת פידבק. בדיוק, אז היה לנו ממש אצלנו בורד, זה לא משנה זכות אקסל או כל רשימה אחרת, של יוזרים כאלה, זה בדרך כלל לא המון, זה אידיאלית הייתי אומרת בין עשרה לחמישים, משהו כזה, יוזרים שאנחנו יודעים שהם מאוד מאוד רלוונטיים, ואנחנו רוצים שהם כבר יבדקו את המוצר live, לא פרוטוטייפ, עם הדאטה שלהם, בחשבון שלהם ושיעבדו איתו. אוקיי, ולחבר'ה האלה אנחנו עושים טיום ציפיות ממש ברור, שזה בטא, אתם שותפי פיתוח שלנו, אתם עובדים איתנו, ואנחנו מאוד מאוד במה שאוכלנו היי טאצ' איתם, אנחנו כל הזמן מדברים איתם, אנחנו מבינים את הפידבק שלהם וכו' וכו'. אז זה כבר נותן לנו איזושהי אינדיקציה די טובה אם אנחנו בכלל פגענו או לא פגענו, אנחנו בכיוון או לא בכיוון. אחר כך, אחרי שהרגשנו שאנחנו קיבלנו את הפידבק, תיקנו, שינינו וכו' וכו', כמובן שהדברים ישנות, עברנו לשלב הבא, והשלב הבא זה להתחיל לפתוח את זה לכל האוכלוסייה בהדרגה. אז בשלב הראשון, לדעתי פתחנו את זה ל-10% מהיוזרים, משהו כזה. למה גם כאן עושים את זה בהדרגה? מרגיש לי שעשיתם כבר כל כך הרבה מבחנים עד עכשיו שאתם כבר ורים להיות די סגורים בשלב הזה. משתי סיבות. דבר ראשון, האנשים שאנחנו דיברנו איתם הם גם אנשים מאוד מאוד ספציפיים, שאנחנו יודעים שהם מאוד היו צריכים את הפיצ'ר ויש להם טיום ציפיות, והסיבה השנייה זה ב ת לוודא שאנחנו לא עושים משהו שפתאום הפעיל את המערכת. בהקשר הזה אפילו משהו ששמנו לב, כל דבר שבסוף נכנס למוצר אנשים משתמשים בו. והנושא הזה של הריסק מנג'מנט אומר שאני אפתח את זה נגיד ל-10% מהיוזרים שלי, ואם יש שם בעיות אז אני אגלה את זה שם, לעומת פתחתי את זה ל-100%, כמויות של יוזרים התחילו להשתמש בו וגילו משהו שהוא מאוד מאוד מאכזב, ועכשיו כאילו הנזק הוא הרבה יותר גדול. כי כולם כבר גילו את זה בעצם. בדיוק. וגם קשה לקבל הזדמנות שנייה, וגם זה מהמסע כאילו שיכול להיות מאוד מהמסע טכנית של טיקטים ובאגים ודברים כאלה. תוך כדי שמרחיבים את המעגל שהיוזרים חשפים אליו, יש דרכים שונות לאסוף את הפידבק. כמו ש רנו בהתחלה, זה בטאץ' מאוד גבוה, אתה יושב עם היוזר, אתה פותח איתו ביחד את הפיצ'ר, אומר לו אוקיי תעשה רפרש, עכשיו אתה תר את הפיצ'ר ואתה ממש בוחן את איך שהוא פוגש את הפיצ'ר הזה בפעם הראשונה. לעומת שלבים יותר מאוחרים.

שבהם אתה לפעמים אפילו מוסיף כפתור פידבק, ואז אתה מתחיל לקבל את הדברים יותר במסות ועושה עליהם סטטיסטיקות. אז פה גם, כאילו, אנחנו אוהבים כזה לעשות אינטגרציה לסלק, וכאילו, הצוות כזה מחובר לסלק הזה ורו את כל הפידבקים במקום. ברגע שנכנס משהו, ישר על זה. בדיוק, וכל כמה זמן מקבלים רגע סיכום של הדברים, עושים אותו ביחד ומבינים איך להתקדם. משלבים יותר מאוחרים, פותחים פוסט בקומיוניטי, יש לנו פורומים כאלה של היוזרים ומתחילים לקבל שם כל מיני שיחות ופידבקים. לעומת השלבים הם ממש סופיים, או אפילו כשהפיצ'ר רץ, זה בתקשורת הרגילה עם היוזרים, שפותחים לנו כל מיני פניות, עוברים דרך הספורט. כן, אבל זה נקודה מעולה של אתם כל הזמן מתקשרים גם את זה שאתם רוצים פידבק, אתם לא רק משחררים את זה לעולם וכזה, טוב, בוא נר אם הם משתמשים בזה או לא, אלא ממש מעודדים אותם לגמרי. דיברנו הרבה על האפקט של זה בתוך הצוות, אבל צריך לזכור גם את האפקט על היוזרים, שלאורך כל הדרך הם מרגישים חלק ממי שבנה את המוצר וממי שהשפיע על איך שהדברים האלה יעבדו. יש לזה ערך מטורף. אני מתארת לעצמי שבן אדם שנתן פידבק ואז רו את המוצר משתנה בהתאם, זה בטח גם נורא כזה מספק לראות שהוא לקח בזה חלק. לגמרי, ולפעמים אפילו הוא רו את זה יום אחרי או יומיים אחרי, וזה יוצר לופ משוגע בין היוזרים לבין הצוות שעובד על זה, שאפשר לעצור אותו. אני יכולה להגיד לתת את הדוגמה של מיי וורק, שהיא ב ת הייתה די קיצונית, אני חושבת, אבל גילינו שבסוף באגרגציה, זה היה 90% בערך מהיוזרים שניסו את הפיצ'ר, רו, זה פיצ'ר שלא פותר לי את הבעיה. עד כדי כך. היה לו בערך 550 פידבקים, קטלגנו אותם לפי אזורים, מתוך זהוצנו ממש בצורה חדה ומדויקת את הדברים שעכשיו אנחנו צריכים לעשות, והגרסה השנייה שעשינו כבר ממש פגעה. אם אוסיף שנייה בשלב הריליס, אז הנה, כבר מה10-15% אפשר להתחיל לקבל איזשהו פידבק כמותני מסקר. בשלב הבא אפשר כבר להסתכל על דאטה. אפשר כבר לראות כמה אנשים השתמשו בזה. אפשר לנתח את הפאנלים. אפשר לראות ריטנצ'ן. מתוך מי שהתחיל להשתמש, כמה בכלל גילה את זה, כמה עשה פעולה משמעותית, מה שקוראים לו adoption, כמה המשיכו להשתמש, פיתחו הרגל, מה שקוראים לו retention, כמה הפכו להיות לקוחות מרוצים וסטיקים, מה הפאטרנים של השימוש. את האזורים האלה של הדאטה, אנחנו כבר יכולים בכמה עשרות או מאות אלפי יוזרים להצליח ב ת לגלות פאטרנים. בנוסף, עדיין usability וuser interviews, זה תמיד קורה במקביל. זה השלב לתלות דשבורד מגניב על הקיר, שממש מלא את המספרים האלה משתנים כל יום, וזה גם חלק מהחוויה. ומתי מגיע סוף השלב האחרון? שלב שאנחנו אומרים, טוב, סיימנו את הפיצ'ר הזה, מתקדמים לפיצ'ר הבא. זה קורה בכלל? זה משהו שאנחנו תמיד נמשיך לפתח? בגדול אני אגיד שאנחנו תמיד צריכים להיות ביד על הדופק ולהבין מה קורה איתו. השאלה, מתי אנחנו מורידים את הרגל מהגז בצורה משמעותית מהפיצ'ר? מפתוח של הפיצ'ר ועוברים להזדמנויות אחרות או לא? וכאן שוב, אנחנו חוזרים אחורה לשלב הגדרת הבעיה, לשלב הגדרת ה-KPI, ורואים אם הצלחנו להגיע למטרות שלנו או לא הצלחנו להגיע למטרות שלנו. ואז אנחנו ממשיכים מעלה. אני כן אגיד שהרבה פעמים, הדבר הזה הוא, שוב, הוא חי ונושם. הנה נגיד בוורקלוד שדיברנו עליו, אז הרגשנו שאת הגרסה הראשונה, את הבעיה הראשונית שניסינו לפתור, עשינו מאוד מאוד טוב. הפיצ'ר הזה, מלהיות המספר אחד בלוקר, הפך להיות לאחת הסיבות שאנשים דווקא בגללם הולכים בכלל למנדק, ולא איבדנו כמעט עסקאות על וורקלוד, נתן פתרון מאוד מאוד טוב, והיוזרים היו מרוצים. אבל עכשיו, שנה וחצי או שנתיים אחר כך, פתאום יש עוד פעם מלא פידבקים על הוורקלוד, שמגיעים לעוד שכבה של יוסקייסים, שהם יותר מורכבים, יותר פוגשים יותר אנשים. בשלב הזה, כאילו, או שאת פועלת יותר לעומק של יוסקייס, או שאת דווקא רוצה להרחיב, את אומרת, אוקיי, הצלחתי נגיד ממש טוב עם החבר'ה של האנטרפרייז והפרודקט מנג'מנט, למה שאני לא אנגיש את זה לשאר האוכלוסייה? או זה עובד כל כך טוב, למה שאני לא אעשה על זה מונטיזציה? למה שאני לא אקח על זה עוד כסף? או למה שאני לא אשתמש בזה במרקטינג? אין לזה ב ת סוף. פתרנו בעיה מסוימת לצורך מסוים, ועכשיו אנחנו מגלים עוד הזדמנויות שאנחנו יכולים להרחיב את הפיצ'ר הזה בשבילן. בדיוק. יש יתרון מסוים בזה שאתה רגע עוצר, וחוזר למשהו אחרי תקופה, גם אם באותו רגע כבר. אתה יודע מה בא לך לעשות, אתה יודע כבר מה הפידבקים הראשונים. קודם כל צריך לזכור שבזמן הזה כבר הייתה הזדמנות נוספת, כבר התחלנו את התהליך הזה על משהו אחר. הזדמנות אחת או מ .

ומתוך מ ובנוסף, הזמן הזה שזה רץ ופוגש לקוחות, ואתה מתחיל לאגור את הפידבק טיפה לאורך זמן, מבשל קצת יותר טוב את השלב הבא, מאשר ישר להקות בו רגע אחרי השחרור של הגרסה הראשונה. אני גם אגיד אבל על הדבר הזה, שעוד איזה best practice שלמדנו, זה להשאיר בתוכנית שלנו גם מראש מספיק זמן, buffer, בשביל כל הדברים שלא חשבנו עליהם, בשביל פידבק. יש לנו ביום ממש צ'אנק שלם בתוכנית, שאנחנו אומרים זה placeholder של פידבק, לא יודעים מה יהיה. כדי לוודא שאנחנו תופרים את כל הפינות ומוצאים מוצר שהוא ב ת ב ת טוב ופותר את הבעיה. אם נחזיק את הדגל של ה-definition of done, אז את רוצה לסיים את השלב הזה, שמה שהבאת לשולחן בפיצ'ר, מוכן ועובד טוב. החשק, הדברים שפתוחים, זה פונקציונליות לדברים הבאים. אבל יש סקירות מסוימת של הפיצ'ר הזה, כשהוא יוצא לפרודקשן, שאתה לא עוצר את הנשימה עד שיבוא השלב הבא של הפיתוח שלו. אם חוזרים לבעיה, אז מבחינתי הבעיה נפטרה. כן, האלמנט הזה נפטר ונפטר עד הסוף. ומכאן רק להוסיף רבדים ולא כזה חלקים שלא נפטרו שם. ואגב, שוב, התלוי הזה, אם אנחנו הולכים עוד פעם לפיצ'רים דווקא קטנים קטנים שלנו, גם שם נרצה לעשות תהליך מזורז של זה. שנייה, רגע, ממש ב-high level. יש לי איזה שיפורון קטן צ'יק למוצר. אנחנו ספציפית במנדי מוצאים אותו קודם כל לצוות ולקבוצה. אחר כך למנדי שישחקו ויחיו איתו קצת ויתנו את הפידבקים הראשוניים שלהם. ולפעמים זה מספיק. זה פיצ'ר נורא קטן, אנחנו נקבל את הפידבקים במנדי ואז נשחרר אותו לכולם. אולי נשחרר אותו לעשרה אחוז ואז יומיים אחר כך למ אחוז. אבל תמיד נרצה לייצר איזושהי מדרגה קטנה מצד אחד. מצד שני לחתור למ אחוז מהיוזרים כמה שיותר מהר. אחלה, אז שאלה ממש אחרונה ככה לפני סיום. אני כן אזכיר שאם למי שיש עוד שאלות על כל התהליך הזה, אתם מוזמנים לפנות אלינו דרך startupforstartup.com ולשאול את שירלי ואורון, אנחנו נעביר להם את השאלות. אז דיברנו כאן ממש לעומק על חמישה שלבים שהם נורא נורא משמעותיים בפיתוח מוצר. עם מה אתם רוצים שאנשים ייצאו מהדבר הזה? מה הכי חשוב לקחת מכאן? בסוף מה שאני חושבת שחוזר על עצמו בכל איזו נקודת מטה כזאת, מעבר לכל הנקטוטות והדברים הקטנים שדיברנו עליהם, זה ב ת להצליח להוריד את האגו במובן מסוים. כאילו לא לחשוב שאנחנו יודעים ואנחנו יודעים לבד ואנחנו יכולים הכל, אלא כמה שיותר לשתף את הרעיונות, לפגוש עוד אנשים, לפגוש את ה… בין אם זה הצוות או בין אם זה היוזרים, וכל הזמן לקבל חיכוך וולידציה מהעולם ה יתי, כדי לאט לאט להתכוונן לפתרון המושלם, פרפקשן תרואי טריישן, ולא מההתחלה לחשוב שאנחנו יודעים הכל. אני חושבת שזה גם ב ת נוגע לעניין של עבודת צוות, זה לא שהפרודקט יודע הכי טוב את הפרודקט, והעיצוב יודע הכי טוב, זה כל הזמן שיח, אנחנו כל הזמן משתפים אחד את השני, אנחנו נותנים את הפידבקים, אין מושלם שהוא אבסולוטי, אלא בהתאם לקונסטריינס, בהתאם לסיטואציה שיש לנו, ואנחנו יכולים להגיע לתוצ הכי הכי טובה רק מתוך הדיאלוג הזה, בין אם זה בתוך הצוות ובין אם זה עם היוזרים שלנו. מהמם. אז בזאת אנחנו נסיים. המון תודה שיר לי. תודה, איזה כיף היה. תודה אורון. תודה, היה ממש כיף. סוף סוף אני יודעת איך עושים פרודקט ומנדי. אני אזכיר לכם שאם יש לכם עוד שאלות, אתם יכולים לשאול דרך startupforstartup.com או דרך הקהילה שלנו בפייסבוק. תודה שהזנתם. Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for Startup for