Excerpt
After decades in enterprise IT and as a CIO, Rajeev Jaswal moved from evaluating technology vendors to building companies himself. In this interview, the Graytitude founder and Argo Intelligence co-founder discusses finding a business niche, growing through referrals, selling to enterprises, building AI agents for real-world environments and the lessons entrepreneurs often learn too late.
Key Takeaways
- Experience as a customer can become a business advantage. Years spent buying and implementing enterprise technology helped Jaswal identify problems that technology vendors frequently underestimated.
- A business needs a clear lane. Graytitude initially tried to solve many different technology problems before narrowing its focus to areas where the team’s experience provided a meaningful advantage.
- Referrals can build a business before brand awareness does. Graytitude’s early growth came largely from professional relationships and the reputation created by successful projects.
- Consulting and product businesses scale differently. Repeatedly solving similar client problems helped the founders recognize an opportunity to turn accumulated knowledge into a platform.
- Selling technology requires understanding the entire buying organization. Security, legal, procurement, audit and operational teams can matter as much as the executive initially interested in the product.
- AI autonomy does not need to be all or nothing. Businesses can give AI greater freedom for low-risk tasks while retaining human approval for actions with significant financial, security or operational consequences.
- The real test of technology comes after implementation. A successful product must work with the company’s existing systems, employees, processes and constraints—not merely perform well in a demonstration.
Table of Contents
It is easy to build a technology company around what looks impressive in a demonstration. It is considerably harder to build something that survives contact with the way companies actually operate.
Rajeev Jaswal learned that lesson from the buyer’s side long before becoming a founder. After spending decades in enterprise IT and serving as a CIO, he had sat through enough vendor presentations to recognize a familiar pattern: the demo worked beautifully, but the customer’s legacy systems, security requirements, messy data, internal processes and employees were treated as problems to figure out later.
Eventually, that frustration helped push him from buying and implementing other companies’ technology to building a business of his own.
Jaswal founded Graytitude in 2018, initially tackling a broad range of enterprise technology problems before learning an early entrepreneurial lesson: being capable of doing many things is not necessarily a good positioning strategy. The company narrowed its focus to areas including mainframe modernization and enterprise automation, growing largely through referrals and channel relationships rather than building a highly visible public brand.
>> READ: Why AI Projects Fail After the Demo — and How Businesses Can Put AI to Work Safely
That experience eventually led to Argo Intelligence. After repeatedly solving variations of the same problems for consulting clients, Jaswal and his team began asking whether the knowledge and technology behind those projects could become a product rather than being rebuilt for each engagement.
The timing coincided with another shift: the emergence of AI agents capable of doing more than generating text. As AI agents increasingly move into multi-step business workflows, entrepreneurs and established companies alike are confronting a new question. How much authority should businesses give software that can not only recommend an action, but potentially carry it out?
The question is especially important when AI touches accounting software, customer data, CRMs, production systems or other critical business applications. The National Institute of Standards and Technology’s voluntary AI Risk Management Framework emphasizes managing AI risks throughout the technology lifecycle, while its companion Playbook provides organizations with practices that can be adapted to their particular needs rather than used as a one-size-fits-all checklist.
Jaswal’s perspective is shaped by having occupied several seats at the table: CIO, technology buyer, consultant and now founder. In our interview, he discusses why promising technology projects fail after the pilot, what AI founders misunderstand about selling to large organizations, how Graytitude found its focus, why he believes AI autonomy should be earned rather than automatically granted, and what entrepreneurs should ask before connecting AI to important business systems.
He also talks candidly about the less glamorous side of entrepreneurship: earning the first customer, learning to say no to opportunities, building through referrals, dealing with long enterprise sales cycles and discovering that experience as a corporate executive does not automatically prepare someone for everything involved in running a company.
For entrepreneurs building AI products—or simply trying to decide how much of their own businesses they should entrust to AI—his experience offers a useful reminder: the technology itself may be only the beginning of the work.
Question and Answer with Rajeev Jaswal
You spent years sitting on the buyer’s side as a CIO. Can you remember an AI or enterprise technology pilot that looked impressive in a demo but ultimately couldn’t make it into production? What killed it?
More than one, and they tend to die the same way. The pattern I remember best was an automation pilot that looked great in the demo. The vendor demonstrated how they could move data from system to system, answer questions, and close tickets in a matter of minutes. We were all sold on this.
Until it hit our real environment. The demo used a handful of clean test data and a couple of modern APIs, and ours consisted of [legacy systems, questionable data, and applications that didn’t have clean APIs]. IT wanted details on exactly what data the tool could access and who had approved what; Audit wanted an audit trail of what it did; and nobody could answer either question, so the pilot fell into review and eventually died on the vine.
What killed it wasn’t the technology; it was everything else: integration, access controls, governance, and ownership. The demo may prove it can work once; production proves it will work every day, safely and within systems you aren’t rewriting. That experience was part of the genesis of Argo Intelligence: from the ground up, we always include what demos tend to skip: connecting to core enterprise systems including the mainframe, controlling what AI bots can do, ensuring humans are looped in for actions with risk, and leaving an audit trail. The unsexy stuff that determines if AI graduates from the pilot stage.
You argue that many AI projects don’t fail because the models aren’t capable enough. What are the biggest reasons you’ve actually seen projects stall between pilot and production?
The model is rarely the issue any more. Everything surrounding it causes the backlog, and I have now seen those reasons repeated four times. The first is integration.
In pilots, models run on fresh data, using slick modern APIs.
In production, the data flows to the AI agent, and the output flows to the rest of the system. If AI can’t reach out to the legacy systems that actually run the business, AI isn’t doing much. The second is trust. Security, risk, and audit teams have standard questions: What can this AI agent get to?
- What just happened?
- Was it approved?
- Can we prove it?
If they don’t have answers, the project is frozen on review.
On day one, governance and auditability isn’t an afterthought. It has to be inherent. The third is ownership.
Pilots are often run by an innovation team without direct access to operations.
When the project is ready to turn on the lights, nobody owns the process, the cost, or the responsibility. It becomes yet another slide in the quarterly deck. The fourth is lock-in fear. Models aren’t stable: in six months, the current open-source model will likely be replaced by another.
Leaders are hesitant to build mission-critical workflows on one vendor’s model, one cloud provider, or one pricing plan, because the landscape will be different in six months.
If the pipeline doesn’t make it easy to replace models and compute providers, they wait, and waiting kills momentum. The pattern is clear. AI doesn’t fail on intelligence.
It fails on plumbing, permissions, and accountability.
The pitch mentions a question CIOs eventually ask: “What happened, and who approved it?” Can you give us a real-world example of why that question matters when an AI agent can take actions inside a business system?
Take something as ordinary as vendor payments. Say an AI agent is set up to process invoices: read them, match them to purchase orders, and update the finance system. It works well for weeks. Then a supplier sends an invoice with changed bank details, the agent treats it as routine, and a payment goes to the wrong account.
The first thing the CFO will ask is what happened. The second is who approved it. If the honest answer is “the AI did it, and we’re not entirely sure why,” you don’t just have a finance problem. You have an audit problem, possibly a regulatory one, and a board that will shut down every AI initiative until someone can explain it.
With a person in that role, there’s a trail: the email, the approval, the name on the change. AI agents need the same thing. You should be able to see what information the agent used, what it decided, what it actually changed, and whether a human signed off on the risky step. Changing bank details should never be something an agent does on its own.
The question matters because accountability doesn’t disappear when work is automated. It just gets harder to find if you didn’t design for it. The organizations that scale AI agents will be the ones that can answer “what happened, and who approved it?” in minutes, not weeks.
Where is the line between an AI system that simply provides information and one that creates meaningful operational risk for a business?
The simple answer is the moment AI stops answering questions and starts changing things. An AI that summarizes a contract is a research tool. An AI that updates the contract terms in your system of record is a participant in your business, and it needs to be treated like one.
But the line isn’t quite that clean, for two reasons.
First, information carries risk when people act on it without checking. If an AI tells a support rep the wrong refund policy, or gives an engineer a confident but incorrect answer about how a legacy system behaves, nothing was technically “changed” by the AI. A person still made the change, based on bad information. Read-only doesn’t mean risk-free.
Second, information AI can reach is itself a risk. A system that can surface anything in the company’s documents can also surface salaries, legal matters, or customer data to people who shouldn’t see them. Access control matters even when the AI never writes a thing.
So rather than a single line, I think about three questions. Can it change something? Can the change be easily undone? And how many people, customers, or dollars does it touch if it goes wrong? Drafting an email scores low on all three. Moving money, granting access, or changing production systems scores high on all three.
The practical approach is to match oversight to that risk. Let AI act freely where mistakes are cheap and reversible. Require a human decision where they aren’t. And log everything in between, because the actions that seemed low-risk are usually the ones nobody thought to watch.
What kinds of actions would you personally never allow an AI agent to take without human approval today?
Moving money and deleting production data are the obvious ones. The ones I worry about more are quieter.
First, anything that changes the rules the agent works under: granting permissions, editing approval policies, or turning off logging. An agent that can loosen its own guardrails doesn’t really have guardrails.
Second, acting on instructions from outside the company. If an email or supplier document tells the agent to do something, a person should see it first. The agent can read anything. It shouldn’t take orders from just anything.
Third, making commitments on the company’s behalf, like agreeing to a discount or accepting contract language. Once those words leave the building, no audit log can take them back.
Fourth, bulk actions. Updating one record is low risk. Updating forty thousand with the same logic is a different decision, even if each change looks identical.
The common thread is reversibility and reach. If a mistake is easy to undo and affects one thing, let the agent move. If it isn’t, a person should own the decision. That list will shrink as trust builds, but it should shrink because of evidence, not enthusiasm.
AI companies often talk about autonomous agents. From the perspective of someone who has actually been accountable for enterprise IT, do businesses really want fully autonomous agents, or is the market getting ahead of what companies will accept?
Both things are true. Businesses genuinely want autonomy, and the market is still getting ahead of what most of them will accept today.
The demand is real. Every CIO I know has a backlog of repetitive work that nobody wants to do and nobody has the budget to staff: reconciling data, triaging tickets, chasing approvals across systems. For that kind of work, an agent that needs a human to click “approve” on every step isn’t much of an improvement. If you want real returns, some work has to run on its own.
But “fully autonomous” is a phrase that sounds exciting in a keynote and alarming in a risk committee. When you’re the person accountable for the outage, the breach, or the audit finding, you don’t think in terms of autonomy. You think in terms of what can go wrong, how fast you’ll know, and whether you can undo it. Most enterprises don’t yet have good answers to those questions for AI, so they hold back, and that’s reasonable.
I think the vendors and the skeptics are both framing it wrong. Autonomy isn’t a switch you flip. It’s something an agent earns, task by task, the same way a new employee does. You start with low-risk, reversible work and close supervision. As the record builds, the leash gets longer. High-stakes decisions may keep a human in the loop for a long time, and that’s fine.
So yes, businesses want autonomous agents. What they don’t want is autonomy they can’t see, measure, or take back. The companies that get this right won’t be the ones that move fastest to full autonomy. They’ll be the ones that can prove, at any point, why an agent was trusted to act alone.
What do AI founders commonly misunderstand about selling technology to CIOs and large organizations?
They think the CIO is asking “how smart is it?” By the time you reach a CIO, capability is assumed. The real questions are what it touches, what happens when it breaks, and who gets the call at 2 a.m.
They underestimate how many people can say no. Security, legal, procurement, and audit all get a vote, and any one of them can stall a deal for months. Treat them as buyers, not obstacles.
They sell replacement when the customer needs connection. No enterprise is ripping out systems that have run the business for decades for a better interface. Work with what’s there, or wait until next year.
They mistake a pilot for a sale. A pilot proves interest. If nobody inside owns the outcome after go-live, you don’t have a deal.
And they ignore lock-in fear. CIOs have been burned before. Tie them to one model, one cloud, or one vendor, and you’ve lost the room.
CIOs don’t buy the most impressive technology. They buy what they can defend a year later.
Conversely, what do established companies and CIOs misunderstand about what today’s AI can realistically do?
They underestimate it and overestimate it at the same time, just in the wrong places.
They underestimate the unglamorous work. Many CIOs still picture AI as a chatbot or a copilot for writing emails. Meanwhile, it can read decades of legacy code, map dependencies nobody documented, and work through the backlog of tedious operational tasks their teams have ignored for years. The biggest returns aren’t in the flashy use cases. They’re in the boring ones.
They overestimate how much judgment it has. AI can be fluent, fast, and confidently wrong. It doesn’t know your business context, your politics, or which rule exists because of an incident ten years ago. Treating it like a senior employee on day one is how you end up explaining an incident to the board.
They think the model is the strategy. Picking a model vendor is not an AI strategy. Models change every few months. What lasts is how AI connects to your systems, what it’s allowed to do, and how you prove what it did.
They wait for it to be perfect. Every year of waiting for AI to mature is a year competitors spend learning how to use it safely. The capability is already good enough for real work. What most companies lack is the discipline to deploy it with guardrails.
And they assume their data is ready. It rarely is. AI doesn’t fix messy data, conflicting sources, or undocumented systems. It exposes them, quickly and publicly.
The truth is less exciting than the hype and more useful than the skepticism. Today’s AI won’t run your company. It can take a surprising amount of work off your people’s plates, if you give it structure.
You founded Graytitude in 2018 after spending much of your career inside larger organizations. What made you finally move from being the person buying and implementing technology to the person building a business around it?
Frustration, mostly. The productive kind.
As a CIO you spend years sitting through vendor pitches, and after a while you can predict how each one ends. The demo is impressive. The product assumes an environment that doesn’t look like yours. The hard parts, the legacy systems, the security review, the people who have to change how they work, are somebody else’s problem. You buy anyway, because you need something, and then your team spends eighteen months making it fit.
What struck me eventually was that the vendors weren’t incompetent. Most of them had simply never been accountable for the mess they were selling into. They’d never been the person explaining to a board why a project slipped, or telling a team their tooling was going to change again.
I’d also spent enough time on the buyer’s side to know where the real waste was. Not in the interesting problems, but in the work nobody wanted to talk about: legacy systems that everyone depended on and nobody wanted to touch, automation that had been promised for a decade and never delivered.
So in 2018 I had a choice. I could keep buying other people’s answers to that problem, or I could build one. I picked the harder path, and I’d be lying if I said I fully understood what I was signing up for. Being a CIO teaches you how enterprises buy, what breaks, and what they’ll actually live with. It teaches you almost nothing about payroll, pipeline, or the stretch where you’re not sure the next contract is coming.
The thing I underestimated most was patience. Inside a large company, you have budget and authority, so you can force a decision. Starting from nothing, you earn every conversation, and enterprises move at their own pace regardless of how good your product is.
What I’d tell anyone considering the same move is this: the operator experience is worth more than you think, but only if you keep listening. The moment you start believing you already know what customers need because you used to be one, you’ve become the vendor you left.
What did Graytitude look like in its earliest days? How did you land your first customers?
In the beginning, we were the people who wanted to solve everything. Automation, security, CRM, mainframe modernization; whatever a customer brought us, we were confident we could help. It came from a good place. We’d seen these problems from the inside, and we knew we could do the work.
It also made us hard to describe. When someone asked what Graytitude did, the honest answer took two minutes, and a two-minute answer isn’t an answer. We were competing with specialists in every category and sounding like generalists in all of them.
The lesson came quickly: pick your lanes, and pick where you can make the most impact rather than where you’re merely competent. For us that meant mainframe modernization and enterprise automation, genuinely difficult work that most firms avoid, and where our experience actually mattered. Saying no to good opportunities was the hardest discipline of the early years, and the most valuable.
Every one of our first customers came through referrals and our own network. Nobody was finding us through a website. They came because someone who had worked with me or with my team vouched for us. That’s humbling in the early days, because it means you’re spending credibility you built somewhere else. It’s also clarifying, because referrals don’t happen unless the work is good. Our growth was entirely a function of whether the last project went well.
That’s still true, and it shaped how we built the company. Before Argo existed, Graytitude was doing mainframe DevOps and automation for large enterprises, working with partners like IBM, Ensono, and others. Those relationships weren’t won with marketing. They were earned one delivery at a time.
The company reportedly grew largely through channel partnerships and enterprise work rather than building a highly visible public brand. Was that intentional, and what are the advantages and disadvantages of growing that way?
It was intentional, though partly a matter of necessity.
Early on, we made a deliberate choice to prove competence rather than manufacture attention. This industry has no shortage of companies marketing capabilities they haven’t built yet, and we didn’t want to be one of them. We’d rather be known by the people who had seen us deliver than by people who had seen our advertising. So we took on large, difficult initiatives, executed them well, and let credibility accumulate with the partners who put us in front of their customers.
There was also a practical reality. We were self-funded and careful about where every dollar went. Given the choice between hiring another senior engineer and spending on marketing, we chose the engineer every time. Building a high-caliber team was the better investment for the work we were doing, and it still is.
The advantages were real. Channel partners brought us into enterprise environments that would have taken years to reach on our own, and a partner’s endorsement carries weight no marketing campaign can buy. It also kept us honest. When your growth depends on the last project going well, you can’t hide behind a brand. The work has to speak.
The drawback is dependency. When your pipeline comes through partners, you’re one step removed from the customer, and their priorities shape your growth more than your own do. Their roadmap shifts, and yours shifts with it. You also build less of your own market presence, which means when you have something genuinely new to say, fewer people are listening.
That’s the balance we’re correcting now with Argo Intelligence. The channel remains important to us, and those relationships were earned over years. But a product needs its own voice. The difference is that we’re building that visibility on top of a track record, rather than in place of one.
Why build Argo as a separate product/company direction rather than simply continuing to grow Graytitude’s consulting business? What opportunity did you see that consulting couldn’t address?
Honestly, because we kept solving the same problem over and over, and it started to bother us.
In consulting, you finish a project, the customer is happy, and then a few months later another customer calls with a version of the same problem. You rebuild it. That’s fine, it pays the bills, but at some point you look around and realize you’ve written the same thing five times for five different companies. The knowledge lives in your people’s heads and in whatever they built for that one client. Nothing compounds.
The other thing about consulting is that growth means headcount. If you want to do twice as much work, you hire twice as many people. We were proud of our team and picky about who joined, so scaling that way was slow by design. And I could see where the industry was heading. When AI agents can do a meaningful share of the work, competing on headcount stops being a strategy and starts being a liability.
What pushed us over the line was watching what we were doing on projects with AI. We were using agents internally on our own mainframe and automation work, mostly to save ourselves time, and it worked better than we expected. That’s when it clicked. The valuable thing wasn’t the individual project. It was the machinery we’d built to get through it.
Sanjay and I talked about it for a long time before we did anything. He’d spent two decades at IBM building products, so he knew exactly how different that is from services. Products need a different rhythm, different people, different patience. You can’t bolt a product onto a consulting business and expect either to thrive, and plenty of firms have tried.
So Argo became its own thing. Graytitude still does the consulting work, and it always will, because enterprises need people who can actually implement this stuff. The projects haven’t gone away. They just take less time now. But the platform had to stand on its own, be sold on its own, and be good enough that someone would buy it without us in the room.
Argo requires human approval before an agent writes to another system. Doesn’t that limit some of the productivity gains companies expect from autonomous AI? How do you think about that tradeoff?
It would, if every write needed a person. That’s not how we think about it. The approval gate is configurable, and the point is to put human judgment where the risk is, not in front of every action.
Most of what an agent does in a day is low stakes and reversible. Reading documents, pulling data, drafting a response, updating a status field. Requiring sign-off on that would be pointless, and people would stop using the product within a week. The actions worth stopping for are the ones that move money, change access, touch production, or commit the company to something. Those are a small fraction of the volume and a large fraction of the risk.
There’s also a practical argument that gets missed. The alternative to approval isn’t speed; it’s hesitation. In most enterprises, an AI project that can’t answer security and audit questions doesn’t ship at all. A workflow that runs with a human checking two steps out of forty is faster than a fully autonomous workflow still waiting for approval from the risk committee. Governance isn’t what slows adoption down. The lack of it is.
The other thing we’ve noticed is that approval gates earn their way out. When a team can see months of an agent doing a task correctly, with a record to back it up, removing the gate becomes an easy decision. Without that evidence, nobody wants to be the person who signed off.
So yes, there’s a real tradeoff, and we’d rather be honest about it than claim there isn’t one. Our view is that autonomy should be something an agent earns for specific tasks, based on evidence, rather than something a vendor turns on by default.
How do you prevent “human in the loop” from turning into a rubber stamp where employees approve dozens or hundreds of AI actions without meaningfully reviewing them?
This is the right question to ask, and it’s a bigger risk than most people admit. Anyone who’s worked in a large company has seen approval workflows where the approver clicks through without reading. AI can make that worse, because it produces work faster than people can review it.
A few things help.
Keep the volume low. If a person is approving hundreds of actions a day, the design is wrong. Approval should be reserved for the small set of actions that are genuinely risky or hard to undo. Everything else should run, with a record. The moment approval becomes routine, it stops being review.
Show the approver what they actually need to decide. A prompt that says “agent wants to update record 58971, approve?” gets rubber-stamped, and deservedly so. The person needs to see what changed, what it’s changing from, why the agent reached that conclusion, and what happens if it’s wrong. If the reviewer has to go look it up in another system, they won’t.
Route to someone who understands the decision. A helpdesk queue approving finance changes is a rubber stamp by design. The approver should be someone with the context and the accountability to say no.
And watch the approval data. If a queue shows a100% approval rate and a five-second median review time, that’s a signal worth investigating. We can’t force anyone to read carefully, but we can make the pattern visible so a manager can see it.
I’ll be straightforward though: no product fully solves this. It’s partly a culture question. If an organization treats approvals as paperwork, they’ll be treated as paperwork. What technology can do is keep the number of decisions small enough to be real, give people the information to decide well, and leave evidence when they don’t.
Can you share an example of an AI workflow that looks easy in a demo but becomes significantly more complicated once it has to operate inside a real company?
Invoice processing is the classic one. It looks great in a demo. The agent reads an invoice, matches it to a P.O., updates the finance system, and routes it for payment. Thirty seconds, start to finish, and everyone in the room can see the savings.
Then you put it in a real company.
The invoices don’t all arrive as clean PDFs. Some come as email attachments, some as scans, a few still come by mail. Vendor names don’t match what’s in the system, because the entity that signed the contract isn’t the one that sends the bill. Purchase order numbers are missing or wrong often enough that “match to PO” turns out to be the hard part, not the easy part.
Then there are the exceptions, which is where most of the work actually lives. Partial deliveries. Credits against a previous invoice. A charge that’s ten percent over the PO, which is fine under one policy and not under another. Different approval thresholds by department, region, and dollar amount, some of which exist for legal reasons nobody in the room remembers.
And then the questions that kill the project if you haven’t planned for them. Who approves a payment the agent flagged as unusual? What happens when the finance system is down mid-run? Can we prove to an auditor what the agent did last March? If a duplicate payment goes out, how quickly do we know?
None of that is an AI problem. The model can read the invoice perfectly well. The complexity is in the integration, the exceptions, the policy logic, and the accountability around it. That’s why demos take an afternoon, and production takes months, and why teams that budget for the demo version are the ones that end up stuck.
A small or midsize company won’t have the governance staff of a Fortune 1000 business. What lessons from enterprise AI governance should smaller companies adopt, and what would be overkill?
The useful lessons are mostly cheap. The expensive parts are what large companies build because they have thousands of employees and regulators watching, not because the principles are different.
Worth adopting:
Know what AI has access to. Most of the problems I’ve seen come from an AI system that could reach more than anyone intended. That’s a one-afternoon conversation, not a governance program.
Decide which actions require a person, and write it down. It can be a single page. Payments over a threshold, anything touching customer data, anything that changes permissions. What matters is that it’s decided in advance, not in the middle of an incident.
Keep a record of what AI actually did. If something goes wrong, you’ll want to reconstruct it. Small companies often skip this and then spend a week trying to piece together what happened from memory.
Give one person ownership. Not a committee, just someone whose job includes noticing if AI is being used in ways nobody agreed to.
Overkill for a small company:
A formal AI governance committee with a charter and quarterly reviews. A model risk framework borrowed from banking. Multi-tier approval chains. Mandatory training programs. A long policy document that nobody reads. These exist in large enterprises because coordination across thousands of people requires structure. In a company of fifty, the structure is a conversation.
The honest version is this: large companies have governance staff because they have scale problems, not because they have better judgment. A small company with a clear head about access, approvals, and record-keeping is often in better shape than a big one with an impressive policy binder and no idea what’s actually running.
If a business owner is evaluating an AI agent or automation platform today, what are the questions they should ask the vendor before allowing it to interact with their CRM, accounting system, payroll or other business software?
Here are five questions, and pay attention to where the answers get vague.
What exactly can it access, and can I limit that? Many tools connect with broad permission set because it’s easier to build. Ask for read-only where reading is all that’s needed.
Which actions require my approval, and can I decide that? If the answer is “it’s fully autonomous,” ask how you stop a bad action mid-run. If the answer is “everything needs approval,” ask how that scales.
What record do I get of what it did? Ask to see an actual audit trail, not a description of one.
Where does my data go, and is it used for training? Get it in writing. “We take privacy seriously” is not an answer you should accept.
What happens if you change your model provider or your pricing? Models and costs are shifting constantly. Ask what protects you from a change you didn’t choose, and what you’d walk away with if you left.
You spent years evaluating vendors yourself. Has becoming the vendor changed your opinion of the companies that used to pitch you?
Yes, though not in the way you might expect. I’m more sympathetic to some things and less forgiving of others.
The sympathy is mostly about how hard it is to get a meeting. As a CIO, I ignored a lot of outreach without much thought. Now I understand what went into those emails, and how many good products never get seen because the founder couldn’t find a way in. I also understand why vendors push for a decision. When your runway is measured in months, and the customer’s procurement cycle is measured in quarters, that pressure is real. It doesn’t excuse bad behavior, but I get where it comes from now.
I’m also more forgiving about pricing. From the buyer’s chair, enterprise pricing looks arbitrary. From this side, you learn how much support, security work, and compliance overhead sits behind a serious enterprise product. Some of what I dismissed as vendor greed was just the cost of doing that work properly.
What I’m less forgiving of is the pretending. Overstating what a product does, glossing over the integration work, showing a demo on data that would never exist in a real company. I used to think that was salespeople being salespeople. Now I know those claims usually come from somewhere higher up, and that somebody in that company knew better. Building an honest product is hard, but being honest about it is a choice, and it’s free.
The other thing I’ve come to see differently is the customer’s role. I’m not sure we were always easy to sell to. We asked for detail we never read, ran evaluations without a real decision-maker in the room, and occasionally used vendors for free consulting on projects we had no budget for. The best vendor relationships I had were the ones where both sides were straight about what they wanted. That takes two.
Looking back across your career as a CIO and now as a founder, what is one lesson about adopting new technology that you think entrepreneurs consistently learn too late?
That the technology is the easy part, and nobody is selling you the outcome.
Most entrepreneurs can evaluate a product, run a pilot, and get something working. What surprises them, usually a year in, is that the hard work starts after it works. Someone has to own it. People have to change how they do their jobs. Processes built around the old way have to be rebuilt. None of that is on the vendor’s roadmap.
That’s the gap in how enterprise technology gets sold. A software vendor sells you a tool and stops at the edge of the license. A consulting firm sells you people and bills for the hours. Neither is accountable for the result, so you end up as the general contractor, holding together partners who each own a piece and none of whom own the finish line.
That’s what service as software should change: buying the outcome rather than tools or hours, with the software and the expertise delivered as one thing. It’s a harder business to run, because you can’t hide behind a support contract when it doesn’t work. Which is exactly why it’s better for the customer.
So the lesson is to judge technology by how well it survives contact with the way your company actually works, and to be skeptical of anyone who won’t stand behind the result they’re describing.
