מומחיות מוצר לא מופיעה בן לילה. תהליך הפיתוח המלא של המוצר הוא מה שיוצר "מומחים" סביב תכונות ופונקציות מסוימות, והוא הבסיס לכל התיעוד שמקדים ומלווה את השחרור שלהם.
צוותים המשתמשים בGuru להנעת מוצר מכירים בחשיבות של having a single source of truth for knowledge encompassing the entire product release lifecycle—from early development through ongoing support and maintenance. על ידי מתן מקום אחד מוסכם ואמין לכל מחלקה לשים מידע מאומת על ידי מומחים, כל המעורבים בתהליכים חוצי-תפקוד יכולים לעשות עבודה טובה יותר. בואו נלך דרך שחרור תכונה אחרונה ב-Guru כדוגמה להנעת מוצר בפעולה.
במהלך ינואר, הפוד Monetization החדש שלנו עבד על החלק הראשון של שדרוג לחוויית החיוב ב-Guru. הפרויקט הזה כלל את צוות הפיתוח המוכר—ניהול מוצר, עיצוב, הנדסה, ושיווק מוצר—כמו גם כמה בעלי עניין אחרים כולל כספים, תמיכה, ותפעול מכירות. זה היה עדכון טכני שדרש תקשורת הדוקה ותיאום בין כל הצוותים המעורבים, כמו גם עבודה הכנה משמעותית כדי שהנציגים שלנו מול הלקוחות יוכלו לדבר בביטחון על השינויים הללו. שלושת השלבים הבאים מסכמים את הדרכים העיקריות שבהן אנו משתמשים ב-Guru להנעת מוצרים סביב שחרורי תכונות כמו זה.
שלב 1: תכנון ופיתוח תכונה
הנעת מוצר מתחילה מיד כשמפרויקט צוות המוצר מקבל אור ירוק. זה יכול להיות לשדרוג פונקציית מינורית, עיצוב מחדש של דף, או תכונה חדשה לגמרי. מהרגע שבו מפרטי הפרויקט מוכנים על ידי מנהל מוצר (PM) ומשותפים עם המהנדסים, המעצבים, ובעלי העניין האחרים, כולם זקוקים לגישה לתיעוד מהימן ומעודכן ממגוון מחברים.
האם תכנית שלנו החלה בדצמבר, כאשר מנהלי המוצר שלנו זיהו כמה מקומות מרכזיים בחוויות החיוב והצ'ק-אאוט שלנו שדרושים ריענון. משם, הם פיתחו תכנית פרויקט והחלו לכתוב את מפרט התכונה המוקדם עבור הפרויקט הראשון בסדרה. ברגע שהם היו מוכנים לשתף עם הצוות, הם תכננו פגישה להכנה כדי להעביר את הצוות על השיפוט המוצע, ולדון בזמנים. מאותה נקודה, היה קריטי שכל המעורבים בפרויקט יהיו גישה לכל המסמכים הקשורים, כולל מפרטי פרויקט, עיצובים, תיעוד חיוב רלוונטי, ועוד.
מאחר שאלה מסמכים משתנים לעתים קרובות, ויכולים להתווסף יותר לאורך השלבים המוקדמים של פרויקט, חשוב שיהיה מקור מהימן שהצוות יוכל לחזור אליו. כדי לוודא שלכולם יש מקום יחיד לשתף ולגשת למשאבים אלה, יצרנו כרטיס משאבי פרויקט פעיל לשתף עם הצוות. שמרנו את זה בתוך לוח הפוד Monetization, שבו כל בעלי העניין המתאימים יש גישה לכותב.
במהלך תהליך הפיתוח, המהנדסים שלנו לא היו צריכים לדאוג לגבי סימון קבצי העיצוב או לבדוק פעמיים אם הטקסט שניתן להם בשבוע שעבר עדיין מעודכן. במקום זאת, הם יכלו להתייחס לכרטיס משאבי פרויקט פעילים בזמן עבודתם, כך שיבטיחו שהם עובדים על המידע המעודכן ביותר. ראו איך צוותי ההנדסה משתמשים ב-Guru.
שלב 2: הכנה לשחרור
אנו רואים בשחרורי תכונות כספורט קבוצתי ב-Guru. כאשר אנו מתקרבים לסוף הפיתוח, אנחנו צריכים להבטיח שעמדנו בכל הדרישות, נבדקנו עבור פוטנציאל בעיות של לקוחות, ותקשרנו את השינויים הקרובים בצורה נאותה לצוותים שמול לקוחות. מאחר שזהו השלב שבו המידע סביר שישתנה במהירות, לוודא שכל הידע מאומת על ידי המומחים הרלוונטיים הוא בעל חשיבות עליונה.
לפרויקט החיוב האחרון שלנו, הקצבנו שבוע אחד לצוות ולבעלי העניין שלנו כדי לבצע בדיקות איכות (QA) ולבחון את החוויה החדשה לפני השחרור. מאחר שזה היה פרויקט טכני במיוחד, היו מספר צעדים המעורבים בהקמת הסביבות והכנתן לבדיקה, כולל הפעלת דגלי תכונה ועבודה עם קבוצת צעדים מיוחדת של צ'ק-אאוט. כדי להבטיח לכולם את כל המידע הנדרש כדי להשתתף בבדיקות, מנהל הצוות שלנו בהנדסה יצר כרטיס עם הוראות שלב אחרי שלב להשתתפות ב-QA. שלחנו את הכרטיס הזה לפוד שלנו ולבעלי העניין באמצעות הודעה כדי לוודא שהם קראו אותו לפני שהחלו בבדיקות.
בזמן שבדיקת איכות הייתה בעיצומה, היה גם חשוב להודיע לצוותים שלנו מול הלקוחות על השינויים הקרובים כדי להכין אותם לכל שאלה שעשויה להיות ללקוחות או לקוחות פוטנציאליים. בעוד ששינויים אלה היו במידה רבה ממוקדים בשימושיות ובמהימנות (לעומת שינוי בממשק עצמו), חלקים מסוימים מחוויית החיוב המורשת עתידים להשתנות עם הפרויקט הזה. כדי לתקשר את השינויים הללו עם הרבה זמן לסקירה ולשאול שאלות, רעננו את הכרטיס שלנו לפירוט תכונת החיוב.
תחזרו שזו הפעם הראשונה בתהליך שאנחנו משתמשים במילה רענן במקום ליצור, וזה מכוון. אנו משתמשים בכרטיסי פירוט תכונות כמקור חיים של אמת לגבי תכונות עבור הצוותים שלנו שמול לקוחות, מה שאומר שיישר קיים עבור כל התכונות החיות שלנו בכל עת.
כאשר אנו מעדכנים ומשפרים תכונה קיימת, אנו מעדכנים ומשפרים גם את כרטיס פירוט התכונה בהתאם. זה מונע את הבעיה הוותיקה של נציג מכירות לא בטוח אם הם מסתכלים על תיעוד ישן על תכונה ומשדרים מהנדסים בפאניקה תוך כדי שיחה. הם יכולים להיות בטוחים שכרטיס על עמוד החיוב שעליו הם סמכו בשנה שעברה הוא בדיוק כמו הזה השנה, כפי שאושר על ידי הצוות המעסיק בשיפורים.
שלב 3: שחרור ומעבר
היישום הבולט ביותר של הנעת מוצר יכול מאוד להיות סביב השקת התכונה החדשה או המשודרגת. מסקירות כמו כרטיס פירוט התכונה למעלה ועד תקלות טכניות מאוד, שיח של פתרון בעיות, הרבה נכנס כדי לוודא שצוותים מול לקוחות מצוידים בכל מה שהם צריכים כדי למכור ולתמוך בכל שחרור. וכשיש תכונות שנעשות רטרואקטיביות ומשופרות עם הזמן, זה נותר חיוני שכל התיעוד יישמר מעודכן ומשקף את המצב הנוכחי של המוצר.
זה לא מפתיע שעמודי חיוב הם מאוד מורכבים ומנומסים, מה שאומר שאין חוסר בשאלות פוטנציאליות שהלקוחות עשויים להיות להם כאשר הם משלימים תהליך צ'ק-אאוט. בעוד שחוויית החיוב שלנו אינה משהו שהצוות המכירות שלנו כנראה יתמודד עליו בפרטים רבים מדי, זה אזור שבו צוות התמיכה שלנו לעיתים קרובות עוזר ללקוחות לנווט. כדי להתכונן להשקה הזו ולשיפורים נוספים הקרובים שלנו לחוויית הצ'ק-אאוט, מנהל הצוות שלנו בהנדסה עבד עם נציג התמיכה שלנו בלקוחות כדי לאסוף רשימה של שאלות טכניות נפוצות, המתעדכנת כאשר מופיעות שאלות חדשות. זה נותן לא רק לצוות התמיכה, אלא לכל מי שמגיב לשאלות של לקוחות על חיוב מקום עקבי לבדוק קודם לפני שהם פונים לצוות שלנו (ובכך, מוסיפים לכרטיס השאלות טכניות הנפוצות!).
בנוסף לשמירה על כרטיס שאלות טכניות הנפוצות מעודכן כמו התהליך מתקדם, כרטיס פירוט התכונה נשמר גם הוא רענן. בנוסף לציון התאריך הרשמי להשקה ודברים חשובים לדבר על חוויית החיוב החדשה, נקשר למשאבים וכרטיסים נוספים קשורים, כמו פוסט הבלוג הזה. על ידי יצירת חנות חד-פעמית לגישה לכל המידע הקיים על תכונה, אנחנו נותנים לצוותים מול הלקוחות ביטחון לדבר עם לקוחות וללקוחות פוטנציאליים עם פרספקטיבה מעודכנת.
לסגירת המעגל הזה, אנחנו לא יכולים לשכוח איך משוב משלקוחות ושוק משחק תפקיד חשוב במחזור פיתוח המוצר. כאשר הצוותים שלנו מביאים תכונות חדשות ומשופרות ללקוחות הקיימים שלנו ולשוק שלנו, אנחנו אוספים תובנות יקרות ערך על מה עוזר להם לבצע עבודה טובה יותר, ומה הם מקווים לראות אותנו מתמקדים בו הבא. תיעוד ושיתוף מידע זה עם צוות המוצר שלנו הוא חלק חשוב בתהליך הפיתוח האיטי שלנו, ועוזר לנו להגשים את הערך המרבי עבור הלקוחות שלנו. וציוד לחלק את דרכי משוב שונות (הקלטות של שיחות, מיילים, וכו') נשמר ב-Guru.
מומחיות מוצר לא מופיעה בן לילה. תהליך הפיתוח המלא של המוצר הוא מה שיוצר "מומחים" סביב תכונות ופונקציות מסוימות, והוא הבסיס לכל התיעוד שמקדים ומלווה את השחרור שלהם.
צוותים המשתמשים בGuru להנעת מוצר מכירים בחשיבות של having a single source of truth for knowledge encompassing the entire product release lifecycle—from early development through ongoing support and maintenance. על ידי מתן מקום אחד מוסכם ואמין לכל מחלקה לשים מידע מאומת על ידי מומחים, כל המעורבים בתהליכים חוצי-תפקוד יכולים לעשות עבודה טובה יותר. בואו נלך דרך שחרור תכונה אחרונה ב-Guru כדוגמה להנעת מוצר בפעולה.
במהלך ינואר, הפוד Monetization החדש שלנו עבד על החלק הראשון של שדרוג לחוויית החיוב ב-Guru. הפרויקט הזה כלל את צוות הפיתוח המוכר—ניהול מוצר, עיצוב, הנדסה, ושיווק מוצר—כמו גם כמה בעלי עניין אחרים כולל כספים, תמיכה, ותפעול מכירות. זה היה עדכון טכני שדרש תקשורת הדוקה ותיאום בין כל הצוותים המעורבים, כמו גם עבודה הכנה משמעותית כדי שהנציגים שלנו מול הלקוחות יוכלו לדבר בביטחון על השינויים הללו. שלושת השלבים הבאים מסכמים את הדרכים העיקריות שבהן אנו משתמשים ב-Guru להנעת מוצרים סביב שחרורי תכונות כמו זה.
שלב 1: תכנון ופיתוח תכונה
הנעת מוצר מתחילה מיד כשמפרויקט צוות המוצר מקבל אור ירוק. זה יכול להיות לשדרוג פונקציית מינורית, עיצוב מחדש של דף, או תכונה חדשה לגמרי. מהרגע שבו מפרטי הפרויקט מוכנים על ידי מנהל מוצר (PM) ומשותפים עם המהנדסים, המעצבים, ובעלי העניין האחרים, כולם זקוקים לגישה לתיעוד מהימן ומעודכן ממגוון מחברים.
האם תכנית שלנו החלה בדצמבר, כאשר מנהלי המוצר שלנו זיהו כמה מקומות מרכזיים בחוויות החיוב והצ'ק-אאוט שלנו שדרושים ריענון. משם, הם פיתחו תכנית פרויקט והחלו לכתוב את מפרט התכונה המוקדם עבור הפרויקט הראשון בסדרה. ברגע שהם היו מוכנים לשתף עם הצוות, הם תכננו פגישה להכנה כדי להעביר את הצוות על השיפוט המוצע, ולדון בזמנים. מאותה נקודה, היה קריטי שכל המעורבים בפרויקט יהיו גישה לכל המסמכים הקשורים, כולל מפרטי פרויקט, עיצובים, תיעוד חיוב רלוונטי, ועוד.
מאחר שאלה מסמכים משתנים לעתים קרובות, ויכולים להתווסף יותר לאורך השלבים המוקדמים של פרויקט, חשוב שיהיה מקור מהימן שהצוות יוכל לחזור אליו. כדי לוודא שלכולם יש מקום יחיד לשתף ולגשת למשאבים אלה, יצרנו כרטיס משאבי פרויקט פעיל לשתף עם הצוות. שמרנו את זה בתוך לוח הפוד Monetization, שבו כל בעלי העניין המתאימים יש גישה לכותב.
במהלך תהליך הפיתוח, המהנדסים שלנו לא היו צריכים לדאוג לגבי סימון קבצי העיצוב או לבדוק פעמיים אם הטקסט שניתן להם בשבוע שעבר עדיין מעודכן. במקום זאת, הם יכלו להתייחס לכרטיס משאבי פרויקט פעילים בזמן עבודתם, כך שיבטיחו שהם עובדים על המידע המעודכן ביותר. ראו איך צוותי ההנדסה משתמשים ב-Guru.
שלב 2: הכנה לשחרור
אנו רואים בשחרורי תכונות כספורט קבוצתי ב-Guru. כאשר אנו מתקרבים לסוף הפיתוח, אנחנו צריכים להבטיח שעמדנו בכל הדרישות, נבדקנו עבור פוטנציאל בעיות של לקוחות, ותקשרנו את השינויים הקרובים בצורה נאותה לצוותים שמול לקוחות. מאחר שזהו השלב שבו המידע סביר שישתנה במהירות, לוודא שכל הידע מאומת על ידי המומחים הרלוונטיים הוא בעל חשיבות עליונה.
לפרויקט החיוב האחרון שלנו, הקצבנו שבוע אחד לצוות ולבעלי העניין שלנו כדי לבצע בדיקות איכות (QA) ולבחון את החוויה החדשה לפני השחרור. מאחר שזה היה פרויקט טכני במיוחד, היו מספר צעדים המעורבים בהקמת הסביבות והכנתן לבדיקה, כולל הפעלת דגלי תכונה ועבודה עם קבוצת צעדים מיוחדת של צ'ק-אאוט. כדי להבטיח לכולם את כל המידע הנדרש כדי להשתתף בבדיקות, מנהל הצוות שלנו בהנדסה יצר כרטיס עם הוראות שלב אחרי שלב להשתתפות ב-QA. שלחנו את הכרטיס הזה לפוד שלנו ולבעלי העניין באמצעות הודעה כדי לוודא שהם קראו אותו לפני שהחלו בבדיקות.
בזמן שבדיקת איכות הייתה בעיצומה, היה גם חשוב להודיע לצוותים שלנו מול הלקוחות על השינויים הקרובים כדי להכין אותם לכל שאלה שעשויה להיות ללקוחות או לקוחות פוטנציאליים. בעוד ששינויים אלה היו במידה רבה ממוקדים בשימושיות ובמהימנות (לעומת שינוי בממשק עצמו), חלקים מסוימים מחוויית החיוב המורשת עתידים להשתנות עם הפרויקט הזה. כדי לתקשר את השינויים הללו עם הרבה זמן לסקירה ולשאול שאלות, רעננו את הכרטיס שלנו לפירוט תכונת החיוב.
תחזרו שזו הפעם הראשונה בתהליך שאנחנו משתמשים במילה רענן במקום ליצור, וזה מכוון. אנו משתמשים בכרטיסי פירוט תכונות כמקור חיים של אמת לגבי תכונות עבור הצוותים שלנו שמול לקוחות, מה שאומר שיישר קיים עבור כל התכונות החיות שלנו בכל עת.
כאשר אנו מעדכנים ומשפרים תכונה קיימת, אנו מעדכנים ומשפרים גם את כרטיס פירוט התכונה בהתאם. זה מונע את הבעיה הוותיקה של נציג מכירות לא בטוח אם הם מסתכלים על תיעוד ישן על תכונה ומשדרים מהנדסים בפאניקה תוך כדי שיחה. הם יכולים להיות בטוחים שכרטיס על עמוד החיוב שעליו הם סמכו בשנה שעברה הוא בדיוק כמו הזה השנה, כפי שאושר על ידי הצוות המעסיק בשיפורים.
שלב 3: שחרור ומעבר
היישום הבולט ביותר של הנעת מוצר יכול מאוד להיות סביב השקת התכונה החדשה או המשודרגת. מסקירות כמו כרטיס פירוט התכונה למעלה ועד תקלות טכניות מאוד, שיח של פתרון בעיות, הרבה נכנס כדי לוודא שצוותים מול לקוחות מצוידים בכל מה שהם צריכים כדי למכור ולתמוך בכל שחרור. וכשיש תכונות שנעשות רטרואקטיביות ומשופרות עם הזמן, זה נותר חיוני שכל התיעוד יישמר מעודכן ומשקף את המצב הנוכחי של המוצר.
זה לא מפתיע שעמודי חיוב הם מאוד מורכבים ומנומסים, מה שאומר שאין חוסר בשאלות פוטנציאליות שהלקוחות עשויים להיות להם כאשר הם משלימים תהליך צ'ק-אאוט. בעוד שחוויית החיוב שלנו אינה משהו שהצוות המכירות שלנו כנראה יתמודד עליו בפרטים רבים מדי, זה אזור שבו צוות התמיכה שלנו לעיתים קרובות עוזר ללקוחות לנווט. כדי להתכונן להשקה הזו ולשיפורים נוספים הקרובים שלנו לחוויית הצ'ק-אאוט, מנהל הצוות שלנו בהנדסה עבד עם נציג התמיכה שלנו בלקוחות כדי לאסוף רשימה של שאלות טכניות נפוצות, המתעדכנת כאשר מופיעות שאלות חדשות. זה נותן לא רק לצוות התמיכה, אלא לכל מי שמגיב לשאלות של לקוחות על חיוב מקום עקבי לבדוק קודם לפני שהם פונים לצוות שלנו (ובכך, מוסיפים לכרטיס השאלות טכניות הנפוצות!).
בנוסף לשמירה על כרטיס שאלות טכניות הנפוצות מעודכן כמו התהליך מתקדם, כרטיס פירוט התכונה נשמר גם הוא רענן. בנוסף לציון התאריך הרשמי להשקה ודברים חשובים לדבר על חוויית החיוב החדשה, נקשר למשאבים וכרטיסים נוספים קשורים, כמו פוסט הבלוג הזה. על ידי יצירת חנות חד-פעמית לגישה לכל המידע הקיים על תכונה, אנחנו נותנים לצוותים מול הלקוחות ביטחון לדבר עם לקוחות וללקוחות פוטנציאליים עם פרספקטיבה מעודכנת.
לסגירת המעגל הזה, אנחנו לא יכולים לשכוח איך משוב משלקוחות ושוק משחק תפקיד חשוב במחזור פיתוח המוצר. כאשר הצוותים שלנו מביאים תכונות חדשות ומשופרות ללקוחות הקיימים שלנו ולשוק שלנו, אנחנו אוספים תובנות יקרות ערך על מה עוזר להם לבצע עבודה טובה יותר, ומה הם מקווים לראות אותנו מתמקדים בו הבא. תיעוד ושיתוף מידע זה עם צוות המוצר שלנו הוא חלק חשוב בתהליך הפיתוח האיטי שלנו, ועוזר לנו להגשים את הערך המרבי עבור הלקוחות שלנו. וציוד לחלק את דרכי משוב שונות (הקלטות של שיחות, מיילים, וכו') נשמר ב-Guru.
חוויית הפלטפורמה של Guru מהלך ראשון – קח את סיור המוצר האינטראקטיבי שלנו
.webp)
