It was July 2025. The heat in Shanxi was suffocating, pressing against the windows of our failing-air-conditioned office like a physical weight. We were a scrappy 15-person software company. Too small to babysit enterprise clients, too busy keeping our codebase alive. So, when a well-connected partner called to say a major university wanted to build a contract management system, we didn’t pop champagne. We knew better.
You’ve probably been there. A warm introduction gets you in the door, and you’re handed a vague mandate: “The school just wants to unify its contracts.” The instinct for most vendors is to nod, smile, and start drafting a feature checklist. That is the fastest way to get escorted off campus.
Because here is the first brutal truth of B2B software: Access and authority are inversely aligned. The leaders who can open doors cannot answer operational questions, while the staff who know the details have no power to decide.
When we met the university president, we didn’t ask for a feature list. We asked for boundaries. We needed to know if this was a real initiative or just a vanity project. We needed to know who would force consensus when departments inevitably started fighting. The president could tell us the “why” and the “scope,” but he couldn’t tell us how a procurement contract was routed or why scientific research contracts required different attachments. That’s not his job.
This is where most product managers fail. They treat the boss’s vision as the complete picture. It’s not. It’s just the starting line.
Instead of holding a massive town hall meeting—a guaranteed way to surface nothing but complaints—we built a fragile, three-layer chain of contacts. The leadership set the direction. A designated coordinator (a department head’s assistant) acted as our navigator. And the actual operators in ten different departments gave us the raw, unfiltered reality.
We didn’t ask these ten departments what features they wanted. We walked a single contract from its birth to its death and asked: Who creates this? Who approves it? Who holds the risk? Who pays? Who archives it?
What we found was institutional chaos. The procurement office feared liability if contract terms didn’t match bid results. The finance team didn’t care about approval buttons; they cared about matching invoices, acceptance documents, and payment milestones. The logistics department was juggling construction progress payments, warranty deposits, and monthly rent collections—all requiring completely different tracking mechanisms. The archive office was terrified that someone would swap the digitally approved PDF for a different physical copy during the stamping process.
Everyone is telling the truth, but everyone is only telling a fraction of it.
If you try to build software based on any single fraction, the system collapses the day it goes live. So, we stopped taking notes and started building governance instruments.
We didn’t return to our sweltering office with a list of desired buttons. We returned with six precise deliverables. We mapped the university’s 74—yes, 74—distinct contract types in a classification matrix. We built a role-and-permission table that tied accountability to job titles, not individuals, so the process wouldn’t break when someone retired. We built an interface matrix dictating exactly which system owned which data. And we created a decision ledger to track every conflicting opinion and who had the authority to break the tie.
Your job isn’t to ask what they want. Your job is to reconstruct a system they didn’t know they lost.
By the time we finished, our 15-person company was teaching a major university how many contract types it actually had, who owned each process, and where the true operational authority lay. The university’s operational self-knowledge was a byproduct they didn’t know they lacked until we handed them the map.
If you’re selling or building B2B software for institutions, stop treating requirements research as a feature scavenger hunt. It’s a forensic investigation. Walk in with a framework, triangulate the partial truths, and force the conflicts into the light. Do the hard work of untangling the bureaucracy, or let someone else sweat in the summer heat while you watch from the sidelines.
FAQ
Q: What's the biggest mistake in B2B requirements research?
A: Assuming the person with the authority to buy the software also knows how the operational process works. They don't. The boss sets boundaries; the frontline workers hold the details. You have to triangulate.
Q: What's the practical takeaway for product managers?
A: Stop taking meeting notes and hoping they magically turn into requirements. You must produce formal governance artifacts—classification tables, role permissions, decision ledgers—that force the client to resolve their own internal conflicts.
Q: What's the contrarian take?
A: You aren't building software for the client; you're acting as an organizational therapist. By the end of the research phase, the vendor often understands the institution's operational gaps better than the institution itself does.