Sait Izmit

Sait Izmit develops enterprise AI products for go-to-market teams. In 2026, he was a principal product manager in Snowflake’s Data, Analytics, and AI team, responsible for AI solutions serving its commercial organization. He helped expand an internal assistant from a pilot into a rollout to roughly 6,000 sales and marketing users, combining technical development with the work of earning trust and changing employee habits.

His earlier career included leading engineering teams at Philips in Europe and the United States, followed by developing AI solutions for Google Ads sales. That experience connects engineering leadership with a recurring business problem: employees need to act on information scattered across many systems. At Snowflake, a seller might assemble customer usage, support history, financial information, product documentation, and account news from separate tools. The assistant brings that context together so sellers can ask questions directly and, increasingly, automate the work that follows.

From retrieval pilot to company rollout

The Snowflake GTM AI Assistant began in February 2025 as a narrowly scoped knowledge-retrieval pilot with one dedicated data scientist. By late May, the team had expanded the project to include structured sales and marketing data, adding staff and dedicated product management. The broader rollout followed in September 2025. In his 2026 account of the deployment, Izmit reported more than a million questions answered and roughly 40,000 questions arriving each week.

Making the assistant reliable

• Quality over coverage: Izmit’s defining product position is quality over coverage. When he joined the team, he wrote 150 questions drawn from the sales process before trying the assistant. Engineers pointed out that some required data the system did not contain; he included them because sellers would ask those questions anyway. The initial test achieved about 50% accuracy. He argued for answering 50 questions at 95% accuracy rather than attempting 100 at 70%—an illustration of his preferred tradeoff, not a measured accuracy claim for the deployed product. A narrower assistant that answers reliably can earn requests for more capabilities. An ambitious assistant that disappoints users in their first few interactions may struggle to win them back.
• Clear limits: His agent-instruction guidance extends that responsibility to foreseeable requests outside the supported scope. Teams should test those questions, explain missing data, supply business context, and specify which tools handle which tasks. An assistant without win-rate data, for example, should acknowledge the limitation rather than invent a calculation. Defining what the system cannot answer is part of making its answers useful.

Testing usefulness and building adoption

The rollout tested different requirements at each stage. A small pilot with eager, feedback-oriented users focused on accuracy and rough edges. A roughly 600-person beta tested whether the assistant supported everyday workflows: clusters of requests for missing data could expose gaps in the minimum viable product. The team also tracked whether people returned, reaching more than 70% retention among weekly active users before proceeding to general availability.

Izmit treats activation as product work, while distinguishing it from retention. Employees who try the assistant and stop returning give the team a product problem to investigate. Employees who never try it require demonstrations, education, and support from their managers. During adoption work, he spent much of his time in sales meetings, demonstrating the assistant, tracking participation by team, and securing sponsorship from sales leaders. The release made the product available; sustained organizational work helped make it a habit.

From answering questions to automating workflows

Once conversational access to data becomes familiar, expectations rise. Izmit calls this the collapse of the wow factor: an initially impressive capability becomes the baseline, and users begin asking what else the assistant can do. He described sellers monitoring email and Slack for customer questions, having the assistant draft responses in Gmail for human review, and automating outreach workflows. He also described teams building reusable skills, custom dashboards, alerts, and applications. These examples explain why he sees data access as the beginning of the product’s development rather than its endpoint.

That progression requires an architecture the team can revise. The initial deployment used agent instructions, Cortex Analyst tools for structured data, and Cortex Search for unstructured knowledge; instruction versions were managed in a Google Doc. As requirements grew, the team added deployment practices, evaluation infrastructure, routing tests, a skill library, and integrations through the Model Context Protocol. When more workflow and orchestration instructions exceeded what could fit into the agent’s instructions, they introduced progressive disclosure to make instructions available as needed. Izmit favors launching with a workable stack and learning from use, while reserving substantial engineering effort for reworking the architecture as capabilities change.

Using conversations to improve software and sales knowledge

Conversation logs supply another development loop. The team uses language models to classify questions into topics and subtopics, identifying missing capabilities, repeated requests, and signs of frustration. Izmit uses those patterns alongside user interviews to see where the assistant fails and what employees need next. The same analysis can reveal gaps in sales knowledge after a product launch. By connecting relevant material from systems such as Confluence, Jira, and Slack, the team can generate sales-enablement documents and competitive battle cards, then feed that knowledge back into the assistant. He also described using patterns in requests to connect teams pursuing related accounts. In his approach, maintaining an enterprise assistant includes improving both the software and the organizational knowledge it depends on.