with Larry Jin — VP of Product, Docusign
Hosted by Shamil Malachiyev · The Founder's Code
VP of Product · Docusign
Larry Jin is VP of Product at Docusign, where he leads product management for the platform area: integrations, workflow capabilities and enterprise products. He joined about five years ago, as the company built Intelligent Agreement Management and its Iris AI engine.
He started as a software engineer, spent about seven years at Microsoft as one of the early product members of what became Microsoft Teams, then worked on conversational features for Amazon Alexa. That adds up to close to 15 years in product management, most of it turning hard technology into products people trust.
Larry Jin, VP of Product at Docusign, explains how AI tools win adoption inside large companies: a value-effort-risk calculus, contracts as the killer LLM use case, and why agents now solve problems that 12-to-18-month CLM projects could not. He opens Season 2 of The AI Floor.
Select a chapter to play the episode from that moment.
They win by balancing three things: the benefit a person gets, the effort they have to put in, and the risk of it going wrong. Larry Jin calls it the mathematical calculus behind every adoption decision at Docusign. Tools like Gemini and Glean spread because they sit inside work people already do, the suggestion appears in the document you are writing, and you stay in control of whether to accept it. Worst case, you reject the change, so the risk stays low while the time saved is obvious. The same logic explains why Claude took off through coding: the IDE developers already lived in became the delivery vehicle. Asking people to learn a new tool and change their behaviour at the same time raises the effort side of the equation, and that is where rollouts die.
"I think about the mathematical sort of calculus for whether someone does something: what's the benefit I'm gonna get, versus the effort I have to put in, versus the risk of it going wrong? And it has to balance out." — Larry Jin, VP of Product, Docusign
Rollouts stall when a company asks people to change everything about how they work on day one. Jin's rule from Docusign's own internal journey: you cannot roll something out brand new, demand new behaviour, and expect success. You have to find incremental paths to value. He splits internal AI into two buckets. The first is company-wide, function-agnostic productivity tools, where trust comes from suggestions a human can accept or reject. The second is function-specific tooling for engineering, sales, marketing and legal, where the same methodology applies: start with low-risk, high-value, repeatable tasks that already sit in the flow of work, then expand. Anything that acts on someone's behalf, the way agents do, is a much bigger leap, and teams have to build up to it rather than jump straight there.
Because the value trapped in signed agreements dwarfs the signature itself. Jin describes the pivot as a natural progression rather than a light-bulb moment: Docusign spent years watching customers lose economic value inside what he calls a digital filing cabinet of PDFs, hundreds of thousands of contracts nobody could query. A question as simple as "what do we owe under this new regulation" meant legal teams manually opening documents and hoping Control-F found the right word. Customers had accepted that this was just how it works. Intelligent Agreement Management, launched a couple of years ago, uses AI to turn those documents into structured data models out of the box, covering the whole lifecycle: creation and negotiation before signature, and search, obligations and renewals after it.
Because LLMs solved natural-language understanding, the one thing that had kept contracts out of reach. Companies applied traditional machine learning to contract understanding for years: specialized models, trained on corpuses of contracts by big teams of data scientists, that could pick out key dates and values reasonably well. Then general-purpose models arrived and matched most of that with no specialized training at all. Jin compares it to his Alexa years, when the devices, distribution and use cases all existed but the intelligence had not caught up; contracts sat in the same latent state. A contract is ultimately words two parties agree to, which makes the domain a killer use case for LLMs, and it is why model vendors keep using contract understanding in their launch demos.
"And then overnight, ChatGPT comes around and you're like, wait a second, this will get you 85% of the way there with absolutely zero pre-training, zero specialized training." — Larry Jin, VP of Product, Docusign
Because a raw LLM re-reads everything, every time. Signed contracts are static: the clauses, key terms, dates and signature metadata never change after execution. Re-ingesting ten thousand of them each time someone asks a question burns tokens on work that only ever needed to happen once. Jin's answer is to ingest and process the corpus a single time, pull the extractions, build the vector index, and let every future question query that index. People also ask contracts the same questions over and over, spend with a supplier, renewal dates, committed versus actual, so the pipeline can be optimized for exactly those retrievals. Skip that step and the LLM will still answer, but at a multiple of the cost and latency, repeated on every single question your team asks.
"Well, yes, it'll do it. It may cost you a thousand X what you want it to. It may also take a thousand times longer than you wanted to, and you're gonna have to do it every single time." — Larry Jin, VP of Product, Docusign
Intelligent Agreement Management is the platform; Iris is the AI engine underneath it. IAM takes an organization's agreements, whether they were e-signed in Docusign or pulled from a folder, into a centralized repository, and Iris builds the structured data representation around them: extractions, semantic understanding, the metadata people query. Iris combines LLM capabilities with Docusign's own proprietary techniques, tuned to the questions organizations ask about agreements at both the individual level (summarize this lease) and the aggregate level (what are we spending on this software category across cost centers). Jin's point is that any enterprise dataset at sufficient scale needs this shape of solution, and departments vibe-coding their own vector databases amounts to every team building a software platform that is not their core competency.
As a platform partnering with specialists rather than trying to build every tool itself. Jin's model: successful platforms like Salesforce or Azure provide basic capabilities, scaffolding, reach and access to data, then let specialized products deliver depth. Docusign's partnership with Harvey pairs Iris's structured understanding of what is in your contracts with Harvey's legal research tools, so a review of ten years of supplier contracts can be cross-referenced against case law and regulatory statutes in different jurisdictions. The same logic drives the Legora partnership. Docusign focuses on in-house legal teams, the people who touch every commercial, procurement and HR contract inside a company, rather than outside law firms, and brings the specialist tools to them through the platform.
Chatbots return text; agents take actions. Jin worked on chatbots in the mid-2010s and remembers the 27-step pizza demos that collapsed when you said the wrong thing at step 23. LLMs fixed the conversation part. Agents extend it: instead of answering a question about a contract, the system initiates the renewal, creates the legal request, attaches the prior version, generates the new draft, routes it to the right reviewer and sends it for e-signature. In software terms the difference between saying and doing is small, one is text and the other is an API call, and LLMs handle both well. An agent is a described process: the reasoning context, the steps, the guardrails, and the tools it may invoke, inside Docusign and out to your CRM or ERP.
Because agents remove the rigidity that killed classic contract lifecycle management deployments. A CLM rollout at a company like a global manufacturer meant a 12-to-18-month project: systems integrators mapping exquisitely complicated workflows into business-process-management tools, and anything that did not conform to the modeled workflow simply broke. If users did not adapt to the workflow, the workflow died on the vine. Agents attack the same fundamental problems, but the workflow itself becomes something you change in natural language: attach this new version from email, parse the differences, run the comparison. No redesign project, no SI engagement. Jin calls that adaptability the radical change, and he separates it from the flying-cars version of agents doing all contracting without humans, which he expects to take much longer.
Whenever the process is regulated and the outcome is known in advance. Jin's example is a bank helping a minor open an account: the questions, the verifications and the guardian-consent checks should be predictable, auditable and near-identical for every applicant. About 95% of that flow should never vary. The agentic 5% belongs in the judgment work inside it, like risk assessment across credit history, prior banking relationships and submitted documents, where an agent can weigh many factors and deliver a better customer experience. The dial between deterministic and agentic moves per process, and in some domains rigidity is the feature. That framing gives buyers a practical test: map the process first, find where predictability is required, and spend the agentic magic on the parts that genuinely need judgment.
Still at the very beginning, by the account of the people furthest ahead. Jin works with Anthropic and NVIDIA and reports that even they feel the pace is too much and they need to go faster, while nearly everyone on LinkedIn projects the opposite. His two-speed picture: an innovation frontier moving at 120 miles an hour, and a tail of the biggest, most regulated industries, healthcare, financial services, insurance, manufacturing, moving at five. Most of the real world lives in the tail, including mom-and-pop businesses still running their CRM on Windows XP. People on the bleeding edge forget they are in a bubble. For the 95th-percentile human being, he argues, the effects of this technology remain incredibly early, and bringing that majority along is the real societal challenge.
"There's an innovation frontier that's moving at 120 miles an hour. And then there's the tail edge of that that is moving at five miles an hour, because those are your biggest, most entrenched, typically most regulated industry verticals." — Larry Jin, VP of Product, Docusign
Shamil Malachiyev: Hey everyone, and welcome to season two of The Founder's Code, called The AI Floor. This is the show where we skip the hype and try to find the real ground level of where AI actually is right now. And I could not have picked a better guest to open with. My guest today helps lead product at Docusign, a company most people still file under e-signature, but that label is about three years out of date. Docusign has just been named one of Fast Company's Most Innovative Companies of 2026, sitting right alongside companies like Google and NVIDIA, for turning itself from a product into a platform, an intelligence layer underneath the world's agreements. And the person driving a lot of that future sharpened his craft at Amazon and at Microsoft before this. He now runs the part of Docusign that is pushing it into the age of AI agents. So without further ado, please welcome Larry Jin. Hi Larry, welcome to the show.
Larry Jin: Hey Shamil. Thanks for having me.
Shamil Malachiyev: To start with, can you talk us a bit through your personal journey that led to where you are right now?
Larry Jin: Sure, yeah. And thanks again for the glowing introduction. I think I got some goosebumps just listening to that. Well, I've been in product management for close to 15 years. I started off with a software engineering background, so it's very technical by nature, and I learned the ins and outs of not just how to use things, but why things work the way they work. Some of my fondest memories in college, or university as we call it in Canada, were studying compilers and operating systems, distributed systems. And it's great as you build some of that foundation. So I took that and did software engineering for a while before getting into PM. Out of school I went to Microsoft as my first gig, was there for about seven years, and worked on really all the cool parts of Microsoft: Windows, Xbox, Skype, consumer. And then eventually I went on to be one of the early product members of what became Microsoft Teams. It went through, I think, four different internal names before it eventually became Microsoft Teams, and I was there for the preview, for the GA. That was a lot of fun.
Then I went to Amazon and spent a couple of years at Alexa, where I worked on bringing conversational speech features for listening to music and radio and even podcasts, just like the one that we're on here, before joining Docusign about five years ago. I came in, and now I lead product management for our platform area, which includes many of our integrations, our workflow capabilities, our enterprise products. So yeah, I'm just really excited to have seen the evolution of many things: software, enterprise software, AI, conversational AI, and, I know this is kind of meta, even the evolution of the product management craft, which I'm sure we can have another session dedicated to at another time.
Shamil Malachiyev: That's awesome. Do you think that technical upbringing has helped you combine the business aspect, understanding the company and the business requirements, with the technology underneath, to be able to manage all of those products?
Larry Jin: I think so, yeah. Absolutely. Product is unique in that it's very diverse in terms of the different ways that people get into it. I've worked with PMs who have marketing, finance, business backgrounds. My old manager, I think, studied biology as his undergrad. It's very diverse. But I do think having a strong CS or software engineering background helps you, because particularly early in your career it helps you get a little more early credibility working with devs in particular, who expect you to be able to go deeper on the how, on certain constraints, on why certain features are easier to build than others. I think it makes it a little bit easier. But as I said, a lot of great PMs start off with completely non-technical backgrounds.
Shamil Malachiyev: And it's going to be a good topic to mention within this podcast, because I think the common thread across different companies, as I've been speaking to different departments and different industries, is that everybody is now becoming a product manager. Whether that's a head of legal ops, whether that's a head of procurement, everyone has to start thinking about technology and get accustomed to understanding how AI tools work, what the LLM layers are, like RAG and everything, to make sure they can automate a big part of their work as well. So I guess it kind of helps you to both look at the products that are developed by Docusign right now for the clients, as well as managing things internally to optimize for efficiency.
Larry Jin: Yeah, a hundred percent. It's interesting. I just gave a talk a couple of weeks ago for our entire HR organization. We have a global team of a couple hundred: HR business partners, talent acquisition, skill development, all these teams that support our global workforce at Docusign. And the entire session was about how our HR team can reimagine how they work now with AI, doing less of the grunt work and more of, like you said, using AI to effectively become product managers. So the whole session was basically how to think like a product manager, but within an HR function. Really thinking about: what are the problems that you need to solve? Who is your customer? In HR's case, their customers are internal employees, or candidates looking for a potential opportunity at Docusign. How do you think about their needs and their pain points as a customer persona? And then use AI to build tools and solutions. It's a very different way of working than a traditional, more operationally focused role where you're just trying to do your day-to-day tasks. Now, with AI, you have to take a step back, and it's more meta: what are the business processes that you can better automate? What are the pain points inside the organization? So I think, to your point, there's something there. The human capital within these organizations is going to be deployed on a different set of problems than historically.
Shamil Malachiyev: And I think the leading AI companies that we have right now, like NVIDIA, Anthropic, OpenAI, have been putting a lot of noise out there in terms of marketing: AI is going to be the only technology present in the company, it's going to replace everyone, we're not going to have employees. Of course, they need to raise their share prices and make their technology seem like AGI is already here. But at the same time, they're really creating a situation where companies are trying to get their employees to adopt AI, but everyone's scared of AI because of the general notion of what those companies have advertised. How do you help drive that engagement and build the trust with people, that it's just a tool to increase your efficiency?
Larry Jin: In terms of creating adoption internally, inside the organization? I'll talk a little bit about our own journey, and how product, organization, engineering have each approached it differently. I would say there are two buckets. There are the general, company-wide productivity AI tools that are job- or function-independent. We use things like Glean, obviously Gemini, and with these tools, I think the way that you earn trust is you really have to show two things. One is that it's a very natural extension of the way that you already work. Gemini is a good example. How do you build trust with Gemini? Well, it's really not that much of a leap for someone who is writing an email or working on a doc to have the little glimmer icon that suggests, hey, let me suggest how to tighten up this paragraph. It gives you a suggestion, but ultimately the human is in control of whether they want to insert it or not. Even earlier today, I was using that to prepare a document, and it's kind of interesting, I think this must be a new feature, but the way Gemini does it now, it's almost like putting your document into track changes: someone makes edits, it shows you all the different suggestions, and you can choose to accept or reject them individually. Gemini started doing that. But the point is that ultimately you're in control.
So that's one: start with low-risk but highly valuable, highly repeatable things that are already naturally in the flow of what you already do. And I think that's why Gemini has been very easy to adopt. Glean also has been easy to adopt, because it's been such a powerful search tool, bringing together different enterprise sources: documents, Slack conversations, emails, even your CRM information. That has been really powerful. So that's the first bucket: general purpose, department- and job-title-agnostic.
The second bucket is more function-specific. Within engineering, you have tools that help you accelerate software development tasks, whether that's coding, testing, deployment, monitoring, CI/CD, DevOps sort of things. Within product, there are emerging specialized tools. Similarly within marketing and sales functions. Sales, I mean, it's an incredible explosion of productivity tools to help with prospecting, better understanding and qualifying leads, preparing you for the upcoming sales call you're going to have with a prospective client. And then legal as well, which I'm sure we'll talk about, is just a huge explosion in legal tech tools to help with drafting and deep legal research and legal matter management. So the second part of it is looking at these job-specific AI tools.
And again, the same methodology applies. You can't just roll something out brand new and say, change everything about the way you're working, and expect it to be successful. You have to find these incremental paths to value. With engineering, there's a reason why Claude has been so incredibly successful in taking off within organizations starting from coding: because it was so natural to go from "I have an IDE where I write my code" to "that IDE is supercharged with being able to auto-generate code for functions and classes and entire libraries and packages." A very, very natural extension of what you're already doing in the flow of work. Whereas if you're asking people to change their behavior... I think about the mathematical sort of calculus for whether someone does something: what's the benefit I'm gonna get, versus the effort I have to put in, versus the risk of it going wrong? And it has to balance out. And I think where the tools have been really successful is where the value is clear and evident in terms of time savings or efficiency, and the risk is relatively low, especially with tools where ultimately I get a choice as a human whether I want to accept the AI suggestion or not. If I don't like it, worst case is I just reject the change.
Shamil Malachiyev: Unless you go in bypass-permissions mode.
Larry Jin: Right. Well, that's where things that are doing things on your behalf are a much bigger leap, which I'm sure we'll talk about with agents. You have to build up towards that. You can't just go there automatically. So there's value, there's risk, and then of course there's the effort, which is: if I have to change my behavior, if I have to learn something new, that's just a much bigger lift than doing something that is already in the flow of the tools that are already used, whether it's Slack or Google Calendar or Gmail, Teams, Word, whatever it is.
Shamil Malachiyev: I love it. So basically, take the tools that everybody is already using and help them implement AI tools that operate within and enhance their current experience, to get their feet wet and start trusting the tools out there, the technology. And let's unpack this, because the Docusign case is very exciting for me. It shows how even the largest of companies can take the newly discovered technology that AI and LLMs are and make such a huge pivot. Docusign made a big bet on becoming infrastructure for the future that companies are going to build around AI, as that trust layer, which is the agreements that you sign, the most basic element. Can you talk us a little bit through that transition, the decision to move from e-signature and CLM into intelligent agreement management?
Larry Jin: Yeah. It wasn't so much a light-bulb moment, like, my gosh, we should be doing this, let's stop everything and go do it. It was really a natural progression of the company and the journey that we've been going through for years now. Like you said, everybody knows Docusign for e-signature. There are few companies, particularly software technology companies in the world, that are so well known, trusted, ubiquitous. Very few people that I've talked to, if they know the Docusign brand at all, it's because they've signed something with it. They bought a car, they opened an account, they leased an apartment. It's one of the few brands, again especially in technology, that just has that trust and reputation behind it.
But we, I would say for almost 10 years, have seen this bigger opportunity of going deeper into this problem space of helping customers get more value out of agreements. Whether that's making it easier to create and generate and negotiate, all the stuff that happens before signature. When you deal with really complicated contracts, particularly between two business organizations, imagine you're acquiring another company, you're a Walmart acquiring a smaller organization, the amount of contracting and papering and legal back-and-forth negotiation is really, really complex. And I think there are huge opportunities to streamline that, both for the low-volume, low-frequency stuff where the value of each individual agreement is really high, and even for the higher-volume, lower-value-per-contract work. It's a pretty wide spectrum, and it's a universal problem. So that's one piece.
The second is, of course, everything that happens after you sign an agreement. Just the sheer amount of economic value that's locked away in what is effectively a digital filing cabinet of PDFs. Every company has got a SharePoint repository or a network storage folder with thousands, or often hundreds of thousands, of these contracts that are dozens of pages. And any time a question comes up, it's like, well, I guess we have to ask Larry Legal to go do this. First you have to send them an email and ask, then they have to create a task in their queue, and then it takes them two business weeks to get back to you. Because they often have to, let's take an example, say a new regulation comes up in Germany that says you have to change your CO2 emissions target, I'm making something up, and you're a company in manufacturing or agriculture, one of these companies that has material impact on carbon emissions. When you go back to your contracts and try to understand what this means for us in terms of liabilities and obligations to our customers, to regulators, to partners, to suppliers and vendors, it is really, really complicated. Legal teams literally have to manually go through mountains and mountains of data, find the documents, open them up, and Control-F. And even sometimes that doesn't work, because the word that you're looking for may not be in the contract; it may be more of a semantic search. So all of these things have just always been really hard. And what's interesting is that most customers kind of just accepted that it sucked. They're like, well, this is just the way that it's done. It's like buying a concert ticket and realizing you have to pay 50% in extra fees. You're like, I guess this is just the way it works, I'll accept it. And you either hire more in-house attorneys or you outsource to external legal firms to do a lot of this work.
And I think what's incredible is that this problem existed for a long time, and it wasn't until LLMs came along that you had the ability to really reason over this in a deep and meaningful way. Traditional machine learning techniques were applied to contract understanding for years. You would develop specialized models and train them on corpuses of contracts so that you could get pretty good at being able to pick out: yes, this is a master services agreement, these are the key dates, limit of liability, total contract value, here's the expiration date, here's the delivery date. And you would hire big teams of data scientists and ML engineers to go do those things. And then overnight, ChatGPT comes around and you're like, wait a second, this will get you 85% of the way there with absolutely zero pre-training, zero specialized training. And so I think it has really opened up people's eyes about what you can do here, and highlighted a problem that I think many people just assumed, well, that's just the way it works, we have to do it manually.
I'll give you another analogy on this, and I've been thinking a lot about this since my time at Alexa. When I was at Amazon working on Alexa, this was between 2019 and 2021, it was this dominant platform in the ecosystem when it came to voice speakers and smart home devices. It was either that or Google; those were the only two games in town. And what's interesting is that the devices were there, the distribution was there, the use cases were there. The AI wasn't there. It had everything going for it except the actual intelligence, because the state of the art in the technology wasn't there. You fast-forward a few years, and now the AI has caught up. Sometimes the problem is there, the need is there, but it may be latent because the state of the art just hasn't been able to fulfill the customer need and promise. And I think with contracts we're getting to a point where, if you look at the announcements and marketing and PR, a lot of the examples from Anthropic and OpenAI and other players in the ecosystem always focus on understanding contracts as one of the first initial use cases. I think because, one, it finally shows the technology can do a really great job, and two, it is a universal need.
Shamil Malachiyev: Yeah. And another thing, when thinking about this topic of agreements: let's take an example of, say, a hundred thousand agreements. You have that in your database, and you go to your ChatGPT and you give it access and say, okay, find me all of this company's agreements. The amount of work ChatGPT needs to do, the amount of tokens it needs to burn to go through all of the contracts, do fuzzy matching on a name to make sure the different variations spelled across documents match, pull out the relevant ones, sometimes twenty or thirty pages each, analyze all of them and come back to you with the research... you've already spent, I don't know, two hundred dollars just checking what the history with one company has been like. And that's something that Docusign has been fixing with the current Agreement Manager. That is fascinating to me, because it really helps save the tokens. And I believe in the future, after we get comfortable using AI for everything, we're going to be thinking: okay, how do we minimize the token usage? Because that's going to be the driving expense for companies. I think what you're doing with Agreement Manager is going to help solve that. Can you talk a bit about Docusign Iris and Agreement Manager?
Larry Jin: Yeah, let me give a quick overview of both capabilities. At Docusign, we launched a new platform called Intelligent Agreement Management a couple of years ago. And a core foundation of that was using AI to understand what's in contracts and to create structured representations and data models around them, out of the box, with a minimal amount of customization. The idea is I can take my 100,000 agreements, like we said, maybe they're in a folder somewhere, maybe they were already e-signed using Docusign eSignature, put them into the centralized repository, and then create the structured data representation around them. That second part is done using Iris, which is the marketing name for our proprietary AI engine. It obviously uses LLM capabilities as well, just like everyone is doing, but it also uses other proprietary techniques.
And you raise a really important point. If you have one agreement, one contract, and you need to process it, summarize it, pull out key information, ask questions about it, you could certainly upload it into ChatGPT, Claude, Perplexity, name your AI tool of choice. It'll do a really good job of that, and it'll remember a little bit of that context for the future. I've recently been using that for some real estate transactions; it's super convenient as a consumer. But it's really different when you're a business organization and you're getting into the order of hundreds or thousands or tens of thousands of documents. Because these are documents that once they're signed, they don't really change. In fact, they shouldn't change, because they're contracts. What is in them, the words, the clauses, the key terms and dates and values, the metadata about who signed them, the timestamps, all of that is static. It is a static memorialization of what was agreed. So it's really inefficient, every time you have to ask a question about your contracts, to re-ingest and reprocess 10,000 of them.
And this is, I think, going to be true of any enterprise data set that is large enough. It becomes about how you intelligently ingest and process it. You're still using the latest and greatest AI capabilities, but you're doing so in an optimized way, optimized for accuracy on the information you care most about. Because for contracts, it turns out people look for the same things over and over again. Take a supplier contract. Say you're a company that buys from hardware manufacturers that make widgets, you buy from software companies, from SaaS companies, AWS, Azure, you buy from Staples because they give you office supplies and pens and staplers. As it turns out, you typically ask the same questions over and over again. Say we have a renewal coming up with AWS for another year of fixed cloud commitment, a lot of large organizations have upfront multi-year commitments, so you're negotiating renewal and you'll ask: what did we sign for the last three years? How much did we commit to spend? How much did we actually spend? How much are we spending on them relative to other similar vendors? And when you get to really big organizations, it turns out that if you look at a category of software spend, there isn't just one of them inside the company; there could be multiple. So procurement specialists or operations people or the head of finance or accounting might ask: how much are we spending on this particular category? Or, hey, Bob's cost center over there for tax auditing seems to be spending a lot of money on this particular software, how much are they spending overall? So you have these questions about your contracts, what's in them, both at an individual level and at an aggregate level over many, many contracts. And you want your AI to be really optimized to help answer these types of questions, but also in a cost-efficient, performant way.
That often means I don't want to have to do this over and over again from an AI processing standpoint. Like you said, that would just be cost-prohibitive in terms of tokens. No, you want to do that in an optimized way once. You want to pull out all the extractions, you want to build your vector index database, and then you want to be able to query that going forward. These are the kinds of techniques where I think people assume, well, if I just throw all this into an LLM, it'll do it. Well, yes, it'll do it. It may cost you a thousand X what you want it to. It may also take a thousand times longer than you wanted to, and you're gonna have to do it every single time. Versus these sorts of techniques that, only when you really understand the domain of the problems you're trying to solve with that data set, can you create these optimized approaches for. And oftentimes it's just how you pre-process, how you ingest, how you process, and then how you store those in the right manner.
Shamil Malachiyev: And then for an average department also trying to just figure out what a vector database is and how to use one, that's already going to take weeks.
Larry Jin: Well, yeah. And nowadays, of course, you could vibe code your own solution for that within the finance department. But do you really want your finance department to build their own version of that and vibe code it, and then your sales department, and then your marketing folks and your operations and procurement folks? At some point everyone is just building basically a software platform, and you really should just have someone do that for you. Especially if it's not your core competency.
Shamil Malachiyev: And I really like that you're giving examples from real industries, because a lot of the listeners for this season are going to be leaders in different departments across all of the industries out there. And I think it will be interesting to go industry by industry to see what the major play is that Docusign is planning for those industries. The big one, I think we can start with legal, because a lot of Docusign's users are heavy legal people, and there's been a lot of news out there with Docusign partnering with both Harvey and Legora. What has been the main play with these partnerships?
Larry Jin: Yeah, it's a great question, a very timely one. I'll say a few things. One is that legal as a department is kind of overloaded, so I'll be a little bit more specific. When we think about legal, there are typically two big buckets of legal groups that you could serve as someone building software. Let's say you're a startup building a new solution and you really want to get into legal tech. One of the first things you have to decide is: who am I building this for? Is it for in-house legal? These are legal teams that reside within organizations. Within Docusign, we have a chief legal officer, and he has a team of lawyers who focus on commercial contracting activities, IP and patent law and protecting our IP; we have legal teams focused on compliance and risk management. That is generally a function that exists in most business organizations. If you're small, you probably have one lawyer, up to Fortune 500s who probably have departments with thousands of lawyers.
And then there are outside law firms, ranging from the small, the billboards you see on the side of the road, personal injury, if you get in a car accident call Jim and Bob, better call Saul, and you roll up to their office and there's the giant inflatable balloon, all the way up to the most reputable law firms that deal with commercial law, that provide legal services as outside counsel but also do a lot of BPO, business process outsourcing. They may help outsource some of the legal tasks. The big firms like EY, Ernst & Young, and Deloitte do that kind of thing as well. For us, we're really focused on the first: how do we help in-house legal teams get more efficient? And the reason why is because they're often the ones that have to touch the contracts inside an organization. And these are contracts of all types. If you're selling SaaS to other companies, every contract you sign is a commercial agreement that says we're going to sell you this many seats or this many tokens over this period of months, here's how much you're going to pay us, here's when you're going to pay us, 30 days after the start of the month or 45 days, whatever it is. Similarly, you have contracts that you take in from buying from others: your procurement department buying software and pens and widgets and real estate space, a very diverse set of spending activities. And then of course you have employee agreements, HR contracts that govern your relationship with your own workers, which could be simple or very, very complex depending on the states and countries and different jurisdictions and labor regulations therein.
So we've always, and I would say with IAM especially, been very focused on helping those users get really efficient with a lot of the legal tasks. One example is just reviewing commercial contracts. How do I make sure that this contract we're about to sign with another business entity doesn't violate our internal posture, doesn't violate our playbooks? There's a whole concept of legal playbooks: making sure the legal team is looking out for the best interest of the company, and that you're not, by signing a contract, opening yourself up to future liability and risk and litigation. So that's a lot of what we do.
Now I'll turn to the legal tech space in general. There are, like you said, so many different companies and startups and really cool technologies that have come on the scene, again largely because of the advent of LLMs. Because ultimately, what is a contract? It is words on a document that both parties agree to. And words have been really, really hard for computers to understand in a natural-language way for a long time, until LLMs came along. So the domain of contracts is a perfect killer use case fit for modern AI and LLMs. And I think that's where we've seen this explosion of early venture activity and startups, but also established companies entering with new product offerings. Thomson Reuters has a product called CoCounsel. Microsoft recently announced a legal Word assistant. We're seeing this because clearly the need is there in the industry, and it's always been there. Like we said earlier, it was just latent, and the tools were not well served. Now, because of the technology, it's increasingly easy to build a solution that can do things at a basic level.
Now, I promised I would answer your question of what we're doing together with these companies. IAM as a platform is not meant to provide every possible tool out of the box for every user of every contract type. When you think about really successful platforms, whether it's Salesforce or Azure, they provide a basic set of capabilities, they provide scaffolding, they provide reach and distribution, and they provide access to data. But it's ultimately by partnering and integrating with many, many specialized tools that you're able to offer a better joint solution to the market. So when we work with Harvey, and we announced that a few weeks ago, the idea is: Docusign has a really good understanding of what's in your contracts, because we have all those optimized techniques for extraction and storage and semantic representation of your agreement structure, all the stuff we just talked about. Harvey has a really compelling set of tools to help legal personas be much more productive in drafting and in doing deep research. One of the really cool use cases: say you're asked to review all of the contracts with a particular supplier over the past 10 years inside your firm. You can pull up all of those contracts and all of the important attributes and metadata using Docusign, using Iris. But then inside Harvey, you can use all of their additional legal research tools to cross-reference that with prior case law or different regulatory statutes in different jurisdictions. Now you can marry those two and create a much better understanding of what's in your contracts and what you've committed to, and then assess the liability and the risk profile based on case law and other frameworks from the outside world. In case you can't tell, I'm not a lawyer, so I am far from being able to speak about this eloquently. But again, the reason the IAM platform is so compelling is that by building the right platform, you can bring in specialization through these partnerships and integrations. That's exactly what we announced with Harvey, but also with other providers like Legora as well.
Shamil Malachiyev: And it's interesting, when you were talking about legal and then HR: within my company, I've also noticed that legal and HR work together a lot. Legal and procurement, they also work a lot. And when I start thinking about what Docusign is currently releasing as a platform, it's almost becoming the platform that can come into a company like Microsoft does, and then you have all these different apps for different departments that come together as one. I'm seeing that Docusign is releasing hubs for different areas of the company, to make sure that it's not just the legal department using Docusign. It's now a tool that can be used by all of the departments, almost as a data infrastructure layer. How are you tackling that? Because there are just so many different use cases within every single vertical.
Larry Jin: Yeah, I think that's spot on. That is the opportunity. There are just so many different variations of the workflow, but you can't go after all of them at once. The way that we've been thinking about it is: within an organization, contracts show up in roughly four different high-level areas or functions. One is sales, so commercial contracts. You're selling software, widgets, AI tokens or whatever to another company. Typically that means you're going to create a services contract, an MSA, a quote. All of these are contracts that ultimately are going to be signed by you as the seller and signed by the customer as the buyer. That's one bucket. The second, like you said, is procurement: I've got to buy widgets and pens, lease real estate facilities, hire outside services. So there is a corpus of these vendor or supplier agreements within an organization. The third is your HR contracts: employees, and governing the relationship and the obligations to your employee, but also your employee back to you. And it gets really complicated, a bit of a tangent, but look at Europe, where we operate. In Europe, every country has a very exacting set of local labor laws around notice periods, and laws that say you can't reach out to a worker off hours. You're literally not allowed to send them emails and Slacks outside core working hours.
Shamil Malachiyev: So anti-capitalistic.
Larry Jin: And so these are really, really complex things. And then the fourth one is your relationship with partners: other organizations that you may be selling with. So you look at these high-level buckets, and what we try to do is create these workflows for those specific lines of business, departments, use cases; we use that terminology interchangeably. For sales, for example, you have to look at what a quintessential sales contracting workflow, the one that 90% of sales workflows kind of look like, involves. Typically a salesperson lives and breathes inside their CRM. They'll be in Salesforce, looking at an opportunity, and they'll say, hey, Shamil is the CEO of this company and I want to send him a quote, because I think he's interested in my new podcasting software. So I'm going to go into Salesforce, generate a quote, and send it over to you. And then you're going to say, hey, this is great, but I want to negotiate a little bit. You may also have your own terms: very specific payment requirements or accounting requirements, or you don't like the clauses in the contract that say you have to agree to be a public PR reference for the software. So that's the negotiation between organizations. Being able to capture those negotiations often includes the salesperson, but it could also include other functions, like legal and finance. And then eventually you get to the part that everybody actually enjoys, which is signing on the dotted line. Shamil finally said yes, he's going to buy the podcasting software, sparks go off, fireworks, great. And then after that: how do you actually find the contract that Shamil signed? How much was he quoted? What were the discounts? How many seats did he buy? All this information. So we look at this workflow and say, okay, 90% of the time it needs these steps, these pieces, these are the people that use them. And then, to your earlier point, you design the workflow and the tools around that. Some of that is going to be UI that we create. A lot of that is UI that we actually put into Salesforce itself. That's the other big element: based on the type of workflow, it may be less about us having a UI that everyone comes to, like a hub, and more about plugging into someone else's hub, because that's where people work. Salespeople typically work in only the CRM and email, Slack, text messages for doing deals.
Shamil Malachiyev: And how do you make those decisions? Implementing that within the overall Docusign infrastructure versus going in and choosing the platforms to integrate with?
Larry Jin: I think it starts with just understanding the day in the life, how people work. And going back to one of the earlier things I said when we were talking about AI adoption: change is really hard. People don't like to change their behaviors. I was joking, but if I were to truly sell you on a new podcasting tool that's not the one you're currently using...
Shamil Malachiyev: Docusign Podcasting.
Larry Jin: The Docusign Podcasting tool, it's going to be the best tool ever for podcasting. You'd be like, I've got to learn a new thing. Now you've got to change behaviors. You probably have a workflow, you're used to a UI, you're used to certain layouts. Same thing with people in every single job function. Try to convince a legal person, for example, that they should use Google Docs instead of Microsoft Word. No way, right? Or try to convince an accounting person to do their accounting outside of spreadsheets. Probably not going to happen. So you understand their behavior, how they like to work, and we try to adapt. I think this is the beauty of where technology is going with AI: it's much more adapting the tool to the person, and not creating a tool and asking people to change their behavior and use it. That's the age and the era that we're in now.
Shamil Malachiyev: Yeah. And can you tell me a bit about the actual agentic piece? Because at Docusign Momentum 2026, just a couple of weeks ago, you had a big announcement about introducing Docusign Agents. Can you tell us about the current vision for those agents?
Larry Jin: Yeah. I think it mirrors how the industry is moving. Where were we 10 years ago? Turn-by-turn chatbots, where you had a very, very specific conversational dialogue. I know this because I worked on chatbots 10 years ago. We were trying to do this when chatbots were a big thing the last time around, in the mid-2010s. Everybody, Facebook Messenger, everyone wanted to be like WeChat, and everyone was creating chatbots and chatbot frameworks. But they all had the same issue: very rigid conversational dialogues. Everybody's demo was, here's how you order a pizza in 27 steps. And then you'd get to step 23, you'd say the wrong thing, the entire conversation would break, and you'd have to go all the way back to the beginning: I want a large pizza with three toppings on it. So that was the baby step. But it proved there was something there. And I think the reason we keep coming back to this modality is because people talk. We communicate. That is our preferred way of interacting. You and I prefer to communicate by talking, not by me drawing a picture on a piece of paper, handing you that piece of paper, and you figuring out what I drew.
Shamil Malachiyev: It would have been a fun podcast, but yeah.
Larry Jin: We'd need more than an hour. But it's the same thing with talking to computers and tools and software: people prefer to talk to it. So LLMs came along, and all of a sudden it was just infinitely better at carrying on a multi-turn conversation across an unbounded number of knowledge domains. And then agents came, the notion of agents, and it was a natural extension: rather than just giving me a response as a piece of text, why don't you go do something on my behalf? The difference between doing something and saying something, at least in software, is that one is a piece of text and the other is a structured request, an API call, an RPC invocation to some other system. And ultimately LLMs are really good at doing both. If it needs to respond to you with text, it can do that. If it needs to respond by invoking a Google Maps API to look up a location, it's really good at that too, because that request is just an HTTP web request with JSON under the covers. So this is a very natural extension of LLMs and conversational chat.
What we're trying to do from a Docusign perspective is say: users don't just want to talk to their contracts. It's very powerful to be able to ask questions like, how much did I spend with this supplier over the last three years? Or, hey, summarize this really complicated lease agreement. You're buying a house, you get this 30-page seller disclosure, and you don't know what 90% of these words mean. Just tell me what I need to know. Here are the things I'm worried about: easements, closing dates, earnest money. And they're really good at that. But the beauty is that you can do so much more than ask questions. Well, what do I need to actually do with this information? Do I need to initiate a renewal? Maybe this contract says it's going to auto-renew or auto-expire in the next three months, and you want to get ahead of it. Well, how do I actually do a renewal? I have to create a request for my legal team. I have to attach the previous version of that contract. I have to generate a new version using the latest terms as a proposal. Then I have to make sure it's assigned to the right person in legal so they know they have to review it. And once all that's done, it needs to be sent over as a document for e-signature, and then stored and captured. So what you're essentially doing is taking what used to be many, many different steps that someone had to do manually, and describing it using natural language: this is the process I want to follow. That's effectively what an agent is. You are describing a way to reason about something with context, the steps it should take, the considerations and guardrails, and then the different tools it can invoke. Some of those tools can be inside Docusign. Many of those tools are outside Docusign: get some information from your CRM, or update something inside your ERP system. That is effectively the anatomy of an agent. Different companies call them different things. Some call them skills or plugins; I think Claude calls their stuff plugins. But they're all in the same general ballpark.
Shamil Malachiyev: And what role do you think that will play in unlocking more engagement and adoption? Because the range of tools you're pushing into the market is huge. You're trying to create value for every single function out there. And agents have been top of mind for a lot of people over the last year. What has bringing agentic capability into those processes unlocked for you as a company?
Larry Jin: I'd say the biggest thing is that it's a much more organic way for our users to work. Let me give you an analogy here. In this space, which maybe five percent of the listeners will know about, there is a software category called CLM, contract lifecycle management. It's been around probably almost as long as e-signature, maybe 15 years or so. There are a number of vendors in the space; you can do a quick Google search and there are all these different companies. Docusign is of course one of them; we're actually the leader in CLM, but there are several others as well. And CLM was an attempt, the old-school way, of solving many of the problems that we've talked about on this episode so far. Creating these complicated contracts and getting the right review, making sure it's the right language and it doesn't contradict or contravene anything inside your company's legal position and playbooks, understanding what you've signed historically so you can make better-informed decisions going forward, and so on.
The challenge with that category was always this. In order to do all of that inside your company, let's say you're a car manufacturer, you're General Motors, and think about GM, they probably have thousands of part suppliers all over the globe, everything from who builds the washer on your door all the way to who does your paint supplies. You're like, this sounds great, I have the CLM thingy that I can deploy inside my company, it's going to radically improve our efficiency when it comes to dealing with contracts. We'll save all this time, we're going to avoid revenue leakage, our legal teams are going to love it. The challenge has been that this is usually a 12- to 18-month massive project, because you end up having to bring in really sophisticated experts, like SIs, and they would map out these exquisitely complicated workflows, and then they would go build that workflow, literally build it using business process management tools. And then anything that doesn't conform to the workflow just doesn't work. So if users don't adapt to your workflow, the workflow just dies on the vine. You had both the complexity of modeling the business process, the rigidness of that process as modeled in your CLM software, and then an adoption challenge, because again, if people don't conform to the process, it breaks. It's kind of like going through TSA at the airport. You're like, oof, I shouldn't have brought that 125 milliliters of water, and you end up being the jerk pouring the water out, and now all of a sudden the queue is backed up.
So with agents, you're solving a lot of the same problems, many of the same fundamental challenges, but it's just a much more organic, human-friendly way of doing it. You don't need to spend 12 months designing the perfect workflow. If the workflow has to change, people can do that using natural language. You can just talk to the tool and say: you know what, here's another version of this contract that they sent me over via email. Can you attach it to the request, parse out the differences, and do the auto versioning and comparison? That is incredibly powerful. The ability to adapt the workflow in a more organic way to how people actually work in the real world, I think that's a radical change in what agents can help achieve. Now, that's the more pragmatic interpretation of what agents can do. There's also the flying-cars version, where it does everything on your behalf and automatically does all of the contracting work without humans involved. And obviously it's going to take us quite a while to get from "agents are helping you do more and be more adaptable to how humans work" all the way to "it's just going to do everything for you." There's a big spectrum of outcomes in the middle.
Shamil Malachiyev: And I guess, the way I'm hearing it: once you map the processes, they can seem very rigid and deterministic. You find those most rigid places, which are bound to break, and those are the places where you can now put agents and make workflows more flexible, I guess.
Larry Jin: And in some industries, some domains, the predictability and rigidity of the workflow is necessary. To give an example: helping kids open a new bank account. Let's say you're a bank, and one of your offerings is to help minors under the age of eighteen open a bank account. What questions you ask them, what verifications you need, legal guardian consent checks, you want those to be pretty predictable. It's heavily regulated, you know exactly the outcome you want to get to, you know exactly the risks that you need to assess. So 95% of that process should be highly predictable, and it probably shouldn't vary all that much between your son Billy and your daughter Janie. Now, that being said, I said 95%, because even in that scenario there's 5% where agentic capabilities can still be truly magical. And that's doing things like risk assessment. You may need to look at many, many different factors: the individual profile, how much information can be gleaned through other databases, social security, prior relationships with financial institutions, credit history. Then the system can come up with a more intelligent risk assessment and deliver a better experience. Maybe we need a little more information; maybe you have to submit a pay stub from your summer job at the amusement park. This is where agents can be incredibly valuable and help achieve better customer outcomes, but also better efficiency inside the organization. And that's an example where you want it to be 90 to 95% deterministic, repeatable, auditable, but in that five percent there's still room for AI and agents to come in and take away some of the additional burden that otherwise a human would have had to spend manually reviewing this particular application for Janie opening a bank account. So there's always going to be room for agents to help. It just dials up or dials down depending on the predictability needed in the process.
Shamil Malachiyev: And when we look at the universal adoption curve, I think a lot of people will know the S-shaped adoption curve, where it starts slow, then picks up crazily, and then fades out. Where do you believe we currently are, as a society, within that adoption curve? Because right now, if you look on LinkedIn, everybody is adopting AI, it's running companies, it's running departments, it's crazy. But in reality, when you speak to the people on the forefront of adopting these technologies, they all feel like they're behind, like they can't keep up with the news. And we can't all be behind, right?
Larry Jin: Right. Well, it's funny. I spend a lot of time talking with, we work with Anthropic and NVIDIA and leading AI companies, and even they'll tell you: we feel like we've got to go faster. And even they would acknowledge that it's actually too much, the pace of delivery and output and innovation is almost too much. I didn't mean to interrupt you, but it totally resonates, your point that everyone feels like they're behind. Even the ones who are furthest ahead probably think that they have to keep up that velocity.
Shamil Malachiyev: Yeah, exactly. That's what's surprising me. Even with Anthropic, I think there was an article yesterday where they came out like: guys, we need to slow the innovation and let the world adopt what is already here, because it's going to take time. And what are you seeing? On an individual level it's easy: you have your own local setup, you're playing around, and that's kind of easy to adopt. But when it comes to adopting these things within companies, then you have legal, compliance, and actual people using it. How are you seeing that level of adoption? And how do you personally, as a product manager, try to push those companies to take those leaps, to try the technology and start trusting it? How are you seeing the industry?
Larry Jin: I think what's happening here is that every company that serves a very large customer base of organizations and enterprises like we do is going to face the same interesting dynamic. There's an innovation frontier that's moving at 120 miles an hour. And then there's the tail edge of that that is moving at five miles an hour, because those are your biggest, most entrenched, typically most regulated industry verticals. So think healthcare, financial services, insurance, real estate, manufacturing, construction. But that's where most of the real world lives. And I think it's easy for many of us who are on the bleeding edge, whether you're at a software company, an AI company, a startup, to forget that you're very much in a bubble of innovation, where the rest of the world is struggling to keep up. Being at a company like Docusign, we have such a wildly diverse set of customers. Some of these are mom-and-pop shops who are like, look, I just really need to get this thing signed. They're not interested in the latest buzz-worthy, hype- worthy kind of AI. So what does that mean in terms of where we are in the journey? I think if there's one thing we can all agree on, because nobody has a crystal ball, it's that the effect all of this innovation, whether it's AI, whether it's agents, has on, let's call it the ninety-fifth percentile human being, is still incredibly early.
Shamil Malachiyev: Yeah, that's the same notion that I'm getting from everybody I speak to: we're at the very, very beginning. At the same time, you look at shareholders, you look at C-level executives, and they're like, we need to push for AI, AI everywhere. But when you actually speak to the people in the industry, everybody is being fairly careful, just starting to take the first steps in adopting all of these technologies. As a final question, I want to know: what are you most excited about when it comes to seeing Docusign within the next two, three years, on the personal level and on the professional level?
Larry Jin: That's a really good question. Going back to that analogy of the fast frontier and the slow one, I think there is still so much economic and human opportunity and value for the average person, the average business. The next time you sign an offer letter, or buy a house, or lease an apartment, or give consent, or sign something because you're getting orthodontics done, anywhere in your life where contracts and agreements show up, take notice of how lousy that workflow probably still is. And it's sort of directly correlated with the size of the organization. The mom-and-pop shop businesses still have the same obligations. If you're going to get your car fixed, there are very specific state requirements on your right to accept the quote or shop it around; there are all these regulations around how that relationship is governed between you and the auto body shop. So they have to do things a certain way. That doesn't mean they're going to give you a great experience. They're going to send you a really crappy PDF, you're going to have to fill it out, and refill it out probably three times, and then you have to pay your deposit, and that's using a different tool over here. These moments in life that revolve around agreements, there is still so much opportunity in them. We talk about AI and agents and all this Star Trek stuff, but basic moments in life are still far from being done ideally. I think that's what I'm still excited about. And the pragmatic part of me with AI is: how do you help these business organizations, especially the SMBs and mom-and-pop shops, who largely feel like the technology is probably leaving them behind? They're like, this is great stuff, but I've got to run a business, and you know what? The CRM that I use to deal with my auto body customers is still running on Windows XP.
Shamil Malachiyev: Ninety-five.
Larry Jin: Right. So how do you bring them along? I think that's the real challenge, the societal challenge.
Shamil Malachiyev: Well, I'm really excited to see the role Docusign is going to be playing once we actually hit the mass adoption part of the bell curve. I think that's going to be a very interesting time. Until then, thank you so much for joining the show, and thank you for sharing all of the cutting-edge work you've been doing. The way you're explaining things, I think you would be a really good teacher, in terms of helping people understand with examples. I think that's going to be really valuable for our listeners as well.
Larry Jin: Well, thank you. If all this product stuff doesn't work out, then I know I've got a career ahead of me. At least I'll hopefully find a job somewhere.
Shamil Malachiyev: Whatever AI does, we'll always find something. Thanks so much for coming to the show. It's been a real pleasure. And I'll make sure to drop you a message once we start doing episodes around product management, because that's something that apparently all of us will have to become fantastic at. Thanks so much, Larry.
Larry Jin: Yeah. I'm looking forward to that. I think that'll be a really good series, and an interesting one too, because like you said, more and more jobs within traditional functions are probably going to start feeling product- management-esque. And people who traditionally consider themselves product managers at the same time also have to evolve. It's really interesting. I think in the next three to five years we're probably going to see some pretty major transformation, and maybe convergence. Like you said, you should probably have a whole podcast series on this topic.
Shamil Malachiyev: I have a lot of questions in my mind right now, but I know your time is quite packed as well. Thanks so much for coming to the show. Let's talk again.
Larry Jin: Thanks for having me.
The AI Opportunity Assessment is a fixed-fee, two-week diagnostic: we map one costly workflow, put a dollar figure on it, and tell you honestly whether to build. We credit the fee to your build.
Book your assessment →Fluidlabs builds AI agents, Docusign IAM implementations and extension apps for the kinds of teams you hear on the podcast. Tell us what you're working on. We reply within one business day.
or email us at [email protected]