Brighthive - (Legal) Product Background

# Brighthive - (Legal) Product Background |[README](https://hackmd.io/@b4wLC1CbS2SjN3JrULd69w/SyfvPQ9IP)|[BACKGROUND](https://hackmd.io/@b4wLC1CbS2SjN3JrULd69w/H1w3U6QUw)|[STRATEGY](https://hackmd.io/@b4wLC1CbS2SjN3JrULd69w/ryNSSz-ID)|[DEVELOPMENT](https://hackmd.io/@b4wLC1CbS2SjN3JrULd69w/ry8SiLj8w)| |--|--|--|--| > ### ***Private: Do Not Distribute*** This (Legal) Product Overview is intended as a preface to the [(Legal) Product Strategy](https://hackmd.io/@b4wLC1CbS2SjN3JrULd69w/ryNSSz-ID) document and establishes a better context around some of the features that help distinguish a Product Strategy from (Legal) Product Strategy and some insight into how to build (Legal) Products. ## 0. Why legal needs to be considered as part of a Product Strategy As a company that works to build data collaborations, the product offerings at BrightHive in and of themselves are of a legal nature. The act of sharing different types of data is one that is governed by different laws and statutes. These laws and statutes generally regulate the sharing of different types of data in a way that is not dissimilar from the `if, then` conditional. All this means is that `if` certain types of data are shared between parties, `then` certain legal requirements must be adhered to. > [name=dazza]maybe back away from making it all exclusively about "if-then" loop to consider additional/different conditionals Looking at the process wherein a data collaboration is realized, the legal aspects of the process have proven to be a hurdle that slows down the process. The legal aspects of this process are an inefficiency, costing time and money and potentially resulting in liability. And while failing to adhere to these legal requirements can result in costly fees, fines, or penalties, the right approach can turn the process of responsibly sharing data into one that transforms its legal nature from a liability and a cost center to a benefit and a value center. Currently, BrightHive is at a crossroads with the opportunity to become a company that sells a product with little administrative overhead and a highly scalable way to reach customers. One key insight into unlocking this new source of value is connecting the features of the product itself with an interface that is not only scalable at the technical and business levels, but also at the legal level. ## 1. Examples of (Legal) Products While innovation has been slow to take hold in law, the development of standardized/boilerplate language has been an example of data-driven thinking in the legal space. The Uniform Commercial Code is an early example of how legal professionals have attempted to become more efficient by creating a set of uniform rules that serve as gap-filler provisions and will be inferred in the absence of express contract language. This sort of boiler plate language is a helpful starting point in understanding how to begin thinking about law, legal processes, and legal operations as system rules and data that can be incorporated as part of a product offering. The concept of boilerplate language overlaps heavily with more familiar concepts, including expert systems, decision trees, guided interviews, or set-up wizards. The simple `if-then` conditional demonstrates why (and how) legal logic can be baked into business and other operational thinking. With boilerplate language, the thinking is: `if I want to deviate from any standard terms` ` then I must select alternate language` By extending this notion of the `if, then` conditional a little bit further, there is a path to understanding how BrightHive might develop a Legal Product strategy. The following diagram shows a basic approach toward developing more sophisticated professional products ![](https://i.imgur.com/1SogCAg.png) *source: https://www.javatpoint.com/expert-systems-in-artificial-intelligence* The following examples demonstrate how this type of thinking can serve as the foundation for more harmonized legal product offerings. > [name=Dazza Greenwood]Can we specify this a little more in terms of BH roles and customer roles? ### a. Creative Commons License Scheme > #### *Key Insight: a fully integrated Business/Legal/Technical architecture can unlock opportunities that each of business, technology, and law would be unable to achieve on their own* The Creative Commons License Scheme best visually demonstrates the thinking required to address business and technical problems in a way that is compliemented by legal expertise. ![](https://i.imgur.com/d1xEydc.png) *source:https://creativecommons.org/licenses/* The Creative Commons License Chooser then goes a step further by showing what the end result of this sort of thinking is something like this: ![](https://i.imgur.com/0nSJq64.png) *source: https://creativecommons.org/choose/* Individuals who want to license one of their work select among a range of options for how such content can be licensed and then the appropriate license is automatically selected. The interface of the licenses themselves are built using a technical standard, the [Creative Commons Rights Expression Language](https://wiki.creativecommons.org/wiki/Ccrel), a human readable layer that represents obligations using a combination of images and [plain language text describing the obligations under each license](https://creativecommons.org/licenses/by/4.0/), and [legal code](https://creativecommons.org/licenses/by/4.0/legalcode) in the form of a longer form contract. ![](https://i.imgur.com/5oZ2dYU.png) *source: https://creativecommons.org/licenses/* ![](https://i.imgur.com/3Dr821L.png) *source: https://creativecommons.org/licenses/by/4.0/legalcode* This example provides, perhaps, the most robust overview of the ingredients that are required for developing a legal product strategy. However, there are additional examples and use cases that can provide some specific insight into how BrightHive can go about doing this for additional use cases, including data sharing and data governance. ### b. Data Protection Expert Systems > #### *Key Insight: privacy rights and obligations can be visualized and compared using expert systems, and rules can be developed to automate notifications when data privacy liabilities are created* ![](https://i.imgur.com/2Sv1e2E.png) *source: https://www.dlapiperdataprotection.com/* ### c. RiskGenius > #### *Key Insight: legal products must be designed based on continuous feedback and testing done by the actual legal end-users of the product* After law school, I worked at a start-up called RiskGenius that uses AI and Machine Learning to augment the work of insurance professionals using digital tools. As such, much of the work we did was related to the approach of unlocking the value of insurance professionals, underwriters, and legal counsel by making it easier and simpler to find and understand that information which was most important to them. <iframe width="711.1111111111111" height="400" src="https://www.youtube.com/embed/nWYpRULmM1w" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> *source: https://www.youtube.com/watch?v=nWYpRULmM1wU* This anecdote demonstrates the need to work with the end-users of the legal processes, often general counsel and others, as a key input to developing a legal product. Several product offerings that we had developed over the years based on our thoughts and understanding of what could work were later shelved in favor of products that were informed by the thoughts and understanding of the people using our product. Further, in looking back at the development of expert systems from earlier in this document, this also implies the need for legal experts to help ensure the legal product that is built is fit for purpose. ### d. DoNotPay > #### *Key Insight: one successful implementation of the Business/Legal/Technical approach can lead to the development of a whole ecosystem of products* DoNotPay has come up with some of the most sophisticated legal product offerings in the suite of offerings they have on offer. Among the things a user of DoNotPay can do are fight parking tickets, automatically sue robo-callers, obtain a stimulus checks, and terminate free trials. ![](https://i.imgur.com/RnCqDUr.png) *source: https://donotpay.com/* Perhaps the biggest reason DoNotPay is able to effectively deliver this amazing array of legal products is because of their comprehensive knowledge of the entire landscape. Their app to fight parking tickets was released for free, provides individuals fighting their parking tickets with a list of points to argue in front of the judge based on a series of answers they have provided, and has been used to fight over 250,000 parking tickets, successfully defending over 160,000 of these cases. Once this insight of scaling legal knowledge was unlocked, DoNotPay went on to develop addition apps. Their app to automatically sue robo-callers registers you on the DoNotCall registry and provides users with a "burner" credit card that is used to get the payment information from robo-callers in order to file a lawsuit against them. Their app to obtain stimulus checks required users to fill out information and then automatically faxed these requests to the IRS and came back faster than those filed directly with the IRS online. While the features of these apps demonstrate an intense focus on the user experience, they importantly reveal what can be accomplished by a comprehensive knowledge of all of the processes involved in accomplishing the major goals of each app. > [name=Dazza]NOTE: Email Service: https://donotpay.com/email https://www.forbes.com/sites/curtissilver/2020/10/07/donotpay-launches-donotpay-email-so-you-dont-have-to-pay-via-email/?fbclid=IwAR1l-7moUP4iqkAPufuZ1aMZA3KV7vPICkldMLMEIirLw_UAnpJrBsVyboo#73fe20452b97 > [name=Dazza]also link to Carta (https://carta.com/pricing/) as a second example of integrated B/L/T offering that leads to the creation of a legal-tech product ecosystem ## 2. Product Augmentation The BrightHive Business Strategy Memo (Memo) indicates that a self-service product offering would be aligned with a Freemium app model (e.g., one tier for a limited, free product offering and additional tiers with additional features for additional cost). From the Memo, we also know that the points of differentiation with competitors includes the following: |Domain| Point of Differentiation| |--|--| |*Technology*|1) simplifying knowledge graph and ontology management, 2) novel trust architecture, 3) modularity, and 4) ensuring interoperability and third-party integrations. This also provides some helpful axes upon which the map of the vision & mission for BrightHive can be charted. |*Service Design*|1) specialization by focusing on multi-party service engagements, 2) complementarity in service offerings that allow BrightHive to partner with larger professional service orgs, 3) integration of BrightHive's services with unique features of the core platform |*Partnerships*|1) effectively building a value-added ecosystem around BrightHive's solutions that rely on the platform and framework for delivery, 2) landing initial trusted partners that lend credibility and weight to our brand, 3) vetting partners so that being part of our partner network is a valued market signal of quality. Analyzing these goals in light of the opportuntity to transform legal processes in the product workflow from static to dynamic, there are some exciting opportunities. Accomplishing these goals does not require anything too extraordinary or complex. As the above legal products have shown, many of the principals for developing legal product systems are similar to processes commonly found in software development and ui/ux engineering. For example, there is a specification of performance goals, measurement and evaluation criteria are set, there is testing to determine when something is ready to be deployed, the system is adapted based on its performance in the real world, and this progress is continually audited and fine-tuned in order to ensure nothing falls through the cracks. In order to properly ensure these principals are met, it is important to keep in mind the key insights derived from the examples listed above. |Key Insights| |--| |A fully integrated Business/Legal/Technical architecture can unlock opportunities that each of business, technology, and law would be unable to achieve on their own| |Privacy rights and obligations can be visualized and compared using expert systems, and rules can be developed to automate notifications when data privacy liabilities are created| |Legal products must be designed based on continuous feedback and testing done by the actual legal end-users of the product| |One successful integration of Business/Legal/Technical approach can lead to the development of a whole ecosystem of products| In addition to developing a legal product strategy (i.e., a strategy to ensure that legal demands are more effectively met), it is important to a) get feedback from key legal stakeholders (including both the users of the product and the domain experts who can ensure the design is efficient), b) break down legal obligations into a set of requirements that can be triggered by the occurrence of certain events later on, c) these triggers and the subsequent notifications are full integrated with the rest of the product, and d) the system is one that is modular, adaptive, and can be interoperable for any new data sharing use case that BrightHive seeks to undertake. > [name=Dazza Greenwood]characterize b and c as cool stuff BH can do once it has more legal tech capacity, down the road. The areas where these impacts will be felt the most are in the creation and administration of the BrightHive platform, the ability to onboard new clients and partners, and in the design of subsequent services. Continue to the Legal Product Strategy for information about how these insights will be operationalized. ----- |[README](https://hackmd.io/@b4wLC1CbS2SjN3JrULd69w/SyfvPQ9IP)|[BACKGROUND](https://hackmd.io/@b4wLC1CbS2SjN3JrULd69w/H1w3U6QUw)|[STRATEGY](https://hackmd.io/@b4wLC1CbS2SjN3JrULd69w/ryNSSz-ID)|[DEVELOPMENT](https://hackmd.io/@b4wLC1CbS2SjN3JrULd69w/ry8SiLj8w)| |--|--|--|--|