Do's and Don'ts of Building a Product

Building a product is not about piling on features or chasing the latest technology buzz. The trap is thinking that adding AI, for example, automatically makes your product better. The actual job is to deliver value that users notice and pay for — not to build technical marvels that sit unused.

I have seen this pattern many times in Indian startups. The team rushes to add an AI feature — a chatbot, a recommendation engine, a custom model — without a clear problem statement or validation plan. Months later, the feature underperforms. The cost is high, and the business impact is minimal.

This lesson teaches you how to avoid those traps and build AI-powered products that matter.

AI features must solve real user problems, not just look flashy

When you build AI into your product, start with the customer problem, not the model.

The trap is adding AI as a press release. You put a chatbot on your homepage, call it "AI-powered," but no one uses it because it does not solve their actual pain point.

Ask yourself: If we remove this AI feature entirely, would customers notice or complain? If the answer is no, you are wasting engineering bandwidth and confusing users.

In India, this is especially common. Teams add AI because competitors do, or because "the CEO wants AI." But AI without clear user value is a distraction.

Choose your AI architecture with care: Planner vs Worker roles

A key architectural pattern in AI product design is separating planning from execution. The Planner decides what to do next based on context and goals. The Worker executes the decided action.

For example, if you add a "Price-Drop" tool to an e-commerce agent, the Planner decides when to call it, and the Worker performs the actual price drop action. This separation keeps your system flexible and maintainable.

Avoid static, template-driven chatbots that cannot adapt to dynamic pricing or personalized recommendations. Those are relics of 2015 chatbot architecture and quickly become brittle.

Memory systems enable personalized, persistent user journeys

AI products that remember user preferences and past interactions create more value.

Think about Rajesh, a price-sensitive shopper. His price sensitivity is learned and persists across sessions. To implement this, use short-term memory (e.g., Redis) for session context, and long-term memory (e.g., Postgres) for persistent user profiles.

Indian users expect personalized experiences even in low-bandwidth or intermittent connectivity environments. Memory systems help deliver that.

AI value lies in nuanced, multi-criteria decision support — not just information retrieval

Many Indian products start with FAQ bots telling users where their package is. That is basic. The real margin is in complex, multi-criteria recommendations tailored to user needs.

For example, a mobile phone shopping assistant that filters by budget, display type, camera specs, and battery life simultaneously. Or a content recommender that understands user preferences beyond clicks.

When designing AI features, identify input signals that enable such nuanced suggestions. This is where AI outperforms keyword search or hard-coded filters.

Technology Readiness Level (TRL) is your litmus test for AI ideas

Before committing engineering resources, grade your AI idea’s TRL. TRL 6 means you have a prototype running in an operational environment.

Your CFO cares about TRL because it correlates to risk and ROI. Your ML engineer cares about model accuracy and latency.

If your idea scores low on TRL, scope it down to a 48-hour workshop prototype. Use this fast feedback to avoid building features that won’t ship.

Common failure modes and debugging strategies for retrieval-augmented generation (RAG)

RAG systems combine a large language model (LLM) with external knowledge retrieval. They are powerful but error-prone.

Failure mode 1: Incorrect indexing

If you chunk PDFs without handling tables or images, your context becomes garbled. Use layout-aware chunking tools like Unstructured.io.

Failure mode 2: Embeddings mismatch

Generic embeddings like all-MiniLM-L6-v2 may not work well for domain-specific search, e.g., fashion product search. Fine-tune domain-specific embeddings on your product descriptions.

Failure mode 3: Partial context hallucinations

The model generates answers based on only some retrieved documents, ignoring contradictions. Detect this with faithfulness scores (e.g., TruLens) and prompt the model to state uncertainty when documents conflict.

Debugging workflow

1. Validate retrieval by manually checking top-k documents for relevance.
2. Check embedding similarity scores for proper matching.
3. Audit your prompt templates to ensure instructions like “Do not answer if uncertain” are obeyed.
4. Use tracing tools like LangSmith to monitor your RAG pipeline.

Scoping AI features: build a prototype before you build a custom model

You may be tempted to fine-tune a custom large language model (LLM) for your domain. But before committing months and multiple ML engineers, build a prototype using an existing API like OpenAI.

For example, an Indian HRtech startup considered fine-tuning a custom LLM on salary data. Instead, they built a 3-week MVP using the OpenAI API and tested it with 10 customers. The API-based version solved 80% of their use cases.

Fine-tuning makes sense only if you find a specific failure mode that the base model cannot handle — such as Indian job titles or regional salary conventions — and customers will pay more for it.

AI product strategy must include cost modeling

Every API call, every GPU cycle costs money. Indian B2B customers are cost-sensitive and won’t pay a 3x premium just for AI.

Your AI feature’s unit economics must work at 10x usage. This means caching aggressively, batching requests, and knowing when to fall back to non-AI approaches.

If you add AI for free and usage spikes, your cloud bill can triple overnight. That kills startups.

Test yourself: Scoping an AI feature at an Indian B2B startup

Field exercise: Diagnose failure modes in your AI feature (20 min)

1. List the AI features your product currently has or plans to build.
2. For each, identify potential failure modes:
   • Incorrect indexing or data chunking?
   • Embeddings mismatch for your domain?
   • Partial context hallucinations or conflicting answers?
   • User experience problems hiding model value?
3. Pick one failure mode and design a debugging plan:
   • How will you validate retrieval relevance?
   • How will you audit prompts and outputs?
   • What metrics will you track for user impact?
4. Share your plan with a peer and get feedback.

Meeting Scene: Debating AI strategy at a Bangalore SaaS startup

Where to go next

• If you want to master AI product strategy: AI Product Strategy
• If you want to learn how to run user research on AI features: User Research Methods
• If you want to understand metrics for AI products: Metrics and KPIs
• If you want to build technical fluency on RAG systems: Advanced RAG and Iterative Design