How a Simple Shift in Perspective Transformed a Complex E-Discovery Process

Yeah, absolutely. So I was, I was working on one of the e-discovery products and uh e e-discovery product, uh, an e-discovery product. So what happened there is, uh, we were having a set of, uh, uh, product setup process. When a new case comes in, we, we ingest all the documents, and, uh, one of the products setup process for, uh, uh, a conversion process. Uh, if, if a reviewer logs in into the software and if, if he has the ability, uh, he, he has to have an ability to redact the contents online in, in the tool. So for that, what we were doing is if they were importing 1 million documents, uh, this tool will run and, uh, convert all, convert all the 1 million documents into a specified format so the reviewers can actually redact it. So what happened there is this tool was actually, I mean, it, it, it took more time and our, our, all our customers were having issues and. Uh, finishing up the setup and, and setting and giving it out for review. So, uh, what, what I did is I, I went in, and after looking at it, I went and researched, uh, our competitors and customer testimonials and gathered data from our customers. And found that the reviewers are actually not reviewing all the 1 million documents that they ingest. They, they were reviewing only 10% or at maximum 20% of the documents. So which means we don't need to actually run this process on all the 1 million documents. So our previous solutions when we were trying to fix up this problem was to Uh, scale up the solution and run it fastly and run it concurrently, and, and there were a lot of engineering solutions that came, came out of my mind. But after realizing this specific point that we don't need this to be run on all the different documents, uh, I, I worked with the product manager to see, is there any way that we can stop this process and, uh, do this on demand so this can run only when, when the reviewer needs the document reviewed. So, that, that was at the time when, when. We were actually originally thinking to solve this problem engineeringly, but through scalability and, and by faster performance, I was able to put in, uh, give, give a solution that, uh, we don't need to run this process, rather, we run it only when it is required. So that was the time when, when we had this complex problem. Uh, uh, I had to, I mean, I, I gave a very simple solution, which resolved a lot of pain points for our customers and for our engineering team.

Sure, absolutely. So, uh, what happened is, uh, previously, when, when, uh, a customer buy, buy our product and Import 1 million data. He had to wait for about 2 weeks, sorry, not 2 weeks, 2 days to actually run, let this reduction process run on all the documents. Now he doesn't have to wait that time. He can quickly finish off the setup process and give it to his reviewers. So this improved the turnaround process for our customers, uh, quickly. It, it, uh, it's, it reduced about 50% of the setup time for our customers whenever they get a new rediscovery case. Uh, to work on, so.

Mhm.

Absolutely. So, uh, the key input was, I understood that there was this customer pain point. They had to wait 2 days to actually start their real work on the product. Uh, uh, I had to do, uh, I, I, I did multiple customer research and found that, uh, this is, we, we were doing something very redundant. So, uh, the key, key insight for me would be to actually realize what, what our customer really wants and whether we are doing, uh, that. Just that, or we have any assumptions about, uh, uh, or, or are we doing something redundant that is not even needed by them. So, uh, I had to, uh, constantly look for that customer pain points and then see whether we are solving it in a very effective way. So that, that was a key insight I gathered from this, yeah.

Yes, so one of the first solutions that I thought of was, uh, rather do it on demand, uh, a customer could actually view a document and then tag it, uh, to a tag, and then later, whenever he needed to, uh, he, what, what he essentially has to do is the reviewer will have a different, uh, user experience. He will just view the document and tag it for reduction, and later he can use the tag to redact all the documents. Uh, together. So that was the first thing that I thought of, but that would change the way the reviewer has been working for so long. Uh, whenever he reviews the document, he has to have this ability to redact right away. So that was the first solution that came to my mind, and that was the first thing. I mean, after thinking out sound about what our reviewers do and, and what do they need, I, I rejected that solution first.

Yes, yes, OK.

Yes, so, uh, when I tagged, uh, the thing is, uh, we were actually making all the document converted to this vector form, so user can redact it on the flight whenever they do it. Uh, but since we don't need it, uh, I just tag the document whenever I find a content. I just tag the document into a ret, a new tag, and then I'll select all the documents that I needed to redact and then tag it to it. And later I enable the process to run on only the tagged documents and come in and then look for it again and then go through the documents again to redact whatever I needed to on the documents. So it was like sort of duplicating the work our reviewers have been doing. So, yeah. OK, fair enough.