The hardest part of building blockchain networks is not configuring the technology; it is designing the rules of the road for how ecosystem partners will work together to achieve their goals. In one word, the hardest part is network governance. Governance design is the design of strategic and operational models aligned to member benefits that are fair, democratic, transparent and evolving.

From our experience launching dozens of successful blockchain networks over the past several years, we developed an approach to blockchain network design that includes activities across three main workstreams: governance design, business value design and technology design. Most often, these workstreams are intertwined and inextricably linked. For example, designing the incentive model to both engage and retain members through business value design is dependent on defining the types of members and their roles through governance design.

As a governance design leader, I am frequently asked how our methodology applies across various types of networks. The most common question is, “How would our governance strategy change if our blockchain network is led by one organization (a founder-led network) versus if we were organized as a consortium including representatives of many organizations (a consortium-led network)?”

Learn why IBM is the top-ranked blockchain for business services provider

Is governance even needed in founder-led networks? In brief, my answer is yes, governance is relevant across both types of networks, but in varying degrees.

Exploring the need for governance

I often hear the perspective that founder-led networks do not really need governance because there are not multiple entities involved. For example, in founder-led networks, a single entity typically owns and operates the network, making many of the consortium-based considerations around governing board structure, voting rights, equity privileges, and others, not particularly pertinent. Other governance topics like operating model, data standards, and product development may also seem irrelevant.

From my experience, the same governance principles are relevant in both founder-led and consortium-led networks, but they are applied in different ways at different levels of significance. In fact, founder-led networks need to have a heightened focus on certain governance topics that arise more naturally within consortium-led networks such as how to invite network members to provide feedback on network strategy and roadmap, how to design the network to maximize potential member adoption, as well as how to clearly show members the benefits they can expect to derive based on the data and resources they contribute to the network.

To illustrate the need for governance in founder-led networks, I’ve developed the following case study for a fictional coffee company highlighting common patterns — based on lessons we have learned from multiple blockchain engagements — that can be avoided with governance design.

Brew It Coffee Company is committed to sustainability and wants to provide its customers a mobile app that allows them to scan a QR code on a bag of coffee beans and see its product journey from farm to shelf, in addition to a Brew It Sustainability Score. Brew It is building a founder-led blockchain network to enable its supply chain partners to share relevant shipping information across the ecosystem with the goal of increasing visibility and transparency to the end consumer.

Operating model

Brew It initially designed its operating model to only include their own employees since it’s a founder-led network. The challenge was that upstream suppliers were not convinced that their perspective was being considered when designing the network. Brew It did not have enough convening power nor a compelling incentive model to encourage upstream suppliers to join the network. The network launch was delayed as the company considered different options to increase adoption.

Brew It amended the operating model to include an advisory council with elected representatives of each major membership group (including growers, millers, logistics providers, and others) that would provide perspective and non-binding votes on major strategic topics. The company also designed a clear process for member feedback on topics like product roadmaps, geographic presence, and others. Following these changes, adoption rates increased.

Data standards

Brew It carefully designed a data schema to be flexible enough to track product across all supply chain partners. Their challenge was that upstream suppliers did not want to change their existing processes in order to populate Brew It’s schema. Brew It’s proof of concept application functioned perfectly with mock data and simulated partners, but as soon as they started integrating with real supply chain partners and real data, the system broke down and their first product release stalled.

Brew It solved this by conducting stakeholder research interviews with relevant supply chain partners to understand their data practices and learned that significant rework was necessary to update the solution. Brew It had to wait for the next budgetary cycle for additional funding. Brew It added a data standards working group to their operational model which included representatives across member types which will revise and update the data standards on a periodic basis.

Product development

Brew It developed its product roadmap without any input from key stakeholders since they own the network and drive its strategic direction. They decided to de-prioritize user accessibility and location-specific features until future development releases in order to deliver a minimum viable product with limited scope. The problem is that Brew It’s headquarters is in the United States and assumed their users would be mostly English speakers. Brew It’s main suppliers are headquartered in Colombia and Ecuador because of the supreme quality of their product and unparalleled dedication to their craft. Brew It’s suppliers’ primary language is Spanish although they are conversational in English and they encountered problems when trying to use the app.

Brew It updated their development by delaying their upcoming product release and increasing the number of development sprints in order to add language options to the app. They also publicized both their high-level product roadmap and feature prioritization criteria to their target members and provided a clear channel for member feedback. In addition, they now hold quarterly product roadmap brainstorming sessions that are open to members to share ideas and collaboratively build the roadmap together.

Taking the next step

The Brew It case study showcases a few examples of why governance is still relevant for founder-led blockchain networks. There are a multitude of additional considerations when designing and launching networks. Networks that prioritize thoughtful governance design early save significant time and money when bringing their ecosystems to market.

Our experience growing blockchain networks across a wide range of industries, geographies, and regulatory environments has allowed us to identify both the common patterns and the nuances required for bringing enterprise business networks to scale.

Accelerated by our operational and commercial frameworks in addition to our technology assets, our clients are moving faster and more competitively than anyone else in the market.

Won’t you join us? Let’s see what we can solve together.

How to get started with IBM Blockchain now