מה העלות של רעיון, האם הוא שווה ערך, או שהוא לא כלום לפני יישום? ניהול פיתוח מוצר בנוי על רעיונות והנחות. צוות מוצר צריך להגיב במהירות לכל דרישות השוק או תנודות. כל החלטה צריכה להיעשות כדי להגדיל את ערך המוצר, הכנסה, או קפיטליזציה. בינתיים, תהליך החקירה צריך להיעשות עם משאבים מינימליים. Hypotheses in this avalanche may be connected with different aspects: אסטרטגיות שיווק חדשות New features. הסתגלות לשווקים חדשים או ניסים. חקירה על יצירת מוצר חדש מאפס. Nevertheless, despite the variety of assumptions, retrospective analysis may show that the whole backlog of ideas in one product niche isn’t endless. Ideas may be developed in personal notes or company chats without a system, and after team member rotation, the team will provide the same investigation without taking previous experience into account. These ideas require a proper framework for storing, accumulating and providing insights about the market, regardless of changes in the team or company growth. This viable system proves that ideas cost a lot and may help product managers to save time and company resources. IdeaOps לפיתוח מוצרים המונח "IdeaOps" כמערכת מוצר הוצג לראשונה עבורי בתוכנית "עסקים מרדניים" של קתרין ר. ליבר בפרק הפודקאסט "Stop Bleeding Out Your Competitive Edge: Use IdeaOps To Start Capturing And Acting On Essential Innovations" (02.02.2025). קישור: https://creators.spotify.com/pod/profile/katya052/episodes/Stop-Bleeding-Out-Your-Competitive-Edge-Use-IdeaOps-To-Start-Capturing-And-Acting-On-Essential-Innovations-e2u9jrk. במאמר זה אני חולק את החוויה האישית שלי בפיתוח המוצר המשלב את הרעיון של המונח המקורי. המונח "IdeaOps" כמערכת מוצר הוצג לראשונה עבורי בתוכנית "עסקים מרדניים" של קתרין ר. ליבר בפרק הפודקאסט "Stop Bleeding Out Your Competitive Edge: Use IdeaOps To Start Capturing And Acting On Essential Innovations" (02.02.2025). . https://creators.spotify.com/pod/profile/katya052/episodes/Stop-Bleeding-Out-Your-Competitive-Edge-Use-IdeaOps-To-Start-Capturing-And-Acting-On-Essential-Innovations-e2u9jrk In this article I share my personal product development experience that complements the idea of the original term. ליבה של המסגרת היא ההבנה כי כל ההשערה היא נכס של החברה. This asset should have an owner, the whole context of the idea, artefacts that were created during the investigation process, links to other assets and the state of the decision. The recommendations described below will reveal the necessity of a process where it is highly important not only to fixate on the adoption or rejection of the hypothesis, but to show the whole tracing process with the history of thinking, time spent and intermittent results. כמו עם כל מסגרת אחרת, ההיבטים העיקריים יובאו במאמר: כיצד לבנות את תהליך איסוף רעיונות. איך לשמור על הרעיונות. כיצד ליישם את המסגרת. How to measure the success and value of changes. How to build the process of idea gathering? התהליך עוקב אחר המלצות נפוצות ומשמשות היטב לבקשות לשינוי הקרובות.כל רעיון חייב לעבור דרך צינור: יצירת Context. של שמאל הוכחה ההערכה ההחלטה יצירה כל רעיון חייב להיות נתפס בתוך התשתית של החברה על פי הכללים: For every idea or request, a unique ticket should be created לפעמים רעיון עשוי להיות מורכב ודורש תיקון של המוצר או הגישה בשוק עצמו. יש צורך ללמד את הצוות איך להפריד כל ההשערה לשיפור יקר אבל נפרד. זה יכול ליצור כמה בירוקרטיה נוספת ולהפחית את מספר הרעיונות - אם זה קשה להכתיב, חלק מחברי הצוות עשוי להימנע קביעת רעיון. בניגוד לכך, זה עוזר לסנן הצעות גלובליות שקשה להבין ולהעריך. In the exaggerated example below, I provide a decomposition process where an idea like “Let’s earn a few additional millions of dollars” is great at its core, but a useless suggestion for the process. However, it’s fine to create a ticket about a new payment workflow because we have noticed problems with the customers' journey. That’s our ticket. Ticket should be created in unified software and available for other team members מנהלי מוצר ממצוות שונות עשויים לשמור על רעיונותיהם במחסום באזורים המקומיים שלהם או אפילו באפליקציות הערות פרטיות.זה טוב יותר מאשר היעדר חסימה בכלל, אבל זה מוביל למגוון רחב של פורמטים וחוסר זמינות לנתח את "התמונה הגדולה". עדיף להשתמש במוצר ארגוני גדול שבו קל יותר לקשר חפצים במהלך חקירת רעיונות, כגון Microsoft Azure DevOps או Atlassian Jira (בהתאם לתהליכים של צוות המפתחים). תוכנה מאוחדת צריכה לענות על הדרישות: זמין לכל חבר צוות בחשבון ארגוני, והוא עוזר גם בניהול זכויות ובקרה במהלך סיבוב צוות. כדי להתאים את המסגרת לצרכים של החברה, יש צורך בהזדמנות ליצור שדות נוספים או סטטוסים מותאמים אישית. פיקוח על ידי החברה.כפי שצוין לעיל, רעיונות צריכים להפוך את הנכסים של החברה. Ticket should be named properly בגלל רעיון / כרטיס הוא נכס של החברה, הצוות צריך ללמוד איך לסווג ולשמור נכסים אלה כראוי (וכמה עצות יינתנו להלן). During the creation of the ticket, especially for non-technical contributors, naming could be omitted and tickets like "Improve the website" may be created. The ticket may be well described in the context part, but for future logs it’s necessary to provide additional information in the title. That’s why it’s better to establish some rules: Ticket title should be unique and include the main suggestion. הכרטיס לא צריך לכלול ביטויים ג'רגן או קיצורים מעורפלים כדי להיות מובן לקבוצות שונות. כותרת הכרטיס צריכה להיות בנויה על ידי מבנה: כדי לעשות XXX ב- YYY כדי לשנות ZZZ; במילים אחרות, להכיל אובייקט, נושא ותוצאה. Still, in real life, this rule may sound utopian; that's why ticket workflow should include naming corrections during investigation. דוגמה עם חברת פיקטיבית "PaperGone": לשפר את האתר -> » מחדש את תסריט התשלום באתר "PaperGone" כדי לתקן יצירת חשבון חובה בעת חיוב כאן אנו מכוונים כמה היבטים מההתחלה: It’s necessary to fix the "PaperGone" website (because we may have a few websites and it’s nice to locate the correct one from the beginning). הבקשה מתייחסת לשיפור תהליך התשלום. The title shows the problem with excessive account creation during the payment. Context הכרטיס צריך לכלול תיאור מדוע צוות המוצר חייב לעבד את ההצעה.בהתאם לתהליכים של החברה, עשויים להיות דרושים או אופציונליים חפצים בהקשר. רשימה של מידע הקשר האפשרי: General description: what is it about? ייתכן שתכיל מידע על שינויים בשוק, בקשות לקוחות או גורמים אחרים. מקורות: עותקים של מכתבי לקוחות, ראיונות, דיווחים או חדשות ממקורות ציבוריים. סיפורי משתמשים (אם יש): כדי לחשוף קהל היעד ואת התסריטים לשיפור. ככל שהקשר מפורט יותר, כך סביר יותר שהצוות ימשיך לקבל החלטה חיובית במהלך החקירה. Links זוהי אחת התכונות העיקריות של מסגרת IdeaOps. כל היפותזה החדשה צריכה להינתן בהתבסס על הניסיון הקודם. עבור הכרטיס "עבדו מחדש את תסריט התשלום באתר "PaperGone" כדי לתקן יצירת חשבון חובה בעת חיוב" הצוות צריך לחפש בקשות אחרות על אתר PaperGone. אולי בשנה שעברה צוות המכירות שאל את אותה השאלה, אבל החלטנו כי יצירת חשבון במהלך תהליך התשלום היא חובה, או שאפילו יש לנו בקשה מלאה "הוסף יצירת חשבון עבור כל תהליך רכישה באתר "PaperGone". בכל מקרה, כרטיסים יחסיים או שינויים יש להוסיף לאחד החדש כדי להתחיל בדיקת ההשערה. קישורים אלה לא צריכים להפסיק את החקירה על הכרטיס, כי המצב בשוק עשוי להשתנות; ההצעה עדיין חייבת להיבדק. Of course, it’s possible that the ticket is completely unique and doesn't relate to anything before. Or the framework was established not so long ago and there’s no available data. In this case, it’s necessary to provide proper attachments and full information at the later stages of the process of the ticket, to improve work in future. Evidence במהלך שלב "הראיות", הקבוצה צריכה לספק חקירה המבוססת על מידע קשור והצעות נוכחיות. שלב זה צריך לספק אמנים כגון: פגישות עם דיונים על יישום עם בעלי עניין, לקוחות, לקוחות פוטנציאליים ומפתחים. מחקר שוק אינטראקציה עם mock-ups הוכחה של מושג (POC) או תוצאות בדיקות A / B. חשוב להקים תהליך של הערכה ולאסוף נתונים על הזמן שהושקע בעבודה על כל חפץ, ללא קשר להחלטה על כרטיס מסוים זה, נתונים כאלה יכולים לספק תובנות יקרות לגבי המשאבים שיש להשקיע בחקירות דומות. Estimation הצוות צריך לספק הערכה המבוססת על ראיות בכמה היבטים: Aspect Description Time and money How many hours of every kind of specialist should we spend to implement the suggestion? The idea should go through an estimation process and the total has to be attached to the ticket. Risks What are our risks to implement or omit this idea? Maybe we will lose a key client if we decide not to implement this feature. Or maybe we are losing money every day with a malfunctioning payment scenario on our website. Some ideas also may backfire - the team could implement a new feature and receive an additional revenue, but will have performance and stability issues. That’s why it’s necessary to investigate and document suggestions from different perspectives. This information also may be useful in the future during the discussion of why such a great idea wasn’t implemented in the product. Priority How important is this idea for the product or business at all? This estimation parameter is a tricky one and depends on the correctness of the product strategy. However, a well-provided “Evidence” stage may help to calculate the priority based on established rules and investigated data. There’re many approaches to priority, but simpler is better, so good old RFC 2119 works fine. זמן וכסף כמה שעות של כל סוג של מומחה אנחנו צריכים להשקיע ליישם את ההצעה? הרעיון צריך לעבור תהליך הערכה ואת הסכום חייב להיות קשור לכרטיס. סיכונים What are our risks to implement or omit this idea? ייתכן שאנו מאבדים לקוח מפתח אם נחליט לא ליישם תכונה זו, או שאולי אנו מאבדים כסף כל יום עם תסריט תשלום פגום באתר האינטרנט שלנו. מידע זה עשוי גם להיות שימושי בעתיד במהלך הדיון למה רעיון נהדר כזה לא הושג במוצר. עדיפות עד כמה רעיון זה חשוב למוצר או לעסק בכלל? פרמטר ההערכה הזה הוא פרמטר מסובך והוא תלוי במדיניות המוצר. There’re many approaches to priority, but simpler is better, so good old RFC 2119 works fine. הפניות : Clegg, D. (1994). Case Method Fast-Track: A RAD Approach. Bradner, S. (1997). מילות מפתח לשימוש ב RFCs כדי לציין רמות דרישות (RFC 2119). אינטרנט הנדסה צוות. זמין ב: https://www.rfc-editor.org/rfc/rfc2119. References: גולן ד (1994 ) אדיסון-ווזלי Case Method Fast-Track: A RAD Approach בראדנר, S. (1997 ) (RFC 2119). Internet Engineering Task Force. Available at: . מילות מפתח לשימוש ב-RFC כדי לציין רמות דרישות https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119 החלטה שלב התוצאה, המבוסס על הניתוח הקודם והחפצים, הוא השלב החשוב ביותר עבור IdeaOps. ישנן כמה אפשרויות כיצד כל בקשה יכולה להסתיים: אנו נעשה זאת – יש צורך לכתוב מדוע זה נשמע כמו רעיון רווחי ומה עוזר לנו לקבל את ההחלטה הנכונה. זה בהחלט לא שווה את זה – בסדר, אבל למה? אולי נתונים מסוימים נאספו לא נכון, או הערך התוצאה הוא נמוך. עם זאת, מנהל המוצר חייב לכתוב חוות דעת מפורטת על ההסרה. זה נחמד, ויש קצת עניין בחברה שלנו, אבל לא עכשיו – מתי אנחנו צריכים לחזור לבקשת זו כדי לא לוותר על זה בפירוק ענק? זה טוב אם אנו משלבים אותו עם בקשה אחרת - בואו נבנה תוכנית כדי לשנות אותו עם בקשה נוספת ואת הצורה של תהליך זה. כמובן, יש יותר תסריטים, אבל במאמר זה אני רוצה להראות דוגמה של חשיבה: כל בקשה חייבת להיות מעובדת לאורך כל הצינור ויש לה תוצאה נכונה כדי להראות לחברי צוות הנוכחיים או העתידיים את הדרך של קבלת ההחלטה. כל בקשה חייבת להיות מעובדת לאורך כל הצינור ויש לה תוצאה נכונה כדי להראות לחברי צוות הנוכחיים או העתידיים את הדרך של קבלת ההחלטה. People can make mistakes or adopt the wrong decision according to the situation and their knowledge. This process obliges them to document this decision and helps the company to revise and learn based on these requests later. How to store ideas We have covered the basic steps of the framework, but for proper use of a general request backlog it’s necessary to build a storage system that helps any team member to find any active or archived idea in minimal time. The best way to achieve this is to slice data via a set of filters and parameters. It is highly important to store all ideas in a unified space, accessible for different teams. Technically, it’s possible to use any spreadsheet software as storage for requests/ideas and filter them using attributes in columns, but it is easier and more manageable to use a large product for teamwork such as Atlassian Jira or Microsoft Azure DevOps. These products can help to organise workflows, proper stage management and role-based access control. Every request may have different dimensions: מוצר דומיין עסקי Business risk. Product functionality. Request Stage. מקורות ככל שיותר מסננים זמינים עבור רעיון backlog, כך חברי צוות רבים יותר עם מגוון רחב של ניסיון ודרכי חשיבה עשויים לנווט דרך זה. הרשימה של ממדים אינה שלמה ומספקת רק דוגמה של דרכים של פירוק. אני ממליץ לארגן כמה סדנאות brainstorm כדי לחשוף את כל המסננים המתאימים עבור backlog ולעדכן אותם מעת לעת. Let’s skim through examples of dimensions. Every aspect may be disclosed as a group of filters; the complexity depends on a product and company's structure. מוצר Companies may develop few products or generations of products, so any ticket should be connected to the product, or platform of product generation. This block may consist of product names: Website, Product 1 for SaaS, Product 2 for On-Prem, etc. Or help to locate the platform: Frontend, Backend, iOS/iPadOS, Android. בדוגמה הקודמת, דיברנו על בקשה פיקטיבית, " " בחברה PaperGone, אז אני אספק פרמטרים אפשריים בתיאוריה עבור כניסה נכונה של בקשה זו. מחדש את תסריט התשלום באתר "PaperGone" כדי לתקן יצירת חשבון חובה בעת חיוב דומיין עסקים תכונה זו צריכה לעזור לאתר את האדם האחראי לעיבוד הבקשה.האם זה רעיון לשיפור שיווקי, או האם זה קשור לבעיות שלנו ב-onboarding?או האם זה על פונקציונליות מוצר נוספת המסייעת לנו לקדם את הלקוחות הנוכחיים?התכונה העסקית היא תכונה מרכזית לדרכה של בקשות דרך מחלקות ומנהלים שונים.דוגמאות: מכירות, שיווק, תמיכה ללקוחות, חשבונאות, פיתוח, QA וכו'. סיכון עסקי Every request may cover a different company risk. Some of them may reveal architectural flaws in product infrastructure, or something connected with sales and competitors. The author of the request should realise what the most suitable option is. This dimension is about possible problems in something: sales (cannot sell without it), upselling (cannot grow current accounts without it), security (potential exploit concern), competitors (something that we don’t have), legal (our agreement forms are not so good). Product functionality To grow complex products, it’s necessary to know what you are managing. A company's products consist of dozens of features, and new requests may be improvements to some of them or related to something existing. It helps a lot to sort incoming ideas through a features funnel to realise the level of demand for some parts of the product or to find the most problematic areas. The way to achieve this decomposition is described in the article - “ » https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition הדרך להשיג פירוק זה מתואר במאמר - " » https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition בקשה לשלב Helps to locate the current status of a request according to the IdeaOps workflow. An example of the stage structure: חדש - אף אחד לא עבד את הבקשה. כדי להעריך - הבקשה עוברת דרך שלבים של קישורים, ראיות, הערכות. Decision stages: Approved - the team has decided to implement the request. Rejected - the team declined the request and provided an explanation of why the idea was rejected. Postponed - the team decided that it’s impossible to process the request in the current situation. מחויב - שלב הפיתוח, אשר דורש הוא בתהליך של ביצוע. Closed - the final stage to indicate the completion of the request. Sure, depending on the process, it’s possible to expand the stages structure to reflect the process in a more detailed way, but it’s always necessary to find a balance between transparency and excessive bureaucracy. מקור הרעיונות עשויים להיווצר על ידי שחקנים שונים, וזמן העיבוד עשוי להשתנות בהתאם למקור.לדוגמה: בעלי עניין, לקוחות, מכירות, מהנדסי תמיכה ללקוחות, מפתחים. This system of parameters helps to find any new or past request with minimal time; however, at the same time, it may be an obstacle for the team members because it complicates the way ideas are shared. The intricacy of the system should reflect the company structure, so my recommendation is to start with the easiest parameters and delve deeper according to the team's responses. כיצד ליישם את המסגרת As with any theory, the most complicated part is integrating the IdeaOps framework into a company's day-to-day processes. Obviously, processes should be adapted, revised, or only partially used according to the company structure, but the general idea is to help provide better ticket processing than there was previously, and even part of the framework will do this well. עם זאת, בכל חברה, יש רשימה סגורה של מכשולים שיש להתמודד איתם. אף אחד לא יודע איך ולמה ליצור כרטיסים ב"דרך הנכונה". There’s a lot of discussions in meetings or via messengers that are not reflected in the idea work item. מקורות מסוימים אינם מסוגלים לספק נתונים מובנים באמצעות מערכת backlog מרכזית. Let’s cover them step by step. Teach team members how to work with a general backlog צור כרטיס בקשה לתבנית ולספק דוגמה. תבניות יכולות להיות מתוארות בתיעוד החברה או אפילו מפותחות בתוכנה (Atlassian Jira או Microsoft Azure DevOps בסדר גמור איתם). New request work items should consist of necessary fields and parameters with required and unrequired markings, so it may be impossible to omit important data. הדוגמאות צריכות לקבוע את הסטנדרטים של שמות ומבנה התוכן. Publish the idea/request workflow, so everyone can understand what each stage means. Broadcast a message that this template is the only way to submit the request. Optionally, if the team structure is not complicated, it can be justified via a meeting. Reject the requests that are not in line with the new process. Definitely, the most complicated stage of new process adoption, because it needs balance not to disrupt the company’s operations. For highly important and prompt requests, it’s fine to fix them yourself, showing them as examples. השלב של אימוץ יגלה עשרות מקרים מיוחדים, ואחרי כמה iterations, הקבוצה תיישם את התהליך החדש. Fix communication outside the request זה טבעי לדבר על נושאים במודעות, באמצעות דואר אלקטרוני או בפגישות, כי זה מהיר ופרודוקטיבי.עם זאת, הרעיון של מסגרת לאחסן את כל הנתונים במקום אחד, כדי להיות מסוגל לגשת לנתונים שוב ושוב, ללמוד ולנתח אותם, חשוב. Every meeting or chain of messages has to be related to the request ticket ID, so later it will be possible to find the activity based on the unique identification number of the request. For every meeting about the request, meeting minutes have to be created. In the era of AI assistants, it’s not so complicated and helps a lot in further analysis. כל בקשה בכל שלב חייבת להיות מיועדת לחבר צוות אשר יהיה אחראי על תיקון כל החפצים החשובים.כן, כמה משא ומתן עדיין עשויים להיעלם בשיחות פרטיות, אבל קיומו של מקדם כללי עבור כל בקשה עוזר לדרג את הנתונים לאחסון. פתרון תסריטים borderline תמיד יש תסריטים שבהם מערכת backlog מרכזית לא עובדת.אולי זהו בקשה של בעל מניות עסוק מאוד, או של השותפים שאינם יכולים לגשת למערכת הפנימית.זה בסדר.הקבוצה פשוט צריכה לחשוף את כל התסריטים האלה ולמצוא דרך להפוך אותם לאלה הסטנדרטיים. The requests from a stock owner should be processed by one of the product leads in X time. This role has to create the request and collect the necessary data by themselves. Partners' requests should be processed by account managers or technical support, depending on the role of the partners. The team should choose the nearest starting point to begin the process. As usual in establishing new processes, it is important to document and declare all steps in public documentation to fix agreements and small details. Success metrics יישום התהליך החדש דורש הרבה זמן ומאמץ, כך כמה מדדים יכולים לעזור לעקוב אחר אימוץ זה. Time-to-insight One of the major goals of the IdeaOps framework is to process ideas from their inception to an analysed decision. This metric shows the number of days from creation to reaching one of the decision states and helps to reveal the following organisational goals: מהירות התגובות ללקוחות או לבעלי עניין בקבוצות שונות. Number of stuck responses whose processing time exceeds the established limits. Shows the relationship between the completeness and quality of the initially provided data and the time it takes to process a request. That’s a great metric to justify additional fields or filters for the request. Indirectly shows how the presence of related requests with previously provided estimates on similar ideas speeds up decision making. משך הזמן Metric Understandable and correct requests should minimise the time a manager takes to process them. A “time-to-insight” metric is proposed to measure the overall processing time, which is related to the process itself. However, it's also important to measure the working time of the responsible manager who participated in this process. Of course, some ideas require weeks of investigation, while some are just about the colour of a button. But the average value per quarter or per year could still help to reveal improvements in time spent. If more and more requests have linked estimations and detailed decisions, it will affect the overall processing time per manager. רמת כיסוי יש צורך להעלות את הרמה המטרי עם בקשות חדשות ותיקות כדי להשיג בסיס אידיאלי של הצעות. מה צריך להתמודד עם במהלך אימוץ, כמה בעיות יש להתגבר: חברי הצוות צריכים לדעת ששימוש במרחב האישי עבור הערות הוא שיטה רעה, מה שמוביל לאובדן נתונים חשובים של החברה. If any Proof of Concept artefact was created or an idea was estimated, all numbers related to completed work and future activities should be included in the request. Otherwise, this time may be lost and spent without reusability. A decision without a description doesn’t help in the future. A rejected idea may be processed and considered from all sides, but without a proper conclusion, it’s just a waste of time. The next similar idea will require the same amount of time for processing, because previous results don’t show the true reason for rejection, so the company will constantly lose money, especially if the team structure changes over time. The adoption manager has to provide regular reviews of closed and stuck requests to improve the process. Conclusion The proposed IdeaOps framework is an idealistic way to process a large amount of different and sometimes incomprehensible data into a manageable structure. It requires well-coordinated teamwork where every member understands that every piece of data and decision is something bigger, that one day may help to reach new heights for the business and improve the overall company situation. Once properly processed, and even rejected, a insignificant proposal from one of the customers may be included in a general change in product strategy, because it contains a clear analysis of the situation, estimates and some clever conclusions as to why it wasn’t important as a standalone improvement, but looks completely different in a new market situation. And if this decision was properly documented and reused, that means that any tiny idea is a real asset of the company and deserves to be processed and stored for the best times. Working on the idea catalogue is just as important as working on revenue, and it’s up to each company to follow the path to improving it.
