{"id":4853,"date":"2018-08-28T17:00:05","date_gmt":"2018-08-28T21:00:05","guid":{"rendered":"https:\/\/abovethelaw.com\/?p=511192"},"modified":"2018-08-28T17:00:05","modified_gmt":"2018-08-28T21:00:05","slug":"build-measure-learn-repeat-as-necessary","status":"publish","type":"post","link":"https:\/\/abovethelaw.com\/legal-innovation-center\/2018\/08\/28\/build-measure-learn-repeat-as-necessary\/","title":{"rendered":"Build. Measure. Learn. Repeat as Necessary."},"content":{"rendered":"

\"\"In last month\u2019s article<\/a> we discussed the Diffusion Curve, the difference between the early market and the majority market, and the idea that new products or services have to \u201ccross a chasm\u201d (a phrases borrowed from Geoffrey Moore<\/a>) to reach mainstream adoption.<\/p>\n

This month, I\u2019d like to build on that discussion with a focus on adoption of solutions within the legal markets. Technology adoption concepts are applicable to both law firms and corporate legal departments \u2013 and within both, the idea of crossing the chasm applies equally to external (e.g. commercial) and internal (homegrown) applications. Unfortunately, the bleak reality is that most new products or services do not work. An article in Fortune<\/a> pegs that number at a staggering 9 out of every 10 startups fail. As an entrepreneur myself, I can attest that crossing the chasm is hard<\/em><\/strong> \u2013 much, much, much harder than most people believe.<\/p>\n

So where does this leave an intrepid legal innovator in the law firm or corporate legal department? For those looking to build or implement innovative new solutions, the good news is that there\u2019s actually a science to the pursuit. It\u2019s still a difficult endeavor, but a little bit of structure and know-how dramatically improves the odds of success (and likewise limits the time and money you spend on ideas that will fail).<\/p>\n

Before discussing what works, let\u2019s take a quick look at how IT solutions have historically been built. We live in a world today where computing power (and storage) is abundant and the tools for building (and testing) such solutions are easy to use and abundant. It was not always so; several years back, programmers didn\u2019t even use something you\u2019d recognize as a computer. They built their programs using punch cards (see Figure 1 below for an example) and then manually fed the cards into the computer in order to run the program.<\/p>\n

\"\"<\/p>\n

Figure 1: Computer punch cards<\/em><\/p>\n

Not only was the process of creating a program time consuming, but getting time on the computer was also costly. As a result, programmers would carefully verify and lay out all aspects of the design before starting their work. This methodology \u2013 known by IT professionals as \u201cwaterfall\u201d because the project moved linearly without changes from start to end, like water going down a waterfall \u2013 was the accepted standard for IT projects for many years. Projects themselves would last for more than a year, culminating in a \u201cbig reveal\u201d at launch.<\/p>\n

While the waterfall methodology was effective, it also had several issues:<\/p>\n