Enterprise Lean Canvas

A few days ago, we were asked to estimate a new big extension for a previous application we developed a year ago.
Since we had a strong deadline to send this proposal, and we couldn't do it the way we are used to (through a Product Discovery Workshop), we decided to try an idea which was in my mind some time ago: a Corporate Lean Canvas, our customized variation to the original Lean Canvas [1].

One clarification I would like to point out is that I will use the word "product" as a representation of the "thing" created after developing software. It could a product, or it could be an internal application for a company. I will use this word to mean the operable result of the project and not something limited for commercialization.

The goal was to had a big picture of what we have to do, identifying the main problems to solve, and having an idea of the size of the development so we can estimate it and price it.
In order to accomplish this we figured out how to adapt and customize the Lean Canvas model, having in mind:

• this development is not a startup product but an internal application
• the goal was not validate the business idea and plan but to have a "big picture" clear vision of the needs that generated this development

So, we ended up with this customized version of the lean canvas:

1. Top 3 problems: This is the first step and should be our north star. This is the main need, the reason they called us. It's very important to reduce the options to a list of no more than 3 items, because you could fall into the mistake of trying to solve every single problem. Besides that, to setting a limit forces you to find the essence of the application and be focused on that.

2. Top 3 Solutions: Here we have to identify the top 3 most important features that the application should have. Obviously, these 3 items should be in harmony with the previous ones, since these should be solutions to the problems stated before.

3. Unique Value Proposition (UVP): As you may know, this is one of the most important and most difficult items to define. The UVP is an effort to distill the essence of the product to be built into a few words. Imagine that anybody should be able to read your UVP sentence and to understand in 10 seconds the value you add with this product. In words of S. Blank: "Unique Value Proposition: A single, clear compelling message that states why you are different and worth buying".

4. Key metrics: We want to validate that the application solves what we thought it solved once implemented. The idea is to find and identify metrics or "measurable things" that show us some improvement after the new application has been working for a while. So, it should be possible to get some metrics before the implementation, and afterwards to validate a real improvement by confirming that these KPIs (key performance indicators) have improved quantitatively. At the end of the project we expect to have improved two or three things, delivering an objetive project success indicator.

5. Target users (or roles): We need to identify the final users and/or roles that are going to use the application. This is strongly related with the problems stated in the first item. Here again we change the meaning of this section as used in the original "lean canvas" since this connotation is not applicable to this kind of products as they have the intention of identifying potential clients.

6. Savings: The idea here is to recognize which are the company savings that this application brings. This could be just money, but since it is often hard to measure or get that information when you're a a provider, we could work around with this by measuring how many hours we save, how much rework is avoided, how many processes we improve, how many reports and controls we automatize, etc. This information could also be interesting for you to put a price on your development.

Note that the solutions identified in the second item are hypothesis that could change or mutate, even the problems as well. The idea of this tool is to explore not only solutions but to identify effectively the root problems or the problems that hurt the most. So, it could be possible that after some iterations you get deeper in the analysis and get a better understanding of what the root problems are and how to solve them.

This new adapted model and its modifications allows us to quickly go around the entire application, understanding needs, main problems to solve, and benefits provided by the potential software. And at last, we could get a quick idea for us to estimate our proposal.

Summarizing, I think this is an quick alternative to help you prepare a formal business plan and study the case in a more focused lean way.