What possibly stood out most and left the strongest impression with us during the Berlin Blockchain Week we attended (18th – 23rd of August) was the (almost) complete absence of any kind of business development talks. We’re framing it like this because we deem it extremely important for facilitating mass adoption of blockchain-based products and services on a global scale. Notice we said “blockchain-based” and not just “blockchain”. That’s because solutions are just that – solutions – regardless of the technological stack used for their implementation.
But a wide-spread opinion persists in the global community that blockchain itself is the solution which is not only inaccurate, it’s counterproductive for the goals we all want to achieve with the technology which is still very young. Business development, meaning business plans, revenue modelling, value streams, stakeholder analysis, user personas and flows, marketing strategies, and a hundred other elements are what is currently missing in the blockchain space – and that was more or less fine up until now.
As of now, we need to put some focus on those areas pronto because these aspects of product development are what is going to help carry the blockchain space from a niche market which it is now to the mainstream adoption and true competition with traditional (centralized) products and services.
The situation we are finding ourselves in is completely natural – any new and disruptive technology adoption is driven by engineers in the beginning. The thing is, if we’re talking about blockchain actually becoming a part of everyday life for a random person on the street (and not for mostly enthusiasts as it stands right now), we need to bring awareness to blockchain space that development teams shouldn’t be just/mostly engineers. At the end of the day, the user doesn’t really care (read: doesn’t care at all) if the underlying technology is blockchain or not – they only care about the end result, is the product/service solving their problem or pain point better than what they are using right now in a centralized space.
This leads us to the conclusion that we need to approach the development of blockchain products and services as we do with any other – covering the complete vertical of necessary activities, and not (falsely) believing that just because something is on blockchain it will resonate it’s value with users as it does with engineers who actually architected it. Develop your product or service value streams without taking into account the technology for implementation – this will lead you to offer real value to all stakeholders in your system. Only then should you start shifting your focus towards choosing the best tool for the job, meaning deciding on a technological stack and it’s concrete implementation.
It’s All about the Ecosystems
One of Simon Sinek’s most important pieces of advice is to always start with “Why?” when developing products. Still, however useful, this is not an approach we adopted. In order to develop a product in a proper way, clearly define its value streams and make it sustainable in the long-term, we start by defining the team and stakeholders.
There are a couple of essential reasons for this approach.
Blockchain-based ecosystems are still ecosystems. Based on our experience, development teams focus too much on the (end) user, thus not sufficiently developing value streams and proper incentives for other stakeholders – validators, master-node owners, various off-blockchain entities etc, all of which are necessary for a system to grow sustainably.
Furthermore, we need to see upfront do we have the necessary skill set and if we do, what is the optimal way of forming a team around a product based on both the skills they bring to the table as well as defining responsibilities and accountabilities in terms of development. We are not talking about just the engineering team here, but the whole development team – business developers, marketers, economists, gardeners or whomever else.
The success of a solution primarily depends on the business logic and its viability (with industry maturity this only becomes more true), not on the technology that is used to implement it. That is why we need to ensure we have the best tools for the job in the form of team members and their skills in order to build a stable base for further development of our solution, whatever that is.
Overcoming End User Adoption Barriers & Habits
This approach will clearly outline your competition, and to answer that question upfront – our biggest “competition” are the (end) user adoption barriers and user habits. Sure, we have “traditional” (de)centralized competition, and that’s a separate topic which is pretty straightforward – whoever offers the best product/service will be a market leader; other factors that affect product/service success on the market notwithstanding right now since they are not relevant for this discussion.
Blockchain and crypto by extension are fundamentally changing the base set and distribution of responsibilities towards assets people have been used to for the past 500 years. And we’re not talking about niche blockchain products here, because when we look at the global landscape, all blockchain products are still niche compared to traditional products and services. To facilitate proper widespread blockchain adoption in the mainstream, for your average user which you want to have on the network (not the average user you currently have), we need to focus primarily on overcoming this adoption barrier, by:
- Developing human-centric blockchain design standards
- Making instructions, onboardings, terms of service and documentation humanly understandable in general
- Facilitating initiatives that educate and foremost build community trust on a global scale
These were the external factors.
10 Usability Heuristics for UI Design in the Blockchain Era
The MVP Workshop Approach
Internally, when developing blockchain products and services, the first thing we (need to) ask and analyze with our clients/partners is — Do you really need blockchain?
If the answer is yes, we need to analyze and decide — In what exact form and why?
It’s a bit paradoxical to even ask that question when you are a blockchain product R&D studio, but this moment clearly showcases our approach – we aim for developing whole systems that are clearly defined in terms of value streams and sustainable in the long term. The best way to really overcome the aforementioned adoption barriers is to make products that actually work for real people in the real world, and not just on the financial markets or as an evaluation for the investors to get more money (although if that’s your primary goal then go for it).
Last but not the least, by asking “Why?” at this point you force yourself to really map-out the complete value network for your system. We had difficulties with this in the past, primarily because we had no tools that were made specifically for evaluating blockchain products/services. That is why we developed the Decentralized Business Model Canvas (DBMC) which you can use freely. We needed a simple way to quickly validate, test and pivot a business model in a decentralized space.
The existing tools like the Business Model Canvas (which we all know) are usually based on the traditional definition of centralized business models and their characteristics as such were not ideal for this type of tasks. The DBMC enables us to work fast and adapt even faster, while ensuring the key questions are answered properly, and the alignment between project goals and what is achievable in the real world is always at the forefront of our product development processes.
Decentralized Business Model Canvas #1
Gathering Facts
Our next step is to gather all possible facts pertaining to the product/market matrix we are evaluating. Whether you are a team developing your own product or a studio like we are, it is extremely important to keep in mind that, at the end of the day, blockchain is not a solution but a technology stack, a tool for facilitating solutions.
The solution itself needs to be viable business-wise, regardless of the technical implementation path. We suggest you be careful when analyzing the facts:
- Don’t try and create casualties that are correlations at best.
- Don’t try and forcefully connect all of the facts into a logical whole.
Facts are just that — facts. Nothing more. They are used to inform your decision-making process. The primary mistake you can make is to consider them as pieces of a solution and try to put them together. Map them out properly and see what they are telling you before you proceed with defining smart goals.
Making Assumptions
Now, we need to start bridging the gap by defining assumptions (including risky ones) and their validation criteria. One of the tools that can help you is called the Experiment Canvas, but it can wait until you are done with the initial planning phase.
Next, we need to ask ourselves — Does anyone care about this at all? The answer usually comes in the form of User Personas. From our experience, a lot of blockchain products/services somehow skip this part of the process or take a shortcut. This leads to situations in which we don’t know how to approach things such as measuring app attributions or obtaining useful pieces of information for substantiating our marketing efforts and decisions.
All of that results in teams starting to make changes to their product/service which doesn’t fully correspond to the needs or pain-points of (end) users, and they start losing satisfaction and trust – all because they didn’t take time to do the User Personas properly and to really map out specific cases which need to be facilitated for each of them. This naturally continues into defining Jobs To Be Done and figuring out the mechanisms that will lead the users to adopt the innovation on the market.
After doing this we will be able to properly construct the User Flows in combination with the low-fidelity design – and this is the base for the Minimum Viable Product.
Only now our engineering team takes the spotlight and agrees on the T-Shirt Size estimations. This is how the entire high-level process looks like from our point of view.
This blog post was guided by the talk we gave during Berlin Blockchain Week – play the video to see the entire session.
You can find the presentation file here (gslides/public access).
