Shantanu Vishwanadha

For practical AI work, I trust a small evaluation set maintained by the team more than a polished benchmark number. The useful cases are the ones that expose where a tool is unsafe, confusing, or too expensive for the workflow.

A useful AI demo proves a capability. Adoption starts when developers can answer: what context did it use, what can it change, how is output reviewed, and where do we report a failure? Documentation should cover that second conversation.

AI support tools should optimize for reversibility. A fast wrong answer creates follow-up work; a draft with its sources, assumptions, and an easy edit path lets the support person use judgment before it reaches a customer.

A shorter setup flow can create longer support threads for AI features. Remove friction, but keep the steps that establish context, permissions, and review. Fast activation matters; false confidence costs more.

The most useful AI demo includes the handoff. Show the point where a person reviews, edits, or declines the output. That is where users learn the actual operating model—not from another polished prompt-result clip.

A support ticket saying ‘the AI got it wrong’ is rarely enough to fix anything. The useful follow-up is: what did it see, what was it asked to do, and where did the result stop being useful? Product teams should make that context easy to capture.

Time saved is a weak first metric for an AI support workflow. It rewards fast drafts even when they create more review work. A better signal is whether the draft can be accepted with small changes and whether its assumptions are visible to the reviewer.

Every AI integration guide should answer a boring question early: what happens when the input is incomplete? If the answer is buried in a model caveat, users discover it in production. Put failure behavior beside the happy path.

I’m honestly tired of entrepreneurship being reduced to a classroom discussion about values, attitude, discipline and how an entrepreneur should behave. We have enough people teaching the philosophy of entrepreneurship. What we desperately need are people teaching the mechanics of it. How to find a market. How to build something people will pay for. How to get the first 10 customers. How to price, sell, negotiate, manage cash flow, make tough calls and execute when things don’t go to plan. Nobody built a company because they attended a workshop on behavioural competencies. Less preaching about being an entrepreneur. More learning how to actually build a business.

AI rollout plans usually start with a pilot. The useful pilot has a defined failure case. Pick work where an incorrect output is easy to spot, easy to reverse, and cheap to correct. Otherwise you are evaluating risk appetite, not model usefulness.

Will it vibrate when I get a call?

Curious, what are those “meaningful” ways?

How many TEDx editions does it take to run out of original ideas? One flagship event? Absolutely. But multiple spin-offs with the same speakers recycling the same talks? What’s the point? At this stage, it’s not about spreading ideas. It’s just the same show, different banners, and a fresh dose of self-importance. 😂

Documentation and AI assistants need the same maintenance discipline. Both become risky when old guidance remains searchable, sounds plausible, and no longer matches the product. Freshness is a support quality issue, not a content hygiene issue.

If an AI feature needs a separate “how to prompt it” guide before it can help, the product still has an interface problem. Prompting skill matters, but teams should first remove ambiguity from the task, the context, and the expected output.

AI support tools are most useful when they make uncertainty visible. A polished answer with a hidden assumption creates more follow-up work than a blunt “I don’t know.” For support teams, confidence should be treated as product behavior—not merely model output.

AI adoption needs a refusal path. People need to know when to stop using the tool, what to check next, and who owns the answer. Without that, the tool moves mistakes downstream.

The best input for an AI documentation assistant is often the question someone asked after reading the docs. It exposes where the reader's mental model and the writer's mental model diverged. Treat that gap as backlog.

A support copilot that cannot show its source turns every answer into a second investigation. Link the answer to the docs, ticket, or policy it used. The citation is part of the interface, not audit garnish.

I trust AI assistance more when the manual fallback is obvious. If I can inspect the inputs, change the result, and finish the task without fighting the tool, I will use it again. Adoption depends on recoverability after an imperfect first response.