איך להחליט איזה משוב משתמשים לבנות (ואיזה לשחרר)

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

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

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

למה “פשוט תבנה את זה” מפסיק לעבוד

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

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

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

שלוש שאלות שממיינות כמעט הכול

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

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

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

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

שלוש הערימות

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

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

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

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

דוגמה קטנה

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

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

החלק שאף אחד לא מספר לכם

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

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