Lean KM and the Minimum Viable Product

We can use the same approach when it comes to implementing Knowledge Management within an organisation (as discussed in my blog series on “implementing KM as if it were a business start-up“).

There are two key words in the definition

Firstly the product should be viable. In other words it should solve the customers problem, add core value, and provide a complete focused experience to the early adopters. The diagram at the head of this post illustrates the principle. If you were creating the first car by a lean and agile process you would not first release the wheels, then the axle, then the coachwork, as none of these elements on their own are viable. It would be better to develop a powered skateboard, then a powered scooter, then a motorbike, so that at each step you provide the complete experience of powered wheeled transport.

Secondly the product should be minimum. It should be the smallest subset of features that delivers value, because this is your starting point to lean about how the user interacts with the product, and which then allows you to take the next development step.  The Knowledge management version of the MVP is the Knowledge Management pilot – that first release of a knowledge management solution to a group of early adopters in the business, in order to test the concept and deliver business value.

In Knowledge Management terms we know that the viable unit is not the tool or the process, but the framework. 

No single item, be it a tool, a technology, a process or a role, will deliver KM value on its own. You need a framework of roles, processes, technologies and governance in order for Knowledge to flow from source to user, and to be applied for business benefit.  The minimum viable product is therefore the simplest possible framework you can release.

For example, if you want to pilot KM in an area of the business where knowledge needs to be shared between multiple business units you could take one of two approaches.

• The all-too-common approach is to introduce a technology (Yammer, for example, or Jive) and anticipate that people will start to use it. However this is neither minimum (both of these technologies are well-developed, with many features), not is it viable (technology alone will not work).

• Better to introduce a simple framework such as a community coordinator (role) who sets up monthly discussions (process) using dial-in conference calls (technology) to discuss an identified agenda of critical knowledge issues (governance). Once the community realises this minimum system adds value, then they can start to build upon this system until they have a KM Framework that fully meets their needs. This is exactly the approach taken by the community described in Johnny’s story. 

Therefore lean and agile Knowledge Management focuses on delivering the minimum KM framework to the business as soon as possible, in order to deliver value, prove the concept, and most importantly to gain learning which allows the Knowledge Management product to take the next step of development.

As the web-page The Lean start-up says

Progress in manufacturing is measured by the production of high quality goods. The unit of progress for Lean Startups is validated learning – a rigorous method for demonstrating progress when one is embedded in the soil of extreme uncertainty

We see this principle in action in the way that IDEO introduced their KM system – through introducing a minimum viable product,learning from it, demonstrating progress, and iterating early and often.

Implementing KM is a place of extreme uncertainty. Apply a lean and agile approach; start with your MVP, introduce the KM skateboard, test it with the users, learn from it, iterate, and build the next improved version.  Pretty soon you will have your KM Porsche.