From lean-startup via design thinking to implementation
Part I — Defining your Minimum Viable Product
In my previous blogs, I presented techniques for finding the right use case for blockchain based on lean startup and design thinking. I also presented an aspect of agile techniques namely, user stories, to manage blockchain projects.
In this blog two-parts blog, I will use a hypothetical scenario to illustrate a process using learn startup, design thinking and agile development. Giving you an end-to-end lifecycle perspective.
The scenario
A hypothetical company called Blockchain Corp (BC) specialises in building productivity tools to support the communities of developers working with blockchain projects.
BC’s initial research suggests that there is a market for tools for the developers’ communities working on Hyperledger based projects. However, Hyperledger has numerous projects under its purview, some of which are focussed on tooling for the developers’ communities. The challenge for BC to determine if there are gaps in Hyperledger projects where it can provide value to the developers’ community as a commercial entity. This means BC aims to be a good open source citizen contributing back to the Hyperledger project whilst drawing revenues from building and selling a useful product.
The Process
BC decided to apply a lean start-up, design thinking and agile development techniques to firstly derived a Minimum Viable Product (MVP) before embarking on delivering a full-fledged product. The process adopted by BC is shown in Figure 1.
Generate Business Model Canvas
BC’s management team were gathered and asked to complete a business model canvas[1]. Every member was asked to contribute by presenting Post-it notes on a blank canvas. The team then prune the Post-it notes in the canvas and eventually settled on version 1.0 (see Figure 2).
Note:
Template for the canvas was source from Startegyzer business model canvas template.
The outcomes of this canvas is only simulated and does not reflection of any real-life scenarios. Any resemblance to real scenario is purely coincidental.
Hyperledger Greenhouse Project and Cloud Native Foundation are mentioned only for illustration purpose only. There is no formal relationship to BC
For the purpose of BC’s product development, seven user types (or personas) were identified as potential product users. Basic characteristics of the personas are captured in Figure 3, Figure 4, Figure 5, Figure 6 and Figure 7.
Note:
There are no rules or conventions for capturing information about persona. In this particular case, I have decided to consider these attributes as it helps me, during the design thinking phase, empathize with their pain-points.
As-Is Activity and Empathy Map
BC’s product development team are asked to empathise with each of the persona mentioned above and record their assumptions in an empathy map as shown in Figure 8.
Note:
Please refer to Emily Christensen’s blog for detail on how to use the Empathy map.
This may seem like a frivolous exercise. If BC is building SDKs how does this inform me of how to build a good product?
In fact, a persona’s experience outside work very much influences how he/she interact with your product (in this case in the role of developers).
For example, how a persona gain knowledge would inform how BC should document and channel its product.
Following the empathy mapping exercise, BC’s product team are asked to identify the steps involved in setting up a development environment using current tools. Figure 9 shows an activity map. The set of data (i.e. “hear-see-think-feel-say-do”) from the empathy map are then overlayed on to the activity map.
Note:
For example, in Figure 8, Felicia “sees” her teammates are mostly unfamiliar with blockchain let alone the Hyperledger platform. This aspect is mapped on to the activity related to orchestrating Hyperledger network as it is a pain-point for her because she is now the single point of knowledge source and her team is unable to work independently.
The fact that Colin is not familiar with backend development and he is not able to get good help to understand Hyperledger meant that he is struggling to do his job with the current tool. Hence his empathy map component appears throughout the activity map.
Ideation
The BC product team members are asked to propose solutions to solve the pain-point identified in the AS-IS activity and empathy map. For this exercise, every member of the team is asked to describe alternative solutions in an A4 (US letter) paper and expressing the solution steps in six Post-it notes (see Figures 10 and 11 for options). This technique is based on IBM’s Design Thinking Field Guide.
The team collects all solutions and then pick from each other’s to generate more solutions for consideration.
Note:
I use the term “smart contract” here to avoid mentioning specific Hyperledger platforms namely, Fabric or Sawtooth. The former refers to “smart contract” as chaincode and the latter uses the term transaction processor. Since this blog principally about the development lifecycle so we’ll avoid reflecting any bias towards a specific platform.
Having ideate and generated options for consideration, the BC team then perform a simple risk/reward analysis. The team members go through each option and then produce a risk/reward map and then vote for the option as the most likely MVP (see Figure 12).
Note:
This is a qualitative technique. You could also use a quantitative technique.
Rough Cut Product Canvas.
Having done the risk/reward analysis, BC’s product team moved on the producing a rough cut product canvas as shown in Figure 13. The team has decided to focus on delivering to three personas: Felicia, Sophia and Benice.
Having completed BC’s lean and design thinking phase, the product team then transitions into the agile software development phase. The process is described in Part II of this blog.
