It has become a business mantra that the first thing a technology startup has to do is to create a Minimim Viable Product (MVP). As discussed in my previous post I consider the term MVP to be of little practical use since it is generally poorly understood and even more poorly implemented. In short, MVPs are almost never minimal and rarely viable. I prefer to talk of experiments or prototypes to keep the mind focussed on what they are intended to achieve.
However we choose to describe our initial attempts at creating a product the fact remains that it is usually necessary for a nascent business to generate income somehow or other in order to survive long enough to complete their MVP/experiment/prototype.
There are many stages creating a successful business, but if you can operate in any way without building anything then you probably should. This first stage may not be pretty and it may be missing some key components of your business model but it may also generate income and it will definitely generate insight.
A walk in the park?
I’m tempted to give this concept a memorable name. Unfortunately for me, Minimum Viable Company has already been taken and has been defined to mean something different, so for the purposes of this post I’m going to call this ‘pre-business’ a WIP. This stands for Walk in the Park (as in ‘walk before you can run’). Or maybe it stands for Work in Progress? It doesn’t really matter, it’s just a label that refers to an idea and it is the idea or concept that matters, not the buzzword (if only this were true for MVP!).
“But what of this blueprint you promised us?” I hear you cry. In this case, the blueprint I’m referring to is a Service Blueprint. So what is a Service Blueprint, and how does it help us create a WIP?
A service blueprint is a diagram that displays the entire process of service delivery, by listing all the activities that happen at each stage, performed by the different roles involved. The service blueprint is built by first listing all the actors involved in the service process on a vertical axis, and all the steps required to deliver the service on the horizontal axis. The resulting matrix allows to represent the flow of actions that each role needs to perform along the process, highlighting the actions that the user can see (above the line of visibility) and the ones that happen in the back-office (below the line of visibility). Roles can be performed by human beings or other types of entities (organizations, departments, artificial intelligences, machines, etc.)
I have found that, in practice, a Service Blueprint workshop offers several useful outcomes to a startup:
- Clarity: First and foremost, it highlights the areas of the process that the founders haven’t given sufficient consideration to. It is not uncommon for there to be significant gaps in the service design because the founders have never considered their business in a linear fashion, from the time a customer first becomes aware of their product or service through signup, first use, continued use and, finally, end of use. Where gaps usually occur is at points of ‘handover’ or transition between states of service. This is exactly what Service Blueprints are intended to uncover.
- Resilience: The next thing that quickly becomes apparent is that the founders have only considered the ‘happy path’, where everything goes well and there are no issues. This is completely understandable - one needs an optimistic mindset to start a business after all - but it does not result in a robust business model. Once you have identified how your business process works when everything goes right you can start asking ‘what if?’. It is these kinds of questions that help build the safety net you need to be able to sleep at night.
- Definition: It defines the flow for any software that you have to build. This is the foundation for enabling your developers to understand the functionality they have to provide and your usability experts to define a suitable information architecture and user experience.
- WIP: It gives you a means of defining your WIP (at last!). Once you’ve designed your entire service ask yourself if you could implement this service using only products or services you buy from other people. Could the bespoke collaborative communication module you so want to build be replaced by email? How about using Slack or WhatsApp, even if only temporarily? Can you at least make an approximation of your business using only off-the-shelf (OTS) components? It probably won’t be a scalable solution. It may not cover all of the elements in your process. It almost certainly won’t be the ideal you’re dreaming of, but it could work and it will probably be quick to implement. As long as you can fulfil 70-80% or more of your service then you have a WIP! If you can do it, then do it. You’ll learn a fantastic amount and you’ll probably be able to earn some money too.
- USP: Is there part of your process that simply can’t be achieved using OTS components? Are you sure? If so, you have just identified your Unique Selling Point (USP). Congratulations! You also know what to build first: an experiment to test the viability of your USP.
The creation of a Service Blueprints will probably be the first time you have seen your business in its entirety. This ‘birds eye’ view is incredibly useful if you approach it the right way:
- Focus on what you are doing, not how.
- What happens if something does wrong?
- Assume your product doesn’t exist (which shouldn’t be too hard, since it probably doesn’t!). Can you provide your service just using OTS components, even for a short time?
- If so, do it now and build for scale later.
- If not, where does the flow break down? You’ve just identified your USP.
Most people, once they have an inkling of a problem, jump straight to the solution. This means that their entire business ends up serving the technology, rather than technology being used to achieve the aims of the business. Service Blueprinting gives you a mechanism for avoiding this trap and for making money now, not later, as well as learning valuable lessons.