The “AI-Native” CRM — that wasn’t
A bootstrapped, pre-launch startup building an AI-native CRM for Indian SMEs brought me in to fix their VC pitch. The pitch was not the problem. The AI was an assistant bolted onto a conventional CRM rather than intelligence running through it — and you cannot position your way out of a product that isn’t what its label claims.
The product as built, on the direction that was set. Above: the home reads the day across leads, accounts, projects and people, and the assistant proposes an order to it — “2 overdue, 5 today. Clear the 5 quick wins first, then a focus block.” — rather than waiting in a separate tab to be asked. Below: the pipeline, where the unit of work the intelligence reasons over is visible as a single object moving through stages. The direction was set in advisory; the build is the team’s.
rivals reviewed before defining anything, so the definition came from the field rather than adjectives.
brain — a single place the customer’s knowledge lives, that every surface draws from.
unit of work, named explicitly, for the AI to reason and weave across.
features shipped by me — the deliverable was a direction, then a deliberate exit.
-
Test the brief before accepting it
The engagement arrived as a pitch problem. An hour with the product said otherwise — and taking the brief at face value would have produced a better deck for a weaker product.
-
Name the real problem out loud
The AI sat beside the CRM rather than inside it. That is a product-concept failure, not a narrative one, and it had to be said plainly before anything else could be useful.
-
Define the label from the field
“AI-native” has no agreed meaning, so it was defined for this product against a review of ten-plus rivals — what the category already does, and what would actually be different here.
-
One brain for the customer’s knowledge
A single place everything the business knows lives, that every surface reads from — rather than a model per feature, each guessing separately with a partial view.
-
One clear unit of work
Intelligence needs something to reason over end to end. Naming the single unit of work gave the AI a spine to weave along, instead of a scatter of disconnected assists.
-
Repair the weaving, keep the architecture
Their information architecture was already sound. The failure was in the flow between the parts, not the parts — which is what made this fixable for a team with no room to rebuild.
- The engagement was bought as positioning; the real problem sat a layer below, in the product concept.
- Bootstrapped and pre-launch — no runway for a rebuild, so the answer had to fit what already existed.
- “AI-native” is a label with no shared definition, so it had to be defined here before it could be designed toward.
- The answer had to hold up in two rooms at once: an investor’s and an engineer’s.
A mislabelled product became a defensible AI-native concept — a fundable investor story and a coherent build direction in the same move, because they were finally the same thing. Direction set, handed back, launch slated. An advisor’s reframe rather than a shipped feature, and scoped that way on purpose.
Answer the question they didn’t ask
Delivering the requested pitch would have been the easy, billable, useless outcome. The brief was a symptom, and saying so in week one was the whole engagement.
Define the label before designing to it
“AI-native” only becomes buildable once it means something specific. One brain and one unit of work turned a marketing adjective into an architecture an engineer can act on.
Set the direction, then leave
The value was a concept the team could carry themselves, not a dependency on me. Advisory scoped to end at the point where staying would have started costing them more than it returned.