Frameworks for Defining Problems in Your Law PracticeMar 31, 2021
Note: This is an excerpt from the article I prepared with Kenton Brice for our 2021 ABA Techshow presentation on Slack vs. Teams for law firms. We thought the assigned topic was too simple, so we expanded it into a broader discussion of how to evaluate legal tech. This post is part 3. You can read part 1 here, and part 2 here.
How to Define your Legal Ops Problem
The business world is replete with ideas for defining problems. The most common method is the simple “problem statement,” which encourages proponents to describe the current state, the desired future state, and the perceived gap in what you’re trying to accomplish. Although this practice is good in theory, it can quickly devolve into advocacy instead of analysis. It is also easy to be too rosy in your future state predictions; in fact, the human cognitive bias known as the tells us that we humans are wired to do just that.
We prefer the following two more recent frameworks for defining problems. One, the User Story, comes from Agile project management. The other, Jobs to Be Done, was defined by management consultant Tony Ulwick and was favored by the late Harvard Business School Professor Clayton Christensen. Both of them help teams and managers to go beyond a simple statement of needs in an attempt to capture why meeting those needs is important.
The User Story
A user story is a simple but powerful framework for describing problems to be solved. Its brilliance comes from its ability to answer three questions in a single statement: Who? What? And Why?. The basic structure goes like this:
As you can see from this example, it is possible to have multiple user stories describing the same problem from different points of view. The paralegal may be more concerned with tracking contract details whereas the senior attorney might be more interested in tracking communications to gain leverage for her client. Looking at the problem form multiple points of view will help you clarify your need and quantify its impact.
Jobs To Be Done (JTBD)
Jobs To Be Done is a tool of a management approach known as Outcome-Driven Innovation. Like with user stories, it tries to answer the “why” question as much as (if not more than) the “what.” You may be familiar with Harvard marketing professor Theodore Levitt’s famous proclamation, “People don’t want to buy a quarter-inch drill, they want a quarter-inch hole.” The hole is first part of the job to be done (but the inquiry goes further—why do they want the hole?).
In the context of your communication software, you might approach your problem by asking the question “what is the job I (and my team) are hiring email to do?” By taking your inquiry to this abstract, possibly absurd, level, you’ll find that you will illuminate some of your hidden assumptions about what you do and what your needs are. Once those assumptions are in the light, you can assess and validate them in a more reflective way. That, in turn, will give you better clarity into the relative strengths and weaknesses of both your incumbent solution and its potential challengers.
Comparing the Relative Importance of Problems to be Solved
Whichever method you use for capturing your problem statements, the next step is to come up with a common set of criteria to compare the relative importance, or value, of solving each one. The obvious reason to do this is to maximize your return on investment or ROI. It is human nature to want to get the most bang for your buck when investing time, money, and effort into a particular endeavor.
- At what frequency does the problem occur?
- What is the severity of the impact on internal team members?
- What is the severity of the impact on clients or external stakeholders?
- What is the cost of the problem in terms of time, effort, or money? (and what assumptions do we make in estimating that cost?)
- What upstream factors contribute to the problem?
- What downstream factors are affected by the problem?
Once you’ve developed your matrix, use it to score a variety of problems you’re encountering so that you can compare them against each other. Some teams might do this with some sort of total impact score, others will weigh factors individually. The specific method isn’t as important as developing a common language and working with your team to develop a framework that makes sense to you.
Want to discuss how to better integrate technology into your law practice workflows? I can help. While I'm a fan of technology, I also am realistic about what it can and can't accomplish. I love helping lawyers and their teams find ways to work better, so don't hesitate to schedule a free 30 minute discovery call to talk about improving the flow of work in your law practice.
Agile Attorney Updates
Join my newsletter to be notified when I add new blog posts, podcast episodes, or other tips and tools for an Agile legal practice