アイデアのコストはどれくらいですか?それとも実装前に価値があるのですか? 製品開発マネジメントはアイデアや仮説に基づいて構築されています。製品チームは市場の要求や変動に迅速に反応する必要があります。製品の価値、収益、または資本化を増やすためにすべての決定を下す必要があります。同時に、調査プロセスは最小限の資源で行われなければなりません。 このの仮説は、さまざまな側面に関連する可能性があります: 新しいマーケティング戦略 新しい特徴 新しい市場やニッチへの適応 新製品をゼロから作るための研究。 それにもかかわらず、さまざまな仮定にもかかわらず、リトロスペクティブな分析は、一つの製品ニッチにおけるアイデアのバックグラウンド全体が無限ではないことを示す可能性があります。アイデアは、システムなしで個人的なノートや会社のチャットで開発され、チームメンバーの回転後、チームは以前の経験を考慮せずに同じ調査を提供します。これらのアイデアは、チームや会社の成長の変化に関係なく、市場に関する洞察を保存、蓄積し、提供するための適切な枠組みを必要とします。 製品開発のためのIdeaOps 「IdeaOps」という用語は、Katherine R. Lieberの「Rebellious Businesses」番組で最初に紹介された「Stop Bleeding Out Your Competitive Edge: Use IdeaOps To Start Capturing And Acting On Essential Innovations」(2025年2月2日)。リンク: 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」(2025年2月2日)。 . 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 この記事では、オリジナル用語のアイデアを補完する個人的な製品開発経験をシェアします。 フレームワークの核心は、あらゆる仮説が会社の資産であるという認識です。 この資産には所有者、アイデアの全体の文脈、調査プロセス中に作成された文物、他の資産とのリンク、および決定の状態があるはずです。以下の勧告は、仮説の採択または拒否を固定するだけでなく、思考の歴史、時間を費やし、断続的な結果を示すために非常に重要なプロセスの必要性を明らかにします。 他の枠組みと同様に、主な側面は記事で紹介されます: アイデア集めのプロセスを構築する方法 アイデアを保存する方法 枠組みをどのように実施するか。 変化の成功と価値を測る方法 アイデアの集まりのプロセスをどのように構築するか。 このプロセスは、将来の変更要請のための一般的でよく使われている推奨事項に従います. Every idea has to go through a pipeline: 創造 コンテキスト Links. 証拠 Estimation. 決断 創造 すべてのアイデアは、以下のルールに従って会社のインフラストラクチャ内でキャプチャされる必要があります。 For every idea or request, a unique ticket should be created 時には、アイデアは複雑であり、製品または市場アプローチ自体の改訂を必要とする場合があります。 チームに、あらゆる仮説を価値のある、しかし分離可能な改善に分解する方法を教える必要があります。 これは、いくつかの追加の官僚主義を生み出し、アイデアの数を減らす可能性があります - 公式化が困難な場合、いくつかのチームメンバーはアイデアの固定を避けることができます。 下の誇張した例では、「いくつかの追加の数百万ドルを稼ぎましょう」のようなアイデアが中心であるが、プロセスのための無駄な提案であるという分解プロセスを提供します。 Ticket should be created in unified software and available for other team members 異なるチームの製品マネージャーは、独自のローカルスペースやプライベートノートアプリでアイデアをバックロッグに保つことがあります。 フレームワークの適応の際には、Microsoft Azure DevOpsやAtlassian Jira(開発チームプロセスに応じて)などのアイデア調査中にアーティファクトをリンクしやすくする大きな企業製品を使用するのが最善です。 統一されたソフトウェアは、以下の要件を満たす必要があります: 企業アカウントでチームメンバーに利用できます. It also helps with rights management and control during team rotation. 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 アイデア/チケットは会社の資産であるため、チームはこれらの資産を適切に分類し、保存する方法を学ばなければなりません(そして、以下にいくつかのアドバイスが提供されます)。 チケットを作成する際、特に非技術的な貢献者にとっては、名前付けは省略され、「Webサイトの改善」のようなチケットを作成される可能性があります。チケットは文脈部分でよく説明されるかもしれませんが、将来のログにはタイトルに追加情報を提供する必要があります。 チケットのタイトルはユニークで、主な提案を含む必要があります。 チケットには、異なるチームが理解できるように、ジャーゴンフレーズや曖昧な略語は含まれてはならない。 Ticket title should be built by structure: To do XXX in YYY to change ZZZ; in other words, contain object, subject and result. チケットタイトルは構造によって構築されなければなりません。 それでも、現実の生活では、このルールはユートピアのように聞こえるかもしれません; それがチケットのワークフローは、調査中に名前の訂正を含むべきです。 仮想企業「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). 支払い手続きの改善を求める。 タイトルは、支払い中に過剰なアカウント作成の問題を示しています。 Context The ticket should include a description of why the product team has to process the suggestion. Depending on company processes, context artefacts may be required or optional. 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 それはIdeaOpsフレームワークの主な特徴の1つです。あらゆる新しい仮説は以前の経験に基づいて分析されなければなりません。調査プロセス前に、相対的または類似のチケットを探す必要があります。 「PaperGone」のウェブサイトで支払いシナリオを再編して、決済時に義務的なアカウント作成を修正する」のチケットについては、チームはPaperGoneウェブサイトに関する他のリクエストを検索する必要があります。 たぶん昨年、セールスチームは同じ質問をしましたが、支払いプロセス中にアカウントの作成が義務的であるという決定を下しました。もしくは、「PaperGone」のウェブサイト上の各購入プロセスにアカウントの作成を追加する」というリクエストを完了しました。そして、実装の責任を負うチームメンバーのいずれも、なぜ私たちがそのような決定を下したのかを尋ねることはできませんでした。 In any case, relative tickets or changes should be added to the new one to start the hypothesis check. These links should not abort the investigation for the ticket, because the market situation may have changed; the suggestion still has to be revised. However, the quality of the research will be drastically improved with an understanding of the whole story. もちろん、チケットが完全にユニークであり、以前の何にも関係していない可能性があります。または、フレームワークはそれほど前に確立され、データがありません。この場合、チケットのプロセスの後期段階で適切な添付ファイルと完全な情報を提供し、将来の作業を改善する必要があります。 Evidence 「証拠」段階では、チームは関連する情報と現在の提案に基づいて調査を提供すべきです。リンクされた、中絶されたアイデアは、新しい仮説と全く異なるように見える可能性があり、一緒に、新しいイメージを焦点に置く。 この段階では、以下のようなアーティファクトを提供する必要があります。 関係者、顧客、潜在顧客、開発者との実装に関する議論を含む会議のメモ。 市場調査。 インターフェイスモックアップ Proof of Concept (POC) or results of A/B testing. 評価プロセスを確立し、各文物の作業に費やされた時間に関するデータを収集することが重要です。この特定のチケットに関する決定に関係なく、そのようなデータは、同様の調査に費やさなければならないリソースに関する貴重な洞察を提供することができます。 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. 時間と金 それぞれの種類の専門家にどれくらいの時間を費やして、提案を実行する必要がありますか? アイデアは推定プロセスを通過し、合計はチケットに付属する必要があります。 リスク このアイデアを実行または省略するリスクは何ですか? 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. この情報は、なぜこのような素晴らしいアイデアが製品に実装されなかったのかについての議論の際に、将来的に役に立つかもしれません。 優先 このアイデアは製品やビジネスにとってどれほど重要か? この推定パラメータは困難であり、製品戦略の正しさに依存します。 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. アディソン・ウェスリー RFC(RFC 2119)を指定するためにRFCで使用するためのキーワード。インターネットエンジニアリング・タスク・フォース。 https://www.rfc-editor.org/rfc/rfc2119で利用できます。 References: Clegg, D. (1994). アディソン・ウェスリー Case Method Fast-Track: A RAD Approach RFC(RFC 2119)を指定するためにRFCで使用するためのキーワード。インターネットエンジニアリング・タスク・フォース。 https://www.rfc-editor.org/rfc/rfc2119で利用できます。 https://www.rfc-editor.org/rfc/rfc2119 Decision 以前の分析とアーテファクトに基づく結果段階は、IdeaOpsにとって最も重要な段階です。 それぞれのリクエストがどのように終了するかについては、いくつかのオプションがあります。 We will do this – it’s necessary to write why it sounds like a profitable idea and what helps us to make the right decision. Also, this comment may be useful for later analysis if the result was worth what was expected. It will help to reveal our misunderstandings and improve decision-making. それは絶対に価値がない - いいけど、なぜ? もしかしたら、いくつかのデータが間違って収集されたのか、あるいは結果の値が低いのかもしれません。 それにもかかわらず、製品マネージャーは拒否について詳細な意見を書く必要があります。 それは素晴らしいことだし、当社の関心はあるが、今はそうではない――この要求にいつ戻ってきて、巨大なバックグラウンドでそれを捨てないようにすべきか?今、ポジティブな決断を下すことが不可能にする何が間違っているのか。 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. 確かに、より多くのシナリオがありますが、この記事では、思考の例を示したいと思います。 すべてのリクエストは、パイプライン全体を通じて処理されなければならず、他の現在または将来のチームメンバーに決定を下す方法を示す適切な結果を得なければなりません。 すべてのリクエストは、パイプライン全体を通じて処理されなければならず、他の現在または将来のチームメンバーに決定を下す方法を示す適切な結果を得なければなりません。 人々は、状況や知識に応じて間違いを犯したり、間違った決定を下すことがあります。このプロセスは、彼らがこの決定を文書化することを義務付け、会社が後でこれらの要求に基づいて修正し、学ぶのを助けます。 アイデアを集める方法 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. それぞれの要求は異なる次元を持つことができます: 製品です。 ビジネスドメイン ビジネスリスク 製品機能 ステージの要請 源です。 The more filters are available for the idea backlog, the more team members with a variety of experience and ways of thinking may navigate through it. The list of dimensions isn’t complete and provides just an example of ways of decomposition. I recommend organising a few brainstorm sessions to reveal all suitable filters for the backlog and refresh them from time to time. Also, it’s necessary to establish rules for adding the filter options and assign an administrator role. Every option has to consist of a closed list of items; otherwise, the whole structure will fall apart. 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 1 for SaaS、Product 2 for On-Prem、等. または、プラットフォームの位置を確認するのに役立ちます: Frontend、Backend、iOS/iPadOS、Android。 以前の例では、我々は仮想的な要求を述べた。 「PaperGoneの会社では、このリクエストの正しい入力のための理論的に可能なパラメータを提供します。 「PaperGone」ウェブサイトの支払いシナリオを再編し、チェックアウト時に必須のアカウント作成を修正する ビジネスドメイン この属性は、リクエストを処理する責任者を特定するのに役立ちます。これはマーケティングの改善についての考え方ですか、それともオンボードの問題に関連していますか? または現在の顧客をリクエストするのに役立つ追加製品機能ですか? ビジネスドメインは、異なる部門やマネージャーを通じてリクエストをルーティングするためのコア属性です。 例:販売、マーケティング、顧客サポート、会計、開発、QAなど。 ビジネスリスク 各リクエストは異なる企業リスクをカバーする可能性があります。それらのいくつかは、製品インフラストラクチャにおける建築的欠陥、または販売や競合と関連する何かを明らかにする可能性があります。リクエストの作者は、最も適切なオプションが何であるかを理解すべきです。この次元は、何かの可能性のある問題についてです:販売(それなしでは売れない)、アップセール(それなしでは現在のアカウントを伸ばすことはできません)、セキュリティ(潜在的な取の懸念)、競争相手(私たちが持っていないもの)、法的(当社の契約フォームはそれほど良くありません)。 製品機能 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 Request stage Helps to locate the current status of a request according to the IdeaOps workflow. ステージ構造の例: 新しい - 誰もリクエストを処理しませんでした。 To estimate - the request goes through Links, Evidence, Estimation stages. 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. コミット - 開発段階、その必要性は、実現のプロセスにあります。 閉鎖 - 要求の完了を示す最終段階。 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. Source アイデアはさまざまな関係者によって作成され、処理時間はソースによって異なります. たとえば: Stakeholders, Customers, Sales, Customer Support Engineers, Developers. 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. 枠組みをどのように実施するか すべての理論と同様に、最も複雑な部分は、IdeaOpsフレームワークを会社の日々のプロセスに統合することです。明らかに、プロセスは、会社の構造に応じて適応、修正、または部分的にのみ使用されるべきですが、一般的なアイデアは、以前よりも優れたチケット処理を提供するのに役立つことです。 However, in any company, there’s a closed list of obstacles that have to be dealt with. 誰も「正しい」方法でチケットを作る方法や理由を知らない。 ミーティングやメッセンジャーを通じて、アイデアワークアイテムに反映されていない多くの議論があります。 一部のソースは、集中的なバックログシステムを通じて構造化されたデータを提供することはできません。 一歩ずつカバーしましょう。 チームメンバーに、一般的なバックロッグで働く方法を教える Create a template request ticket and provide an example. Templates could be described in company documentation or even developed in the software (Atlassian Jira or Microsoft Azure DevOps are perfectly fine with them). 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. 例は、命名とコンテンツ構造の基準を定めるべきである。 アイデア/リクエストワークフローを公開して、各段階の意味を誰もが理解できるようにします。 このテンプレートがリクエストを提出する唯一の方法であるというメッセージを送信します. 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. リクエスト以外のコミュニケーションの修正 メッセンジャーやメールやミーティングで話題を論じるのは自然なことですが、それは迅速かつ生産的です。それにもかかわらず、すべてのデータを一箇所に保存し、データに何度もアクセスし、それを学び、分析するためのフレームワークのアイデアは重要です。 各会議またはメッセージチェーンはリクエストチケットIDと関連付けられなければなりませんので、リクエストのユニークな識別番号に基づいて後でアクティビティを見つけることができます。 リクエストについての会議ごとに、ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング ミーティング 各段階のすべてのリクエストは、すべての重要なアーティファクトを固定する責任を持つチームメンバーに割り当てられる必要があります。はい、一部の交渉はまだプライベートディスカッションで失われる可能性がありますが、各リクエストのための一般的なファミレーターの存在は、データをストレージにルーティングするのに役立ちます。 Solve borderline scenarios There are always scenarios where a centralised backlog system doesn’t work. Maybe that’s a request from a very busy stock owner, or the partners that cannot have access to the internal system. And that is okay. The team just has to reveal all these scenarios and find a way how to route them into the standard ones. As an example: 株主からの要請は、製品のリーダーの1人がX時間で処理する必要があります。この役割は、要請を作成し、必要なデータを自分で収集しなければなりません。 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 新しいプロセスの実装には多くの時間と努力が必要なので、いくつかの指標がその採用を追跡するのに役立ちます。 時間の洞察 IdeaOps フレームワークの主要な目的の 1 つは、アイデアの起源から分析された決定までアイデアを処理することです このメトリックは、作成から決定状態の 1 つに達するまでの日数を示し、次の組織目標を明らかにするのに役立ちます: さまざまなチームにおける顧客や利害関係者への対応の速度。 処理時間が定められた制限を超える滞在回答数。 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. 間接的に、以前同様のアイデアに関する推定を含む関連要求の存在が、意思決定を加速させる方法を示す。 時間の使い方Metric 理解可能で正しいリクエストは、マネージャーがそれらを処理するのにかかる時間を最小限に抑えるべきである。 全体的な処理時間を測定するための「時間の見通し」メトリックは、プロセスそのものと関連するものであるが、このプロセスに参加した責任あるマネージャーの作業時間を測定することも重要である。 もちろん、いくつかのアイデアには数週間の調査が必要だが、いくつかのアイデアはボタンの色にすぎない。 しかし、毎四半期または毎年の平均値は、時間を増やして改善するのに役立つかもしれない。 ますます多くのリクエストが関連する推定と詳細な決定を持っている場合、それはマネージャーごとの全体的な処理時間に影響を及ぼす。 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. 何を扱うべきか 養子縁組では、いくつかの問題を克服する必要があります: チームメンバーは、ノートのための個人スペースの使用は悪い慣行であり、重要な会社データの喪失につながることを知っておくべきです。 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. 養子縁組マネージャーは、プロセスを改善するために、閉じた要求と閉じた要求の定期的なレビューを提供しなければなりません。 結論 提案されたIdeaOpsフレームワークは、多量の異なる、時には理解できないデータを管理可能な構造に処理する理想的な方法です。それは、各メンバーがデータと決定のすべての部分がより大きなものであることを理解し、いつかビジネスにとって新しい高度に達し、会社の全体的な状況を改善するのに役立ちます。適切に処理され、時には拒否されると、顧客のいずれかから無意味な提案が製品戦略の一般的な変更に含まれることができ、それは状況の明確な分析、推定、そして独立した改善として重要でない理由についてのいくつかの賢明な結論を含んでいますが、新しい市場の状況でまったく異なるように見えます。そして、この決定が適切に文書化され、再利用された場合、それは、どんな小さなアイデア アイデアカタログに取り組むことは、収益に取り組むことと同じくらい重要であり、それを改善するための道を歩むのは各社次第です。
