Written by: Ratko

MVP Workshop at Aeternity Starfleet 3 Malta

MVP Workshop had the honour of taking part at Aeternity Starfleet 3 Malta, November 5/6 2019.

As a blockchain product development studio, we held a 2-day workshop providing business and product development mentorship for 15 startups building their products on aeternity blockchain, as a continuation of our close collaboration with Aeternity Ventures.

The experience was amazing for many reasons, and we thought it might be useful to share everything with the community – you might consider this blog post as a lightweight guide to product development on the blockchain, as we @MVP Workshop do it. That said, let’s get into it.

Aeternity Starfleet – Why were we there?

Blockchain as a space in which we develop products, services, ideas and everything else is still extremely young, and we are delighted when we have the opportunity to share our knowledge in very practical ways.

Good practices, both in product and business development as a whole, need to be transferred and adapted for the decentralized space. This really stood out during our trip to Berlin Blockchain Week back in August, and we really started putting our efforts into creating tools and frameworks for facilitating mass adoption of blokchain products.

MVP Workshop’s Workshop

Invite to Starfleet was a great way to do two things – share our knowledge in an actionable and practical way, and try to adapt out practices into a 2-day workshop for startups in different industries, with different project scopes and in different phases of product development. Talk about a fun challenge. We decided to go with two workshop facilitators:

Petar Atanasovski, Product Manager
Celsius Network, Swarm Fund, Cere Network
Focus – Product Discovery & Definition, UX
Aeternity Starfleet role: Mentoring Co-Captain

Stefan Ignjatović, Business Developer
MVP Workshop Growth, Celsius Network, Cere Network
Focus – Strategic Consulting, Product Development
Aeternity Starfleet role: Mentoring Co-Captain

What added to the pressure under which we thrive is that Aeternity Starfleet has a really hands-on approach for a startup accelerator – it packs a traditional incubation cycle of at least half a year into less than 2 months, offering not just financial resources but complete domain expert guidance, meaning really bootstrapping the teams with everything they need to put their products on the market.

We felt great responsibility to give teams as much as we could while keeping it practically usable on the spot, since many of the decisions they make during this phase will resonate throughout the project development cycle. We also wanted to teach the teams to fish for themselves in the future, besides giving them buckets of saltuna to eat immediately. Our workshop was divided into three segments with a natural segue – Value Proposition Design, Customer Development and Defining the Business Model(s).

Note – we will be using practical examples from the workshop without giving to much context about teams’ products in order to keep this blog to the point. For a broader picture about the startups we worked with you can check out which 10 teams made it to the second phase of Starfleet 3, following Genesis Week which our workshop was a part of.

Value Proposition Design

MVP Workshop approaches the development of blockchain products and services by covering the complete vertical of necessary business development activities, not relying on the buzz-effect of blockchain technology to excite the market about your product, as it often does the engineers who actually created it.

Blockchain is all the rage these days, but the customer and their end-user will be asking “what’s in it for me”. This is probably one of the key points in the process, where we need to be aware of the “problem” and “solution spaces” as separate for the time being, and only focus on the problem space.

This is sometimes difficult to do when you already have a product you have been working on for months (or years) and someone asks you to take a step back for a second, but it needs to be done. If it helps, think of your product as your competitor’s – you want to know everything there is about it, find all the “dirt”, and identify all the aspects that could be improved in some way. So, for now we are in the “problem” space, and we need to ask ourselves – who are our users?

In decentralized space the more appropriate question would we “Who are our stakeholders?”, but let’s start with the users as entities whose pain points we are tackling for some reason, and leave the rationale and incentivization for all system stakeholders on a docket for now.

Your goal is to clearly define the User Persona(s) for your product/service, as well as the context in which they are looking for a solution to their pain point(s). The best way to start is to define your perfect user across different aspects – demographic, psychographic, behavioral, or any other you might find relevant to inform a truly holistic overview.

If your goal is to create a new way to crowdfund community-organized development projects, a service which is rather new (or non-existent in mass adoption terms), you would need to figure out who is the archetype of a person that would use such a service – this requires the multi-aspect analysis in order to create a definitive (as possible) User Persona, so you can start figuring out how to find them.

On the other hand, if your goal is to provide a service for selling genuine football kits, you are targeting the need for buying football kits + the need for being sure the kit is genuine. In this case, the complex research is not needed in order to find the defining characteristic(s) of your User Persona in the context of your product, but it will be needed to figure out who exactly those people are, where do they live, and how you can reach them.

A little side note – everything you do needs to be prioritized, meaning something is always more important than something else. In that spirit, you will be focusing on your Primary User Persona for starters, meaning the person whose pain point you are primarily solving and for whom you create and subsequently derive from the most value.

In the case of a P2P lending platform, your Primary User Persona could be the people who want to borrow money with lowest interest possible. Your other User Personas (secondary and so on) could be the HODLers since they help expand the lending pool and collect interest, the people who trade your token on exchanges and so on. Notice that there was no mention of blockchain as such yet, and that is going to stay the case throughout most of this blog post.

As we separated the “problem” and “solution” spaces, we will be separating decentralized business models from blockchain – a technology stack for facilitating solutions, not a solution in itself.

It might be counter-intuitive, but whenever we sit down with a client in the early stages of the project development cycle, we always ask and analyze – do you really need blockchain? The effect of this is most evident when you look at the adoption curve.

While defining your User Persona(s) be aware that no-one will ever use your product just because it is on blockchain. Your product needs to provide real value regardless of the tech implementation path. Naturally, everything you decide needs to be prioritized, and this is the case with defining User Persona(s) as well, prioritizing Innovators and Early Adopters which comprise your Early Market.

Now, neither of these customer segments will be enticed to use your product/service just because of blockchain. Although, Innovators are natural explorers, which means they are willing to sacrifice a lot of comfort (speed or great UI design) if a new product/service excels in certain aspects compared to everything else available on the market, especially when that certain something really pains them and you are solving it amazingly well.

An important note with Innovators is that they cannot be created by your marketing efforts, they need to be found. The first group of users which make up a community around your product are the Early Adopters, and these are the ones you will be targeting with a complete Minimum Feature Set, since you validated your key feature(s) with the Innovators.

It might seem like we are jumping the gun, and dealing with things that might be way down the road without tackling how are User Personas defined in practice. The reason for this is that everything we talked about is now used to frame your thought process, and put it in the right place for you to be able to do the following properly – define your main User Persona, which will be representative of your primary target group.

One of the best tools for this is the Product/Market Fit Canvas, which will make you go through everything we talked about in a structured way. This canvas relies on defining the user’s pain point and subsequently goal as a Job to Be Done, a mechanism by which consumers adopt innovations whenever they have a need for a product that would enable them to accomplish that goal, i.e. get the Job Done.

This is expanded by further asking – why do your customers need to use THIS product to get the job done? – making you really pinpoint the key value proposition for your product/service.

Next step would be to deal with non-primary User Personas which can, besides as users, be considered as stakeholders when talking about decentralized systems. As with your users, you need to properly incentivize all network participants in order to establish balanced value streams and make everyone act in the best interest of the system itself.

After mapping the key value proposition, you are now mapping all value propositions that exist in your product’s ecosystem, and the best tool for that (for obvious reasons) is the Value Proposition Canvas.

This canvas can (and should) also be used for your primary User Persona, but for the workshop we decided to use it like this since we didn’t want to go too deep into other User Personas in order for teams not to lose focus of what’s important, but still get the outlines of most stakeholders. Remember – prioritization.

Since we made all teams think really hard about their value propositions, it was time for them to try and present their key value in 30 seconds or so. Some of them got it on the spot, while others saw how much value can differ for different users.

One of the teams was building a platform that makes sure the drivers will have access to more parking options in high-density urban areas through barrier automation. In this exercise they saw how different parking needs can be with car drivers and how differently they perceive value, as well as figuring out why a parking garage owner/operator would be incentivized to adopt their solution as a key stakeholder in the system. A good way to get to the point when asking “Why would someone use this?” is to keep asking the same “Why?” over and over until you get there. It usually takes 5 – 7 times.

Although it sounds counter-intuitive once again, be ruthless to your project – if you find and fix all the holes and gaps there will be next to none when it finally hits the market, and that’s how great products are made. Don’t be afraid to make crucial changes if they are well-founded.

Customer Development

You might have noticed how much assuming we did. It was structured and informed, but there are still very few things we are sure of, and we need a way to assess the risks and test everything out. We also need to be sure not to do the following two things:

Don’t try and create causalities that are correlations at best
Don’t try and forcefully connect all the facts into a logical whole

Our aim here was to help the teams improve the way they make assumptions when developing products, giving them a high-level framework for mapping out and testing decisions that are not primarily data-driven, because we always assume – about our clients, products, features and that creates risk – an analysis often skipped in the early development stages because we assume everything is going to go more-or-less well.

Basically think of everything that can go wrong, talk to domain experts, and rely on your mapped value streams to pinpoint the key risks. A simple way to start would be to map the risks onto a matrix according to probability and impact, and prioritize them by importance. This is well complemented by the PMR risk analysis framework which you would want to do for your top 3 – 5 identified risks:

Prevention – what we can do so the risk doesn’t occur
Mitigation – if the risk occurs, what is our immediate response
Reaction – what actions do we need to take to rectify the ‘damage done’

In the case of decentralized crowdfunding platform for European cannabis ventures, one of the biggest risks would be the lack of control over law policies from the perspective of the SMEs in the cannabis industry, whom this platform would be primarily helping, which can significantly impact the profitability of said SMEs business models if they are sudden or major. To narrow this down in a general fashion, let’s say the risk is defined as ‘A law that negatively impacts the platform’s business model’.

A prevention of this risk would go along the lines of ‘Gaining enough influence to impact policies’, which could be realized for example through strategic partnerships with the local or national government. If something like this risk actually happened, the platform’s immediate response could be to ensure there is no panic within their user base. The reaction could be to figure out a support system for the business’ impacted by the policy change, and probably transfer a part of or the whole business somewhere with better policy climate. The risks on the map up there are just random examples, but this risk would most likely be in the area of 1 or 2 if we were to really try an quantify it.

A nice extension to complete the trilogy and possibly turn risk analysis into actionable strategies is the Cross SWOT (or TOWS) Analysis, which can be surprisingly useful for turning weaknesses and threats (i.e. key elements of risk) into growth opportunities. It takes time to complete properly, but it is often very much worth it.

Although it might seem like the law that doesn’t impact the platform but impacts the SMEs should not be considered as a major risk, it is – because with no fertile ground for the SMEs, the platform doesn’t have users or revenue streams, meaning this needs to be taken into account when evaluating risks. One of the useful strategies you could get from a Cross SWOT is how to use this situation to your advantage, by creating a strong relationship with the SME community, gathering it closely around their crowdfunding platform brand. An initiative like this could improve the service and satisfaction of the users as well as general management of the community, and possibly help them gain some political influence based on the combined economic strength providing them with some level of control when it comes to laws and policies impacting them.

Some analysis approaches are qualitative in nature, but remember to always quantify everything in one way or the other – without doing so you will be unable to make informed, data-driven decisions. There are many approaches to testing out your assumptions, and we’ll cover main categories that cover different aspects and are complementary in nature and scope:

Qualitative & Quantitative – Quantitative methods are typically anything that you can count, like time on page, percent of users engaging with x, page views, user flows, time to task completion. Qualitative methods entail researchers engaging users and digging into their behaviors, feelings, attitudes and emotions by utilizing a plethora of well practiced soft skills.

Generative & Evaluative – Where are you at in your research process? Depending on your answer you might want to focus on more generative research (early on ideation) or more evaluative research (is what we are building right?).

Behavioral & Attitudinal – This final dimension categorizes our research methods into the realms of “What opinions does a user have about this product or service?” and “How is user actually interacting with this product or service?”

You can notice how we are using basically everything we worked on in the first section here and building on top of it. This process takes time do facilitate properly, but greatly changes the outcome in the long run.

In order to provide the teams with a clearly defined framework for experimenting with their assumptions we used the MVP/Experiment Canvas which makes you list and prioritize your product’s risky assumptions, and figure out how to test them out. It might be a good idea to run through the Value Proposition Canvas once more at this stage and rethink the value streams before proceeding further – just in case.

In the blockchain space it is often the case of building non-existent products based on raw business ideas using unstable new technologies – and that makes us thread carefully. You will want to go through the whole process again for each new iteration of your product in order to (re)align everything. Right now you have a Proof of Concept (PoC) for your product or service. The next step in your product development process would be to start translating everything we did so far into a list of features, forming the outlines of a Minimum Viable Product (MVP).

Take care not to think about the technological implementation just yet and focus on features as such – what task(s) they need to accomplish and in what way in order to get the Job Done?

Because we need to prioritize everything, a great tool to use in this phase is the MVP Features Matrix:

Forget It – simply too much effort for what is gained; put it in the backlog and revisit at some point in the future.

Build Later – the gain is not proportional to effort needed for implementation, but these features can often be the key differentiator down the line as the market saturates.

Build It Now – features tied to your key value proposition.

Fake It – you decided you must have the feature, but maybe you cannot implement it in the way you wanted or needed to; figure out a way to provide the feature until you can achieve proper implementation, because the users shouldn’t even be aware or care (and often don’t) about the underlying technology of the products and services they use.

At this point, you have all the elements needed to start forming the Business Model(s), and we have just the tool for the job to be done.

Decentralized Business Models Canvas

The second day of the workshop was aimed at forming clearly defined business models for all teams. Some elements were covered in the Value Proposition Design and Customer Development, but to have a complete holistic picture of the product/service we need to take care of more aspects of business development.

To do that, we need proper tools. As MVP Workshop is very interested in not only adopting technology and facilitating decentralized business models that actually work but also providing the highest level of service possible to clients and partners, we were logically lead to ask ourselves the following question: “How to validate decentralized business models?”

One of the most popular tools used to describe, design, challenge, and pivot business models is the Business Model Canvas. However, it was created with a centralized business model in mind, and we needed a simple way to quickly validate, test and pivot a business model in a decentralized space.

That is why we decided to adapt various tools or build new ones from scratch, and one of the most important ones is the Decentralized Business Model Canvas (DBMC). It enables us to work fast and adapt even faster, while ensuring the key questions about product development are answered properly. With that in mind, let’s take a closer look at it.

You will be using most if not all of the work you did so far to fill in the segments of the DBMC, as well as tackling the basic structure of cost and revenue streams. So let’s get into what each of the segments should look like in order to form a holistic overview of your decentralized business model.

User/Customer Segments

Who are we building the product for? You mostly answered this question through forming your User Personas, but it would be good to map all of your user groups/archetypes here, with key user characteristics prioritized in the context of your product.

Value Proposition

What is the value we promise to deliver to our users? This is the place to gather all value streams around the key value proposition for your product/service. Feel free to go back to the Product/Market Fit or Value Proposition canvases and explore options to make sure nothing is missed or inadequately defined.

Proposed Solution

What does the solution actually look like? Without going too deep (or at all) into technological implementation, describe the solution and how it should function in the sense of Jobs to Be Done. This naturally extends into User Stories in later stages of product development, which you can think about in broad terms to help define what the solution looks like in the real world.

Reaching Trust

What mechanisms do we use to reach trust? Both due to the extreme novelty of blockchain in terms of mass adoption and some events that didn’t really help the blockchain space (the ICO era), we must be careful with managing communities around the products and services on blockchain, since trust currently isn’t the golden standard. Good UX practices will definitely help bridge the gap, but think about initiatives (educational or otherwise) that can advance your user growth and, at the end of the day, brand image.

Validator Incentive

What are the incentives for validators, or stakeholders in general, to take part in the network and work in its best interest? This may wildly vary depending on your product and subsequent implementation, but you will definitely have multiple actors in the system that need to have the proper value streams provided to make sure your platform can grow sustainably.

Interaction Channels

What are the best channels for communicating with your users and the community in general? Think about choosing the proper communication platform for each of your User Personas, and make sure you have a regular update schedule. Mapping a taxonomy of your product will help you focus on content categories that are most relevant for your users, which you can place in various forms. Really, anything plays here as long as you have a proper rationale behind your decision – educational blog, 24/7 customer support, chatbots, dedicated resource pages on your website, blog posting, paid marketing campaigns, podcasts, AMAs, meetups, etc. All major social media channels are a must in most cases, at least from the perspective of general brand building. Don’t forget the system stakeholders in general, besides your primary users.

Network Governance

How are decisions made within the network? What is the initial set of network rules? How are Smart Contracts utilized? Who decides on future changes in network operations? What is the voting system? This varied a lot as well with the products teams were defining during the workshop, and that is perfectly fine. Depending on your product architecture and business goals, you need to define how the network will be governed in order to be able to grow sustainably, which is very much in line and tied to the Validator Incentive segment.

Cost Structure

What are the key costs of doing business? Think primarily about your capital expenses for setting everything up or expanding your scope (CAPEX), and operational expenses meaning your day-to-day spend on a monthly level (OPEX). This will outline your primary cost structure.

Revenue Streams

What are the key ways to generate revenue? Answering this question is closely tied to the previously mapped value streams, as well as both incentivizing stakeholders and actually making enough profit at the end of the day for future growth. We won’t be going into the details here, but be aware not to rely entirely on best practices that currently exist, since blockchain as a technology does offer ways to disrupt many traditional revenue stream models. We will mention some useful tools which you can use to (roughly) estimate your financials:

The Tech Stack

This is the point where you would start making decisions when it comes to the implementation path you will take. A useful tool for evaluating both business and technical aspects of your solution, especially if the project relies heavily on your tokenomics model, is the Token Modelling Canvas. That said, we will stop here since the talk about the product development process from the tech stack perspective deserves it’s own blog post. In the meantime, you can check out how we bootstrapped a custom PoS blockchain network.

[Update: November 18, 2019] This blog has been expanded into a lightweight guide to product development on blockchain. You can find the presentation on our SlideShare account and use it as a checklist in your practical work. Have an awesome day and consider subscribing to our newsletter for more content like this 🙂