מלכודת התרחבות ההיקף: איך לומר לא לפיצ'רים שנשמעים טוב אבל לא באמת

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

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

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

זו התרחבות היקף (scope creep), והיא הורגת יותר אפליקציות קטנות שנבנו עם בינה מלאכותית מכפי שבעיות טכניות אי פעם יהרגו. לא כי אתם בונים את הפיצ’רים — אלא כי נגמרים לכם הזמן, הכסף או השפיות בניסיון לבנות אותם.

איך התרחבות היקף הורגת אפליקציה שעובדת

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

ואז מגיעה בקשה מספר ארבע: “אפשר שיהיו רמות הרשאה שונות?” פתאום אתם צריכים לחשוב מחדש מי יכול לראות מה בכל מסך. זה לא פיצ’ר; זה שינוי ארכיטקטוני. אתם מבקשים מבונה ה-AI שלכם לעשות את זה. זה נוגע בהכול. שבועיים הופכים לשלושה. האפליקציה נעשית איטית יותר כי הוספתם לוגיקה לכל תצוגה.

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

בניתם משהו שעובד. שברתם אותו בניסיון להיות הכול.

מסגרת ההחלטה

אתם צריכים שער. כל בקשת פיצ’ר עוברת דרך שלוש שאלות:

שאלה 1: האם זה שייך לאפליקציה הזו, או שזו אפליקציה אחרת?

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

מבחן טוב: “אם הייתי לוקח את הפיצ’ר הזה ומשיק אותו בנפרד, אנשים היו רוצים לקנות אותו?” אם כן, הוא כנראה שייך לאפליקציה אחרת. אם התשובה היא “לא, זה הגיוני רק כחלק מהדבר הגדול יותר”, אז אתם בונים את ההיקף הנכון.

תקבלו בקשות כמו “להשתלב עם ה-CRM שלנו”. מה שזה באמת אומר זה “תהיו ה-CRM של עצמכם”. זו אפליקציה אחרת. אתם יכולים להשתלב עם CRM מאוחר יותר. אתם לא יכולים להוסיף פיצ’רים בשווי של CRM שלם בלי להפוך ל-CRM.

שאלה 2: האם זה פותר בעיה לרוב המשתמשים שלכם, או רק לזה האחד?

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

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

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

שאלה 3: כמה זה עולה ומה המחיר לרעיון המקורי?

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

שאלו בצורה קונקרטית: “אם אני בונה את זה, מה אני לא בונה?” אם התשובה היא “כלום, יש לנו זמן אינסופי”, אתם לא כנים. אין לנו. הזמן סופי.

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

דוגמה אמיתית: טופס קליטה

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

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

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

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

בקשה רביעית: “אפשר שמאמנים ישלחו מעקבי קליטה דרך SMS?” עכשיו אתם מערכת תקשורת. לא.

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

איך לומר לא

החלק הכי קשה הוא בעצם לומר את זה. אתם לא רוצים לתסכל את המשתמשים שלכם.

היו כנים: “זה רעיון מצוין, אבל זה מוצר אחר ממה שאנחנו בונים כאן. מה שאנחנו בונים זה [העבודה האחת שלכם]. אם ננסה לעשות קביעת פגישות או חשבוניות או דברים של CRM, נהיה בסדר בכולם ומעולים באף אחד.”

לעיתים קרובות הלקוח יבין. הוא שאל כי הרעיון עלה לו בראש, לא כי הוא בודק אתכם.

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

הפיתוי להיות הכול

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

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

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

תגידו לא. הגנו על הליבה. עשו זאת, ותבנו משהו שאנשים באמת רוצים להשתמש בו.