בקשת הפיצ'ר שכדאי לכם באמת לבנות (ואיך לזהות אותה)

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

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

איזה שלוש?

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

האותות שמשנים

אות 1: חזרה לא יזומה

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

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

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

אות 2: העקיפה משנה

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

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

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

שימו לב אילו בקשות הן חוסמות. מישהו שאומר “אני לא יכול להשתמש בזה עד שתעשו X” לעומת מישהו שאומר “יהיה נהדר אם היה לכם X”. ההבחנה הזו היא זהב.

אות 3: הפיצ’ר נצמד למודל עסקי

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

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

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

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

אות 4: הבקשה לעזרה

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

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

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

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

הפיתוי לבנות את פיצ’ר היוקרה

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

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

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

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

איך באמת להחליט

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

1. כמה משתמשים ביקשו (באופן בלתי תלוי)? יותר זה טוב יותר.
2. האם זה חוסם או נחמד-שיהיה? חוסמים דחופים יותר.
3. האם המשתמשים שלכם יכולים לעקוף את זה היום? אם לא, זה חשוב יותר.
4. האם מישהו יעזור לכם לבדוק את זה? אם כן, בנו אותו קודם.
5. האם זה יחשוף שוק חדש? אם אולי, זה בונוס, לא סיבה.

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

הפיצ’ר שלא תבנו (עדיין)

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

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

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

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