Hello to Canada’s SaaS and AI Community,
An AI feature can work as intended and still leave customers doing much of the same work. Meanwhile, the company has taken on another product to maintain, support and pay for.
Milen Kohli, Director of Growth at Unicorne Cloud, suggests a useful test: would customers notice if you took it away? Speaking with SAAS NORTH AI, he shared how to spot worthwhile opportunities, design experiments that test the hard questions and account for the people and data behind AI adoption.
Key takeaways:
- Look for workarounds that customers and employees have come to accept.
- Measure the whole task, including review and corrections.
- Use proofs of concept to test what could prevent a project reaching production.
- Plan for the changes AI brings to data, responsibilities and workloads.
Co-Founder/Producer, SAAS NORTH Conference Editor, SAAS NORTH NOW
A Working Feature Still Has To Earn Its Place
“If you just shut off that tool tomorrow, would it be catastrophic to your business? Would it hurt your customers?”
Milen’s question is deliberately demanding. A feature doesn’t have to be indispensable to justify its cost, but a SaaS company should be able to explain what customers can now do better because it exists.
That becomes harder once a project has momentum. Teams can demonstrate the interface and explain the model yet struggle to show whether customers finish tasks faster or can accomplish what they couldn’t before. Every feature also brings maintenance, support and potentially variable AI operating costs.
Milen encourages teams to follow what happens after the feature produces an answer. Does the customer move forward, or open a spreadsheet and finish the job elsewhere? The unfinished work may be where the more valuable opportunity sits.
That distinction matters when a company decides what deserves a place on its roadmap. A feature that makes existing information easier to retrieve may still be worthwhile, but you should assess it against the time and cost of supporting it.
Following the customer through the full task gives product teams a clearer picture of the value they are proposing.
Look at the Work People Have Learned to Tolerate
“Don’t pick an agent, don’t pick a tool, don’t pick a model even first. First find a problem to solve.”
Consider a subscription support request. An employee checks billing, opens the contract and reviews account notes. The records disagree, so they wait for a colleague who knows which exception applies. Eventually, the customer gets an answer. The next employee learns the same workaround.
That familiar routine can hide both the cost of the task and the judgement it requires. Before commissioning an assistant, leaders need to understand why the work takes so long, how often it happens and what an improvement would be worth.
The example is hypothetical, but the pattern is familiar: a workaround becomes so routine that nobody thinks to count it. Asking employees to walk through an actual request, including the delays and exceptions, can reveal what a process diagram leaves out. It may also show that the best improvement is narrower than the AI assistant originally imagined.
As Milen describes it: “This is our problem today, this is how much it’s hurting us, and once we adopt it, this is what the end result will be.”
Give The Experiment Permission To Disappoint You
“Don’t build a proof of concept that will never go into production,” Milen says.
A path to production doesn’t guarantee a launch. A useful proof of concept (POC) can show that records are too unreliable, human review cancels out the expected savings or the application costs too much to run. Finding that out early is valuable.
The test should focus on the assumption most likely to derail the project. If success depends on retrieving accurate information from inconsistent records, test those records. If it depends on reducing review time, measure the review. A polished demo won’t answer either question.
A test built around a tidy sample can make an application look more capable than it will be in everyday use. Milen’s production-minded approach means including the awkward cases early, while the scope is still small enough to change course. The point is to learn whether the proposed improvement holds up beyond the demonstration.
Milen advises keeping early projects narrow: one workflow, the relevant data and clear success criteria. Leaders also need to make it acceptable for a team to recommend stopping. Otherwise, a POC can become a launch commitment before the evidence supports it.
Decide Which Records AI Can Trust
“The boring foundation part is going to be the most important part.”
For Milen, that foundation starts with questions companies may have avoided for years. Which customer record is authoritative? How quickly do updates move between systems? Who can access sensitive information, and who corrects errors?
Employees often navigate these gaps from experience. They know which system lags behind and whom to ask when records conflict. An AI application needs a reliable way to handle that knowledge, especially if a pilot relied on someone manually cleaning data or correcting outputs behind the scenes.
Before expanding a successful pilot, teams should also record what people did to make it succeed. If someone reconciled conflicting records, prepared the inputs or corrected the answers by hand, that work belongs in the cost and reliability assessment. Otherwise, the next deployment may depend on invisible effort that was never budgeted.
Companies don’t need to rebuild their entire data environment before starting. They can test within a well-understood area, then address new dependencies as they expand. Work such as establishing reliable customer entitlements can also support future products, making the investment useful beyond one AI feature.
AI Changes the Work Around It
“Putting a chatbot in front of somebody and saying you have AI now, but not changing the way they work is the wrong way to say, I’ve implemented AI,” Milen says.
A faster first draft doesn’t necessarily mean a faster finished task. If employees still have to check every result, or remain responsible for errors without clear guidance, the expected savings may never appear.
Milen expects developers to spend more time defining requirements and evaluating what agents produce.
“People are going to have to think more, and then the action will happen on its own.”
That makes judgement, clear instructions and review capacity part of the implementation plan.
The practical question for managers is what happens to the time saved. More output can simply create a queue of material awaiting approval. To see a business return, companies need to decide which reviews are necessary, who owns the final decision and where the team should direct any freed-up capacity.
The same applies in customer support and analysis. Teams should measure the work through to completion, including approvals, exceptions and corrections, then decide how any capacity gained will be used.
For a SaaS business, that might mean finally delivering a product improvement customers have requested for months. The return comes from what the team can now deliver, not simply how quickly AI produces an output.
