Policy : Build AI Products Around User Needs, Not Model Capabilities

Commitment to User-Centred AI Product Development The technology industry has a persistent tendency to build things because it can, and then search for problems those things solve. In most domains this tendency produces waste. In AI it is particularly acute — because the capabilities are genuinely impressive, the demos are compelling, and the enthusiasm is contagious. Teams fall in love with what a model can do and construct use cases around its capabilities rather than starting where every good product starts: with a real user need that is currently underserved. Our commitment is to reverse this pattern — to lead with user need, validate it rigorously, and then ask whether AI is the right tool to meet it.

What This Means Building AI products around user needs means applying standard product discovery discipline to AI initiatives: talking to users, understanding their problems, mapping their current workarounds, and identifying the specific friction that an AI system could relieve. It means validating that the user need is real and significant before building anything. And it means being willing to conclude from that discovery process that a simpler solution would serve the need better than an AI one — because the goal is to serve the user, not to deploy the technology.

Our commitment to user-centred AI product development is built on:

• Discovery Before Delivery – No AI product enters delivery without a documented discovery phase. Discovery includes direct user research, problem definition, current state mapping, and validation that the problem is real, significant, and not already adequately solved. Discovery outputs are reviewed before delivery commitment.
• User Problem Statement Primacy – AI product briefs lead with a user problem statement, not a technology proposal. "We want to build an AI system that does X" is not a valid product brief. "Users experience Y problem, which causes Z consequence, and we believe AI could help by..." is the starting point.
• Jobs-to-Be-Done Framing – We frame AI product opportunities in terms of the job the user is trying to get done. This prevents scope drift toward technically interesting capabilities that do not serve the core user need and keeps the team anchored to what actually matters to users.
• Non-AI Alternative Consideration – As part of discovery, we explicitly consider and document whether non-AI solutions — process change, better tooling, improved data access — could meet the user need at lower cost and risk. AI is chosen deliberately, not by default.
• Prototype with Users – Before building production AI systems, we prototype the user experience with real users. This often reveals that the technically elegant AI solution creates a user experience that is confusing, untrustworthy, or simply not useful — discoveries that are far cheaper to make in prototype than in production.
• Adoption as a Success Metric – We measure user adoption of AI products as a primary success metric. A system that meets its technical specifications but is not used by the people it was built for has failed. Adoption is an outcome of genuinely solving user problems — not a communications or change management challenge to be overcome post-launch.
• Continuous User Feedback Integration – After deployment, AI products maintain active feedback channels to users. Feature development is driven by user feedback and observed behaviour, not by model capabilities that have become technically available. The product roadmap serves the user need, not the model's potential.

Why This Matters AI capabilities that are not anchored to real user needs produce demonstrable outputs and negligible outcomes. Teams invest in building sophisticated systems that users find confusing, do not trust, or simply do not need to the degree assumed. Starting from user need is not a constraint on AI ambition — it is the mechanism by which AI ambition is focused where it can actually deliver value. The best AI products feel effortless to users because they precisely address a real friction — and that precision only comes from deep understanding of user need, not from capability-led design.

Our Expectation Every AI product initiative begins with documented user research and a validated user problem statement. Teams that cannot articulate the specific user need their AI system addresses are not yet ready to build. Building AI products around user needs, not model capabilities, is how we deliver AI that creates genuine Value — not impressive technology that users find no reason to use.