Field notes
Notes on building AI products: evals, agents, shipping 0→1, and turning a messy problem into a product people keep using. Written by a product manager who builds with AI agents.
I build AI and B2B products from zero to one, using AI coding agents for the build. IIT Kanpur.
See the portfolio- Essays published
- 36
- Words written
- 30.3k
- Topics covered
- 9
The topic map.
Every essay sits in one of nine topics, and every topic in one of five themes. Brighter blocks hold more writing.
AI Product
Strategy, UX and economics of products built on probabilistic models.
Open topic05Agents
Tool use, autonomy and reliability for AI that takes actions on a user's behalf.
Open topic02AI Tooling
How product people use AI tools to think, prototype and ship faster.
Open topicPM Craft
Discovery, specs, prioritisation and metrics: the everyday work of good product management.
Open topicEvals
How to know whether an AI feature is actually good, before and after launch.
Open topicEvery essay.
Filter by theme or search. Press / to jump to search.
Hyperlocal growth stalls on supply coverage before user demand
In hyperlocal marketplaces, funnel drop-offs rarely stem from bad UX. Instrumenting unavailable screens reveals when your real growth constraint is partner density.
A model lineup is a pricing portfolio
OpenAI's GPT-6.1 Terra cuts price 50% while keeping the premium tier intact. The product lesson for PMs building on top of AI APIs is that model choice is cost architecture, not just capability selection.
Human overrides should expire
A manual override can rescue a stuck workflow, then quietly become permanent policy. Give overrides an owner, a reason, and an expiry so exceptions return to deliberate review.
Give agents permissions in steps, not all at once
Giving an agent one broad permission setting makes routine work either risky or frustrating. A permission gradient ties each action to its impact, reversibility, and evidence.
Answer product interview questions with a bet
Strong product interview answers do more than list options. They make a clear bet, show what evidence would change it, and name the next test.
Write the state contract before you automate the workflow
When an AI feature hands work between a model, a person, and software, define which states are real and who can change them. A practical contract prevents silent drift.
What would have happened anyway? The missing line in case studies
A polished launch story shows what happened, not whether the product choice mattered. Use a counterfactual to make the decision, evidence, and trade-off legible.
Mistral Large 4 makes the wait part of the launch
Mistral announced a public API preview for Large 4 while saying the weights would arrive later. That staged release is a product promise about who can test what, and when.
Make AI tools show their work before asking for trust
A fluent answer can hide missing evidence. Design AI interfaces to expose the source, the transformation and the uncertainty behind consequential outputs, so users can verify the part that matters.
Log every action before an agent retries
When an agent times out after taking an action, retrying can duplicate the work. Give every attempted action a durable record, a status and a recovery rule before trusting automation.
Set a failure budget before you read the eval score
A single pass rate hides which failures your product is accepting. Turn an eval into a failure budget with explicit limits, owners and release decisions.
Name the assumption that would kill your product bet
Roadmap bets often list upside and effort while hiding the belief they depend on. Write the disconfirming observation first, then design the smallest test that could change your plan.
Show the decisions, not more screenshots
Screenshots show what a product looked like, but not how a PM made the hard calls. Build each portfolio case around the decision, evidence, trade-off and result a reviewer can inspect.
Write the error budget before you add an AI feature
A product brief for an AI feature should name which mistakes are tolerable, who absorbs them, and what happens when the system runs out of room. Here is a practical way to set that boundary.
Account Aggregator drop-offs happen before the OTP
Fintech onboarding flows treat Account Aggregator as an API pipe and wonder why half the users abandon. The real bottleneck is consent UX, phone number mismatch, and brittle fallbacks.
Voice is an input mode, not the whole interface
Voice products can lower the cost of expressing a request, but the rest of the workflow still needs visible control. Design for corrections, confirmation and a graceful switch back to text.
Treat your prompt library as a codebase, not a folder of text files
Prompts degrade silently when treated as static copy. Version control them, test them against golden inputs, and treat prompt edits like code refactoring.
Give your agent domain actions, not database CRUD
Exposing raw CRUD endpoints to an AI agent leads to brittle multi-step plans and corrupted states. Design coarse-grained domain tools that enforce invariants in code.
Exception queues stall without a named owner
Exception queues often collect unresolved work without making responsibility clear. A practical way to assign ownership, deadlines and the next action in a B2B workflow.
Don't let context switching kill your agent's reasoning
When working with AI agents, context switching isn't just about lost time—it's about the agent losing the thread of the task. Minimize state jumps to keep reasoning robust.
The interface for agentic ambiguity
When AI agents operate in ambiguous territory, the interface needs to explicitly expose the trade-offs, not just the output.
AI product hypotheses as experiments, not roadmap features
When we treat an AI feature as a fixed requirement, we lose the ability to learn. Framing them as hypotheses allows the team to pivot based on real-world reliability.
Keep a decision log beside the PRD
Requirements explain what a team plans to build. A compact decision log preserves why the team chose it, what it rejected, and when to revisit the call.
An agent handoff should carry its evidence
When an AI agent passes work to a person or another agent, a conclusion alone is not enough. A compact evidence packet makes the handoff reviewable and actionable.
The fallback is part of the AI experience
When an AI answer is uncertain, a blank error state leaves users stranded. Design the fallback as a clear next step, with boundaries and a useful alternative.
Ask the coding assistant what it needs before it codes
A coding assistant asked to implement a feature will often choose an approach before the product question is settled. Use it first to map unknowns, constraints and the cheapest useful test.
Why your LLM tests miss edge cases
Testing LLMs like software breaks when the model finds paths you didn't anticipate. A framework for finding the gaps in your eval set.
Who owns the next step in a credit workflow?
A loan application can look complete while the work is stuck between people. Model each state with an owner, an expected next action and an exception path before optimizing for speed.
Decide when your AI agent should stop
An agent spec needs more than a goal and a set of tools. Define what counts as done, when to stop, and what evidence earns another action before it touches user data.
A score is not a priority until something loses
Prioritization scores make options comparable, but they do not make the trade-off. Use a decision note that names the winner, the displaced work, and what evidence could change the call.
Audit your RAG chunks before you tune the model
If retrieval hands the model the wrong passage, no prompt or model swap can recover the answer. Grade your chunks before you tune anything downstream.
Build a map before you claim domain fluency
Moving across product domains is easier when you make your learning visible. Map the user, money, workflow and constraints before borrowing familiar frameworks from your last role.
Your eval set is the real PRD
For AI features, the document that actually decides what ships isn't the spec. It's the list of inputs and the answers you'll accept. Write that first.
Design for the answers your model gets wrong
Most AI UX is designed around the demo, where the model is right. The product people trust is designed around the moments it isn't. Five patterns that help.
Stop asking "can AI do this?" Ask what a wrong answer costs
The capability question is almost always yes, eventually. The question that actually separates good AI product bets from bad ones is the price of being wrong.
Nothing matches that yet. Try another word or layer.
New essays every Tuesday and Saturday.
Follow along on LinkedIn, or get every essay from the subscribe page. No spam, no tracking.