Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles An Agile Input Management Process Framework - The Agile IMP

An Agile Input Management Process Framework - The Agile IMP


This article presents a proposal for an Agile input management process framework for software product development.

The goal of the proposal is to arrive at a conceptual framework that:

  • Is scalable
  • Starts with the input givers
  • Allows decisions for next steps
  • Allows downstream processes to start seamlessly
  • Defines clear roles, responsibilities and workflows
  • Drives as fast as possible for important inputs from input giver to customer value
  • Uses the Agile/Lean methodology toolkit and is compatible with it


Any commitment to the implementation of an idea implies a commitment to the subsequent investments.

Such a commitment also implies a decision against other investments that could be made instead – and a decision against the possible benefits reaped from them.

Looking at current software industry numbers, we are still not very good at making the right choices:

This decision process of what software we should actually build starts with the handling of inputs.

Inputs are the things people tell us about our products. They should be leveraged to be drivers for innovation and the development of our products.

In order to achieve this, inputs must be managed. The greater the number of inputs a company receives and the more diverse the input channels by which input arrives, the greater the need for an effective channeling, pre-filtering and maturing process.

But how should one manage input, exactly?

  • What are the prerequisites of an effective input management process?
  • What input is relevant?
  • What input is important?
  • How do I make sure that I catch all relevant and important input?
  • Where does input management stop, when do subsequent processes start?
  • And what about feedback loops and constant elicitation?
  • What could be workflows and roles?

These questions are by no means new. The ways of addressing them differ significantly. But each I have seen seems to leave some questions open, especially when considering a product, for which hundreds of inputs may arrive at the company via totally different routes. The following list presents some examples:

  • Some companies use a Phase-Gate model variant. However, this model has been criticized as being cumbersome, difficult to scale, hindering innovation and placing too great an emphasis on NPV and ROI..
  • At the other extreme, in quite a few companies there is no real input management. Product development is driven by the loudest customer. Which works fine, so long as the customer base is very small, the customers are very similar and the code base is small. But what happens when product and customer base grow?
  • Some adapt a DEEP product backlog and write inputs into it. But how do inputs find their way from input giver into the backlog and what happens to them en route?
  • Some use an innovations management system. But what about input from people who have no access to the system or would not use it, even if they had access? Are there other routes of input into the company that we should also consider?
  • Great innovations management books have been written with emphasis on collaboration and intrinsic motivation. Important Lean ideas such as value stream mapping are also represented. However, to me personally, a book of this type often seems like a wonderful power-toolset but without a specific “Quick Start”-manual

For me, it comes down to this: I want to be able to talk to my colleagues about managing inputs the way I can talk about established development process frameworks such as Scrum - I want to use unambiguous terminology and refer to a structured conceptual framework.

I want to flesh out my real life process the way I need it but at the same time ideally be guided by a process framework towards thinking about all aspects that could be important to me.

The following sections present an attempt to define such an input management process framework. It builds upon and uses Lean and Agile concepts and tools.

The current status is not elegant, may be controversial in places and probably falls far short of the mark set above.

However, I feel that has by now reached a level of maturity to be useful as a basis for discussion, which is why I would like to present it in the remainder of this article, structured as follows:

  • An Agile IMP QuickStart section gives an overview of the framework and introduces basic concepts and terminology
  • A worked example shows the Agile IMP in action
  • A link to a detailed requirements specification is presented. This specification outlines a possible MVP for an Agile input management process framework.

Agile IMP QuickStart

The Agile IMP is an input management process framework for use in the development of software products.

Examples for inputs are change or feature requests, critique or market trends.

1. Goal

The Goal of managing inputs within the Agile IMP is to complete a business case in the form of a Lean Canvas for important input, upon which a decision for the next steps is then based.

2. Process Overview

An Agile IMP defines the following process phases:

  • Channel and Enrich Raw Input
  • Mature Input
    • Consolidate Input
    • Complete Lean Canvas
  • Decision

And the following roles:

  • Product Responsible Person (PRP)
  • Input Manager
  • Input Giver
  • Input Channeler
  • IM Subject Matter Expert (SME)
  • Decision Board

Figure 1: Agile IMP Overview

3. The Core Idea of the Agile IMP

As stated above, the goal of an Agile IMP is the completion of the Lean Canvas for important Input and presenting it for decision.

The Agile IMP attempts to:

  • Structure input content according to the sections of a Lean Canvas
  • Address a section of the Lean Canvas only when it “makes sense”

Figure 2: Lean Canvas Template

Roughly, a Lean Canvas addresses:

  • What an Input is about – sections:
    • Problem/Customer segments
    • Unique value proposition
    • Solution
  • What has to be done/invested in order to implement the Input – sections:
    • Channels
    • Cost structure/Revenue streams
    • Key metrics
    • Unfair advantage

The Agile IMP process phases are structured so that:

  1. We get the Input Givers View of what his Raw Input is about (Channel and Enrich Raw Input Phase)
  2. We filter for Important (Related) Input
  3. If the (related) Input is important, we derive a Company View of the Input (Mature Input Phase):
    1. What the Input is about (Consolidation)
    2. What the company has to do/invest (Complete Lean Canvas)
  4. We present the completed Lean Canvas for decision

The Lean Canvas sections are filled out accordingly.

A positive side effect of this procedure is that company resources, which mainly come into play during the Mature Input Phase, are essentially only called upon when the input is important.

4. Agile IMP Prerequisites

  • Product Strategy: All actions in managing input must be guided by actionable product strategy goals
  • Input Management Repository (IMR): Contains or allows access to all information regarding input content, the management of specific inputs and background information gathered during management of inputs
  • Value Your Input Givers: THE prerequisite for any sustainable input management process

5. Agile IMP Roles

5.1. Product Responsible Person (PRP)

Has overall responsibility for:

  • The product
  • The input management process

5.2. Input Manager

Responsible for:

  • Day to day work with inputs and their management
  • Setup and maintenance of the process

5.3. Input Giver

  • Gives Raw Input to our products.
  • Can be company internal or external.

5.4. Input Channeler

  • Responsible for an Input Channel (a route an Input may take from Input Giver into company)
  • Facilitator between Input Manager and Input Givers for her Input Channel

5.5. Input Management Subject Matter Expert (SME)

  • Is company internal
  • Can be consulted for estimates and elicitation when maturing inputs

5.6. Decision Board

  • Must be heard in all decisions regarding product development and should meet regularly
  • All company represented on the board

6. Agile IMP Phases

6.1. Channel and Enrich Raw Input Phase

Figure 3: Examples of Input Channels for Raw Input into the Input Management Repository (IMR)

  • Channel Raw Input from Input Giver into the Input Management Repository
    • Via an Input Channel the input management process has been set up to support
    • Input Channeler decides, whether the Raw Input is within the specified Scope of the input management
    • Input Channeler facilitates between Input Manager and Input Givers
  • Enrich Raw Inputs with Meta-Information
    • Regarding the product itself and the input management collaboration process and regarding relevance to a strategic product goal
    • Performed by Input Channeler/Input Manager
    • Meta-Information allows categorizing Raw Input

6.1.1. Overview Channel and Enrich Raw Input Phase

Figure 4: Overview Channel and Enrich Raw Input Phase

6.1.2. Ready for Next Phase – Mature Input

  • Criteria for potentially important (related) Raw Input have been defined by PRP/Input Manager using Meta-Information
  • Potentially important (related) Raw Input is brought to the attention of the PRP by the Input Manager, triggering PRP involvement
  • The PRP decides, whether to mature the Raw Input towards a Lean Canvas

6.2. Mature Input Phase – Derive a Company View

6.2.1. Collaboration During Mature Input Phase

The process of collaboration with externals has to be clearly specified/restricted by PRP/Input Manager, as company internal information may need to be safeguarded.

6.2.2. Consolidation

PRP and Input Manager transform the subjective view(s) of the Input Giver(s) for (related) important Input into a consolidated company view for the Lean Canvas sections:

  • Problem/Customer segments
  • Unique value proposition
  • Solution

Figure 5: Consolidation = Step back and Think

6.2.3. Complete Lean Canvas

  • PRP/Input Manager collaborate with Input Management SMEs to derive a company view of the Maturing Input for Lean Canvas sections:
    • Channels
    • Cost structure/Revenue streams
    • Key metrics
    • Unfair Advantage
  • To minimize effort, the Input Manager guides SMEs to give Fuzzy Estimates

6.2.4. Ready for next Phase – Decision

PRP prepares the following for the decision phase:

  • The Lean Canvas of a Matured Input
  • The impact of the Input on the defined product strategy goals
  • The impact of the implementation of the Input on overall company resources

6.3. Decision

The PRP presents the Matured Input to the Decision Board as follows:

Figure 6: The Decision

6.4. After Approval

An approved input:

  • Is a repository of information for setting up and conducting the subsequent processes
  • Must be made accessible to those responsible for the subsequent processes.

Figure 7: After Approval

6.5. Process Overview: Flow of Inputs

Figure 8: Flow of Inputs

7. Process Management

  • Housekeeping: The Input Manager keeps the Input Management Repository (IMR) as “clean” as possible.
  • Maintaining and adjusting the process: Input Manager/PRP review process decisions and adjust the process, when necessary. Review is obligatory on product strategy changes.
  • Impact on Product Strategy: Insights gained during the management of input that question assumptions made in the formulation of product strategy are communicated by the PRP to those responsible for product strategy.

Worked Example of the Agile IMP

In order to illustrate the working of the Agile IMP, I would like present a hypothetical example using an even more hypothetical Product – the FileOmnivore.

1. The FileOmnivore Product Backstory

The original Lean Canvas of the FileOmnivore could have looked something like this:

1.1. From Launch until now

The FileOmnivore has been around for about 10 years and is well established.

New employees have been hired for the FileOmnivore and overall costs have increased.

As the application is by now a little dated (GUI has not really been updated for 5 years), a major re-launch is planned within a year and has been communicated to the world. The re-launch should be financed by fresh venture capital.

However, lately numbers have started to stagnate and the product just about breaks even, making investors edgy.

1.2. Current Product Strategy

The above leads to the formulation of a new short term product strategy goal of:

Increase number of file conversions by 10% within 6 months

2. Input Management

An input management process based on the Agile IMP has been established for the FileOmnivore.

2.1. Adjusting the Process

Because of the new product goal, the Input Manager and the PRP set the following Product-Meta-Information as “Near to Product Strategy”:

  • File Upload
  • File Download
  • Time to Convert File
  • User retention/acquisition
  • Usability
  • Performance

2.2. Channel and Enrich Input

2.2.1. FileOmnivore as Direct Input Channel

The FileOmnivore web application contains a “Suggestions” section for registered users.

A “Suggestions”-page contains a form, with which suggestions can be submitted.

This form is a Direct Input Channel into the Input Management Repository. It contains fields:

  • Your suggestion
  • What problem would this solve?
  • How would this benefit you?

It is assumed, that the Type of Input Givers for this Input Channel are End-Users of the application.

Registered users can see suggestions of others and can vote (like or dislike) and comment on them.

For this Direct Input Channel, the Input Manager takes the role of Input Channeler. She also acts as a moderator for comments.

2.2.2. Channel Raw Input

Joe Enduser enters the following suggestion (i.e. Raw Input):

Suggestion:                                  “Make all your links bigger!”
What problem would this solve?: “Could actually hit the link!”
How would this benefit you?:       “Upload my file – giving up now….permanently”

The Input Manager tries to (very politely) contact Joe Enduser, but he is unwilling to communicate.

Even though the suggestion seems odd, it is definitely in scope of the input management. The Input Manager decides to accept it into the input management.

2.2.3. Enrich Raw Input Product Meta-Information

The Input Manager enriches the Joe Enduser’s Raw Input with the following Meta-Information:

  • File Upload
  • File Download
  • User retention/acquisition
  • Usability Collaboration Meta-Information

Within 3 days the Raw Input has 102 likes and 50 dislikes – in total 152 votes.

There are also several comments, some along the lines of: “Yeah, great idea, would really help”, some others: “What for? That would be really silly – would totally corrupt the layout of the site!

2.2.4. Ready for Next Phase (Mature Input) Criteria for Potentially Important Raw Inputs

The PRP and the Input Manager have defined criteria for potentially important input. One defined criterion, relevant for Raw Inputs “Near Product Strategy”, is “Number of Votes > 150”. Triggering PRP Involvement

The Input Manager therefore brings the Raw Input to the attention of the PRP.

As the Input has shown great activity in a very short time and is strongly relevant to Product Strategy, the PRP decides to mature the Input towards a Lean Canvas.

2.3. Mature Input Phase

2.3.1. Definition of Type of Collaboration for the Mature Input Phase

The PRP decides that for the Mature Input Phase:

  • Information regarding company investments and internal concerns must be safeguarded – a maturing input must therefore not be made publically accessible
  • Potential Input Givers should be informed that an issue is under consideration and should be able to join a moderated discussion of the issue with regards to the elicitation of “Problem”, “Solution” and “Unique Value Proposition

For the Direct Channel “FileOmnivore”, the Input Manager decides to use the “Suggestions” section as communication channel with End Users.

2.3.2. Input Management Subject Matter Experts (SME)

A representative from each of the following company internal teams has been designated as SME:

  • Design
  • Software development
  • Technical editors
  • Hosting
  • Finance
  • Sales
  • Support
  • Marketing
  • Community management

2.3.3. Consolidation = Step back and think

Joe Enduser’s Raw Input was:

Solution:                                “Make all your links bigger!”
Problem:                                “Could actually hit the link!”
Unique Value Proposition:    “Upload my file – giving up now….permanently”

Input Manager and PRP transfer the Raw Input into a Lean Canvas

Thinking about the input and checking against the FileOmnivore application, Input Manager and PRP come up with some questions.

  • Upload File” is not a link but is a button in the application – does Joe Enduser actually mean “make all buttons bigger”?
  • There are totally contradictory views amongst the end users regarding the input – why? Is there a browser layout problem for one of the main browsers?

Joe Enduser is still not available, so the Input Manager posts the following in the “Suggestions” section of the FileOmnovire:

Hi together,

There has been a lot of activity for Joe Enduser’s suggestion with quite a bit of controversy.

We would like to tackle the problem but we need a little more information.

  • Do you think Joe means “links” or “buttons”?
  • This might be a browser problem – could you tell us what browsers you are using in what version?

Thanks to you all, will keep you posted

Answers regarding “link or button” are given, e.g. “link, button, same difference”, “OBVIOUSLY buttons”

A Browser list can be compiled, containing, amongst others, entries for “BrowseDroid” and “WebITios”.

The Input Manager asks the Design SME, whether there are any layout problems regarding buttons for browsers on the list.

Design SME: ”No, but you can ignore BrowseDroid and WebITios. They are only for mobile.”


PRP and Input Manager suffer a mild epiphany.

The Input Manager asks the End Users:

“Are those who voted for Joe’s suggestion using mobile devices?”

The answer is a resounding “YES!

PRP and Input Manager formulate a first version of a root cause problem hypothesis:

The FileOmnivore is not usable for end users of mobile devices

They decide to validate the hypothesis and ask the Hosting SME for some rough numbers for the past month and for a month 5 years ago. After a couple of days, the Hosting SME sends the following table:

The table is persisted at the input.

PRP and Input manager conclude: An implicit assumption of the Raw Input Lean Canvas has become invalid - the section for “ Customer Segment”: “Workers at their workplace receiving text files in diverse formats that then need to be processed by them” assumes:

                                                               workplace = PC or laptop

This is no longer the case.

The Lean Canvas section “Customer Segment” is therefore reformulated:

Workers using PCs, laptops or mobile devices receiving text files in diverse formats that then need to be processed by them

Using the hosting numbers, the “Problem” section is transformed to:

The application is not optimized for mobile devices (currently 30% of all users)

80% of users of mobile devices abort up/downloading files

After an aborted file up/download, only 50% of users revisit the site

PRP, Input Manager and the SMEs from teams “development”, “design” and “hosting” brainstorm possible solutions for the core problem under the constraints:

  • Solution has to be rolled out quickly (product strategy goal “Increase number of file conversions by 10% within 6 months”)
  • Major re-launch planned within a year – interim solution
  • No negative impact on PC and laptop users

They find some solution candidates:

  • Native apps
    • Development SME: “No app development knowledge in team.”
    • Design SME: “Huge design effort
    • Hosting SME: “No deployment process and unclear, how many users would actually download an app.”
  • Responsive theme of whole application
    • Development SME: “No problem - interfaces clean, no effort apart from integration tests, which might be tricky, now I think about it”
    • Hosting SME: “No problem”
    • Design SME: “Huge design effort”
  • Just make up/download buttons bigger
    • Everybody (after Design SME does quick spike): “Looks horrible and does not really help anybody”
  • Create a mobile theme for Start, File upload, File download page with links to the PC theme for all other pages and introduce a user agent theme switch into the application
    • PRP: “Those are the most important pages and also the ones most visited.”
    • Development SME: “Doable.”
    • Hosting SME: “We all need to think about impact on SEO but doable.”
    • Design SME: “Doable.”

The Input Manager pitches the last solution to the End Users and receives a nearly unanimous thumbs up (98% - you never ever get them all).

This means that the Raw Input Lean Canvas:

Has been consolidated to:

The PRP decides that the Lean Canvas for this Consolidated Input can now be completed.

2.3.4. Complete Lean Canvas

The PRP informs each Input Management SMEs of the current state of the Maturing Input asking for:

  • Work that needs to be performed specifically for the Input by the team represented by the SME
  • Comments
  • Rough estimates for the work by the SME’s team. Units for estimates should be:
    • <=man day, <=man week, <=man month, <=6 man months etc. for personnel
    • <=100€, <=1000€, <=5000€, <=10000€ etc. for monetary investments

He receives the following feedback, which he saves at the Input:

The PRP asks the Finance SME for the current FileOmnivore overall Cost Structure and receives:

  • $5000 per month per FTE
  • 25 FTE assigned to FileOmnivore - $125000 per month
  • $10000 other costs

After meeting with the Sales SME, the PRP decides that there is no need for the adaptation of the File Omnivore Revenue Streams.

Using all of the above SME feedback, the PRP can now fill in the Lean Canvas “Cost Structure”, “Revenue Streams” and “Channels” sections:

Still missing in the “Cost Structure” section is the ominous “Break Even Point”, which is often noted in the last row of the section.

Because of the existing Revenue Stream structure and by assuming that mobile device users would behave similarly to the PC users after the input has been implemented, with the resulting positive impact on the number of file conversions and on user retention, the “Break Even Point” is fairly easy to estimate.

Basically, the “Break Even Point” is reached at that time when the following holds true:

However, the description of the estimation process would be quite tedious to write let alone read, so I will skip it here. Let us assume break even at “1 month after rollout”

The PRP now starts thinking about the “Key Metrics”. Key Metrics are indicators of how the business is doing. Ash Maurya categorizes them into:

  • Acquisition
  • Activation
  • Retention
  • Revenue
  • Referral

The FileOmnivore Input tries to deal with a problem mainly regarding:

  • Retention
  • Revenue

For the FileOmnivore as a whole, the following Key Metrics are already in place:

  • Set up Account
  • (Re)new Subscription
  • Number of Files per Account/Subscription

The PRP decides that “(Re)new Subscription“ and “Number of Files per Account” are also Key Metrics for the Input.

He further defines:

  • Page Visit Distribution PC/Mobile
  • Number of Files PC/Mobile

After brainstorming with his SMEs, the PRP finds a formulation for the “Unfair Advantage” section and then completes the Lean Canvas:

2.3.5. Ready For Next Phase – Decision

The PRP must now prepare the Lean Canvas for the decision, taking into account

  • Its impact on product strategy goals
  • Its impact on the company resources

The product strategy goal was: “Increase number of file conversions by 10% within 6 months

The PRP uses the following numbers from the Hosting SME to give a prognosis of the impact of the input on product strategy:

Assuming a similar behavior for mobile device users and PC users after the input has been implemented, the number of aborted file conversions should be reduced from 80% for mobile device users to approx. 2%, i.e. successful overall file conversions should increase to approx. 98%.

As mobile device users make up 30% of the end users, that would mean an increase in file conversions of approx. 30%

 ⇒This input could be THE driver for reaching the product strategy goal.

Nearly all department teams of the company work in Scrum-like 2 week iteration cycles.

The PRP informs himself about work currently in progress or planned.

He then formulates a recommendation: “All necessary company resources should be assigned to the implementation of the input at the end of the current cycle and all other work should be postponed for those resources.“

The PRP documents his decision preparation in the input.

2.4. The Decision

A Decision Board has been established. The Team Leads of all company teams and the CEO are members. The board meets every 4 weeks.

The PRP presents the Lean Canvas of the input and his preparation to the board at the next scheduled meeting.

The board approved the input unanimously.

The decision is documented at the input.

2.5. After Approval

The PRP schedules a Kickoff planning meeting with the Team Leads of all involved in the implementation of the input. The list of attendees and the agenda are derived from information documented in the input.

2.6. Process Management

2.6.1. Impact of Input Management on Product Strategy

As the elicitation of the input has shown that the original product assumption regarding end users being PC users only is no longer valid, the PRP communicates this issue to the company’s “Product Strategy Board”

2.7. Last but not least: Value Your Input Givers

The Input Manager posts on the “Suggestions Section” of the FileOmnivore:

Hi everyone,

I am very happy to tell you that we will implement the solution we discussed for Joe Enduser’s suggestion ASAP!

Thank you all for helping us!

Please watch this space for upcoming release information.

All the best

Joe Enduser has continuously received status updates for his suggestion. When it is clear that the solution will be implemented, he finally resurfaces and posts:

Great! Will definitely have a look when it comes out.


The Requirements Specification V1.0 of the Agile IMP

The current status of the detailed requirements specification of the Agile IMP (V1.0) can be downloaded here.

This specification defines a possible MVP for an Agile Input Management Process Framework.

There are quite a few issues that did not make it into the specification of the MVP, for example:

  • Moving maturing inputs in/out of Active PRP Focus and having a pool of "out of focus" maturing inputs
  • Advice on the size (investment/time) of a Lean Canvas presented for decision - thinking about what chunks of work have to follow the approval and scaling the size of the input accordingly
  • Input management process capacity
  • Introducing an Agile IMP into a company

For these and quite a few other topics, I decided that, while important, they are not part of the core MVP of an Agile input management process framework.

But I could be wrong.

I would very much appreciate hearing your thoughts on this - as well as on any other part of the framework presented in this article.


When I set out to define the input management process framework described above, I basically took what I had chanced upon over the years, mainly in Lean and Agile methodologies, and jumbled it up to fit my needs. I hope that I did not misinterpret or misrepresent any of the original concepts.

In most cases, I unfortunately have no idea where I came across something for the first time – good candidates are books or articles by Ash Maurya, M&T Poppendieck, Martin Fowler, Robert C. Martin, Mike Cohn, Eric Evans, Eric Ries, Gojko Adzic, Karl Fogel, Jurgen Appelo or Ken Schwaber. But I have also followed discussions, watched presentations and read stuff on the internet.

I would therefore like to acknowledge the Lean and Agile community as a whole - thanks for actively disseminating of all those diverse concepts, tools, process proposals and debates.

I would also like to thank the editors at, especially Shane Hastie, for their very helpful and constructive expert feedback during the deep review process.

About the Author

Ina El-Kadhi has over 20 years of experience in the software industry, having held nearly all roles possible: Developer, Chief Software Architect, (Distributed) Team Lead, Scrum Master, Scrum Product Owner/Product Manager, Director Business Operations, Head of Development (Distributed Teams). During that time, she has adopted different variants of Lean/Agile methodologies in her teams and has followed discussions and trends in those areas, as well as developments in classical product management paradigms.

Rate this Article