Frameworks for Defining Problems in Your Law Practice

improve your productivity law practice technology legal project management Mar 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 Optimism Bias 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 a _______, I need to be able to _______, so that I can _______.

If you prefer a framework with more of a Mad-lib set of prompts, you can think of it like this:

As a [user role or position], I need to be able to [perform some task or set of tasks], so that I can [accomplish some goal or outcome].

When describing a user story, specifics are your friend. Narrowly-defined problems often suggest simpler solutions. And simple solutions tend to be far less expensive (in terms of time, money, and effort) then big-bang solutions. Agile project management places a premium on small, actionable problem-solution sets for another reason as well: shorter implementation timelines accelerate feedback loops, meaning that you will be empowered to make course corrections without over-spending on time and resources only to learn you’re not on the right course. Think driving a boat, not launching a rocket.

If the problem your team encounters includes the forked email conversations we described in the introduction, then your user story might go something like this:

As a transactional paralegal, I need to be able to see conversations about a deal in a single chronological stream so that I can track which terms have been agreed-to and which are still in negotiation.

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?).

For purposes of defining a problem within your practice, the key question is simple to express yet complex to answer: “What is the job that I (or my team) am hiring a product or service to do?” (Note that there is a slightly different version of the question that is useful for defining your own products or services where the subject of the question is your client or customer).

In his MBA courses, Professor Christensen used the real-world example of a time his team was hired to help McDonald’s sell more milkshakes. He approached the problem with the humorous-sounding question, “What is the job a person hires a milkshake to do?” We won’t recount his story but we encourage you to watch him tell it himself.

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.

Less obvious, but equally important, is making sure that you are not just solving a problem that will create what Lean practitioners call a “localized efficiency,” meaning something that might improve a small part of an overall workflow without helping the overall system. What’s worse, localized efficiencies in upstream parts of a workflow can create additional pressure on downstream bottlenecks and cause even more turbulence or delay.

Put another way, you not only need to make sure that you’re solving the right problem, you need to solve your problems in the right order.

For quantifying problems, we recommend a simple matrix of questions you can ask and answer for each. You’ll want to determine what factors are most important to your team, but elements to consider include:

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?

How you answer each question will depend on the availability of data or other measurement sources, but don’t let the absence of detailed data dissuade you from trying to quantify the problem. Objective data is helpful where it is available, e.g. "this particular problem causes our paralegals to spend an additional 30 minutes processing each transaction and we handle 50 transactions per year, therefore we can recover 25 additional person-hours if we solve it" (again, be wary of your natural optimism bias when making these calculations).

In the absence of objective data, or even in compliment to it, you should consider capturing subjective information as well. Perhaps by using a common 5-point scale to capture a team members frustration around a particular 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