# Brighthive - (Legal) Product Strategy

|[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***

## 0. Overview
The following is intended to be read following the [(Legal) Product Background](https://hackmd.io/@b4wLC1CbS2SjN3JrULd69w/H1w3U6QUw) document. This (Legal) Product Strategy provides an overview of different templates used to develop a product strategy.

In general, a Product Strategy should be comprised of the following components: 1) a Product Vision & Mission, 2) Personas, 3) Product Metrics, and 4) a Product Roadmap. The way the components are organized, however, is something that can take a number of different forms. Below are some examples of different available models around which a product strategy can be developed.

|[Model 1](https://www.myproductroadmap.com/products/strategy027)| [Model 2](https://www.pinterest.co.uk/pin/566679565603405846/)| [Model 3](https://www.slideteam.net/setting-product-strategy-ppt-powerpoint-presentation-gallery-infographics.html)| [Model 4](https://blog.hubspot.com/service/product-strategy)|
|---|---|---|---|
|Problem|Market Needs|Key Attributes|Vision
|Solution|Corporate Goals|Business Model|Customers
|Offering|Features & Innovation|Price Positioning|Business
|Channels|x| Market Positioning|Competitors
|Revenue|x|x|Macro
|x|x|x|Roadmap

## 1. Product Vision & Mission: Toward Self-Service Data Collaborations
The Product Vision & Mission set out to define the big picture of what BrightHive is aiming to achieve.

> ***Mission: BrightHive aims to build a product that enables trustworthy, efficient, self-service data collaborations***
> [name=Dazza Greenwood]Let's reference the existing BH mission.

The BrightHive Business Strategy Memo (Memo) indicates that this product offering will follow the 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 us to partner with larger professional service orgs, 3) integration of our services with unique features of BrightHive core platform
|*Partnerships*|1) effectively building a value-added ecosystem around our solutions that rely on BrightHive's 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.

Accordingly, there will need to be a harmonized `business`, `legal`, and `technical` architecture. For example, the `legal` specifications -- those methods that enable `legal` to be integrated with the `business` and especially the `technical` -- must be in line with BrightHive's plan to develop the knowledge graph and ontology management, as well as the overarching trust architecture. With the `legal` and `technical` requirements serving as the core protocols by which a data collaboration takes place, different interfaces can be built according to these protocols and based on a specific set of user roles to help with modularity, multi-party engagements, complementarity, and integration. Notifications can be delivered to such parties in accordance with their obligations as they change over time.
> [name=Dazza Greenwood]Develop a list of "core legal protocols" (e.g., notice)

## 2. Personas
Personas for the legal product strategy are broken down by type and include Customers, Partners, and BrightHive's internal team. Many of these personas for a legal product strategy are known and would not be different from a traditional product strategy. However, there are some key areas that need to be addressed and those are included at the end of each subsection.

### a. Customers
The Memo indicates that ideal customers are B2B, medium and large enterprises and organizations with relatively high data maturity with strong internal/external incentives for cross-enterprise collaboration. The Customer Personas can be divided among Learning & Work, Public Sector, Social Sector, Health, Insurance, and Supply Chain Management. Specifically, among the Customer personas that will need to be dealt with are the legal teams for each customer type.

A more mature (Legal) Product could verify or prove that the legal architecture that BrightHive has is functioning as stated. Such a verification tool could be built using rules built on top of a distributed architecture that logs changes to the knowledge graph of the various data collaborations. An interface to help the legal personas for each of the customer types might include a verification rule that shows which laws or regulations are associated with a data collaboration (e.g., FERPA, HIPAA, etc.) and a list of auditable records that can be randomly checked for validation. Another feature that would be helpful for these personas would be notifications that are sent out, in accordance with the rule, for instances of non-compliance.

### b. Partners
In line with the goals of the Memo, Partnership personas include consulting and professional services outfits. To aid in their ability to build a value-added ecosystem around BrightHive's platform, it will again be useful to make the functions that Partners deal with easy to understand, deploy, and update.

Accordingly, this means the onboarding processes for deploying a data collaboration must be well-defined, modular, and adaptable based on a history of the most frequently used models for a data collaboration, and also interoperable enough (with APIs and the opportunity for customizations) that these type of Partners can develop an ecosystem of their own products to build on top of the BrightHive platform.
>[name=Bryan Wilson]maybe revisit this
>[name=Dazza Greenwood]maybe gloss over this because it is largely prospective in the existing strategy. This will need to include some concept of cooperatition with the partners, in some cases.

### c. BrightHive
[BrightHive's existing team structure](https://brighthive.io/brighthive-team/) substantially completes the roles that would be required to deliver a legal product. The critial persona that would need to be accounted for in this structure, however, is specifically for someone who can validate the legal architecture as it relates to the technical and business architecture. While much of the functionality described and specified in the previous sections and subsections, having a person with a substantial knowledge of the interconnections of legal rules with the design of business and technical services is going to be the critical piece missing from the BrightHive team page.

## 3. Product Metrics
A list of metrics for the overall success of BrightHive are outlined in the Memo and are meant to assess the overall health of the BrightHive platform ecosystem. For the BrightHive Legal Product Strategy, the metrics that can be used to determine the overall health of the legal product might include the following:

> [name=Dazza Greenwood]Let's tighten up these criteria a little more.

|Metric|Evaluation Criteria|
|--|--|
|*Elements linked to Knowledge Graph*| Percentage of the .JSONLD schema that are accounted for in legal architecture|
|*Elements represented in API*| Percentage of the legal components represented in an API|
|*Clauses*| Number of clauses stored in GitHub|
|*Templates*| Number of templates that specify popular/pre-defined use cases |
|*Rules & Regulations*| Number of different laws accounted for (e.g., FERPA, HIPAA, etc.)|
|*Notifications*| Number and Type of Rule notifications that can be sent out to the parties of a Data Collaboration|
|*Noncompliance*| Number of infractions, duration of infractions, cost of infractions, and Rules & Regulations associated with the infractions|
|Net Promoter Score| How much do legal product stakeholders and users like working on/with the product?

It is anticipated that this list will be updated and adapted based on feedback from the different stakeholders and users of the legal product. However, this list of metrics could be used to set and evaluate KPIs and certain thresholds could be set for use as OKRs.

## 4. Product Roadmap
In seeking to improve the modularity of legal functionality for the BrightHive platform, the BrightHive (Legal) Product Roadmap, itself, will be as a series of components. Each Stage is broken down into a discrete task.

|Stage|Description|
|--|--|
|*Introduction*| Provide broad introduction to the concept of a Legal Product and generate interest internally by identifying areas of growth for BrightHive teammembers|
|*DTA 2.0*| Map the `legal` version of the DTA to the `business` version of the DTA (e.g., plain language w/ icons)|
|*DTA 3.0*| Map the `legal` version of the DTA to the `technical` specifications of the .JSONLD schema
|*Atomize Clauses*| Each clause for DTA 2.0 is represented as a file in a GitHub repo that will be used to assemble different DTA configurations later on|
|*Configure Templates*| Configure templates (e.g., lists of the different clauses required for DTAs in different domains) for basic use cases of each Customer Persona (e.g., Education and FERPA, Healthcare and HIPAA, etc.), starting w/ those that are current and working up to those that are underway, as well as different Data Collaboration Types (e.g., Trustee-less, Collaboratives, Exchanges, Trusts, etc.)|
|*Build Notifications*| Configure custom notifications that go out to the parties of a DTA each time a Data Collaboration is updated|
|*Build Composer*| The Composer will automate the lifecycle of the DTA process|
|*Build Analytics Panel*| The Analytics Panel will provide insight into the functionality of different DTAs by enabling queries of the knowledge graph + an overview of the actions that have taken place in each Data Collaboration|
|*Develop Compliance Modules*|Use data management, analytics, and notifications as a way to track and report compliance for regulatory requirements like access logging and consents within specific domains (e.g., HIPAA, FERPA, etc.)|

> [name=Dazza Greenwood]Check especially the last two with Tom re how this plays with what Engineering Team is already up to.

After the completion of each of these discrete tasks, there will be a minimally viable legal feature set that is able to meet the goals of building a product that enables trustworthy, interoperable, and legally verifiable self-service data collaborations.

## 5. Next Steps
My proposed next steps for work on the legal product strategy include 0) getting feedback on this draft, 1) identifying the different individuals that could help accomplish the task identified in each of the different stages of Legal Product Roadmap, 2) developing a more robust Legal Product analysis in .ppt format using one of the models listed above, and 3) developing additional educational materials that will aid in helping individuals with onboarding to the (Legal) Product Team.
> [name=Dazza Greenwood]This section may be best as an email as part of a transmittal letter w/ the draft attached.

------------------
|[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)|
|--|--|--|--|