Recouping Time and Money in Supply Chains
ConsenSys partnered with Ernst & Young and Microsoft to tackle an ambitious global supply chain issue. All three companies had a hypothesis that blockchain could solve the 2 shortcomings of Electronic Data Interchange (EDI) which are 1) the inability to support syncing up multiple parties and 2) no common business logic between the same parties.
The project was mostly focused on one area of the supply chain process with an open mind to create a scalable solution that can apply to other areas of the supply chain as well as other markets outside of the supply chain with similar problems. The supply chain use case was codenamed “Radish34” and eventually lead to the Baseline Protocol which has created an enormous buzz in the supply chain community.
Role & Duration
Lead Product Designer
Team of 4 Executives, 14 Engineers, 1 Product Manager, 1 Project Manager
July 2019 – March 2020
Supply Chains lose billions of dollars due to value leakage caused by discrepancies in how each computes contract data between partners. Since they use separate systems of record to account for the same transactions, their records are often inconsistent leading to substandard outcomes. A basic substandard outcome being over or under-pricing, but it can be numerous issues depending on the complexity of the contract.
In order for the Ethereum ecosystem to become relevant and profitable by the end of 2020, Ethereum has to prove itself as a trustworthy asset for Enterprise companies. Most notably, it needs to prove that a user can make secure and private transactions on the main Ethereum network and that this solution is far more valuable than the SaaS applications already available.
We created a new set of technologies and business processes that utilize advanced cryptographic techniques against the Ethereum main-net that guarantee consistency and auditability of shared data. We indeed proved blockchain capabilities to be a viable connection between disparate systems and acts as a source of truth. The solution was released as an open-source project and is governed by OASIS, encouraging entrepreneurs and engineers to improve upon the initial work.
The Baseline Protocol has drawn an incredibly large following with 14 companies initially signing on as supporting founders. That number of supporters plus maintainers and adopters has grown exponentially. The success of the project has lead ConsenSys to new contracts with some of the largest Fortune 500 companies. Ernst & Young has also adopted our demo user interface into their product OpsChain.
I was the sole “designer” on the project. I planned and facilitated strategic and tactical activities, from idea generation to execution. Along with facilitating, I also had a major role in researching, conceptualizing and evaluating ideas and then turning them into a tangible product concept that we could validate. Below, I have broken my activities performed into categories.
- Market & Process Research
- Stakeholder Interviews
- Kickoff Activities
- Service Design Blueprint
- SME Interviews
- Target Market Interviews
Ernst & Young had been working on a supply chain solution prior to meeting with ConsenSys. Their top executive already created an outline of what the product should do. The blueprint had a lot of “the what”, but didn’t have a lot of focus on “the why”. It also conflicted with some of the goals of ConsenSys. We had planned to meet in New York City in a week to have a kick-off meeting and set the direction.
Prior to our kickoff meeting, I took a week to dive into case studies on supply chain and understand industry leaders and types of resources are already available.
Along with market research, I also took an Udemy course to familiarize myself with the supply chain process, language, and the tools used so that I can ask more informed questions.
I held virtual 1-on-1 meetings with all of the major stakeholders to understand their roles and how decisions affect their area/team along with their vision of the problem and business objectives.
I ran the first day of our Kickoff Workshop between the three companies. Most of the team did not know each other, so I started with an icebreaker exercise. I reiterated the exercise of what success looks like and what failure looks like, but with the entire team. As mentioned, there were large personalities in the room, so I opted to have them individually write down their answers on sticky notes. I would use those notes to demonstrate how everyone’s vision differed and that we needed a decision-maker to set the intended outcome and align the team to a shared vision.
Service Design Blueprint
Also during the kickoff meeting, I hung up a service design blueprint that I created based on the Ernst & Young executive’s initial outline. The service design blueprint is a combination of a user journey and systems architecture. The user journey maps what a user is trying to accomplish from beginning to end. The system architecture aligns with the user journey and describes what a user will interface with (Front Stage) and what technology is used to make that happen (Back Stage). The goal was to show the scope of the project, align on user problems, see what drives these processes today, reveal dependencies, and point out which part of the process we can greatly improve upon. I also wanted to point out steps that were missing so that we understand the whole customer experience lifecycle.
Subject Matter Expert Interviews
Ernst & Young and Microsoft made their supply chain experts available to me. A few of them work directly with a majority of the Fortune 500 and had incredible insight into their day-to-day and the problems arise in the industry. Most of them told me what I needed to build, so I used a laddering technique (or 5 Whys) to get to the root of the problem they think that solution will solve.
Target Customer Interviews
Along with insight, they also provided me with access so that I could contact real customers and ask them follow-up questions and get more detailed examples of their process and the problems they have encountered. This would continue throughout the project as we hit certain milestones.
From these interviews, I put together a general persona focused around procurement officers. I also spoke to Supplier Sales people and Carrier Logistics that I included in the narrative, but not the focus. The end result was eventually tailored to be more attractive to a CTO and Engineering Lead as we found that these are the people that would ultimately look at our product and make a decision.
I like to start every project with a Mural board that we can collaborate on and refer back to. I find these great to reflect on as we get deeper in the weeds and start to lose our “why”. It helps get the discussion started and show where there are gaps in our knowledge.
The first statements on the board are “The Purpose of the Project” and “What We Believe”. I like to demonstrate when project goals are too heavily focused on the technology and not enough on customer goals. These make terrible products. “What We Believe” is always
Another important question to ask is what needs to be true in order for this to be a success. The items in this column will need to be sussed out quickly before wasting time working on a solution that is destined to fail.
Personas are also listed out and how we might meet their underserved needs. It also notes our competitive advantage.
As mentioned, I took everyone’s input on what would be a successful outcome and what would be a failure. They were all over the place, a little fluffy at times, and we clearly weren’t aligned. I held a session and designated a decision-maker to make final calls on success criteria and how we measure if we were successful.
Minimum Feature Set
From the success criteria, we defined that we needed to focus primarily on 2 users on different systems, setting business logic rules and that logic keeping those separate systems consistent. Those transactions would be on Ethereum main-net but needed to be executed in such a fashion that only the intended parties can see the business logic and data.
There were a lot of unknowns in that small use case, so we started with a few spike sprints to research our riskiest assumptions. Our riskiest assumptions were (1) that we could hide transactions from unwanted eyes on the Ethereum main-net. (2) Our next risky assumption would be that leaders in supply chain would care and adopt this method. It had to be significantly more valuable.
The next step was to run a series of quick workshops or design sprints to quickly get ideas out on the table. The outputs were a series of mind mapping exercises, messy whiteboard sessions, quick sketches and eventually the makings of a coherent solution.
I like to use Google Ventures’ 5-day Sprint method, but often modify it to appease executive schedules and folks that are uncomfortable with or unwilling to share ideas. The goal is to get everyone participating and sharing their thoughts. I want everyone leaving these sessions to understand what a user is trying to accomplish and have ownership over the solution.
The process starts with loose mind-mapping exercises to get everyone’s monkey brain jotting down ideas on paper without withholding any thought. I encourage ridiculous. We start with the end in mind and think of all the ways we can possibly accomplish this goal.
2 elements needed to be addressed on this project. One being the actual task of building something relevant to solve supply chain value leakage. The other element was the task of making sure what we build resonated with the target audience and was easy to adopt.
As shown with the service design blueprint, we already had an initial vision of the user flow from executives. We were now zooming in on specific areas that we prioritized and loosely whiteboarding how that experience would work.
Storyboarding is similar to user flow, but with a little more visual context that tends to help with alignment and memory. I also start to add bits of potential user interface elements along with questions posed to the engineers of how these systems work.
The team collaboratively sketched out ideas of potential user interface ideas and how the development may be implemented. Along with Ui elements, I also like to participate in sketching out my understanding of engineering.
Once we have shared agreement from the sketches on direction, I quickly put together some wireframes for the interface. I started with a small screen view and prioritize features and expand out to larger screen views.
Once our wireframes have been vetted and approved, we moved on to prototyping.
While creating the prototype, I further refined the design and created a design system of reusable parts. Anything downstream changes can be modified across the prototype with one edit.
While working on the prototype and showing customers, it became clear that demo was somewhat of a boring, stripped-down supply management tool. Customers were not understanding the impact. The team decided to reformat the prototype into a walkthrough. This worked well. It also helped the development team that came on late to understand why we’re building elements in certain ways to assure they made sustainable engineering decisions. Prototype HERE
Once we had our repo opened up and functioning with some of our modular pieces working, we invited CTOs and engineers to take a look under the hood. We also had the walkthrough prototype to share. Once again we contacted our intended customers and asked for feedback on what we had produced.
I wrote up a testing protocol for what the team wanted to learn about our target audience. I used both the GitHub repo and the walkthrough prototype as more of a talking platform than a usability test. We were interested in what CTOs and engineers thought of the concept. Without code, they were leery to listen theory, but now that we had an open repo of working code, they were far more intrigued. The team also wanted to know how willing they were to partner up with us and share engineers to refine the code. The received an overwhelming response to this and it’s helped us further the project and tailor it to the customers’ needs.
Once we had positive responses from our select group of users, it was time to see if we could attract a larger audience. We branded the Baseline Protocol, set up a press release, a gitbook explainer, a social media marketing plan, and some other networking outreach strategies.
It seems odd to “brand” a protocol, but this has actually helped attract members to the community and make it a recognizable entity across our marketing channels.
The branding process came in a few stages. First, I used my apple pencil and iPad app, Proceate, to doodle out potential designs quickly. Then I moved into Adobe Illustrator and played around with what I deemed the best options. I also played around with typography. In the next step, I presented 4 options in black & white to the stakeholders. There was agreement that they liked lowercase but wanted me to explore further. I created 3 other lowercase options and presented them to the stakeholders. 1 was selected. Finally, I explored color variations and the stakeholders chose their favorite.
The inspiration for the final choice was that I see Baseline being a foundation layer that other companies can build their stacks on top of. The logomark also looks like a square-ish “b”.
Keeping in contact with users. Put up chat system to talk to people interested in the Baseline Protocol. Updating Content
As mentioned, we created a new set of technologies and business processes that utilize advanced cryptographic techniques against the Ethereum main-net that guarantee consistency and auditability of shared data… Aaaand people did care and were very excited about the protocol.
The User Interface
The user interface I worked on with the team for our demo walkthrough is now being adopted by Ernst & Young in their next iteration of OpsChain. They featured an MVP of the user interface at the EY Global Blockchain Summit on April 21, 2020, which streamed to over 8,000 viewers.
The Baseline Community
The repo received over 300 stars, 80 forks, and sparked a whole lot of conversation on Reddit, Twitter, Slack, Discord, and Telegram. There are over 500 members in the Baseline community. It’s been great having those platforms for folks to reach out to us and tell us what problem they believe this protocol could solve for their business. We are able to collaborate with these people and help them expand on the concept to fit their use case.
We also hold office hours weekly and connect with folks that interested in implementing the Baseline protocol. We post these meetings on our YouTube channel.
Teams continue to expand on the tech stack provided and collaborate with us for guidance. Most notably a team from Unibright, Provide and Envision Blockchain collaborated around the Baseline protocol and made connecting data from an SAP system to a Microsoft Dynamics 365 system a reality. Watch their demo here.
The buzz around the Baseline protocol and the use cases presented have created new deal flows for ConsenSys and as notable partnerships (that I’m not allowed to discuss. sorry.).