SHORT ANSWER
Startups use AI in three places: inside the product as a feature that completes a user task, inside operations to remove repeated manual work, and inside go-to-market for research, content and support triage. For a small company, internal operational work is often the easiest first use to measure because the baseline task already exists and the team can compare time, quality and cost before and after.
Answered by Andrew Crossley, AI Product Consultant & Product Partner · Updated 2026-08-01
Small teams have the most to gain and the least capacity to experiment badly. Choosing the wrong first AI project can consume a quarter without producing a useful result.
A coherent AI strategy should explain how AI changes customer value, operating cost or both. Simply listing the tools a company uses is not a strategy.
Support triage, sales research, onboarding data entry and QA are easier to measure because the current handling time and error pattern already exist.
Pick a step users already find tedious and produce a reviewable draft rather than an automatic action.
Not tokens and not calls. Use the full cost of a task that reached the intended outcome without unacceptable rework.
Anything customer-visible, financial, contractual or difficult to reverse should keep review until the evaluation evidence justifies more autonomy.
FROM EXPERIENCE
Classifying inbound support messages by reason code, drafting a first response and routing the exceptions can produce a useful operational baseline: handling time, correction rate, resolution and the reasons customers contact you.
That reason-code data also becomes product evidence, because repeated contact reasons often expose friction the roadmap should remove rather than automate forever.
Choose a repeated task with a clear baseline and a reviewable output, such as support triage or sales research. The important property is measurability, not whether the use case sounds sophisticated.
Not necessarily for a first hosted-model workflow. Engineering depth becomes more important when the use case involves sensitive data, complex retrieval, high scale, specialist infrastructure or deep integration with critical systems.
Know what data is being sent, remove unnecessary identifiers, use appropriate business/API terms, restrict access and write down the data handling and deletion path before the pilot begins.
IN SHORT
Turning LLMs, RAG and agents into products that hold up in production.
Read moreFive days to build your own AI-powered MVP, no engineering team.
Read moreContinuous discovery that tells you what to build next.
Read moreA short call to work out whether the problem is strategy, scope or speed.
Work with AndrewTHE FRAMEWORK
MORE ANSWERS
No, but it is removing a large part of what product managers used to spend their week doing. AI already writes specs, summarises research, drafts tickets, analyses feedback and builds prototypes. What it cannot do is decide what a company should refuse to build, hold accountability for a metric, or persuade a room. Roles weighted towards documentation are shrinking; roles weighted towards judgement are becoming more valuable.
Founders need four categories, not forty tools: a frontier chat assistant for thinking and drafting, an AI-assisted build tool for prototypes and MVPs, a research and synthesis tool for customer and market work, and automation for repeated operational tasks. Pick one per category, use it deeply, and add another tool only when a specific recurring task justifies the subscription and context-switch cost.
For a UK founder, a focused commercial AI MVP with one core journey typically sits around £12,000–£25,000 in the pricing model used on this site. A prototype or narrow validation build can be roughly £3,000–£8,000. Multiple user roles, RAG or agentic workflows, several integrations, sensitive-data requirements or bespoke design can push the build above £25,000. Model and infrastructure running costs should be measured separately per successful customer task.
Choose an AI product consultant when the uncertainty is the customer problem, scope, AI use case, evaluation, pricing or what should be built at all. Choose a developer when those decisions are validated and the bottleneck is implementation capacity. Early founders often need a product-led build that combines both: senior product judgement to cut the scope and enough engineering execution to ship the one journey that matters.