Applying Legal Design Thinking to the Software Development Process
Legal compliance for technology startups can be overwhelming. GDPR, CCPA, HIPAA, SOX, PCI, NIST — with so many long acronyms covering so many different legal frameworks, it can be hard to keep track of what applies to what, and become easy to fall into the trap of thinking you’ll deal with it later. But that can result in big technical and legal debt down the road that inhibits a startup’s growth very quickly. There is a middle road — applying legal design thinking from the beginning allows companies to innovate while at the same time choosing a legal framework for their software that meets customer needs and ensures business success.
For most of my legal career, I’ve helped software and technology companies integrate legal compliance into the product development process. Startups and even mid-to-late stage companies spend so much product development energy on proving the use case that fundamental questions about operability and compliance often get pushed to the side. But with a few sensible tweaks to the development process, taking operability and compliance into account in parallel with the use case can actually propel proving the use case. Design thinking, agile software development, and legal design have all contributed to the way I reached this conclusion.
Design Thinking is about forming a question about what is the human need behind creating a business solution, doing research, generating ideas, testing whether those ideas work through gathering feedback, and then incorporating those learnings back into the ideas. The pioneering design studio IDEO identifies 4 ways to get started with design thinking: (1) gather insights by practicing empathy, observation, and interviewing, (2) build scrappy prototypes to learn about unmet needs, (3) turn problems into questions, and (4) use research to understand the past, present, and future. It’s a combination of what’s desirable from a human point of view, economically viable, and technologically feasible.
There are many different flavors of agile development, but they generally focus on: (1) iterative, incremental and evolutionary cross-functional teams working in design sprints, (2) co-location of team members to reduce cycles, (3) short feedback loops and quickly adapting to changed circumstances, and (4) continuous integration and other tools that lead to high-quality code that leads to a highly-stable product. During my career as the lead attorney for the pioneering agile software development company Pivotal Labs and the lead intellectual property attorney for Pivotal Software, I had the privilege of working and learning from some of the best software engineering teams ever assembled. I watched them use the best of agile development and open source software to lead Silicon Valley into a new way of developing software, and learned how legal can best fit within and complement those processes. Our engineering teams’ goals were to make better software, designed to solve real problems and taking user needs into account throughout the development process. It was true human-centered design based on test-driven development. By the end of my time with Pivotal, compliance was fully embedded into that process.
The term “legal design” is relatively new (and rapidly changing), but at its core it’s about combining design thinking, agile software development methodology, and legal methodologies to develop user-centric solutions and innovations. While frequently attached to access to legal services, it has recently expanded into things like smart contracts, easy to understand policies (think about looooonnnnngggg privacy and data protection policies) and making the legal system more based on how people think.
My flavor of legal design was born out of my experience with agile software development and involves a lot of trial and error working with hundreds of software engineers. Taking legal compliance into account throughout the development process was not where I started, but it was where I ended because there was no other choice or way to keep up with how fast the agile teams were building software.
Typical software product development efforts can be categorized into 3 buckets: (1) use case, (2) operability, and (3) compliance.
This is what most people think about first when it comes to a product – what is the product goal, what are the functions and features of the product, the kinds of essential things you test in an MVP plan to ensure that there’s a product/market fit.
This is the question of the nuts and bolts you need to support that product – DevOps, system, cloud, Open Source software management, security, the environment in which the product is going to work, integrations, APIs, etc.
This is where legal generally fits into a traditional product development process. It’s highly context-dependent, e.g., a product for elementary schools may have COPPA issues, a hospital may have HIPAA issues, a bank may have PCI compliance issues. It can include things like security reviews, internal policy compliance (e.g., what are “acceptable” open source licenses may depend on whether you’re distributing the product or not), or pen-testing.
These 3 issues don’t necessarily overlap in the places where you’d expect, i.e., similar products could have completely different answers for (2) and (3).
My general process in handling legal support for any new or ongoing product development:
1. Start at a high level with team discussions – given (1) the product’s use case, (2) the operability requirements, and (3) what are our compliance obligations?
2. Rank the compliance issues based on their risk and consequence and cost just like use case requirements are prioritized on their value and cost – what are the core risk issues versus incidental risks (for example, storing sensitive data may be a high compliance issue, whereas storing usage data without personal information might be a less sensitive issue).
3. From an intellectual property (IP) protection standpoint, work with the teams to help them understand and identify what are the novel innovations that we should protect.
4. Given everything learned through (1)-(3) discussions:
1. Prepare a legal roadmap of the compliance issues that may affect product development and vet/refine that with the teams.
2. Provide training on what compliance and IP issues are involved so that we can all level-set. This would include training for the leadership layer (team leads, those that are more involved in the decision making), and training for individual contributors (doing a crash course training on compliance and other legal issues so that people are generally aware of the issues that we all agree are important).
3. Have regular meetings with key people in leadership to make sure that we can adapt as things change, and keep the flow of information and awareness going back and forth between legal/developers/leadership.
4. Put a few check-in-with-legal type mechanisms during the development cycle (or I directly track the development backlog) so that legal is not a barrier to continuous development and delivery (catch every potential issue early vs. later).
Generally, I’ve found that the product development energy is on the use case, operability is thought about late, and companies often only think about legal/compliance when they get burned by an issue. The general idea here is to have issue (3) [compliance] become part of the product discussion – thinking about compliance as part of the product vs. something that may be orthogonal to the development. And then to constantly iterate based on the changes in product direction and changes in the law (CCPA, for example). These are true principles of agile development, and contrary to the common belief that legal principles are too expensive to pay attention to in the beginning. To the contrary, building these principles into the software development process turns out to be not only the right thing to do from a principle perspective but also the cheaper thing to do in the end, as building compliance in after the product is hardened can cause a lot of unnecessary costs and pain to remediate.
One of the greatest benefits of the software development tools being developed in the past 10 years has been to free up developers from the commoditized parts of the development process and focus on building products focused on user needs. That freed up time can be used to create a software development methodology that brings legal and compliance in from the start.