Meet Mappy, Happy, and Dappy: Personas for Blockchain Product Management

The holiday season is behind us and the new year has begun. It’s a traditional time for individuals and companies — including those of us exploring the brave new world of blockchain technology — to assess what we’ve accomplished, and to set targets for the year to come.

It’s 2019, and it’s time for the blockchain world to get real.

It has been all too easy, until now, to get caught up in the crypto hype, lambos, market volatility, and irrational exuberance of this new technology. But that chapter of blockchain’s history is rapidly coming to a close. One after another, technically dazzling projects begun without a clear focus on real users, distribution models, and real-world use cases will lose the race. In many such cases, start-up funding will run out before the products find user bases to serve.

Crypto projects can survive the shake-out and prosper in 2019 and beyond only if they have a clear idea of who their products and services are intended for and what those users need.

It’s time to get sharp on blockchain customer personas.

Personas for Blockchain Development

Product Managers have long utilized personas to help steer product development towards meeting the needs of real world users.

Customer personas are fictional characters that product managers create to represent the different users of a specific product. They exist to help product managers communicate research about their ideal groups of users — and give faces to these groups. … Personas matter because they represent a product’s core customer demographics. Product managers must make informed decisions about who their customers are, what they need, and how their product will be the solution. Personas help product managers make these decisions. — The Aha Group

The increasingly popular Jobs to be Done framework further focuses product management and innovation on deconstructing a job that certain personas are trying to get done such that product is built to help get the job done rather than building features or technology in search of a use case.

In this post I propose three personas to help focus blockchain product management: Mappy, Happy, and Dappy.

I encourage the blockchain community to provide feedback on these personas, and to help develop them and improve them — as a collective community resource towards achieving mainstream adoption of blockchain products.

Meet Mappy, Happy, and Dappy

Most blockchain projects to-date have focused on building decentralized applications, known as “DApps,” (or “Dappys”) only to find that the technology, scalability, and usability of blockchain is not yet ready for mainstream DApp adoption. Impatient crypto speculators are known to decry: “where’s the usage?” when it comes to DApps. Within the industry there is widespread hope that DApps will begin to gain some traction by 2020 and everyone is waiting for the first must-have killer DApp to emerge.

A smaller set of blockchain projects have prioritized developing blockchain solutions for existing centralized businesses with large user bases. The counter thesis amongst this crowd is: DApps are part of an exciting future, but that future could take years to materialize and gain consumer adoption; meanwhile there are mainstream businesses with millions of users (we call them “MApps” or “Mappys”) who envision delivering more customer-centric experiences and developing competitive advantage by moving parts of their businesses onto public blockchains. In doing so, centralized businesses could drive requirements for blockchain usability and scalability to enable mass-market adoption.

Both groups believe in an increasingly decentralized future. The healthy debate is over which comes first: decentralized apps or decentralized app users.

It’s the age-old product management question of which matters more: features or distribution?

One of the world’s all-time greatest product managers, Reid Hoffman, founder of LinkedIn, comes down squarely on the side of distribution:

[W]e want to create great products that people love, that gives them moments of magic, it’s part of why we do what we do. But if you are not building the strategy of product distribution, into what you are doing, then you are relying entirely on a form of: running into a field with a large metal pole hoping that lightning strike, and that’s not usually a winning strategy.

(Greylock, November 10th 2016, 4) — LinkedIn Founder Reid Hoffman.

No matter which side of that debate you come down on, building the right product for your target customers and their users is critical to gaining acceptance and distribution.

Towards that end, Francesco Pacella and I developed three personas that our product teams rely on every day at OST: Mappy, Happy, and Dappy.

• Mappy is a mainstream application whose core code runs on centralized servers. The Mappy company is curious about dipping some toes into blockchain and putting some transactions “on-chain” to provide increased customer value, build user trust, and gain competitive differentiation. If it works, Mappy would look to decentralize more transactions over time. Mappy typically has a large existing user base and they’re interested in blockchain to the extent that it improves their user engagement and helps with their key KPIs, but they will certainly resistant to taking a step back on user experience due to integrating blockchain into their app.
• Happy envisions a hybrid application that combines the benefits of Mappy with the “programmable money” features of blockchains like Ethereum. Happy is intrigued by the idea of having smart contracts govern business logic to boost customer trust and empowerment.
• Dappy is on the cutting edge, developing a fully decentralized application whose backend code runs on a decentralized peer-to-peer network. Dappy is prepared to go all-in on blockchain, smart contracts, user anonymity, and even governance.

Mappy, Happy, and Dappy may sound like Scrooge McDuck’s lost nephews, but these personas represent three types of businesses, differentiated primarily by the degree of decentralization they are ready to embrace in the near term. Knowing which of Mappy, Happy, or Dappy you are building for, and understanding the key differences between them, is critical to building successful blockchain products that gain end-user traction.

These profiles serve as more than reminders. Product managers rely upon detailed customer personas to help them understand target customers so they can tailor solutions to their needs.

Building for Mappy

• Mappy is a mainstream application with an existing user-base.
• Mappy is likely less impressed by flashy technology than by rock-solid reliability. As a blockchain developer serving Mappy, you better come with a viable scalability solution for Mappy to onboard millions of users and billions of transactions onto your blockchain.
• Mappy’s interested in blockchain technology as a means to boost KPIs like user acquisition, engagement, and retention. When speaking to Mappy, we recommend focusing on blockchain as an enabler of business results, not as a grand vision for the future.
• Mappy cares less about complete decentralization of the consensus mechanism on day one and is willing to take a long term path to decentralization. Proof of Authority may be an acceptable starting place with a roadmap to an open validator set over time.
• Mappy is intrigued by how Blockchain could be deployed to empower users with greater ownership of the value they generate through their contributions to the company’s ecosystem, greater flexibility in how they use and share it, and greater transparency on how it is distributed.
• Mappys are often interested in using Blockchain to power more open and transparent loyalty and rewards programs. They envision using blockchain tokens to reward users for loyalty and for rewarding actions and content contributions.
• Mappy is also intrigued by the interoperability potential from blockchain tokens, enabling Mappy users to earn with Mappy and seamlessly spend elsewhere, and vice versa.
• Some Mappys are turning to token economies as a way to simplify and reduce transaction costs of cross-border payments. This is particularly important for companies with users in countries that restrict cross-border money flows or struggle to support international transfers due to a weak domestic financial system.
• Mappy’s developers likely have very little understanding and knowledge of blockchain. Don’t expect them to write solidity code on their own. They’ll want Blockchain served up to them in bite-size snippets that they can easily integrate into their apps, with APIs, SDKs, recipes, and UX guidelines.
• They won’t immediately be familiar with concepts like “gas,” multi-sigs, consensus algorithms, or smart contracts. You’re going to need to simultaneously dumb it down while also helping educate.
• Mappy’s developers will need a sandbox connected to a testnet and the ability to launch betas and pilots on mainnet to a sample of their user base at minimal risk, before on-boarding large numbers of users.
• The “jobs to be done” of Mappy’s blockchain team is to prove to their bosses that blockchain can be a core differentiator to get ahead of the competition and grow their business.
• Mappy is used to web-based dashboards and mobile apps for analytics and reporting. Don’t expect to just point Mappy at a block explorer and tell them to have at it on their own.
• Mappy’s users likely have very little understanding and knowledge of blockchain. Don’t expect them to be immediately comfortable with writing down private keys, understanding what a public/private key is in the first place, signing transactions, or paying for gas.
• From a “jobs to be done” standpoint, the farthest thing from the Mappy user’s mind is how to use Mappy on a blockchain, rather they just want to continue to get joy and value from the Mappy app, without caring (yet) if transactions are on a blockchain or not.
• Mappy will be less inclined to expose their users to crypto market volatility. You’ll need to consider use of stablecoins and economy stabilization mechanisms.
• Mappy will not want to take on any legal, regulatory, or licensing risk (e.g. for money transmission or for being a custodial service). You’re going to need to help them navigate the legal landscape and in most cases take on all legal, regulatory, and licensing responsibility on their behalf. Compliance is largely national and local, so you’ll need to research and deploy a globally local legal strategy.

Building for Happy

• Happy has a lot of similarities to Mappy, but Happy’s blockchain ambitions go further, to include the creation of complex rules for the creation and distribution of value and greater “on-chain” decentralization to increase user trust.
• Happy embraces the notion of “programmable money” and decentralized markets that can reshape and drive their business in fundamental ways.
• Happy seeks to shift parts of their business logic into on-chain smart contracts that auto-execute when certain pre-programmed conditions are met.
• Some Happys want to introduce the use of tokenized digital assets onto their platforms, including non-fungible tokens that users can own and trade.
• Happy is likely to want to see a faster path to network decentralization and a decentralized consensus engine vs. Mappy. Proof of Authority may be a non-starter for Happy.
• Happy may be more blockchain ambitious than Mappy, but don’t expect most Happys to be writing directly to protocols. Happy is going to want to experiment with blockchain on-chain logic before jumping all-in. Happy will need simple web-based tools for functions such as smart contract writing and deploying on-chain logic.
• Some Happy’s see an opportunity to create centralized applications with refined UX on top of open source protocols.

Building for Dappy

• Dappy is a decentralized app running on a decentralized network.
• An open decentralized consensus protocol validates Dappy transactions.
• Dappy does not collect or retain any personal user data.
• Dappy likely has no installed base of users.
• Dappy’s developers are tuned in to the latest blockchain technologies and developers. They’re comfortable developing directly on protocols.
• It is expected that all of Dappy’s source code shall be provided under open-source license and should be available for people to see, and edit as they see fit.
• Dappy’s users are expected to be more blockchain savvy than Mappy and Happy.
• There are some expectations that the governance of Dappy overtime shall be decentralized, with users of Dappy holding the power for key decisions.
• The expectation often is that Dappy as an organization could eventually fade away and the application and network it operates on could continue to run on its own (such as Bitcoin and Ethereum do today).

Achieving Blockchain Product Market Fit

In his seminal post for Stanford University in 2007, Marc Andreessen posited that the only thing that matters for startups is getting to product market fit.

The only thing that matters is getting to product/market fit.

Product/market fit means being in a good market with a product that can satisfy that market.

You can always feel when product/market fit isn’t happening. The customers aren’t quite getting value out of the product, word of mouth isn’t spreading, usage isn’t growing that fast, press reviews are kind of “blah”, the sales cycle takes too long, and lots of deals never close.

And you can always feel product/market fit when it’s happening. The customers are buying the product just as fast as you can make it — or usage is growing just as fast as you can add more servers. Money from customers is piling up in your company checking account. You’re hiring sales and customer support staff as fast as you can. Reporters are calling because they’ve heard about your hot new thing and they want to talk to you about it. You start getting entrepreneur of the year awards from Harvard Business School. Investment bankers are staking out your house. You could eat free for a year at Buck’s.

Lots of startups fail before product/market fit ever happens.

My contention, in fact, is that they fail because they never get to product/market fit.

Carried a step further, I believe that the life of any startup can be divided into two parts: before product/market fit (call this “BPMF”) and after product/market fit (“APMF”).

by Marc Andreessen, June 25, 2007

Getting your product personas right is critical for achieving product market fit — whether you’re building tools to help a Mappy deploy blockchain tokens to incentivize and rewards their users, or the next great Dappy to redefine prediction markets, if you don’t understand who you’re building for, it’s nearly impossible to achieve product market fit.

Mappy, Happy, and Dappy have very different needs and very different internal and external user expectations. Understanding those needs and building for them is key to building apps that gain acceptance with Mappy’s, Happy’s, or Dappy’s internal teams, and then ultimately to gaining adoption with their end users.

About the Author

Jason Goldberg is Founder and CEO of OST, Open Simple Token. OST powers blockchain economies for forward thinking businesses, focused primarily on Mappys and Happys with tens of millions of users. OST’s APIs, SDKs, dashboards, wallets, and protocols provide everything businesses with millions of users need to integrate Branded Tokens into their apps in minutes. OST also leads development of the OpenST Protocol, a framework for tokenizing businesses and the OpenST Mosaic Protocol for running meta-blockchains to scale Ethereum applications to billions of users. OpenST Protocols are made available via open source for any developer or Dappy to utilize. OST has offices in Berlin, New York, Hong Kong, and Pune. For more information, please visit https://ost.com.