Some principles of Business Model Design applied to the blockchain.
During the previous articles of this series, we have introduced our readers to our exploration of business model design applied to the blockchain, as well as to the basic methodological framework we are using.
The framework explained isn’t new. It’s the basic one used by many designers all over the world. However, it’s not enough. A design practice needs to address the nuances of every business. The blockchain industry is not an exception (in fact, there is plenty of it), so we need to find out how to apply this framework. We believe that it will work much better if we apply some basic principles, as explained below.
Skin in the game and expertise are always welcome!
The first thing we need to take in mind is that designing a business model is not ONLY about applying a design methodology. Moreover, is neither about replacing tech or business rationale with design techniques. That’s a mistake we shouldn’t make!
Business Design, as Design Thinking, is a way to merge different disciplines (design, tech, and business) to enable the creation of holistic product visions. As explained by Tim Brown (one of the creators of the Design Thinking methodology), “Design Thinking is a method of meeting humans’ needs and desires in a technologically feasible and strategically viable way.“
In other words, when designing a product or service we are trying to solve human needs, as well as figuring out the kind of business emerging from that, and the technology that could serve us for that purpose. Therefore, we need to perfectly align value creation, tech performance, and business feasibility.
What does this principle mean in real life? It’s a clear reminder for designers to include both business and tech people in the process. In fact, designers should be facilitators, helping teams comprised of blockchain developers, product managers, marketers and project leaders to go through the overall process. You should always involve those with real skin in the game, as well as real knowledge and competencies. Create a collaborative environment where everybody can safely bring their expertise!
Designing should also be rooted in the real facts of the company you are working with. That means knowing not only the customers but the engineers and product managers that are working with the technology on a daily basis. At the same time, business managers should also be involved, because nobody will better understand the nuances of a particular industry that those actually working on it.
Speaking about the blockchain, my experience is that every group should include (at least) a seasoned blockchain developer, some people with real experience in sales/marketing in the industry covered, and finally some people with experience in product management. Otherwise, we will miss on the table critical information, risking the overall result. Of course, if you can include some potential users, that would be perfect!
Design restrictions are mandatory.
Usually, a design process is a delicate balance between creativity and focus. We need to open the scope of our work to allow people to think out of the box. At the same time, we shouldn’t lose our focus. Otherwise, the results will be too abstract, or people will simply get lost in a huge constellation of possibilities.
To achieve this balance we should apply some design restrictions. Restrictions are great because they create some fences we shouldn’t cross over. These fences prevent us from exploring possibilities that are not realistic, or from getting lost in the midst of an unleashed creativity storm. They help to better ground our work, focusing on what really matters.
In our experience we can apply two kinds of design restrictions:
- Push vs. Pull.
- Canvas restrictions.
Let’s explain how they work.
Understand Push vs. Pull
Push and Pull are two usual terms in marketing strategy, and they refer to the way we relate to the customers through the different channels we could use. Push is about throwing the message to the customers, “pushing” it to as many people as possible, so the potential customers will finally notice it and hopefully pay some attention. Unsegmented ads (like those displayed in banners, newspapers or billboards) are one the most common “push” marketing actions.
In the opposite side, “Pull” is about giving the customers what they are looking for. When we deliver a message that addresses the needs of a particular kind of customer, displayed in the places or digital channels s/he usually visits or browse, we are applying a pull action. Segmented ads in digital channels where we have behavioral data of the clients (such as search engines or social media) lay in this category. Inbound marketing is also a great example of a Pull strategy.
The difference between the two strategies can also explain as follow: Push goes from the company to the customer, Pull goes the opposite way. Push doesn’t segment the customers when promoting a product, Pull always tries to deliver what a particular group of customers is looking to get their attention.
The same approach can be used in any design process. If you have a push approach, you will try to design a value proposition (as well as the business model over it) starting from a technology you already have. In the Pull approach, you start with your customer pain, gains, and jobs, to find a solution to those with the biggest business potential (and not really worrying that much about using a particular technology).
The Push approach tries to solve a problem for many blockchain startups out there: to find a problem for the technological solution you already have. For that purpose, you need to find your potential customers, working with those potentially interesting segments. It is a pretty interesting approach for designing solutions with the blockchain technology, whose features are completely new, and hence not tested in the market.
In fact, this is what the blockchain people out there are already doing. Starting with a small community of crypto users, a constellation of blockchain startups is trying to find new markets for this technology, starting with finance but also moving to supply chain, digital ID or e-commerce.
For this endeavor, design methodologies could help to find those customers whose needs could be clearly addressed by a blockchain-based solution, as well as building the right problem-solution and product-market fit. At the same time, it can also help to understand how to build a proper growth funnel and monetization strategy, both critical elements for a sustainable business model. The Push approach is especially interesting for those companies exploring the potential application of the blockchain to improve, boost or disrupt their business model. In other words, if you have already a working business, you can use the blockchain to play the efficiency game or just go for the disruption. It’s up to you!
However, this fact doesn’t mean that we can’t use the Pull approach. As we learn how the blockchain could be used to solve business problems in several industries, we can take this knowledge and try to find a problem-solution fit wherever we want.
Moreover, Push and Pull could be complementary. Every designer works in both ways at the same time, going in both directions at a different moment. We should be aware of that; even in we choose a Push strategy, we will need to play the Pull game to fine-tune the value proposition. And the same applies to the Pull strategy; sometimes we will need to explore other potential customers, trying to get the best fit for our technology.
Do both approaches work? Absolutely! I’ve been doing that during the last two years and it works, as long as you use the right framework to assess the very particular nuances of the technology. At Design4Chain we have created our own: the TFB approach and the Blockchain Analogy Cards. At the same time, we have created a cheat sheet to carefully detail our brief in the HMW phase. We will detail all of them in the forthcoming blog posts.
Use canvas restrictions.
Related to the previous one, we can also add more design constraints, such as focusing only in B2B or B2C clients, allowing only some particular ways of monetization, or including some mandatory partners into the equation. That would depend on the particular project we are working with.
I have found that canvas restrictions are great for the Push approach. If you are exploring how to apply the blockchain technology to improve or disrupt your value proposition, or maybe to find new customers, you can “lock down” several parts of the canvas, starting with the Key Resources in the left part (where the blockchain technology should live in any canvas).
From that starting point, you might want to lock down the channels part, so you can use your existing marketing and sales solutions for your the new solution you are building. Maybe you would also like to work with the same customers you already have. Doing that, you will be basically exploring how the blockchain could unlock new value propositions to your customers, with new possibilities in terms of customers relationships and revenues.
The previous one is just an example of how we could work with restrictions to help us focus on building blockchain solutions. In every case, we should clearly state the kind of restrictions we need, including them in the HMW brief (we will explain that in the next post of the series).
At the same time, we need to carefully consider the context of the business model, as it will probably add more important restrictions to work with.
Always work with your context.
Business models are not born in a vacuum. They are feasible because there is a full business ecosystem that allows building whatever is planned. We can explain many cases of a business model that was a great proposal taking them isolated, but whose fate was doomed because they didn’t take in mind the ecosystem and environment where they were born. To prevent that from happening, we should also include in the process some context restrictions. They will inform our design practice, clearly pointing to those critical elements that should be taken in mind in order to build something that will work.
Which context restrictions should we keep in mind? From my experience, we should work with at least four:
Data privacy restrictions.
If we are building a solution handling personal data, we should be aware that we need to match the technology with the standards imposed by the data privacy laws out there, especially Europe’s GDPR.
This is especially important in the blockchain industry. Remember that the blockchain is an immutable ledger, so probably it is not a good idea to use it to record personal data. A good GDPR specialist might be of great value to help us understand how to comply with the privacy laws with our new blockchain solution.
There are some economic regulations (such as KYC and AMLregulations and securities laws) that we need to address when building a blockchain app. If you a trader or you have run an ICO you might be already aware of that!
These constraints apply especially if we are designing financial dapps. If that is your case, don’t forget to include in your team some good financial adviser! Otherwise, you might risk issuing something that is tightly regulated, bringing a high risk into your business.
Other legal constraints.
When we are dealing with complex industries (such as supply chain or pharma) we should be aware that business practice usually involves complex compliance requirements, including certifications and legal registrations. We shouldn’t forget about that. Maybe, we can even find that the blockchain could be a way to ease those restrictions (one example for that is supply chain provenance). The potential here for finding new value propositions is huge.
With this term, I call those constraints coming from the fairly immature status of the blockchain ecosystem, where we can’t do everything, even if it’s legal and feasible, simply because there is no market for it. Think about crypto finance. During the last two years, the guys at #defi have been building nice dapps and new ways to handle, trade and create value online.
However, there is no business in many cases (apart from exchanges and payment solutions), simply because there isn’t enough users to sustain a growing company. So, if we want to address the business part of designing a new solution (remember, that part where we want to significantly impact a market), we should also be aware of the potential size of the market.
Another BIG constraint today is the technology itself. As I explained before, many startups have been building consumer dapps to finally find that the technology was not yet mature in terms of scalability or transaction costs. It is a big constraint and should be always taken in mind. And that’s the reason because you always need a blockchain developer in your design team. S/he will properly assess the technical feasibility of your value proposition.
Yes, that is also a constraint. Business acumen informs us about good and bad practices that could potentially impact our business solution. Designing is about creativity and exploring new venues, but it should be also common sense.
That’s it! Although we are not detailing all the elements involved (that would take a long, long, post), we believe that the previously mentioned are the basic principles we need to keep in mind when designing a business model using the blockchain technology.
Some final strategic considerations.
Designing with restrictions is in our opinion the most interesting approach to start designing business models with the blockchain.
However, we should also consider that designing is also a strategic choice. Where should we start? Which industries are ready for the tech? Which parts of the value chain are easier to disrupt with decentralized technologies?
That’s a complicated question, and probably nobody has the answer. However, we believe that the theory proposed by Iansiti and Lakhani about how innovation works on the blockchain could help us to find some guidance.
These two researchers say that the blockchain, as a foundational technology, will follow several phases: single-use, localization, substitution, and transformation. Every phase is defined by the novelty of the applications and the complexity of the coordination efforts needed to make them workable.
What this theory says is that this foundational technology will go from the simple to the complex in terms of novelty, and from the single user to the network effects, in terms of coordination.
In fact, the blockchain technology has been taking this path, from the simple-performing operations to the most complex ones (moving from payments to exchanges), and from those operations that require just a few participants to those involving network effects (we started paying pizzas with bitcoins, and now we are tracking the supply chain for the cheese and the bread of those pizzas).
What that these means in terms of designing a business model? It’s not easy to make a general statement because every project is different, but for us the advice is clear: start simple, solving small problems one by one. Usually, big ideas willing to disrupt whole industries (a very common proposal in 2017, as seen in thousands of whitepapers) show a lot of holes when passing through a careful examination: the market is not ready in terms of volume, there are too many legal and business nuances that probably will be critical for the success of the idea (meaning a higher risk of failure), and the technology isn’t ready yet.
On the opposite side, those ideas who rely on simplicity, a clear value proposition and a real market (this means real users already using blockchain solutions, or willing to explore them) have usually better odds for succeeding. They might not be the next “killer app”, but surely the next step in a long way. And, as the Spanish poet said: there is no way, you will make it while walking step by step.