Although fundamental product management (PM) theories like strategy, prioritization, and execution still apply, there’s new considerations for PMs building products in the blockchain space. The following is part 2 of a 3 part series discussing these considerations (you can read Part 1 here).
Working with Smart Contracts
Working with smart contracts differs from working with “traditional” code. Smart contracts are responsible for moving around people’s money, so the code needs to be airtight. If done right, developer teams will likely spend more time on security audits than on traditional teams. It’s imperative to make sure everything works as expected.
Data security breaches can be tragic, but losing people’s money opens up a whole world of pain, which can compromise your community’s reputation. Money requires trust, and without it, building a trustworthy brand is near impossible.
Smart contracts are supposed to be immutable, so once they’re deployed to Mainnet, you can’t edit the code. That means if there’s an exploit and people lose their money, there’s almost nothing you can do to reverse it. The “build fast and break things” mantra may not apply to smart contract protocols. Designing smart contracts with upgradability in mind is a possible workaround, however it can be very expensive to run given the increased complexity of the code. Other developers may design the smart contracts to enable the freezing of funds if a breach is detected, however such methods have been said to contradict the ethos of “decentralization.”
Developers should build simple smart contracts first to handle basic functions before expanding to more complex features. Also, having your smart contracts audited by a third-party is an absolute must. Although expensive, it could save your team a LOT in regard to community sentiment and money if you get hacked. Not everyone can be as lucky as SpankChain, who had their fund recovered by the hacker and actually gained a new employee in the process.
Smart contract gas fees are another thing to consider. On Ethereum (and other smart contract blockchains), users are required to pay fees in order to execute smart contract functions. As a new user, this can be a bit of a shock at first, in that most people are accustomed to using apps for free (the tradeoff being that we give away our data, of course). Gas fees can limit what you can do with your smart contracts. The more complex the smart contracts, the more expensive they become.
For example, at HelloSugoi, the first version of our smart contract protocol was built with upgradability in mind. This turned out to be quite expensive. Why? Because gas fees are loosely correlated to the price of ETH. When the price of ETH goes up, so do gas fees (network activity also affects gas; the more people using the network, the higher gas required to execute the smart contract). During the bull run of 2017, the cost of creating an event became prohibitively expensive (from a few cents to over $50). As such, we needed to refactor our smart contracts in a way that was less expensive to deploy.
Cost of computation (on such a granular level) is not something typically considered in “traditional” software development. PMs need to be aware of smart contract computation costs when designing product features and functionality.
Working with Tokens
When building a product that requires a token to function (which is few and far between), PMs need to understand how the token works on a deep level, particularly in regard to how users must interact with it. If done correctly, tokens will play an integral role in a product’s user experience, function, and design.
Different tokens require different user behaviors. For example, with token curated registries (TCRs), applicants looking to be included on a list must deposit some number of the native token. As an applicant, the quality of an application and the size of a deposit must be carefully considered, for there’s the risk of losing the deposit if token holders vote against an applicant’s inclusion on a list. A user must be aware of the various game theoretic outcomes in order to optimize their position in the registry. Sound complicated? That’s because it is (at this point). PMs will need to figure out new ways to seamlessly integrate a token in to a product’s design and function. And if it turns out there’s no simple way to to this, then your product most likely doesn’t need a token.
In the near future, I see the convergence of token engineering (TE) and PMing become an entirely new role: Token Engineering PMs. Part of this new role would involve identifying and understanding various ecosystem actors, their incentivizes, and how they interact with one another. Instead of focusing on one specific kind of user, PMs will need to understand an ecosystem in its entirety in order to properly align incentives.
At the highest level, blockchains are designed to align the interests of disparate actors to coordinate around desired outcomes in the absence of a central authority. In short, blockchains are meant to get people do to things. Tokens (utility) are simply a coordination mechanism. For example, with event ticketing, we’re not just focused on end users, we’re trying to align the incentives of all ecosystem actors: event organizers, promoters, venues, fans, artists, managers, booking agents, and vendors to produce optimally efficient outcomes while considering rational self-interest from the viewpoint of each actor. How do we reduce resale, improve distribution, and fill every seat in the venue? It ultimately comes down to identifying and producing desirable outcomes that benefit all ecosystem actors, while removing unnecessary rent seekers (brokers and scalpers).
--
Big thanks to Matt Lockyer for the amazing feedback. You can read Part 1 of this series here.
This story originally appeared on BlockchainBeach.com. You can read it at https://www.blockchainbeach.com/new-considerations-for-product-managers-building-on-blockchain-part-2/