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

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

היא בוהה בזה כבר שבועיים ולא השיקה.

כששאלתי למה, היא אמרה: “זה עובד, אבל… זה לא מרגיש מוכן.”

שאלתי אותה מה היא הייתה משנה. היא אמרה: “אני לא יודעת. זו הבעיה.”

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

מה “מוכן” באמת אומר

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

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

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

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

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

שלוש שאלות שמפרידות אב-טיפוס ממוצר

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

1. הייתם משתמשים בזה כדי לפתור את הבעיה שלכם?

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

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

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

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

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

2. הראיתם את זה לשלושה אנשים שהם לא אתם?

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

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

הנה מה שאתם מחפשים: איפה הם מתבלבלים? איפה הם מהססים? על מה הם שואלים? לא “מה הם חושבים על זה?” (אנשים נחמדים מדי). בקשו מהם באמת לעשות את הדבר — לקבוע פגישה, לשלוח מייל אישור, לבטל משהו.

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

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

3. מה היה נשבר אם הייתם נותנים את זה לעשרה משתמשים אמיתיים?

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

עבור אפליקציית המטפלים:

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

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

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

איך להחליט: מבחן שלוש השכבות

השתמשו בזה כדי להבין איפה אתם:

שכבה 1: הזרימה המרכזית — האם המסלול המאושר עובד? האם משתמש יכול לעשות את הדבר העיקרי שהאפליקציה שלכם מיועדת לו?

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

שכבה 2: מקרי קצה משימוש אמיתי — הראיתם את זה לשלושה משתמשים אמיתיים. האם הם נתקלו במשהו שלא בניתם עבורו? האם הם התבלבלו איפשהו?

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

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

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

הנה כלל האצבע:

• כל שלוש השכבות עובדות? אתם מוצר. שחררו אותו.
• שכבות 1 ו-2, לא 3? אתם 80% מוכנים. בלו יום על ליטוש.
• שכבה 1 עובדת, שכבות 2 ו-3 לא? אתם אב-טיפוס. אל תשחררו עדיין.
• שכבה 1 לא יציבה? אתם לא מוכנים. תמשיכו לבנות.

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

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

הדבר שמקשה על זה

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

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

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

זה לא הגופנים.

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

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

השתמשו בזה. היא קצרה וכנה.

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

אם אתם יכולים לסמן את כל חמש התיבות, אתם מוכנים. השיקו.

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

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