MyBlock Hackathon Concept
Led hackathon team demonstrating blockchain concept in financial sector
I. Context & Background
To test the viability of implementing a blockchain product at our organization, my immediate working team hosted a hackathon focused on emerging technologies. As as student of the varied and interesting facets of blockchain technology, I had read about how people were successfully using blockchain in the financial sector. With a concept in mind, I began assembling a team of interested colleagues who were bullish about the impact that blockchain could accomplish by decentralizing many of the labor-intensive business processes our company regularly administered.
Over thirty ideas were submitted for the hackathon, and twelve were selected to participate. Teams were flown to Dallas, TX, and given twenty four hours to produce a concept and prototype. As team captain, I would be responsible for showcasing our product concept to senior leaders. The winning team would be awarded $20k to begin working on the project after the hackathon ended.
II. Objectives
When deploying a future-focused technology such as blockchain, one has to be cautious about overselling its capabilities. Because we are so early in its development, there has been much speculation about what this technology can accomplish. However, speculation is not action. Ideas are only of value if they can be brought to some sort of fruition, as a vision alone is not worthy of commendation.
Therefore, I approached this competition both optimistically and cautiously. How would we develop a solution for a financial services company that was over one hundred years old? One with a mentality that often reigns supreme in its overall industry, which is akin to “don’t rock the boat.” An industry mired in hundreds of years of regulation, often standing (sometimes uncomfortably) close to the state in the level of power it wields.
The approach I directed my team to take was simple enough: solve a real business problem. Do not worry about what the soothsayers and oracles are saying. Do not focus on the hyperbolic predictions that blockchain will bring about a thousand year world peace, cure cancer, and take us to the cosmos. Just focus on identifying a business problem that we actually have, and solve for it. Provide value. Define a roadmap for future development. We were fortunate that the hackathon was relatively open-ended in its objectives. Nobody told us what we were supposed to deliver. The only thing we knew was that we were up against many other teams with bright, motivated, and knowledgeable people with equally interesting ideas.
The KPIs of the project were:
- Solve a tangible business problem
- Demonstrate using it in a pre-production environment
- Provide a rough cost analysis
- Get it done in 24 hours, with no sleep
What was my role in the project? As team captain, I had the responsibility of defining a vision and keeping the team on track. I should mention the obvious: I wasn’t a blockchain expert, and neither was anyone on the team. Therefore, I spent most of my time working with the team filtering ideas and delegating tasks. For example, there was a debate brewing between a software developer and a senior business analyst about whether blockchain was scalable enough to plug in to our legacy back-end systems. The developer was optimistic about the possibility of this and the business analyst took the opposite position. Both made very good points in their analysis, and ultimately it was my decision to make. Not knowing what else to do, I played the part of college professor and proceeded to attempt to poke holes in their logic, and encourage them to speak in the simplest terms possible. The business analyst relinquished his position on the condition that we provide adequate user testing in our lower regions before implementing a solution. Lesson learned? Leadership is tough (especially when you aren’t an expert on the subject). Lastly, it was agreed that I would present the findings of the group to a panel of judges at the conclusion of the project, so it was essential that I developed a working understanding of the concept as soon as possible.
My personal objectives were:
- Define the problem we intended to solve, incorporating real business needs
- Analyze the competitive landscape
- Delegate tasks to working team
- Solve problems as they arise
- Champion team morale
- Intimately understand the problem
- Present to our judge panel
III. Methodology
Listening to (Internal) Customers
The team and I donned our business hats and identified the most common grievances we had heard permeate the culture of our organization: slow insurance underwriting, unclear customer and associate incentives, slow claims processing, and more. Those opportunities represented the clearest use cases for deploying a novel technology where none had been attempted before.
For each of these problems we set out to define the business problem. What was the nature of it? Was it really about speed, and speed alone? What about costs? Where did revenue come into the picture? Could we expect to sell blockchain as a way to reduce expenses? Surely, it can’t simultaneously increase revenue while decreasing expenses? Even the most seasoned MBAs attempt to solve that very problem in existing businesses and come out the other end quite perplexed.
In the three problem areas we defined: underwriting, incentives, and claims, we looked at them purely through the lens of expense reduction. However, we knew that accomplishing the end goal of expense reduction would require a substantial upfront capital expense to implement blockchain. Just like the adage of “you have to spend money to make money” surfaces all too often in the corporate world, it also could be said that “you have to spend money to save money.” The business case for these ideas was strong because they identified expense reduction areas and improved the efficiency of our operations. That’s it. We did not posit blockchain as anything revolutionary. In fact, one could argue that deploying this technology to speed up insurance claims is the most anti-revolutionary thing you could propose!
We journey-mapped many internal processes at the company and interviewed SMEs across the contact center, claims, and underwriting departments. We spoke to blockchain experts in the field and calculated what the implementation costs would be for a blockchain solution. We spoke to developers and people on the front lines of implementing this solution at other organizations. In researching solutions, we pored over what industry competitors were working on, often with few discussion points. It was too new to have been used anywhere with much success. This posed a problem.
Move Fast and Break Stuff
While we didn’t have the resources available to build a full-scale solution, we did have access to a sandbox test environment that had been stood up by IT in advance of the hackathon. We knew that we could at least simulate the performance of our solution in this manner. We decided to build an information architecture model that incorporated a tokenized version of the Ethereum blockchain that would be used for processing claims. The current process for executing this process took at least eight different business teams on average a total of 21 days per claim, a staggering number that needed improvement. Our concept involved creating a token at the claim ingestion date, which would be passed then to the team responsible for identifying coverage, then on to the team who provides an estimate of the value of the claim, then on to the investigatory team (if needed), then on to the claim payout. Each step would be written to an immutable ledger which would be instantaneously accessible by any internal team requiring it, thus allowing multiple teams to work on the same claim at the same time instead of the usual “waterfall” method which my company was using.
Test and Verify
After our solution was built and validated, we began to run tests in our Amazon sandbox environment, where each of us simulated use by a respective business team. We watched in real time as pieces of tokens were appended, altered, and saved in a permanent way as each unit of work was completed. In our sample claim process, we were able to complete a claim analysis in under 35 minutes. With the proof of concept verified, we were ready for showtime!
IV. Results
Along with presenting an information architecture model that incorporated a tokenized version of the Ethereum blockchain, a working prototype, and a full set of code, we presented a 16-month roadmap to implement our solution with the prize money. When it was my team’s turn, I stepped up in front of the room and faced an alphabet soup of MBAs, JDs, and Ph.Ds, to whom I would deliver our concept. Instead of focusing on the technology; however, I focused on what the technology could accomplish. It’s a trap that people get sucked into when introducing new ideas; nobody wants to buy a new technology for novelty’s sake. They just want their problem solved, but better. It was an interesting feeling, being the leader of my team, yet having to rely on subject matter experts to augment or provide case studies in the event my technical understanding was eclipsed.
And that folks, ultimately, is the role of a product manager. We must own the problem, not necessarily the solution. I could speak at length about the nuances of claims processing, why we must improve the process, why and how customers feel neglected, and a litany of other issues around the cause for concern. Similarly, Henry Ford may have been able to articulate with incredible specificity who his customers were, why they needed inter-city mobility, where they were going, and things related to these problems. The solution happened to be an automobile, which in his day was an almost Frankensteinian collection of steel tubes, rubber bushings, and wheels, arranged in a certain way. The engineering aspects of the problem are less important than the problem itself, if indeed the goal is to be an effective product manager. At a macro level, it is perhaps fair to say that all of these problems are equally important. Alas, I do not aspire to be an engineer. But I digress…
After several rounds of discussion, presentation, and persuasion, the lead panelist looked at me and provided a response. “We like what you’ve done here,” he said, “but this is too new of a concept for us to pursue at this time.” We were rejected!
“But, how could they not see the potential?” was a common phrase heard throughout our group, as we knew the failure to adequately articulate blockchain as the solution to these problems rested squarely on our shoulders. In several candid chats with people who heard our presentation, there was hesitation to award us with the prize for one core reason: it was too expensive. New = expensive. Blockchain was deemed not ready for prime time.
Why was this so? Let me count the ways. When you factor in many of our legacy systems, regulatory issues, a lack of technical expertise, both internally and in the market at large, a lack of examples by competitors and almost no institutional experience doing such a thing, ever, it quickly made sense. Yet, I stand by what my team and I created.
V. Reflection
Ultimately, this was a battle worth fighting. The sheer chaos of formulating an entire business pitch in the span of twenty four hours was an invigorating experience. Looking back, I can’t believe how much we were able to get done with only a team of eight.
But that’s the way it goes, isn’t it? You work to define a problem, pitch a novel solution, and see if you can get traction. The business world works the same way. Any industry focused on innovation, if it is ever to actually achieve it, works in fits and starts. There is no “magic sauce,” only a methodology. And the one we applied, of defining the problem to the best of our abilities, is the best one we have. I suspect it always will be.
I’d also add that this was my first experience directly managing a team of contributors. This was a really exciting thing for me because I had previously been an individual contributor on my work teams. I had to delegate tasks, solve problems, and resolve disputes. I tried to be democratic, yet authoritative in how we arrived at decisions. What was the best part, you ask? It was at the end, when one of my teammates shook my hand and said, “Joe, it was great working with you. You are an inspiring leader.”
Having the opportunity to develop a concept and show it to our colleagues was energizing and exciting. If given the opportunity, I would do it all again.