As I already mentioned in a previous blog entry (in Spanish), there are several canvas templates for business modeling that have been created as derivative works from the "business model canvas" devised by Alexander Osterwalder (thanks to its Creative Commons BY-SA license). These tools follow different approaches to modify the original in order to focus on specific aspects, and because of that its use may be more or less adequate according to our goal or the development stage of our business idea. Given that the most popular of these alternative versions is the "lean canvas" created by Ash Maurya, I'm going to analyze the modifications it introduces with respect to the original and thus identify which cases one approach or the other can be a better fit for.
As Ash Maurya explains in this blog entry, his proposal gives more relevance to aspects which detail the characterization of the problem to solve and the proposed solution, as well as the reasons why that solution is competitively better than others (what the author labels as "unfair advantage" in his canvas). On the other hand, he changes most of the left side of Osterwalder's canvas, leaving out some concepts closely linked to the design of the organization and the partnerships to establish in order to build the product (that is, focusing on the product's features and value, and not that much on the organization behind it).
Considering these changes, it looks like a very agile approach for a validation from a conceptual and market-oriented point of view, in order to check whether our solution has the necessary potential to be chosen above others by our targeted customers, although it might not validate whether we are able to consolidate the team and collaborators to build and maintain that solution over time. It seems, therefore, very adequate to register the validated learning in a customer development process, taking for granted that we will be able to consolidate a team and gather the necessary resources to build the solution. It also seems useful when that requisite has less relevance, for example in a learning experience focused on practicing the "get out the building" principle and customer development interviews, which doesn't expect to verify if we are capable to build a real company operating the business.
On the contrary, Osterwalder's canvas was created as a result of his PhD thesis project, whose object was to create a business model ontology, that is, to analyze and extract the "core properties" that characterize a business model. Because of that, it has a certain bias towards "characterizing an already created business" and not towards "registering key aspects to explore and validated learning when we are searching for a model" (as Ash Maurya also points out in his blog when he discusses the reasons to create his derivative work). Consequently, it is tremendously useful to establish a common language in order to present or analyze a business model (for example when presenting your business in front of a VC panel, or as a case study in a learning experience), although it doesn't integrate elements specifically focused on the exploration process that is required when starting every entrepreneurial initiative.
[Haz clic aquí para la versión en español de esta entrada]
Considering these changes, it looks like a very agile approach for a validation from a conceptual and market-oriented point of view, in order to check whether our solution has the necessary potential to be chosen above others by our targeted customers, although it might not validate whether we are able to consolidate the team and collaborators to build and maintain that solution over time. It seems, therefore, very adequate to register the validated learning in a customer development process, taking for granted that we will be able to consolidate a team and gather the necessary resources to build the solution. It also seems useful when that requisite has less relevance, for example in a learning experience focused on practicing the "get out the building" principle and customer development interviews, which doesn't expect to verify if we are capable to build a real company operating the business.
On the contrary, Osterwalder's canvas was created as a result of his PhD thesis project, whose object was to create a business model ontology, that is, to analyze and extract the "core properties" that characterize a business model. Because of that, it has a certain bias towards "characterizing an already created business" and not towards "registering key aspects to explore and validated learning when we are searching for a model" (as Ash Maurya also points out in his blog when he discusses the reasons to create his derivative work). Consequently, it is tremendously useful to establish a common language in order to present or analyze a business model (for example when presenting your business in front of a VC panel, or as a case study in a learning experience), although it doesn't integrate elements specifically focused on the exploration process that is required when starting every entrepreneurial initiative.
[Haz clic aquí para la versión en español de esta entrada]
No hay comentarios:
Publicar un comentario