Brighthive - (Legal) Product Development

# Brighthive - (Legal) Product Development |[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 Distbute*** ## 0. Background Successful (Legal) Product Strategies will be mindful of the various legal considerations that exist for a given product. From this point of understanding, it is then possible to develop a (Legal) Product that modularly packages legal knowledge for known and anticipated use cases, improving trust in the product itself and reducing uncertainty that is associated with legal nuance. In order to realize this opportunity at BrightHive, it will be helpful to analyze the existing inventory of projects and workstreams for legal issues and then research the possible ways such work can be refactored as part of a more holistic and comprehensive vision. ### a. Inventory Taking an inventory of the existing products, personas, processes, and procedures is done in order to ensure organizational continuity and efficiency. In the context of understanding the (Legal) dimensions of ap roduct, this means that products can be grouped based on similar (Legal) requirements in order to ensure work is neither duplicative nor inefficient in utilizing individual or organizational effort. *Inventory* *Data Services with Login to monitor services and view data and collaborators and stuff. * 1 - Data Resource API (configurable REST API and we'll manage as many as you want) * 2 - Data Pipeline Manager - ETLs, Pipelines, Moves Data, AirFlow Thing * 3 - Actual ETLs we will write for you, which are orchastrated by AirFlow * We will timebox this with X total hours per month or per year PLUS EXTRA if needed * 4 - Monitoring and Logging * 5 - Authentication (and Authorization) * 6 - Master Clients Index - assignes IDs and de-dubplicates (Add-In "Ask Us" for pricing) ### b. Mapping out Project Workstreams After the (Legal) dimensions of a product are accounted for, the next step toward developing a (Legal) product is to map out the processes for each product, accounting for the personas executing a process and the specific procedures that are required. This step will ensure a comprehensive understanding of all of the processes required by a product and also serve as way to identify alternative, adjacent opportunities to harmonize existing product workstreams with (legal) product workstreams. ### c. Research For the issues identified in the mapping excercise that require legal insight and invite new opportunities to package the product in a way that is efficient both at the product level and the legal level, the next step is to research possible ways that legal knowledge/expertise can be engineered into a comprehensive product workstream. The deliverable of the research workstream should be a series of blueprints or outlines for a product, a list of specific legal requirements at each stage of the product, and preliminary metrics by which to evaluate the potential success of a prototype. Once these things are accounted for, the next step is to put all of this knowledge into action by building a prototype. ## 1. Prototype Building a prototype is not as much of a linear process as catalogging an inventory of a product. Where catalogging an inventory is a set of discrete tasks, developing a working prototype can continue through cycles of iterations until a product is ready to be implemented. ### a. User Stories After there is a set of blueprints, legal requirements, and metrics for a possible prototype, the next step is to get feedback on how different designs sound to the key stakeholders who will actually be using the product to make sure the incorporation of the (Legal) aspects of a product do not unnecessarily disrupt the product workflow or fail to account for important considerations. These user stories will then continue to be adapted based on the demo, testing, and feedback that happens during this cycle of product development. ### b. Demo Once a set of user stories has been developed, it is now time to actually build the prototype. When building a prototype, it is important to remember that this is a fluid process -- it might not ever get to be exactly perfect. As such, prototypes will often ### c. Testing & Feedback Testing and feedback play vital roles in the prototyping process, completing a circle between the idea phase, the user feedback, the creation of a demo, and the evaluation of that demo against measurible criteria and feedback from key stakeholders. ## 2. Implementation Implementation is the stage where a product goes from being an idea and disconnected from a product to the product itself. Implementation usually requires coordinating with engineers or developers, creating a testing environment where the prototype can be engineered into the broader context of the product, the development of internal on-boarding criteria, and identifying the times and metrics by which the product will be evaluated. Implementation will adhere to the blueprint set out in the background phase and should be updated while developing the prototype. These blueprints should be further adapted in order to account for a higher resolution of detail with regard to the way the (Legal) product aspects are actually implemented. This attention to detail will make it easier to i) deploy a (Legal) product with an API, ii) update the (Legal) product for new context and circumstances, and iii) lead to a more complete and interoperable vision for additional (Legal) product development. The implementation process should include various levels of testing before a product should be deployed. ## 3. Deployment The principle aim of the Deployment phase includes developing the framework by which the (Legal) Product actually becomes available for purchase. There are several discrete tasks that make up this process. Internally, before a (Legal) Product can be successfully deployed, it will be necessary to create cheat-sheets that answer new questions about the product. Cheat Sheets force Legal Subject Matter Experts to distill knowledge into appropriately sized pieces of information that ensure healthy and accurate communications among all product stakeholders. Such materials can include Frequently Asked Questions and can be adopted as there is more and more feedback about the product. Externally, there will need to be changes that are made to the organization's website, notifying customers about the new (Legal) Product offering, as well as some publication of materials associated with the (Legal) Product. This could include blog posts, API specifications, and any other features seen as being helpful for the broader public to better understand the current state of the product. ## 4. Adaptation Once the product is deployed, there should be methods and mechanisms in place for providing feedback on performance, usage, and analysis of the extent to which the product is actually performing as desired. From there, it is possible to modify the product/metrics as required based on these observed performance standards. Then, as changes need to be made, this entire process can be repeated to the extent that it is necessary. In the case of products, the goal should be the journey. By adhering to the steps laid out in this document and following through with them, it will be ensure the product is fit for-purpose, the implementation does not mess up other contingencies, and the product is adapted to new and changing circumstances. ------ # Recommended Reading Alex 'Sandy' Pentland - *[A Perspective on Legal Algorithms](https://law.mit.edu/pub/aperspectiveonlegalalgorithms)* Richard Susskind - *[Expert Systems in Law: A Jurisprudential Approach to Artificial Intelligence and Legal Reasoning](https://onlinelibrary.wiley.com/doi/epdf/10.1111/j.1468-2230.1986.tb01683.x)* Thibault Schrepel - *[Law and Technology Realism](https://law.mit.edu/pub/lawandtechnologyrealism/)* ------- |[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)| |--|--|--|--|