In less than a week, a few thousand of us land at the Gaylord Opryland for ILTACON. The AmLaw 200 IT and information governance leadership is there in full force for this annual opportunity to engage in the learning that comes from connecting with peers and in the formal education program. I’ve seen posts from people excited to connect with their “nerd herd” and I appreciate the unique opportunity to be with the only people in the world who understand and want to talk about the most pressing challenges of your job. What might surprise you is that the vendors want into this club and not for the reasons you think.
I've sat on both sides of the vendor table. For years I worked in information governance in a Fortune 100 corporate legal department. Working with software vendors came with the job. Like you, I’ve scheduled the demos, crafted the RFPs, and scheduled the follow-up meetings with colleagues where we debated exactly how to score the vendor and its capabilities. Now I receive the feature requirements and requests as a member of the Product team at ActiveNav.
Whether you are exploring new technology solutions on the exhibit floor or having a sit-down with an existing partner at ILTACON, sooner or later the conversation will turn to features. It’s how you have that conversation that makes all the difference. A feature request is a finished answer. "The platform must use AI" names a technology without naming the problem it's meant to solve. When you ask for the feature a good salesperson shows you the feature. What you both miss is the opportunity to talk about the real problem you need to solve. AI may well be the right answer to the problem. The trouble is that presenting it as a requirement skips the part where the two of you work out the real problem together and learn from each other in the process.
The outcomes you want don't come from the feature you specified and received. They come from a feature you helped build, in a conversation where you bring the problem, the vendor responds with questions about it and shares what they know about working with other firms that share that problem, and potential new answers take shape between you.
Here’s how to have that mutual learning conversation instead. Start with what you're trying to solve, in outcome terms. Not "we need an AI-powered solution," but something closer to "my team can't keep pace with what's piling up: every week more lands in our file shares and sites than anyone can review, I can't tell the GC what risk is sitting in the backlog, and we're making keep-or-delete calls half-blind." Now you've named a problem. It has a shape, a stakeholder, and a cost. Then tell them what you do today: the workaround your analysts make, the manual process, and the part that always takes longer than it reasonably should. Don’t be afraid to share the workaround, no matter how unsophisticated it is. A vendor who's paying attention learns more from it than they do from your feature wish list. Next, explain what's hard. Specifically, where today's process breaks and what you've already tried and didn't fix the problem long-term. Then describe what solved looks like and who does what differently as a result. Lastly, tell the vendor how you'll report success, so you'll both know what a real answer to the problem looks like.
When you have this conversation, you are not doing the vendor's job for them. The good vendors in Nashville are there to learn how your work happens because they can't build elegant solutions to problems they don’t understand. When you tell them how the work moves through your firm, you're making sure whatever gets built fits your reality instead of the feature request they think they need to have to win your business or secure the contract renewal.
The mutual learning benefits everyone. You won’t waste your time at ILTACON sitting through the simple-case demo. The good vendors who listen and ask clarifying questions will tailor the demo to your problem and your needs. They’ll also take what they learn from you back to their product teams to build better tools that fit how you work and what you’re trying to do. Both of you leave smarter than you came, which is the point of ILTACON.
The two-way part is also a test. A vendor who only takes your feature list is telling you they'd rather sell to the box than learn the problem behind it. ILTACON is the perfect place to learn about what kind of service and attention you’ll get before you sign the contract. The vendor who pushes on the "what's hard" part, who tells you where their product won't help, is showing you they're on the same learning track as you.
This kind of collaboration reaches past the show floor, into the receptions, meals, and sit-down meetings. Explaining the problem before jumping to the fix is what gets more out of your vendor meetings next week where there's time and opportunity to think out loud. Describe what you’re trying to accomplish and share the context around it. If the vendor is one of your people, you’ll leave with a richer understanding of it and better tools to address it in future product releases.
Some of your people at ILTACON are wearing exhibitor badges. The ones who ask sharp questions about your hardest problem, who want to know how your work moves before they show you anything, belong in the nerd herd. Bring them the problem instead of the wish list, and you’ll leave Nashville with the opportunity to help build software that fits how your firm works.