IdeaOps: Why Every Request is a Company Asset in Product Development

What is the cost of an idea? Are they valuable, or are they nothing before implementation?

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.

Hypotheses in this avalanche may be connected with different aspects:

• New marketing strategies.
• New features.
• Adaptation for new markets or niches.
• Investigation for creating a new product from scratch.

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 for product development

The core of the framework is the realisation that every hypothesis is a company asset.

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.

As with any other framework, the main aspects will be introduced in the article:

• How to build the process of idea gathering.
• How to store the ideas.
• How to implement the framework.
• How to measure the success and value of changes.

How to build the process of idea gathering?

The process follows common and well-used recommendations for upcoming change requests. Every idea has to go through a pipeline:

• Creation.
• Context.
• Links.
• Evidence.
• Estimation.
• Decision.

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

Sometimes an idea may be complex and require an overhaul of the product or market approach itself. It is necessary to teach the team how to decompose every hypothesis into valuable, but separable, improvements. This may create some additional bureaucracy and decrease the number of ideas – if it is hard to formalise, some team members may avoid idea fixation. In contrast, it helps to filter out raw suggestions that are hard to comprehend and estimate. During the process of establishing a framework, it is necessary to assess team compatibility to find the balance.

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

Product managers from different teams may keep their ideas backlog in their own local spaces or even private notes apps. It’s better than the absence of a backlog at all, but it leads to a myriad of formats and unavailability to analyse the “big picture”.

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).

Unified software should respond to the requirements:

1. Available for any team member by corporate account. It also helps with rights management and control during team rotation.
2. Suitable for customisation. For tailoring the framework to company needs, it’s necessary to have the opportunity to create additional fields or custom statuses.
3. Supervised by company. As aforementioned, ideas should become the company's assets. It means proper maintenance of the main storage.

Ticket should be named properly

Because an idea/ticket is an asset of the company, the team have to learn how to classify and store these assets properly (and some advice will be provided below). One of the most important parameters is the name.

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:

1. Ticket title should be unique and include the main suggestion.
2. Ticket shouldn’t include jargon phrases or obscure abbreviations to be understandable for different teams.
3. Ticket title should be built by structure: To do XXX in YYY to change ZZZ; in other words, contain object, subject and result.

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".

Here we are targeting a few aspects from the beginning:

• 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.
• The title shows the problem with excessive account creation during the payment.

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:

• General description: what is it about?
• Why should we investigate it? May contain information about market changes, customer requests or other triggers.
• Sources: copies of customer letters, interviews, reports or news from public sources.
• 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.

For the ticket “Rework the payment scenario on the “PaperGone” website to fix mandatory account creation at checkout” the team should search for other requests about the PaperGone Website.

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.

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.

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

During the "Evidence" stage, the team should provide an investigation based on related information and current suggestions. Linked, aborted ideas may look completely different with new hypotheses and, together, bring a whole new picture into focus.

This stage should provide artefacts such as:

• Meeting minutes with discussions about implementation with stakeholders, customers, potential clients, and developers.
• Market research.
• Interface mock-ups.
• Proof of Concept (POC) or results of A/B testing.

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

Team should provide estimation based on evidence in a few aspects:

Decision

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:

• 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 definitely not worth it – okay, but why? Maybe some data were collected incorrectly, or the result value is low. Nevertheless, the product manager has to write a detailed opinion about the rejection. In some future requests, it may be revealed that this particular request was redundant, but if we rethink it in the big picture, the concerns of product managers may be solved.
• It’s nice, and there is some interest for our company, but not right now – when should we come back to this request so as not to abandon it in a gigantic backlog? What is wrong right now that makes it impossible to make a positive decision?
• 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:

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:

• Product.
• Business domain.
• Business risk.
• Product functionality.
• Request Stage.
• Source.

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

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, "Rework the payment scenario on the 'PaperGone' website to fix mandatory account creation at checkout" in the PaperGone company, so I will provide theoretically possible parameters for the correct entry of this request.

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.

Request stage

Helps to locate the current status of a request according to the IdeaOps workflow.

An example of the stage structure:

• New - nobody has processed the request.
• 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.
• Committed - the development stage, that requires is in the process of realisation.
• 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.

Source

The ideas may be created by different actors, and the processing time may vary depending on the source. For example: 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.

How to implement the framework

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.

However, in any company, there’s a closed list of obstacles that have to be dealt with.

1. Nobody knows how and why to create tickets in the “right way”.
2. There’s a lot of discussions in meetings or via messengers that are not reflected in the idea work item.
3. Some sources cannot provide structured data via a centralised backlog system.

Let’s cover them step by step.

Teach team members how to work with a general backlog

• 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.
• The examples should establish the standards of naming and content structure.
• 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.

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

It’s natural to discuss topics in messengers, via email or in meetings, because it’s fast and prolific. Nevertheless, the idea of a framework to store all data in one place, to be able to access data again and again, to learn and analyse it, is important. Still, there are a few ways to fix the process:

• 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

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:

• 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

Implementation of the new process requires a lot of time and effort, so a few metrics could help to track its adoption.

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:

• Speed of responses to customers or stakeholders across different teams.
• 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.

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:

• Team members should know that using personal spaces for notes is a bad practice, which leads to the loss of important company data. If anything has to be documented, it should be done in the request. The same applies to meeting summaries.
• 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.