Blogs

Lawyers, Video Games, and Software Product Development

By Ryan McClead posted 07-10-2017 11:47

  

I have absolutely no statistics to back this up, but I am going to go ahead and confidently assert that there is a greater proportion of completionists within the population of video game playing lawyers than there are in the video game playing population at large. 

A completionist, for those of you who are unfamiliar, is a gamer for whom winning a game is not nearly enough. Within the game, a completionist must achieve every available goal, receive every award, speak to every character, and slay every monster.  A game cannot be put down by a completionist until it has been ‘completely completed’.  Anything less is…well, incomplete.

I’m confident in the assertion above because most lawyers I know are like this in their working life, it’s how they are taught.  As a lawyer, you don’t deliver an incomplete contract, or a quickly scribbled brief.  You can’t put out a publication that is insufficiently footnoted or produce a pleading that is incorrectly formatted.  Every document that leaves the confines of the firm must be checked and double checked, confirmed to be accurate and comprehensive.  Anything less would be considered shoddy workmanship at best, and at worst, would constitute malpractice. This ‘legal completionism’ serves lawyers very well in almost every respect. However, there is one area where a completionist attitude actively works against lawyers and law firms… when they try to apply it to software products or automated services.

Now to be clear, I am not advocating for shoddy workmanship, nor am I suggesting that firms should begin willfully producing inaccurate or incorrect applications, but for lawyers and firms that are exploring client facing legal applications, you need to recognize that software is not a document and it will never meet the completionist standards to which you (quite rightfully) hold all other content that is leaving your firm.

So how do we reconcile this impasse?  How can a notoriously completionist profession move beyond the concrete and infinitely controllable world of the document and enter the complex and comparatively messy world of software without losing their collective minds?  Easy.  You have to change the rules of the game.

 

Software: the New Game

By simply deciding that you want to create a software product or automated service, you have already chosen to play a completely different game. The reality of software is that it’s not perfect. It never will be. It never can be. Still, without achieving ‘perfection’, you can produce a valuable and useful product, you just need to mitigate some of the inherent risks. This is where Design Thinking comes in. 

Now, if you know anything at all about Design Thinking, you’re probably a bit confused because Design Thinking is a method or series of tools derived from design but applied to business in the creation of new products, services, processes, or other structures. Design Thinking is not generally considered a risk mitigation strategy, but from the point of view of a law firm entering into the software product and automated services marketplace, I think that’s exactly how you should think about it.

 

Design Thinking as Risk Mitigation

 

First, let me be clear that I am not an expert on Design Thinking.  I’m merely a student, a practitioner, and a strong advocate, who has implemented aspects of Design Thinking into his working process. And while I still have much to learn, there are a few lessons that I have learned over the last several years that can help lawyers and firms as they enter into the brave new world of software development and product design.

Rapid Prototyping

If you can only be bothered to learn one thing about Design Thinking, learn to ‘prototype’.

The traditional method of technology development (in a firm) is for IT to get with the Subject Matter Expert (SME), and gather all of their requirements in exhaustive detail.  This process often takes days or weeks on its own.  Then the development team goes off for 6 to 12 months and builds exactly what they understood the SME to describe (they too are often completionists).  By the time IT comes back to the SME with a product, often the SME has left the firm. Or they’ve completely lost interest and moved on to other projects. Or IT only delivers half of what the SME expected. Or the SME is incensed because IT just plain got it all wrong, wasted a lot of time, and spent a lot of money. With a good prototyping phase, you can avoid all of those outcomes.

Rapid Prototyping is a core principle of Design Thinking.  Rather than gathering all of the requirements and spending a great deal of time trying to build a product to exacting specifications, you get an overall idea of the concept, gather some basic requirements, and build a ‘rough draft’ very quickly.  Prototypes are usually incomplete, often semi-functional, and commonly look like crap.  But they illustrate the developer’s current understanding of the SMEs vision. And if they are turned around in a few days or weeks, it is highly unlikely that an SME has ‘moved on’ in any sense.

The prototype becomes the focal point for developer and SME to discuss the project.  If the developer has wildly misunderstood the SMEs vision, very little time has been wasted or money spent, and the SME or project manager can very quickly get the project back on track.  Or maybe they decide, based on the prototype, that the project itself was ill conceived, or the technology isn’t yet capable, or the firm doesn’t have the right tools or skills to create it themselves.  A prototype is just as likely to kill a project quickly as it is to kick it up to the next level.  And frankly, killing an ill-conceived, poorly understood, or impossible project quickly is the second best outcome you can have.  The best being that the SME likes the prototype, makes some recommendations, and asks to see the next version with the new changes as soon as possible.  Which brings me to the second principle.

 

Iteration

If it is determined that a project should move beyond the prototype phase, you don’t simply go back to gathering detailed requirements and building out the complete tool, you build the second prototype incorporating any lessons learned from the first prototype.  And then like the famous shampoo instructions,  you rinse and repeat.

 

Widening the Feedback Circle

Of course, it’s not sufficient to work directly with an SME throughout this process of Rapid Prototyping and Iterative Design, at some point you need to get a version of the product in front of friendly users to solicit their feedback. Even better than asking for feedback, is to give them the product and actually watch them use it.  People will tell you one thing, and then consistently do something else. It’s always good to see directly how or where people are stumbling or hitting roadblocks as they attempt to use your product. These friendlies will always find new problems that the SME and developers would have never found on their own.

 

Beta Testing

When you finally have a product that you think is pretty darn good, the most difficult step for a legal completionist is beta testing. Beta testing is making a product more widely available to clients even though you acknowledge that it is not yet finished.  It’s incomplete.  It might (gasp) have a few bugs to work out.  While not specifically a Design Thinking tool, beta testing is an important step in the development of software and automated processes.  It takes the previous step of widening the feedback circle to a much larger client base, which in turn increases the likelihood of finding previously undetected problems with your product.  This is a particularly hard concept for many lawyers to grasp, but without a good beta test, you greatly increase the risks of finding the same bugs in a fully paid production release, which brings certain expectations of completeness that a free or discounted beta test doesn’t.

 

Conclusion

Each of these tools (Rapid Prototyping, Iteration, Widening the Feedback Circle, and Beta Testing) helps to mitigate the risks associated with developing software or automated processes. They will help to ensure that you don’t waste a bunch of time going down the wrong path, or developing a product that is difficult to use, or that clients don’t want.  But they all also require that you actively share incomplete work product with your colleagues, supervisors, management, and even your clients.

Several times I have seen great legal products get to a completed state, ready to go to market, only to put on the shelf by a firm’s technology, ethics, or executive committee that is concerned about the liability of a software product carrying the firm’s logo.  While nothing you can do will stop law firms from having extraordinarily risk averse committees, if you work through a design thinking process, you can at least counter with data that shows the processes you went through, the feedback you got, and if you’ve successfully beta tested, the praise and accolade’s you’re getting from actual clients who are willing to pay for the final product.  And nothing else sways a stubborn committee quite like, “people are clamoring to pay us for this.”

0 comments
224 views

Permalink