Lean Startup - איך לגדל מוצרים מצליחים?

בספר The Lean Startup, אריק ריס מספר על חברה שהקים בשם IMVU. הרעיון שלה (פלוס מינוס) היה לייצר צ'ט שיש בו Avatar - מן דמות תלת-מימדית מונפשת שמתלווה לשיחה המתהווה ומעצימה את הצד הרגשי של השיחה. ניתן לפתח את הדמות (להלביש אותה, לעשות איתה כל מיני מחוות) כל שהמוצר הוא בעצם חצי צ'ט - וחצי משחק Second Life / The Sims.

שוק ה Instant Messaging (בקיצור IM) היה גדול מאוד ומבוסס באותה התקופה. מכיוון שמדובר במודל של Marketplace (בו הערך של המוצר הוא "כמספר המשתמשים בריבוע") - לא היה טעם להתחיל מאפס: מה טוב Chat Client שאין לי עם מי לדבר בו? האסטרטגיה המבריקה של החברה הייתה למשוך משתמשים בעזרת ה Avatar / הצד המשחקי של הצ'ט - וכך לגרום להם להעביר אט אט חברים לרשת ה IM החדשה.
החברה תייצר Client שיוכל להתחבר לרשתות IM קיימות - כי שם הרי כל החברים שלכם.
שיחה שתתבצע בעזרת שני משתמשים עם ה Client של IMVU - יתווסף עליה מימד ה Avatars.

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

• מערכת ה Plug-ins לתמיכה ברשתות ה IM השונות התגלתה כמורכבת יותר מהצפוי. 
• היעד לגרסה הראשונה היה אגרסיבי: כחצי שנה. הצוות התחיל לעבוד +12 שעות ביום על מנת לעמוד ביעד השאפתני.
• זה לא הספיק, ולכן הצוות החל "לחתוך" פינות רבות במימוש הטכנולוגי ("הרי אנחנו סטארט-אפ").
• לקראת ההשקה ההרגשה הייתה שאיכות המוצר היא לא-טובה. מה עושים? משחררים בכל זאת, או מקצים עוד זמן לתיקוני באגים? הרי, למכור מוצר מלא באגים - זו דרך מצוינת ליצור שם רע למוצר ולחברה.
• כנגד ההיגיון הבריא (אריק מספר היום שזה המזל הגדול שלהם), הם החליטו לשחרר את מה שיש להם. גרסה ראשונה יצאה לדרך.

ביום ההשקה הם פתחו את האתר בו מורידים את התוכנה, התחילו לפרסם ברשתות החברתיות ולקשר לדף ההורדה - אבל כלום. אפס הורדות.

(טוב, אופס! הייתה בעיה בכפתור ההורדה.) - מה שתוקן מייד ואז החלו ההורדות: 3, 7, 11, 23, 38, 43, 49, 65, 77, ... וכך המספר עלה. עשרות הורדות, אח"כ כמה מאות - שום דבר שדומה לציפיות על עשרות-אלפי משתמשים.

Avatar לדוגמה של IMVU

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

לאור חוסר-ההצלחה, הצוות החל להביא משתמשים אמיתיים למשרד - על מנת לבצע בדיקות שימושיות.
משתמשים שהיו teenagers - פתחו את האפליקציה ופשוט השתמשו בה. לא היה להם פידבק מיוחד ("כן, מגניב").
חבר'ה יותר מבוגרים פשוט שאלו "טוב, מה אתה רוצה שאעשה עם האפליקציה?". כשהנחו אותם, היה ברור שהחוויה פשוט מוזרה עבורם - עבור הצוות זה היה פשוט מאוד מייאש. הם לא קיבלו מהמשתמשים שום תובנה עמוקה שעזרה לפתור את עניין הרישום.

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

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

"למה לא?!"
- "אני עדיין לא יודעת אם הרשת שלכם היא קוליקית. להזמין חברה לרשת לא קוליקית - זה פשוט מביך ברמות!!1"

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

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

הם פספסו בהנחות היסוד המהותיות:

• ההנחה שיהיו משתמשים משכבות גיל שונות. (מה שמשפיע מאוד על המודל העסקי והיכולת לשלם).
• ההנחה שהתקנה של Plugins היא דבר שמשתמשים יסתדרו איתו לבד. "מה זה פלאג-אין?!" - שאלו רוב המשתמשים.
• ההנחה שמשתמשים ירצו להזמין חברים שלהם לרשת של IMVU - ובצורה ויראלית.

הסיפור של IMVU יכל להיות עוד סיפור מני רבים של סטארט-אפ שכשל. מה שמיוחד בסיפור הוא מה שהציל את המוצר:

• מכיוון שהיה מספר מסוים של משתמשים ששיחק עם המוצר (ועדיין לא זנח אותו)...
• ומכיוון שהמשתמשים לא העזו להזמין חברים לצ'ט...
• היזמים הוסיפו כפתור בשם "ChatNow" - המאפשר למשתמש אחד לשוחח עם משתמש אקראי אחר. זה היה ניסיון אקראי לייצר קצת תעבורה במערכת.
• אבל, באופן פלאי כמעט - הרשת החלה להצליח.
• הדמות שהמשתמש עיצב, ה Avatar, עזרה להפיג את המתח הראשוני עם בן-שיח זר לחלוטין.
• מסתבר שהמשתמשים לא רצו להתחבר לשירותי IM אחרים או לדבר עם החברים הקיימים שלהם - הרשת שצמחה הייתה רשת לשיחות עם זרים.

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

מתודולוגיית ה Lean Startup

Lean Startup היא מתודולוגיית פיתוח רזה שמנסה לשפר משמעותית את סיכויי ההצלחה של סטאראט-אפים, או ליתר דיוק - מוצרים חדשים. בקהילת ה Lean Startup אוהבים מאוד להדגיש הצלחות של המתודולוגיה ב Enterprises גדולים וארגונים ממשלתיים.

מתודולוגית ה Lean Startup היא אחד החידושים המרעננים והחשובים (לדעתי) בעולם התוכנה בשנים האחרונות.


לכאורה, נראה שמדובר בעוד מתודולוגיית Agile.
מדוע אנו זקוקים ל*עוד* מתודולוגיית Agile?? האם לא מיצינו כבר את הכיוון הזה?


עיון בעקרונות ה Agile (ליתר דיוק: Lean [א]) הוא: ״Eliminate waste" - להתמקד בביטול פעולות לא-נחוצות כאמצעי לשיפור הפריון של הארגון.

מהו waste?

• תכנון לקוי - בואו נשפר אותו.
• ישיבות ארוכות - בואו נגביל אותן בזמן (timeboxing - רעיון דומיננטי של סקראם).
• שכבות ניהול מיותרות - בואו נבטל אותן ונעצים את הצוות.
• באגים שצצים בפרודקשיין - בואו נעשה מאמץ לאתר אותם מוקדם יותר.
• וכו׳

כל אלה נושאים חשובים וטובים. הם שיפורים חיוביים, אבל הם לא מתמודדים עם "ה waste הגדול מכולם" או ה BWoA (קרי: Biggest Waste of All).

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

בעוד סקראם היא מתודולוגיה שמתמקדת בעיקר בזווית של ניהול פרויקטים / ארגון קבוצת פיתוח, Lean Startup מתמקדת בעיקר בעולם פיתוח המוצר - והיא מביאה בתחום כמה רעיונות מרעננים (אם כי לא מקוריים).

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

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

במקום זה, יותר יעיל למדוד למה באמת אנשים מגיבים (מעשים > דיבורים) - בעזרת סדרה של ניסויים.

במעט סרקזם, ניתן לומר שאם תשאלו אנשים מה חסר להם בסקראם - הם יובילו אתכם ל LeSS או SAFe [ב], אם תבחנו מה שורש הבעיה של ארגוני-תוכנה - תגיעו ל Lean Startup.

אז מה הוא בעצם ה BWoA?

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

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

קרוב לוודאי שנתקלתם בכמה שכאלו בקריירה שלכם...


"Fail early, Fail fast"

החשבון הוא פשוט:

• אם השקענו שנה, בפיתוח של מוצר לא מצליח - אזי בזבזנו שנים-עשר חודשי פיתוח!
• נניח שבעזרת ניהול פרויקט נכון יותר, ניהול ישיבות יעיל, ושלל תהליכים אותו פרויקט - סיימנו את הפרויקט הנ"ל בתשעה חודשים (נניח באופטימיות). אם זה לא פרויקט מצליח - עדיין בזבזנו תשעה חודשי פיתוח!
• אם השקענו 100,000 שקל אצל מגדת עתידות שאמרה לנו בוודאות שהפרויקט ייכשל - אזי בזבזנו רק 100,000 ש"ח. חודשי פיתוח של צוות פיתוח הם יקרים הרבה יותר! הזמן שהתבזבז - עשוי להיות יקר יותר מכסף.

מכיוון שאין לנו בתעשיית התוכנה מגדת-עתידות אמינה, אנו נשקיע זמן פיתוח בפיתוח של Minimal Viable Product (בקיצור: MVP). המוצר הזה יאמר לנו בהשקעה קטנה ואמינות גבוהה (אם עשינו אותו נכון) - האם המוצר השלם הולך להצליח (ואז שווה להמשיך ולהשקיע בו) או האם עלינו לשנות כיוון משמעותי (מה שנקרא גם "Pivot" - "שינוי ציר התנועה").

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

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

Lean Starup היא מתודולוגיית פיתוח ״רזה״, המבוססת על רעיונות של חשיבה מדעית, המתמקדת בעיקר בשאלה: כיצד נצמצם למינימום את ההשקעה במוצרים/פיצ׳רים לא מוצלחים?

ע"פ המתודולוגיה (בקצרה) אנו בונים ניסוי בדמות מוצר מינימלי (MVP) שיאמת או יפריך את ההנחה שיש לנו, שסט יכולות מסוים יפתור בעיה אמיתית של לקוחות אמיתיים, שניתן להרוויח ממנו כסף, או שאנו יכולים לייצר אלגוריתם כזה וכזה. הניסוי אמור להיות מוגדר-היטב, ותוצאותיו ברורות מעבר לפרשנות אישית של חבר-צוות כזה או אחר.

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

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

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

דוגמה אהובה היא הסיפור של חברת SnapTax, שביצעה במשך חודשיים וחצי בסוף השנה (תקופת חישוב המס בארה"ב) כ 500 ניסויים שונים על אופן השימוש המוצר שלה - זה אומר כ 11 ניסויים שונים שמתחילים כל יום!
אם היה ספק: רעיון ה Continuous Deployment (בניגוד ל Delivery) - נולד כחלק ממתודולוגית ה Lean Startup: ביצוע ניסויים הוא צורך קיומי של החברה, ולא ניתן לבצע ביצועים ברצף ללא ביצוע שינויים תכופים בסביבת הפרודקשיין. מי שאמור לדאוג לקיום של ה Continuous Deployment הם א
לא המפתחים - אלא ה CEO.

בשלבים הראשונים של המוצר, התהליך הוא תהליך של Pivot (שינוי כיוון מהותי) - אם הניסוי כשל, או Preserve (מעבר לסיכון/ניסוי הבא שאותו נרצה לבדוק) - במקרה של הצלחה.
קודם כל עלינו לדעת שאנו מפתחים משהו שכמות מספיק גדולה של משתמשים באמת תרצה להשתמש בו.

משהו שאין בתרשים: אם ב Agile אנו מתקדמים בכיוון כמעט אחיד ועושים שינויים בעיקר בסדרי העדיפויות / שינויים קטנים במוצר לאורך הזמן, ב Lean Startup המסלול, לפחות בהתחלה, הוא הרבה יותר כאוטי: שינוי הלקוחות שאנו פונים אליהם, ביטול או שינוי מהותי ליכולות עיקריות של המוצר, או אפילו כתיבה מחדש - של חלקים או כל המערכת. זמן פיתוח משמעותי מושקע בניסויים ואיסוף התוצאות שלהם - ולא רק בפיצ'רים. המדד להצלחה הוא לא כמה "Story Points" השגנו בזמן נתון - אלא כמה למידה משמעותית.

״סטארט-אפ מצליח הוא סטראט-אפ שהצליח לבצע מספיק איטרציות בהגדרת המוצר - לפני שנגמר לו הכסף״ -- אריק ריס. (ההדגשה היא שלי)

כיצד נראה תהליך של Lean Startup?

את הסטארט-אפ הבא של אריק הוא החל בזהירות: הוא החליט לא לבזבז משאבים או זמן מיותרים. הוא זכר איך ב IMVU - שעד שהם לא שיפרו את תיאור המוצר כמה פעמים באתר, כמעט ולא היו הורדות.
אריק יצר עמוד אינטרנט עם תיאור המוצר - והוסיף כפתור "Download", למרות שלא באמת היה לו עוד מוצר.

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

הנה כבר היה לו ניסוי ראשון: איזה אחוז מהאנשים שהביעו עניין בדומיין (לחצו על לינק בכדי להגיע לאתר ההורדה), מתחברים לתיאור המוצר? אולי תיאור המוצר הוא בעייתי? אולי הגדרת הבעיה לא מדברת אליהם?

לאחר מכן הוא שכלל את האתר, ועשה A/B Test - "תיאור מוצר א'" מול "תיאור מוצר ב'". "תיאור מוצר ב' מול תיאור מוצר ב'2" - וכו'.

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

Lean Startup לא דוגל בביצוע ניסוי לכל דבר. ניסוי הוא עלות, ולעתים עלות לא-מבוטלת. השיטה היא לבצע ניסויים לגבי חוסרי הוודאות והסיכונים הגדולים למוצר בכל רגע נתון. הסיכון הכי גדול של המוצר החדש יהיה - שאנשים לא מתחברים לרעיון הבסיסי. בעלות ניסוי דיי נמוכה (אתר אינטרנט) - אריק הצליח לתקוף וללמוד תובנות לגבי הסיכון הגדול ביותר של הסאטראט-אפ שלו - ערך גדול מאוד!

עוד מבחן חשוב שנוהגים לדבר עליו הוא מבחן התשלום: יש הבדל תהומי כמעט בין אנשים שמצביעים בסקר "כן, המוצר הזה מוצא-חן בעיני", לאנשים שמוכנים לשלם על המוצר (למשל: מראש, וב 70% הנחה). כבני-אדם יש פער בין הכוונות שלנו - למעשים. זה פער טפשי מדי לחברה ליפול בו.
שלב ביניים זול בין 2 המצבים הנ"ל הוא ההצהרה "כן, אני מתכוון לרכוש את המוצר ב 29$ לחודש". כאנשים שמצהירים משהו קונקרטי זה מגביר את הסבירות שהם אכן יעשו זאת (אבל עדיין - אין הבטחה).


Zappos

עוד סיפור מפורסם של Lean Startup הוא הסיפור של זאפוס - היום חנות הנעליים הגדולה בעולם, עם מחזור מוערך של כ 2 מיליארד דולר בשנה (ב 2009 היא נרכשה ע"י אמזון).

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

ההיפותזה העיקרית הייתה שיש שוק גדול שמוכן לקנות נעליים באינטרנט (דבר שלא היה מקובל בכלל באותה התקופה - שנת 1999). הוא מצא כמה חנויות נעליים באזור ועשה איתן הסכם: הם יתנו לו לצלם את דגמי הנעליים השונים שיש להם במלאי - והוא מתחייב בחודשים הבאים שאם יש לו הזמנות - הוא רוכש אותן מהם במחיר מלא.

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

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

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

היו לו עוד מספר לא קטן של גורמים שהוא לא ידע כיצד יתנהגו - ושיכולים להשפיע על העסק:

• מה הרגישות של הלקוחות לזמני משלוח?
• כמה ביקוש יש, ואיזה סוגים של נעליים ימכרו טוב יותר?
• כמה אנשים יבקשו להחזיר נעליים ברגע שהוא יגיע ל Scale?
• האם אנשים ירצו להתקשר לחנות? לאיזה סוג של שירות הם יזדקקו? איך סוג של מחלקת Support כדאי להקים?
• הוא חשב לתת הנחות על פני חנויות רגילות - מה הרגישות של לקוחות להנחות? כמה הנחה תספק כמה ביקוש?

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

מיתוס המנהיג בעל החזון המושלם.

ההסתייגות הראשונה לרעיונות ה Lean Startup מגיעה מסיפורים על איש אחד: סטיב ג'ובס.

המנהיג בעל החזון המושלם הוא אדם בעל תובנות עמוקות על השוק והצרכנים - שיודע לקלוע ״בדיוק״ לאיזה מוצר יעבוד. זהו כשרון מופלא, ואנשים בעלי הכישרון הזה - באופן טבעי צריכים להנהיג ("FTW").

מדוע אפשר להאמין למיתוס:

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

מה החולשות של המיתוס:

• הוא מתבסס על הטיות אנושיות, למשל: הטיית השרידות (דוגמה חיה אחת, חזקה פסיכולוגית יותר מסטטיסטיקה של אלפי מדגמים).
• סטיב ג׳ובס דוגל באסטרטגיה של סיכון גבוה / רווח גבוה:
• כשהוא המציא את Newton - הוא הימר על הכל והביא את אפל לסף פשיטת רגל.
• כשהוא המציא את ה iPhone - הוא הימר על הכל, והביא את אפל להצלחה אדירה.
• על רוב ההימורים הגדולים אנו לא שומעים - כי זה לא מעניין לספר על עוד יזם שכשל.
  אנו שומעים רק על סיפורי ההצלחה (המעטים) - וכך מקבלים תמונה מעוותת של המציאות, שלא משקפת את הסיכון הגדול.
• גם לו היה מנהיג בעל חזון מושלם - איך תוודאו שהאדם שאתם מתמסרים אליו הוא כזה? שהוא לא סתם עוד אדם כריזמטי עם בטחון עצמי?

למרות שמה שאנשים מסוימים ינסו לטעון, Lean Startup הוא דיי הגישה ההפוכה לגישה בה אפל השיקה כמה מוצרים מאוד מצליחים. לאפל יש מגבלות: היא מייצרת מוצרי חומרה - שבהם קשה מאוד לבצע MVPs (אולי עכשיו, בעזרת הדפסה תלת-מימדית - זה יהיה יותר אפשרי). אפל כאסטרטגיה משקיעה רק במוצרים עם קהל פוטנציאלי מאוד רחב. בשל ההנחה הזו, מפתחי המוצר באפל האמינו שעובדי החברה הם קהל מספיק טוב לקבל ממנו פידבק להשקת המוצר.

יש גם כמה קווי דמיון שניתן למצוא בין הגישה של אפל ל Lean Startup:

• כשאפל הציגה מוצרים לראשונה, היו להם כמה תכונות פורצות דרך - אבל גם הרבה תכונות מביכות. חשבו על השעון: מה עושים איתו? זהו פסודו-MVP: אפל שחררה מוקדם יותר - על חשבון ליטוש "המוצר המושלם".
• שחרור ה iPod הראשון רק למשתמשי מק (בעלי חיבור firewire, לא היה לiPod חיבור USB) - עזר לאפל ללמוד הרבה, מקהל מוגבל יחסית - שהם מכירים היטב.
• ה Clickwheel המפורסם של ה iPad הופיע קודם בדגם ה iPod Mini, ורק לאחר שהוכח כמוצלח - הועבר לדגם הרגיל ממנו היו רוב ההכנסות של אפל.
• יחסית למוצר חומרה, אפל עובדת ב cycles קצרים: שחרור כל שנה. בכל cycle - יש כמה שיפורים משמעותיים. זה עניין של פוקוס - לעשות כמה דברים אבל טוב, ולא המון פיצ'רים לא-חשובים.

לסיכום אפשר לומר כך: אם אכן יש לכם מנהיג בעל חזון מושלם - אולי אתם לא זקוקים ל Lean Startup. אם אתם טועים - כדאי מאוד לעבוד במתודולוגיה להפחתת סיכונים (Lean Startup, או דומה לה).

ביקורת 


תגובה צפויה להעלאת רעיונות ה Lean Startup היא: "זה נשמע נהדר - אבל זה לא מתאים לנו".

התירוצים הנפוצים הם:

• כי המתחרים יעתיקו את הרעיון אם נחשוף אותו בניסויים מוקדמים.   
• תשובה: הם כמעט תמיד מתעלמים ממה שאין לו עדין נתח שוק, ולהעתיק בלי הבנה מעמיקה - זה לרוב לא שווה הרבה. אם ניתן להעתיק את הרעיון בקלות - אז זה יקרה גם אחרי שיצאתם לשוק.
• כי אנחנו חברה גדולה שחושבת בגדול - ואין לנו זמן ל"ביצוע ניסויים".
• תשובה: כן, אבל לשרוף שנת פיתוח של 50 מתכנתים יש לנו זמן?
• כי אין לנו כוח אדם מתאים: יש לנו מתכנתים - לא אנשי מחקר שוק. 
• תשובה: רבים מהמתכנתים יכולים ללמוד לעשות את זה. זה מעניין, מאתגר, ומאוד מספק.
• כי שחרור של גרסה מינימלית יפגע בשם הטוב שלנו - אסור ל Brand שלנו להוציא מוצר פחות מ"מענג".
• תשובה: זה לרוב תירוץ. אפשר להוציא כ"בטא" או "אלפא", אפשר להוציא את הניסוי תחת מיתוג אחר של "חברת-בת לא ידועה".
• לא יאשרו לנו בחיים לעבוד ככה. יש תהליכים בחברה.
• תשובה: זו באמת בעיה. בעיה של החברה.
• זה בכלל לא מתאים לחברות גדולות. זה ה Lean Startup.
• תשובה: הכל בראש. אם HP וממשלת ארה"ב מסוגלות - אז גם חברה קטנה יותר, של כמה עשרות אלפי עובדים בלבד - מסוגלת.
• האמת, שהשם Lean Startup הוא לא הכי מוצלח. "Lean Product Incubation" - הוא שם פחות קליט אך יותר מדויק: העניין הוא מוצר חדש בעולם לא מובן - לא גודל הצוות שמפתח אותו. 
• כן אני אסכים שהסבירות להצלחת מתודולוגיה שכזו בארגון קטן וצעיר - היא גבוהה לאין שיעור מיישום בארגון גדול ומורכב. כן המתודולוגיה הזו מתאימה יותר לסאטרט-אפים.

ביקורות אחרות הן מסביב ללחוץ שעומד על העובדים (ביצוע ניסוי כל יום??), הקושי לגייס אנשים שיעבדו במוד עבודה שכזה, או הסיכוי לבצע את הדברים בצורה לא טובה (ניסויים לא ענייניים, MVPs מוטעים - וכו').
ביצוע ניסויים, וניתוח התוצאות - הוא לא דבר פשוט ודורש עבודה לא-מעטה, ויצירת MVP בשוק עם חסמי כניסה גבוהים - הולך להיות דבר יקר (אלא אם תמצאו דרך מקורית לעשות זאת).

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

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

בכל מקרה, כדאי לזכור שזה לא "הכל או לא-כלום". אפשר להיות מושפעים מרעיונות ה Lean Startup ולהרוויח מהם - גם ללא אימוץ מושלם / קפדני, אולי קיצוני.

סיכום

רבים סופגים את רעיונות ה Lean Startup כ:

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

(הסקירה שסיפקתי היא מעט בסיסית - ואכן לא כיסיתי את הרעיון השלישי).

זה מדויק - אבל לא נכון.

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

התיאור הנ"ל הוא כנראה מבנה המיינסטרים של אימוץ ה Lean Startup, אבל הוא בהחלט לא מחייב. הדברים החשובים באמת הם:

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

צר לי שאני מגיע לפוסט הזה רק עכשיו. החשיפה לרעיונות ה Lean Startup באמת היוו עבורי פקיחת עיניים חשובה, שהייתי מעדיף לשתף עם קוראי הבלוג לפני שנתיים, ככה - ולא רק עכשיו. 


שיהיה בהצלחה!

---

[א] - אנשים רבים משתמשים במונחים "Agile" ו "Lean" כמושגים נרדפים - אך יש שוני חשוב בהשפעות והנחות היסוד של כל גישה. 

Lean היא השפעה ישירה של ה Toyota Production System או מה שקרוי Lean Manufactoring - וניסיון לתרגם אותם לעולם התוכנה. Kanban ו Lean Software Development - הם מתודולוגיות לדוגמה, והדובר הלא רשמי שלהם (עד לאחרונה) היו בני הזוג Poppendieck.

 Agile הן סדרת מתודולוגיות שהושפעו באופן עקיף מאותם רעיונות של טויוטה, אך ניסו להגדיר מחדש תהליכים לעולם התוכנה - ללא תרגום ישיר. היישומים המוכרים היום הם SCRUM, XP, ולאחרונה גם SAFe ו LeSS. 

[ב] מתודולוגיות סקראם חדשות, לכאורה מתאימות לארגונים גדולים. לי יש כמה סימני שאלה גדולים לגביהן (וגם לגבי סקראם בכלל, וכיצד הוא השפיע בפועל על התעשייה).