מבוסס על סיפור אמיתי: איך מתכננים מוצר נכון? [טור אורח]

איך מתכננים מוצר ואיך מתאימים אותו לשוק? שי רפפורט מספר על כל הטעויות שעשה וכמה לקחים

product getty images

קרדיט צלם\תמונה: yoh4nn, Getty Images Israel

מאת שי רפפורט

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

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

כמובן, היינו אנשי העולם הגדול וידענו שהכי טוב והכי לוהט זה SaaS. לכן מההתחלה מכרנו במודל של שירות חודשי, אבל האמת היא שההתקנה של השירות דמתה יותר למוצרים בקופסה משנות ה-90. כדי לבצע אינטגרציה, לקוחותינו נאלצו להתקין שרת וירטואלי בחוות השרתים שלהם, לתת לנו גישה, להתקין תוכנה ולהטמיע רצועות קוד באתרים שלהם (Server side code). בניגוד למודל SaaS שחותר למכירות Low touch / no touch (ללא מגע יד אדם), אנחנו נזקקנו להדרכה וליווי צמוד של כל לקוח בתהליך ההטמעה. זה לא הדבר הכי קל או הכי סקלאבילי לחברה דלת אמצעים, שמפנה את עיקר מאמצי השיווק שלה לשוק העולמי. חמור מכך, מצאנו עצמנו מסוגלים לספק שירות רק ללקוחות, שכתבו את האתרים שלהם בשפות התכנות שבהן תמכנו, וגם אז לא בוודאות (שימוש בטכנולוגיות cache, למשל, הכשיל את פעולת המערכת שלנו). בשורה התחתונה, אם מוצר הגנה בפני רובוטים פנה מראש לשוק מצומצם, הרי שבמו ידינו כיווצנו הלאה את אותו שוק באופן יישום הפתרון שלנו.

אם כך, מדוע בחרנו דווקא במימוש הזה? עשינו זאת בעיקר, משום שהיה לנו הכי קל והכי מהר ליישם את המוצר בצורה הזו, וכן מתוך המחשבה שבהיותנו שירות מבוסס API, שהאתר מתשאל "ברקע", נדלג מעל המלכודת של הפיכתנו למערכת קריטית ונקודת כשל אפשרית (Single point of failure), כמו מוצרי אבטחה אחרים, שנמצאים על הנתיב הקריטי של תנועת המשתמשים. גם אם לא ניסחנו זאת לעצמנו באופן ברור, מה שעשינו הוא בחירה במסלול של הסיכון הטכנולוגי הנמוך ביותר. זה שיקול טוב ונכון לפרזנטציות ולהוכחות היתכנות, אבל לא הראוי ביותר למוצר שצריך לכבוש את השוק. ובכל זאת, לאותם מעט לקוחות שעבורם התאמנו טכנולוגית ושעבורם אכן פתרנו בעיה ידועה ומכומתת בכסף, היינו כמעט בגדר פתרון קסמים מועיל, לא מסוכן וללא תחרות. איתרנו בזריזות את רוב הלקוחות שענו לקריטריונים הללו ותוך כשנה וחצי מההשקה הגענו להכנסות של כ-$50,000 לחודש. באותם ימים, המשקיעים אהבו אותנו באופן כמעט אירוטי, והתנופה הזו הביאה אותנו לגיוס של קרוב לארבעה מיליון דולר נוספים, שהיו מקור המימון שלנו לשנים הבאות.

startup PD

גאה אך מתוסכל

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

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

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

המתחרים הפנימו ויישמו משהו מהר מידי

אבל הדבר המדהים עוד יותר בניהול המוצר של ב-Cloudflare, שבגללו אני מלא הערכה אליהם, הוא הדיוק וחוסר המורא שלהם בניהול המוצר. לדוגמא, הם הבינו שאם עליהם לספק שירות בהתקנה עצמית פשוטה, אסור להתקין שום רכיב אצל הלקוח. לכן השירות חייב להנתן ב-100% מהענן. אבל, אם הם יישבו בענן, בין אתרי הלקוחות שלהם לבין המשתמשים, הם עלולים ליצור איטיות (latency) באתרים ולגרום ללקוחות לנטוש. כדי לפתור את זה, צריך לבזר את השירות שלהם בכמה שיותר נקודות בעולם, ואם אפשר, לשלב גם טכנולוגיות של האצה, כדי שיוכלו לומר ללקוחות, שהם לא מאטים את האתר שלהם, אלא אפילו מאיצים אותו משמעותית אגב ההגנה עליו. בקיצור, הם הבינו שהם צריכים להיות, מה שנקרא, Content Delivery Network או CDN, שזו לא רק טכנולוגיה נוספת, אלא קטגוריה שונה משירות אבטחה (בשוק היו ויש חברות ענק שהן אך ורק CDN). זה לא הפחיד אותם. הם לא אמרו לעצמם "But this is not what we do…" ותחת זאת, בתקציב התחלתי דל, התחילו לפתח בעצמם את כל הרכיבים במוצר (Security, CDN, DNS, FEO), תוך הצטמצמות מוקפדת ליסודות המינימליים הנדרשים מכל רכיב לשם השגת המטרה של חווית משתמש מנצחת, שהם שולטים בה מקצה לקצה.

ובחזרה אלינו. כאמור, לא מצאתי שותפים בתוך החברה לחששותי האסטרטגיים. החלטתי לעשות מעשה, ותוך כדי מאמצי גיוס הכספים, להכין תשתית לדור המוצר הבא. יצרתי קשרים עם כמה דמויות טכנולוגיות מובילות מעמק הסיליקון, כדי לברר על בניית CDN, להכיר את הטכנולוגיות הנדרשות, להבין עלויות, סיכונים ואלטרנטיבות. כתבתי מסמך אפיון ארוך ומפורט (מדי) למוצר אבטחה שאפתני, יותר טוב מהקיים בשוק כמעט בכל אספקט אפשרי. רציתי אותו קל להתקנה, משוכלל בהדיפת התקפות, עם UI סופר-מתוחכם של Single page app ורציתי שייבנה עם אפשרויות קסטומיזציה לערוצי הפצה ולפרטנרים, כדי שנוכל לאגף את המתחרים באופן הגישה לשוק. ישבתי אפילו לילות רבים עם מעצב ובניתי את מסכי המוצר, שיום אחד עוד ניישם אם רק אצליח לגייס כספים. מבצע הקומנדו הזה, שעשיתי בלי גיבוי העובדים, הבורד, או השותף, מילא אותי בהתלהבות, אבל גם בהרבה מתח, וכעס ארסי. יכולתי להתווכח באותה תקופה עם כל אדם, על כך ששהוא אידיוט גמור ולא מבין לאן העולמות של אבטחת המידע ו-application delivery מתקדמים, אפילו אם זה היה השליח של הפיצה. ארז החליט לבודד את עצמו מהדרמה שיצרתי ולשכתב לבדו, בפרוייקט ארוך, את מנוע זיהוי הבוטים של המוצר כדי לשפר כמה חסרונות שנתגלו בו בינתיים.

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

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

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

startup laptop PD

המוצר הוא הכל

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

הצטמצם להכרחי בלבד

גם אם תוביל חמור אל השוקת, לא בטוח שישתה והחמור שאני הייתי אכן לא למד את הלקח כולו, גם כאשר השוק עצמו הראה לי איך נכון לבנות את המוצר. אני יכול להתרברב שבמחקר ובאפיון שכתבתי ראיתי בבירור מגמות שוק של עשור קדימה, הרבה לפני אחרים, אבל עם תובנות כאלו בלבד לא מנצחים את המשחק, אלא עם אסטרטגיה. וכאן טעיתי שוב, ובגדול. ניסיתי לתקן את כל מה שלא נכון או לא מושלם במוצר בבת אחת ולהפוך אותו לטוב ביותר שיש. תכננתי מפלצת ענקית ויפהפיה, אבל לא התמקדתי ביעד עסקי ברור, קצר טווח ובר השגה. תוכנית של 8-9 חודשים בעולם התוכנה, היא לרוב תוכנית גרועה. ייקח למפתחים 3 חודשים להבין אותה ועוד 12 חודשים לבצע ועד אז הכל יכול לקרות, לרבות השתלטות עוינת של מפלצת הספגטי המעופפת על העולם. בדיעבד, ברור כשמש שצריך היה להוציא באופן המיידי ביותר האפשרי את אותם פיצ'רים שיציבו אותנו מחדש על המפה ושיאפשרו לנו לקצור נצחון ראשון בחלקת שוק, שהמתחרים עדיין אינם זוללים אותה. אם, למשל, מסקנתנו היתה שהמעבר ל-Low touch והעבודה עם פרטנרים הם הכלים להשגת יתרון, כל הדגש הטכנולוגי צריך היה להיות על המעבר ל-Low touch ועל חווית המשתמש, בעוד שאתר האינטרנט והשיווק עוברים לדבר בשפת פרטנרים מיד מרגע ההחלטה (ממילא לוקח מספר חודשים לסגור עסקה עם כל אחד מהם). תחת זאת השקענו בעודף פיצ'רים ולבסוף שחררנו את רובם אפויים למחצה, תוך שאנחנו מכלים את שלושת המשאבים הקריטיים של העסק: הכסף, המגע עם השוק ואמון המשקיעים. אמנם לא חייתי בוואקום גמור ושמעתי אינסוף פעמים מושגים כמו Minimum Viable Product או Lean startup, אבל לא הבנתי את המהות שמאחורי הבאז. בואו אנסח את זה עבורכם במילים הכי פשוטות: עליכם להתמקד אך ורק באותם פיצ'רים, אשר בזכותם תשיגו יתרון שיווקי קריטי ובר קיימא בפלח שוק ידוע ומוגדר, ואת אותם פיצ'רים לבצע הכי טוב שאתם יכולים בעבור המשתמש המיועד.

התרחב אל כל מה שהכרחי

בעוד ש-Cloudflare לא נבהלו מכך שכדי לממש את חזונם יצטרכו להיות CDN, ספק DNS ולהתעסק עם עוד לא מעט טכנולוגיות מורכבות (FEO, Anycast וכו' וכו'), אנחנו אמרנו לעצמנו שאנחנו לא חברת תשתיות, ושהתעסקות בכל הטכנולוגיות הללו היא מחוץ לתחום שלנו וגדולה עלינו וכי ממילא נוכל לחבור עם חברה שיש לה תשתיות כאלו. זו היתה טעות קרדינלית שנבעה מפחדנות בלבד. נכון, צריך להצטמצם לעיקר. נכון, אחנו פועלים בעולם של התמקצעות ושל everything-as-a-service, עולם שבו הדבר ההגיוני לעשות הוא להתרכז בפיתוח שלך ולשכור תשתיות או שירותים הכרחיים אחרים שאינם בליבה. אבל איך באמת יודעים אם רכיב מסויים הוא בליבת הטכנולוגיה או לא? האם שרתים ותשתיות, לדוגמא, הם משהו שתמיד צריך לשכור מחברה כמו אמזון ודומותיה? אם אתם מתלבטים בשאלה אם רכיבים מסוימים הם בליבת המוצר והטכנולוגיה או שאפשר להשמיש טכנולוגיה צד ג', אני ממליץ לשאול שתי שאלות קריטיות: הראשונה היא, האם הרכיב הזה הוא commodity, כלומר, יש לו תכונות גנריות ודי תחליפים בשוק כדי שניתן יהיה להחליפו באחר ללא כאב. השניה היא, האם אני משוכנע שאין לשימוש ברכיב צד ג' השפעה משמעותית על המוצר שלי, על חווית השימוש בו ועל רמת השליטה שלי בה? אם התשובה לאחת השאלות היא שלילית, המשמעות היא חמורה: בלי בעלות על הרכיב הזה, אינך הבעלים האמיתי של המוצר שלך. אם תוותר על הבעלות והשליטה בטכנולוגיה הזו, לא יהיה לך מוצר שלם ותדון את עצמך מראש לעמדת תלות ולמיקום נמוך בשרשרת המזון של עולם הטכנולוגיה.

השתמש בדמיון

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

לטורים הקודמים:

מתי שותפות בסטארטאפ עובדת?

על תחילת הסטארטאפ שלי הרבה לפני האקזיט

הכותב הינו מנכ״ל חברת Fireblade

כתב אורח

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

הגב

6 Comments on "מבוסס על סיפור אמיתי: איך מתכננים מוצר נכון? [טור אורח]"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
Sort by:   newest | oldest | most voted
MeirM
Guest

ממש אבל ממש אהבתי. שי זה כתוב בצורה כל כך מפורטת שאני ממש מרגיש כאילו הייתי שם איתך. עוזר לי להבין דברים במסע שלי. תודה ותכתוב יותר…. מת לשמוע עוד….

Amit D
Guest

אחת הכתבות הטובות של הזמן האחרון. נהניתי לקרוא!
בהצלחה בהמשך!

מתכנת
Guest

כתבה מעולה- כן ירבו
"project honeypot" מן הסתם השם הוא בעל משמעות כפולה- ללכוד את הבוטים אבל גם ללכוד לקוחות – המפתחים ידעו בדיוק מה הם עושים
אז עוד מסקנה מהכתבה היא שמתחרים עיסקיים יכולים לקום גם מספריות "תמימות" בעולם ה open-source

מתכנת
Guest

עוד מסקנה היא שמתודולגית release early, release often היא הכרחית בעולם ה dog eat dog של טכנולוגיות ה web

חן אזר
Guest

מאלף.

שמואל
Guest

לגזור ולישמור

wpDiscuz

תגיות לכתבה: