כלים פנימיים מול אפליקציות ללקוחות: מתי לבנות מה (ולמה זה משנה)
אותו כלי לבניית אפליקציות עם בינה מלאכותית יכול לייצר אפליקציית תזמון מלוטשת ללקוחות הצילום שלכם, או תחליף מסורבל-אבל-אהוב לגיליון אלקטרוני עבור צוות התפעול שלכם. מבחוץ, שניהם “אפליקציות”. מבפנים, אלה עבודות שונות לחלוטין, ולהתייחס אליהן כאל זהות זו הטעות הכי נפוצה שאני רואה בונים חדשים עושים.
ההחלטה בין כלים פנימיים לאפליקציות ללקוחות אינה עניין של איך האפליקציה נראית. היא עניין של מי סובל מה, ומה קורה כשמשהו נשבר. תטעו בזה ותבזבזו שלושה שבועות בליטוש כפתור שאף אחד בצוות שלכם לא התעניין בו, בזמן שהמשתמשים האמיתיים שלכם נתקלים בבאג שגורם להם להפסיק לסמוך עליכם.
הנה איך להבין מה אתם באמת בונים, ומה משתנה כשאתם יודעים.
הקהל מחליט כמעט הכול
לקוח הוא מישהו שבחר בכם. הוא היה יכול להשתמש במתחרה. הוא שילם לכם, או נרשם. הוא ישפוט אתכם מול הדבר הכי מלוטש שהוא אי פעם השתמש בו, גם אם האפליקציה שלכם עולה 9 דולר בחודש ושלהם עולה 90. אין לו סבלנות לתווית מבלבלת, לזרימת התחברות מוזרה, או למסך ריק שלא אומר לו מה לעשות.
חבר לצוות הוא מישהו שחייב להשתמש בדבר הזה כי הבוס שלו אמר לו. הוא גם מישהו שיגיד לכם, בהודעת סלאק ב-11 בלילה, שהתפריט הנפתח בסדר הלא נכון. הוא יסבול מכוער. הוא לא יסבול איטי, כי הוא משתמש בזה ארבעים פעם ביום.
אותו כלי. אותו סט פיצ’רים, אולי. רף שונה לחלוטין.
כשאתם מתיישבים מול כלי לבניית אפליקציות עם בינה מלאכותית כדי לתאר מה אתם רוצים, השאלה הראשונה שכדאי לכם לענות עליה לעצמכם היא: מי המשתמש, והאם הוא בחר להיות כאן?
כלים פנימיים: מהירות מנצחת ליטוש
כלים פנימיים חיים ומתים על דבר אחד: כמה זמן הם חוסכים לאנשים שמשתמשים בהם?
מנהלת נכסים שאני מכיר בילתה שני ערבים בבניית מערכת מעקב אחר בקשות תחזוקה לצוות בן שלושה אנשים שלה. היא, בכל קנה מידה אובייקטיבי, מכוערת. הכפתורים לא עקביים. בסרגל הצד יש שגיאת כתיב שאף אחד לא טרח לתקן. אין לוגו.
הצוות שלה משתמש בה יותר מכל תוכנה אחרת שיש לו. היא חסכה להם בערך חמש שעות בשבוע של הודעות סלאק בנוסח “מישהו כבר התקשר לאינסטלטור לגבי דירה 4?”. הליטוש היה מוסיף אפס שעות של ערך.
שלוש תכונות שאני רואה בכלים פנימיים בנויים היטב:
- המסלול הקצר ביותר מ”אני רוצה לעשות X” ל-”X נעשה” מנצח. דלגו על מסך הפתיחה. דלגו על האשף. תיכנסו ישר לדבר עצמו.
- מקרי קצה יכולים להיות מכוערים. אם חבר לצוות נתקל בשגיאה, הוא ישלח לכם הודעת סלאק. לקוח פשוט היה נוטש.
- עדכונים נוחתים מדי יום, לא במהדורות. אתם לא משחררים מוצר. אתם מכווננים את הסדנה שלכם.
אם אתם בונים לצוות שלכם, תישענו חזק על “מכוער ושימושי”. התנגדו לדחף להוסיף עמוד שיווקי, מסך הגדרות, או מסך ריק מעוצב להפליא. שום דבר מזה לא מצדיק את קיומו.
אפליקציות ללקוחות: הקצוות המשעממים הם המוצר
אפליקציות ללקוחות הן בעיקר קצוות. זרימת ההתחברות. תהליך ה-onboarding. מה שקורה כשכרטיס אשראי נדחה. המייל שיוצא כשמאפסים סיסמה. המסך שמישהו רואה בפעם הראשונה שהוא פותח את האפליקציה ואין בה עדיין כלום.
אף אחד מאלה אינו הפיצ’ר שהתלהבתם ממנו. כולם הם מה שהלקוח שלכם שופט אתכם לפיו.
חבר השיק בשנה שעברה אפליקציית חשבוניות קטנה. הוא בילה את החודש הראשון בבניית עורך החשבוניות — הדבר שהתרגש ממנו. הוא היה יפהפה. אז הוא הפעיל אותו, צפה בלקוח מנסה להירשם, וגילה ש:
- מייל האימות נחת בספאם.
- אחרי האימות, האפליקציה זרקה את המשתמש ללוח בקרה ריק בלי שום הוראות.
- כפתור “צרו את החשבונית הראשונה שלכם” היה מתחת לקו הקיפול במחשב נייד של 13 אינץ’.
שלושה לקוחות נרשמו באותו שבוע. אפס יצרו חשבונית. המוצר עבד. המעטפת סביבו לא.
עבור אפליקציות פונות-לקוח, הכלל הגס הוא: בלו חצי מהמאמץ שלכם על השטח שהוא לא הפיצ’ר המרכזי. onboarding, מצבי שגיאה, זרימות תשלום, הגדרות חשבון, מייל תמיכה. הדברים האלה הם המוצר, גם אם זה לא מרגיש ככה.
איך לדעת מה אתם בונים
ההחלטה בין כלים פנימיים לאפליקציות ללקוחות קלה יותר ממה שהיא נראית ברגע שאתם שואלים כמה שאלות אבחון:
מי משלם על זה? אם התשובה היא “החברה שאני עובד בה, כחלק מתקורה”, זה כלי פנימי. אם התשובה היא “המשתמש, באופן אישי, עם כרטיס האשראי שלו”, זו אפליקציה ללקוחות. המקרה הביניים — הבוס שלכם משלם, אבל הבוס שלכם הוא לקוח — בדרך כלל עדיין נמשך לכיוון הציפיות של אפליקציה ללקוחות.
מה קורה אם זה נופל לשעה? כלי פנימי: מישהו מתעצבן. אפליקציה ללקוחות: מישהו נוטש. רדיוס הנזק של באג שונה לחלוטין.
כמה משתמשים יהיו לזה, אי פעם? חמישה עד חמישים זה בבירור פנימי. מאה עד אלף כבר מתחיל להיראות כמו מוצר אמיתי. חמשת אלפים ומעלה אומר שאתם חברת תוכנה, בין אם רציתם להיות אחת ובין אם לא.
האם תהיה למשתמשים בחירה? כלים פנימיים הם חובה. אפליקציות ללקוחות הן וולונטריות. משתמשים וולונטריים עוזבים ברגע שמשהו מעצבן אותם.
אם אתם לא יכולים לענות על אלה בבירור, אתם לא יודעים מה אתם בונים, והכלי לא יכול לעזור לכם להתכנס.
המלכודת הנסתרת: כלים שהופכים למוצרים
כאן זה נעשה מעניין. המוצרים העצמאיים הכי מצליחים שאני מכיר התחילו את חייהם ככלים פנימיים. מישהו בנה משהו לצוות שלו, הצוות הראה אותו לחבר, החבר רצה אחד כזה, ועכשיו יש לקוח.
זה סיפור נהדר. זה גם רגע של סכנה מירבית, כי ברגע שאתם גובים ממישהו, הרף זז בן לילה. סרגל הצד המכוער שהצוות שלכם סבל הוא עכשיו סיכון נטישה. הטיפול בשגיאות בנוסח “שלחו הודעת סלאק למפתח” הוא עכשיו סיוט תמיכה.
אם אתם חוצים את הגשר הזה עם כלי לבניית אפליקציות עם בינה מלאכותית, התייחסו לזה כאל מעבר אמיתי. בלו שבוע — לפחות שבוע — על הקצוות המשעממים. onboarding. מצבים ריקים. חמש הדקות הראשונות אחרי ההרשמה. הודעות שגיאה שמסבירות את עצמן. אל תקדמו את הכלי עד שהעבודה הזו תיגמר.
החדשות הטובות הן שכלי בינה מלאכותית הפכו את המעבר הזה לזול יותר מבעבר. עבודת הליטוש שבעבר לקחה חודש עם פרילנסר היא כמה סשנים טובים של ניסוח הנחיות וקצת סבלנות.
השאלה ששווה לשבת איתה
כל השאלה של כלים פנימיים מול אפליקציות ללקוחות מתמצה בהנחיה אחת לעצמכם, לפני שאתם מתארים רעיון לכלי בינה מלאכותית: האם זה כלי שאני משתמש בו, או מוצר שאני מציע?
התשובה משנה את ההנחיה. היא משנה על מה אתם משקיעים זמן. היא משנה מה אתם מתעלמים ממנו. וזו פיסת הבהירות הכי שימושית שאתם יכולים להביא איתכם לבנייה.
אם הייתם על הגדר לגבי באיזה צד אתם, הכתבה שלנו על מה צריכה להיות האפליקציה הראשונה שלכם שבניתם עם בינה מלאכותית היא קריאה משלימה טובה. רוב האפליקציות הראשונות צריכות להיות כלים. גם רוב השניות. לקוחות מגיעים אחר כך, והם מגיעים ביתר קלות אחרי שפיתחתם את השריר מבנייה של דברים שרק הצוות שלכם היה צריך לסבול.