Build. Learn. Invest. Iterative Capital

We are a global financial technology firm offering liquidity services to the emerging digital currency markets.

Bitcoiners Can Build Better Products By Using This Process

Bitcoin may be a superior settlement network, but new infrastructure needs to be built before it can work as a global financial platform for business and individual use. Isolated as it is, the network is still immensely valuable, but the value is yet unrealized. That value can be captured by the first firms to successfully productize the network for next-generation enterprise use.

The core of productization is an understanding of process as it is seen in the venture-backed startup world. Ideas are a dime a dozen, and prototypes are easy enough to hack together. This post doesn't address ideation, but rather how to iterate once you've got users on a prototype, and you're trying to get into a cycle of iteration and improvement towards product market fit.

Why Discuss Process?

Building software is a process. Hiring for an engineering role is a process. Creating a permissions policy is a process. Businesses live and die by the efficacy and standardization of their processes.

The product design process enumerated below is just one possible implementation; there are lots of ways to make software. How one arrives at the process is called "process design," and it can be formal or ad-hoc. In this article, I make an argument in favor strictly formalizing the process into repeatable, well-understood cycles.

But first, let's discuss the nature of process design, and how to think about it in your own business.

Scoring

Process design is the "scoring" of a series of human interactions in the attempt to achieve an overall performative act – think of the scoring of an orchestral piece and its subsequent performance. The process of scoring can be employed in product and service design, too.

You set out upon four stages in the design of any process, which we can summarize with the acronym RSVP:

  • Resources. Assess the people and tools at your disposal. Who is available and what can they do well with the implements and services on hand?
  • Scoring. Arrange the people and tools into a series of intermingled processes which produce a whole.
  • Value-action (ie., coming together and making decisions). Where there are differences of opinion about the way to score, take a generative-difference approach and add more than you leave out. Unnecessary steps will become obvious once in action.
  • Performance. Carry out the score; that is, complete the process and see what kind of end result you get!

Software product development is process, whether consciously designed or not. In Bitcoin and cryptocurrency communities, development-specific processes are extremely well-understood, but design process – which can be applied not just to products but to the company as a whole, and to the process of making processes itself – is scarcely discussed. Until the "Bitcoin industry" has companies like Airbnb, it will remain a niche network. That designer-founded company brought human-centered thinking to the forefront of Silicon Valley culture in 2008, by showcasing its power to create two-sided marketplaces using nothing but commodity technology (ie., AWS).

How to Think About Process Design

The important thing about process design generally, wherever you employ it in your organization, is that it not be goal-driven. Lawrence Halprin, the American designer and architect who originated The RSVP Cycles (outlined above) as a design practice, wrote of "community planning" (think: company or user-group planning) in 1969:

One of the gravest dangers that we experience is the danger of becoming goal-oriented. It is a tendency that crops up on every hand and in every field of endeavor. It is a trap which goes like this: things are going poorly (in the realm of politics or religion or building a city or the world community or a personal relationship or whatever). As thinking people we must try to solve this problem that faces us.

Let us set ourselves a "goal" upon which we can all agree (most goals after all are clearly moralistically based and incontrovertibly "good ideas"). Having set ourselves this goal we can then proceed posthaste to achieve it by the most direct method possible. Everyone can put his shoulder to the wheel, and systems engineering, technology, and our leader (or whatever) will get us to the agreed goal.

It doesn't work! The results of this oversimplified approach, now coming into general vogue, are all around us in the chaos of our cities and the confusion of our politics... Human community planning cannot ever be a science anymore than politics can rightly be called political science...

We can be scientific and precise about gathering data and inventorying resources, but in the multi-variable and open scoring process necessary for human lifestyles and attitudes, creativity, in-quantifiable attitudes, and openness will always be required. There is a difference between being idealistic, which is life-oriented and process-oriented, and Utopian, which implies a finite and formal goal. In that sense, scores are non-Utopian.

The score is the mechanism which allows us all to become involved, to make our presence felt. Scores are process-oriented, not thing-oriented... scoring makes the process visible.

On that note, below we enumerate our score for product development. We won't go through the entire RSVP cycle here, just the output (ie., the score) which as Halprin says, "seems to me the key link in the entire RSVP cycles," and the one most open to interpretation (and thus in need of explaining).

Before we talk about our product development score, let's first define the conditions that indicate you need to score a product development process. Generally, within a small team of developers and designers, with a small or medium-sized active user base, you'll find:

  • Everyone has a lot of new ideas for the product, including users
  • There are competing visions for what the product will become long-term
  • Various economic opportunities exist adjacent to the product and need evaluation

How do you prioritize what to build and when?

Crafting Value Propositions

Value propositions are a theory about how people will extract value from your product or service. "Value Props" are hypotheses which you are constantly trying to prove or disprove with data analytics and ethnography. One of the value propositions of our Escher platform is that we make it easy for developers to build apps and services on Bitcoin, with instant BTC:USD built-in.

Value propositions are meant to be doubted and tested. Often times users are doing something you don't expect with your platform. You'll need to talk to users and collect analytics to determine what's really going on. Once you have an idea, you can help users be even more successful at their tasks. The ideas you and they have for increased success – whether features, database changes, documentation additions, or other engineering and design tasks – should all be expressed in value propositions.

Turning Value Props into User Stories

A user story is a description of a value proposition in action. All ideas and feature requests should eventually be scrutinized and rewritten as user stories. They are generally written in the following format:

User wants to do action in order to achieve goal.

An example from the Escher platform might be:

An Escher user wants to connect a bank account in order to pay a Lightning Invoice.

Accomplishing that story may require elements of design, engineering, marketing, and customer support. That's why it's important to think carefully about each user story and the work it will require to accomplish. As we collect our ideas, we try to keep these user story cards comprehensive and descriptive, and discuss their finer points in the card's comments.

Quarterly Product Planning Meetings

As time goes on, collect your team's and users' ideas, in the form of user stories, as cards in a Trello board called Roadmap. Once you have a bunch of them, gather your designers and engineers and conduct a roadmap planning meeting. Here's how these meetings should go:

1) Assign each user story card an owner. The owner is not the originator of the idea, they are the person who will end up having to implement the idea. Generally, this person is an engineer or a designer. We use Trello labels to make it easy to distinguish visually between engineering and design cards.

2) Create three lists in the Trello board: Small, Medium, and Large, and sort each card into a list based on the manhours it will take to implement. Small cards should be about 2 hours; Medium about 8; and Large 24-36. Any card that seems like it will take more than 36 manhours, break down into a few Large cards. We use Labels to mark cards S, M, or L.

3) As a team, prioritize the cards based on your internal needs and the urgency of your users' requests. Priorities can vary from unblocking some major feature, to satisfying a big customer, to fast-tracking a profitable new interaction. We tackle prioritization holistically, considering sorts of all user stories at once. The reason for this is time: everything we build comes from the same 24 hours in a day. So, we strive to get our work queue as "single file" as we can, to be able to estimate accurately when we will be able to ship features. We begin to achieve this by creating four (4) lists for each category, for a total of 12 lists:

  • Small Priority
  • Small Next
  • Small Backlog
  • Small Ideas
  • Medium Priority
  • Medium Next
  • Medium Backlog
  • Medium Ideas
  • Large Priority
  • Large Next
  • Large Backlog
  • Large Ideas

4) Break down the Mediums and Larges into Smalls. Do this by clicking on a given Medium or Large card, and creating a Checklist. Next, list out all the parts of the implementation, in full sentences, with each item taking about 2 manhours. Make special note of dependencies on other teammates or components. At the end, you should now have three big consolidated lists of all Small cards: Priority, Next, Backlog, Ideas.

5) Lastly, break out all these cards into personal boards (eg., mine is called Chris) which have the same Priority, Next, Backlog, Ideas structure. Because each Small card is about 2 manhours of work, expect each team member to get through 3-4 cards per work day. If they're crushing more, then either their estimates are too easy, or they are cruising for burnout. Adjust accordingly.

Next, we will plan a building and design sprint to put a big dent in all these new cards.

Planning Sprints

Sprints generally last two weeks and allow engineers and designers to work hard in healthy cycles that prevent burnout. The other two weeks of the month are used for ideation and preparation, which creates a nice seasonality. A typical month looks like this:

Week 1: Sprint planning

Week 2-3: Sprint, ship, deploy, test

Week 4: Collect user feedback and squash bugs

This is where it pays to have broken down the Big, Medium, and Small cards into Smalls. The product manager can easily estimate what work can be done in each two week period, and during spring planning, can discuss with the CTO any implementation details that might need to be brought to the attention of the engineering team. This way, we know what we're getting into when the spring begins.

As You Build, Keep in Mind...

In general, it's best to empower people closest to the work to solve implementation problems that don't effect other components. Major architectural decisions do, however, require extensive group discussion. It's best to rap about these sorts of things with the relevant specialists outside the product meetings.

It's also worth noting that what the designers mock up gets built. Because product designers are on the front lines, charged with creating true product-market fit through iteration and feedback loops, they hold a keystone role in the development process. Each time a new major new feature, component, or line of business comes into existence, use a kickoff meeting to make sure they understand the impetus behind the initiative.

Conclusion

The Bitcoin network is an incredibly powerful tool, but only if it is made accessible with an easy-to-use application layer. We hope this guide assists your team in adding more useful products and services to the Bitcoin world.


H/T to investor Aaron Schildkrout, who taught me this process in 2013.

Recent

Load More