A 90-Day Plan for Two AI Products

The situation

Two AI products were going into four enterprise clients at the same time. The first was an agentic telecom platform meant to replace human agents on outbound calls, texts and email, and it was live at three of the four. The second was an AI compliance system that reviewed every collections interaction before it went out, and it was live at two. One client had both, and that client was the largest.

The signals contradicted each other. Engineering said requirements were unclear. Sales had promised full automation. The CTO said the system was not production ready. The fourth client wrote in to say the experience was still manual-heavy. Usage was climbing, complaints were climbing, and conversions were falling.

The rules were part of the exercise. Seven days, 15 slides, no clarifying questions, every assumption stated out loud, and every decision defended live afterward. I did it alongside my full-time job.

Why this problem

Usage up and conversions down says the product is active but not delivering, so I started there rather than with the roadmap. Underneath it were three different problems wearing the same shirt: nobody had defined what the agent actually had to accomplish, the compliance system had not been configured to enforce each client’s rules, and the gap between what sales sold and what engineering shipped had no owner.

The obvious move was to lead with the telecom platform. It was the revenue product, it was live at three of four clients, and it was the one people were asking about.

I argued for the opposite. The telecom platform cannot legally operate without the compliance layer underneath it, because every outbound interaction has to meet FDCPA requirements. An unstable compliance layer does not slow the telecom product down. It turns every message it sends into exposure. Fixing the compliance system first was not the cautious option, it was the only order that let the revenue product run at all.

My role

Solo, start to finish. No engineering input, no real usage data, and no chance to ask a single clarifying question, which is its own constraint: every gap in the brief had to be filled with a stated assumption instead of an answer. I used most of the seven days, working around a full-time job.

I had not worked in collections or debt recovery before this. The closest I had come was recovering funds from restaurants during my time in fintech, which shares the mechanics but not the regulatory weight. So I treated FDCPA exposure as the thing to design around rather than a detail to handle later.

The call

Stabilize the compliance system first. The telecom platform accelerates in month two, not before.

Before choosing that, I defined who the plan had to work for, because “the client” was three different people with three different definitions of success:

Who	What they need	North star
Operations Manager	the agent closing accounts, not just touching them	conversion rate above the pre-deployment baseline
Compliance Officer	every interaction audit-ready before it goes out	zero FDCPA violations
Executive Sponsor	recovery that shows up in the numbers, not in activity	cost per recovered account trending down

Every decision in the deck had to hold up for all three at once. That is what made the sequencing defensible rather than merely cautious: compliance first protects the Compliance Officer immediately, and it is also the fastest honest route to the Operations Manager’s conversions and the Executive Sponsor’s cost per account.

I also split the four clients by what they actually needed. The largest got weekly contact across both products and a formal review before any scope entered the roadmap. The two single-product clients got biweekly updates. The fourth, the one that wrote in unhappy, got a dedicated recovery cadence with weekly tracking against compliance milestones.

How it held up

Midway through, the brief threw three shocks at the plan at once.

Engineering capacity dropped. I protected month one completely, delayed month two validation by about two weeks, and cut scope from month three. The sequence held and the timeline stretched, which is the trade I would make every time.

The largest client expanded scope. I acknowledged it formally, scoped it with them, and deferred it to month three or later. Their expansion got a real planning conversation rather than a slot in the queue, and the order of work did not change because of who was asking.

A competitor launched. Nothing broken internally got fixed by that news. What changed was client patience, so communication accelerated and stabilization did not.

The plan itself stayed three months long: stabilize, validate, accelerate. Lock compliance configuration per client and close the manual gaps. Turn the telecom platform on against a stable foundation, lowest-risk client first. Then expand where month two data says it is safe, starting with the client that had been carrying the manual load.

What I would push on now

Zero FDCPA violations is the right target, but it is also a number that looks perfect when the system is not catching anything. I would pair it with the pre-send block rate and audit trail completion, so anyone reading the dashboard can tell a clean system from a blind one.

The CTO said the system was not production ready, and my plan still begins rolling out in month two. I would define what ready means with engineering before committing to that date, rather than treating the date as the fixed point.