Какова стоимость идеи, ценна ли она или ничего не стоит до ее реализации? Product development management is built across ideas and hypotheses. A product team should react quickly to any market demands or fluctuations. Any decision should be made to increase product value, revenue, or capitalisation. Meanwhile, the investigation process should be done with minimal resources. That means an avalanche of ideas in times or budget deficits. Гипотезы в этой лавине могут быть связаны с различными аспектами: Новые маркетинговые стратегии. Новые особенности . Adaptation for new markets or niches. Исследование по созданию нового продукта с нуля. Тем не менее, несмотря на многообразие предположений, ретроспективный анализ может показать, что весь запас идей в одной нише продукта не бесконечен. Идеи могут быть разработаны в личных записках или корпоративных чатах без системы, и после ротации членов команды команда предоставит одно и то же исследование без учета предыдущего опыта. Эти идеи требуют надлежащей структуры для хранения, накопления и предоставления информации о рынке, независимо от изменений в развитии команды или компании. Эта жизнеспособная система доказывает, что идеи стоят много и могут помочь менеджерам продуктов сэкономить время и ресурсы компании. IdeaOps для разработки продуктов Термин «IdeaOps» как продуктовая рамка впервые был представлен мне в шоу Katherine R. Lieber «Rebellious Businesses» в эпизоде подкаста «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» как продуктовая рамка был впервые представлен мне в шоу Katherine R. Lieber «Rebellious Businesses» в эпизоде подкаста «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 В этой статье я делюсь своим личным опытом разработки продуктов, который дополняет идею первоначального термина. The core of the framework is the realisation that every hypothesis is a company asset. Этот актив должен иметь владельца, весь контекст идеи, артефакты, которые были созданы в процессе расследования, ссылки на другие активы и состояние решения.Рекомендации, описанные ниже, покажут необходимость процесса, в котором крайне важно не только фиксировать на принятии или отвержении гипотезы, но и показать весь процесс отслеживания с историей мышления, затраченное время и прерывистые результаты. As with any other framework, the main aspects will be introduced in the article: How to build the process of idea gathering. Как хранить идеи. How to implement the framework. Как измерить успех и ценность изменений. Как организовать процесс сбора идей? The process follows common and well-used recommendations for upcoming change requests. Every idea has to go through a pipeline: Создание . Context. левой стороны. Evidence. Оценка . По решению . Creation Every idea has to be captured inside company infrastructure according to the rules: 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 Менеджеры продуктов из разных команд могут держать свои идеи заблокированными в своих местных пространствах или даже в частных приложениях.Это лучше, чем отсутствие заблокированности вообще, но это приводит к множеству форматов и недоступности для анализа «большой картины». During the framework adaptation, it’s crucial to establish a unified storage for any insights. It’s better to use some big corporate product where it's easier to link artefacts during idea investigation, such as Microsoft Azure DevOps or Atlassian Jira (depending on dev team processes). Унифицированное программное обеспечение должно отвечать требованиям: Доступен для любого члена команды по корпоративному счету. Он также помогает с управлением правами и контролем во время ротации команды. Suitable for customisation. For tailoring the framework to company needs, it’s necessary to have the opportunity to create additional fields or custom statuses. Под надзором компании. Как уже было сказано выше, идеи должны стать активами компании. Ticket should be named properly Поскольку идея / билет является активом компании, команда должна научиться правильно классифицировать и хранить эти активы (и некоторые советы будут предоставлены ниже). Во время создания билета, особенно для нетехнических вкладчиков, наименование может быть упущено, а билеты, такие как «Улучшить сайт», могут быть созданы. Ticket title should be unique and include the main suggestion. Ticket shouldn’t include jargon phrases or obscure abbreviations to be understandable for different teams. Заголовок билета должен быть построен по структуре: Для того, чтобы сделать XXX в YYY, чтобы изменить ZZZ; другими словами, содержать объект, предмет и результат. Still, in real life, this rule may sound utopian; that's why ticket workflow should include naming corrections during investigation. Example with fictitious company "PaperGone": Improve the website -> " ". Rework the payment scenario on the 'PaperGone' website to fix mandatory account creation at checkout Здесь мы сосредоточимся на нескольких аспектах с самого начала: 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 request is about improvement of the payment process. Название показывает проблему чрезмерного создания счета во время оплаты. Context Билет должен включать описание того, почему команда продукта должна обрабатывать предложение.В зависимости от процессов компании, контекстные артефакты могут быть необходимыми или дополнительными. List of possible context information: Общее описание: о чем идет речь? Может содержать информацию о изменениях рынка, запросах клиентов или других триггерах. Источники: копии писем клиентов, интервью, отчеты или новости из общедоступных источников. User Stories (if applicable): to reveal target audience and scenarios to improve. The more detailed the context, the more likely the idea team will proceed to a positive decision during the investigation. Links That's one of the main features of the IdeaOps framework. Every new hypothesis should be analysed based on previous experience. Before the investigation process, it’s necessary to look for relative or similar tickets. Для билета «Переработайте сценарий оплаты на веб-сайте «PaperGone», чтобы исправить обязательное создание аккаунта при оплате», команда должна искать другие запросы о веб-сайте PaperGone. Maybe last year the sales team asked the same question but we made a decision that account creation during the payment process is mandatory. Or even we had a completed request “Add account creation for every purchase process on “PaperGone” website”. And we may not have any of the team members available who are responsible for the implementation, to ask why we adopted such a decision. Or one of the teams tried to remove the mandatory account creation and the product team noticed the decrease of user data to send very important marketing emails and aborted the changes. В любом случае, относительные билеты или изменения должны быть добавлены к новому, чтобы начать проверку гипотезы. Эти ссылки не должны прервать расследование за билет, потому что ситуация на рынке может измениться; предложение все еще должно быть пересмотрено. Конечно, возможно, что билет является совершенно уникальным и не имеет отношения ни к чему ранее.Или рамка была создана не так давно и нет доступных данных.В этом случае необходимо предоставить соответствующие приложения и полную информацию на поздних этапах процесса билета, чтобы улучшить работу в будущем. Evidence Во время этапа «Доказательства» команда должна предоставить расследование, основанное на соответствующей информации и текущих предложениях.Связанные, абортированные идеи могут выглядеть совершенно по-другому с новыми гипотезами и, вместе, привнести в фокус целую новую картину. Этот этап должен обеспечить такие артефакты, как: Meeting minutes with discussions about implementation with stakeholders, customers, potential clients, and developers. Market research. Интерфейс для mock-ups Доказательство концепции (POC) или результаты A/B тестов. It’s important to establish a process of evaluation and to gather data on time spent working on every artefact. Regardless of the decision about this particular ticket, such data can provide valuable insights about the resources that have to be spent on similar investigations. 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. Время и деньги 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. Существует много подходов к приоритету, но проще лучше, поэтому хорошая старая RFC 2119 работает хорошо. Ссылки : Clegg, D. (1994). . Addison-Wesley Case Method Fast-Track: A RAD Approach Bradner, S. (1997). (RFC 2119). Internet Engineering Task Force. Available at: . Key words for use in RFCs to Indicate Requirement Levels https://www.rfc-editor.org/rfc/rfc2119 References: Клег, Д. 1994 г. . Addison-Wesley Case Method Fast-Track: A RAD Approach Брэднер С. (1997 год) (RFC 2119) Интернет-инженерная рабочая группа. доступна по адресу: . Ключевые слова для использования в RFC для указания уровней требований https://www.rfc-editor.org/rfc/rfc2119 https://www.rfc-editor.org/rfc/rfc2119 Решение The result stage, based on the previous analysis and artefacts, is the most important stage for IdeaOps. According to the framework, the result comment provides general insight for the future. There are a few options for how each request may end: Мы это сделаем – необходимо написать, почему это звучит как выгодная идея и что помогает нам принять правильное решение.Также этот комментарий может быть полезен для последующего анализа, если результат был достоин того, что ожидалось. Возможно, некоторые данные были собраны неправильно, или значение результата низкое. Тем не менее, менеджер продукта должен написать подробное мнение об отказе. В некоторых будущих запросах может быть раскрыто, что этот конкретный запрос был избыточным, но если мы пересмотрим его в широкой картине, проблемы менеджеров продуктов могут быть решены. Это хорошо, и есть определенный интерес к нашей компании, но не сейчас – когда мы должны вернуться к этому запросу, чтобы не бросить его в гигантском отставании? It’s good if we combine it with another request – let’s build a plan to revise it with an additional request and the form of this process. Sure, there are more scenarios, but in this article I want to show an example of thinking: Каждая просьба должна быть обработана на протяжении всего трубопровода и должна иметь соответствующий результат, чтобы показать другим нынешним или будущим членам команды, как принимать решение. Every request has to be processed through the whole pipeline and shall have a proper result to show other current or future team members the way of adopting the decision. Люди могут совершать ошибки или принимать неправильное решение в зависимости от ситуации и своих знаний.Этот процесс обязывает их документировать это решение и помогает компании пересмотреть и узнать на основе этих запросов позже. 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: Product. Бизнес домен . Business risk. Функциональность продукта . Request Stage. Source. Чем больше фильтров доступно для идеи backlog, тем больше членов команды с различным опытом и способами мышления могут перемещаться через него. Список измерений не является полным и предоставляет лишь пример способов разложения. Я рекомендую организовать несколько сеансов мозгового бурения, чтобы раскрыть все подходящие фильтры для 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. Product 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. In an earlier example, we mentioned a fictional request, " " in the PaperGone company, so I will provide theoretically possible parameters for the correct entry of this request. Переработка сценария оплаты на веб-сайте «PaperGone» для устранения обязательного создания аккаунта при оплате Business domain This attribute should help to locate the responsible person to process the request. Is this idea about marketing improvements, or is it connected to our issues in onboarding? Or is it about additional product functionality that helps us to upsell current customers? The business domain is a core attribute to route requests through different departments and managers. Examples: Sales, Marketing, Customer Support, Accounting, Development, QA, etc. Business risk 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 The way to achieve this decomposition is described in the article - “ «» https://hackernoon.com/know-your-product-a-practical-guide-to-functional-decomposition Запрос этапа Помогает найти текущее состояние запроса в соответствии с рабочим процессом IdeaOps. 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. Committed - the development stage, that requires is in the process of realisation. Закрытый – заключительный этап, указывающий на завершение запроса. Конечно, в зависимости от процесса, можно расширить структуру этапов, чтобы отразить процесс более детально, но всегда необходимо найти баланс между прозрачностью и чрезмерной бюрократией. Source Идеи могут быть созданы разными участниками, а время обработки может варьироваться в зависимости от источника, например: заинтересованные стороны, клиенты, продажи, инженеры поддержки клиентов, разработчики. 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. How to implement the framework Как и в случае с любой теорией, наиболее сложной частью является интеграция рамки IdeaOps в повседневные процессы компании.Очевидно, что процессы должны быть адаптированы, пересмотрены или только частично использованы в соответствии с структурой компании, но общая идея заключается в том, чтобы помочь обеспечить лучшую обработку билетов, чем было раньше, и даже часть рамки будет делать это хорошо. However, in any company, there’s a closed list of obstacles that have to be dealt with. Никто не знает, как и зачем создавать билеты «правильным образом». There’s a lot of discussions in meetings or via messengers that are not reflected in the idea work item. Некоторые источники не могут предоставлять структурированные данные через централизованную систему отслеживания. 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. Примеры должны устанавливать стандарты наименования и структуры контента. Публикуйте рабочий процесс идеи/запроса, чтобы каждый мог понять, что означает каждый этап. 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. The adoption stage will reveal dozens of special cases, and after a few iterations, the team will implement the new process. 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. Every request at every stage has to be assigned to a team member who will be responsible for fixating all significant artefacts. Yes, some negotiations still may be lost in private discussions, but the existence of a general facilitator for every request helps to route the data into storage. Solve borderline scenarios Всегда бывают сценарии, когда централизованная система отслеживания не работает. Возможно, это запрос от очень занятого владельца акций или партнеров, которые не могут иметь доступ к внутренней системе. И это нормально. 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. Успешные метрики Реализация нового процесса требует много времени и усилий, поэтому несколько показателей могут помочь отследить его принятие. Time-to-insight Одна из главных целей рамки IdeaOps заключается в обработке идей от их возникновения до анализируемого решения.Эта метрика показывает количество дней от создания до достижения одного из состояний принятия решений и помогает раскрыть следующие организационные цели: Скорость ответа клиентам или заинтересованным сторонам в разных командах. Количество застрявших ответов, время обработки которых превышает установленные пределы. 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. Time spent 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. Coverage Level Shows the completeness of the request backlog. It’s necessary to raise the metric level with new and old requests to achieve an ideal base of proposals. What has to be dealt with During adoption, a few problems have to be overcome: Члены команды должны знать, что использование личных пространств для записей является плохой практикой, что приводит к потере важных данных компании. 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. Заключение 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.
