To recap: designing a blockchain financial product is mechanism design, applied to financial products. This is distinct from designing a token economy, and the design sprint process I lay out below is not intended to be a guidebook for those kinds of systems. (Talk to people like Tarun at Gauntlet, instead!)

Instead, what might a binancial product design sprint look like? Adapting GV’s design sprint process looks like it might work, but with 2 major caveats:

  1. Defining the “How Might We”s to solve a particular problem can often feel like deciding on a feature set for the financial product. But when the features of products (like having perpetual risk) are so intertwined with the mechanisms needed to coordinate among the 3 types of parties, does it make sense to decide on features so early in the process?
  2. How do you conduct a design sprint, building a prototype and testing a financial product in 1 week, when the metrics of success are usually trading behavior that can only be observed with “real” money on the line with a baseline level of volume?

On the first issue, I propose turning the “How Might We” process into a brief goal-aligning session to explain why the financial engineers are in the room in the first place. Do you really want to create a new financial product for your project, and why? Is it something your users want or need, or would its existence serve as a stepping stone to help them achieve their goals? For example, if you’re building a checking and savings product, your “Mom and Pop” users aren’t going to trade interest rate swaps themselves, but they would certainly help you (or your banking partner) manage the interest rates paid to them!

On the second issue, let’s change the metrics of success, then. I would argue that a blockchain financial product will behave successfully in the “real world” if all counterparties, market makers, and arbitrageurs understand its features and its mechanisms. The more quickly they understand the product and how it “should” trade, the more quickly the product will trade that way. To that end, the important thing to test about your financial product is whether your users understand what it is.

With that in mind, below is my proposal for how you’d run a “binancial product” design sprint. I’d love to practice implementing this with binancial engineers from other projects – please reach out if you’re interested!

  1. Defining “How Might We”s to agree on why a new financial product is needed.
  2. Brainstorming the list of desired behaviors/outcomes that we want the financial product to have.
    1. Some ideas: perpetual risk, fungible risk across counterparties, decentralized risk creation
  3. Making a map of the participants in the financial product’s ecosystem
  4. Interviewing experts to brainstorm different mechanisms that could be used
    1. Lightning demos of existing financial products that have similar mechanisms or behaviors
    2. For each of these existing financial products, fill out a “token utility canvas” listing desired (and undesired) behaviors. Use dot voting to decide on which behaviors are most important.
  5. Drawing linkages between the participants in the financial product’s ecosystem based on the proposed mechanisms
    1. Voting on which linkages are most important
  6. Making prototypes and mockups:
    1. Here’s where you have some discretion. My suggestion? Make marketing content that explains how the financial product works. This could be a blog post, slide deck, tweetstorm, or poster.
  7. User testing: Show the content to 5 users, and ask them questions to assess whether or not they understand the product. I like the idea of selecting 5 users, from amateur to expert, to test how simply you’ve explained the product, but you could also select 5 users that have a level of prior knowledge commensurate with your expected user base.