AI has made it faster than ever to go from a product idea to a working prototype. But it's also made it easier to skip the thinking that used to precede it.

This creates twofold problems:

1. Everyone prompting the same idea gets roughly the same output without any strong differentiation.
2. When you're building through a long AI conversation, there's no reliable way to know how much context is being retained and where the tool has drifted.

Palash Somani, Head of Product at Seekho, built a framework called Manthan to encourage structured product building in the AI era. It includes six modules, each corresponding to a step in how product managers used to build before AI took over.

For PMs building with AI tools, Manthan provides a structured sequence that preserves your thinking across every step of the build. The modules below walk through the framework to help you build with more clarity and context.

What is Manthan?

Manthan is a six-module framework built by Palash Somani. It runs as a skill in Claude Code, accessible through slash commands. It's self-paced, so you can work through it on your ideas at your own speed, and push back or adjust at any point.

Every module captures your decisions in a markdown file, so your earlier thinking and context carries forward into every step that follows. Future modules read those files directly instead of going through the complete chat history. This is important for optimizing token usage.

Manthan also includes a Principles Auditor. This is a principles.md file that Claude checks before every response. It works on two kinds of principles:

• Global: Always solve for the user problem you defined; account for what the previous and next screen requires. These apply across every project.
• Local: Insights you unlock mid-session that you want to apply for the rest of the build.

Let's walk through each of the six modules from this framework.

Module 1: Turn your fuzzy idea into defined scope

One of the most common mistakes in AI-assisted product work is building before you've finished thinking. The speed of output generation creates an illusion of progress. But a polished output ≠ a clear output.

Module 1 is designed to break that pattern. It asks you to work through 10 specific fields about your product idea before you build anything:

1. Product name
2. One-line product idea
3. User problem written in the user's own words
4. Jobs to be done (JTBD) that defines a specific trigger, behaviour, and outcome
5. Core loop to explain the sequence of actions a user takes from entry to return
6. Value proposition that this product must deliver to be worth coming back to
7. MVP proof behaviour that would tell you this is worth investing further in
8. Success metrics to know your product is working well
9. What you're not building to establish boundaries
10. Top risks that could make this fail

Once you've filled these in, Manthan challenges your answers and thinking.

If your one-liner sounds more like a category than a product, it shows you what's missing. If your JTBD reads more like a user problem, it draws out the difference. You go back and forth until each field is specific enough to build toward.

The output is a tightened scope document with all 10 fields locked. Every subsequent module reads from this document, so getting it right here matters.

Palash explained this with an example of a learning companion for early-career PMs. When he specified "early career PM" as the user type, Manthan pushed back tagging it as too broad. It also asked questions like: Who exactly? What do they do? How do they behave?

By answering these questions, Palash could define a very specific user archetype as someone who searches for how to run a PRD review the night before and then acts confident in the meeting. He asks safe questions in standups to avoid looking disengaged (markers of early professionals on a steep learning curve). That one behavioural detail (learns in private, performs in public) became a design constraint crucial for every subsequent decision.

Module 2: Ground your scope in real research

With your scope locked in the first module, module 2 validates it against reality. Manthan runs three streams of research using Claude's parallel sub-agents:

• Web research: the broader problem space, existing solutions, and industry patterns
• Company data: your internal metrics, experiment results, and product learnings (connected via tools like BigQuery)
• User research: verbatims and insights from user calls (connected via wherever your team logs qualitative data, like Slack)

When the research is complete, the framework synthesises the findings against your scope document. You get a structured summary of what the web confirms about your thesis, what your company data shows, and what users have actually said.

Your role from here is to make explicit decisions on each finding. You can confirm or reject every insight Manthan shares. What you approve carries forward into every module that follows, and whatever you reject is excluded.

The output is a validated research layer, locked to your scope, that module three reads from directly.

Note: Most AI tools draw on publicly available and documented data, which can skew toward certain markets. If your product is specific to your region, your industry, or your internal user base, add your company and user data for more grounded research.

Module 3: Map what your user feels

The functional job is usually the easiest part to articulate. You're defining what the user wants to accomplish. Module 3 asks you to go two layers deeper, into the emotional and social dimensions of that same job.

This module starts by identifying recurring patterns from module 2 that reveal how users actually relate to the problem. These are behavioural and emotional truths.

Palash's example included themes like:

• Users want feedback on their thinking
• Generic content fails at the moment of need
• Daily, short, and habit-shaped beats long and course-shaped

Each theme should complete this sentence: because users feel or want X, we should design for Y. From these themes, the module creates a 3×3 JTBD grid:

This 3×3 grid also makes the archetype from module one concrete. Instead of a general description of a user type, you now have a map of what that person feels and wants at every stage of the experience, specific enough to test every design decision against.

Module 3.5: Trace every touchpoint of your user's journey

Once you know your JTBD and archetypes, you know what users need to accomplish. The framework creates a user needs map to define what draws them in, what keeps them engaged, where they get stuck, and how they know they're making progress.

The map covers eight dimensions:

1. Trigger: what brings the user to the product in the first place
2. During behaviour: what they need to do and feel while they're in it
3. Feedback: how they know they're doing well
4. Failure state: what they need when the product lets them down or they get stuck
5. Progress signal: how they know they're getting better over time
6. Real-life translation: how the product experience connects to outcomes outside the product
7. Perceived identity: how they want to be seen when they're using your product
8. Time horizon: what they need in week one versus month one

As you work through the needs map, you'll unlock insights specific to your product. These insights shape your downstream decisions and become a part of your local principles file.

Module 4: Cut your feature list down to what actually matters

By module 4, you'll have a well-researched understanding of your target user, their needs, and the space you're building in. This also means you'll also have more potential features than you can or should build. Module 4 allows you to trim this list of features into the most essential ones based on concrete criteria instead of guesswork.

Manthan scores all potential features against five questions to create a Build, Backlog, Kill list:

1. Does it drive the primary success metric you defined in module one?
2. Does it drive retention from day two to day seven?
3. Does it enable monetisation?
4. Is it required for the core thesis to be testable?
5. Does it have zero workaround? Is there no other way for the user to get this value?

Palash demonstrated that with an example of a leaderboard for the PM learning companion app. Leaderboards are common in learning products. But the archetype defined in module one actively doesn't want public accountability because they learn in private. A leaderboard contradicts the product's core behavioural premise.

The archetype and JTBD work from earlier modules make that call fast and defensible. Without it, the leaderboard might have made the list.

Module 5: Lock a design direction that sets your product apart

AI-generated product interfaces tend to look similar with the same muted tones, component layouts, and spatial logic. Without a clear design direction, the tool defaults to the average of everything it's seen.

Module 5 is designed to break that pattern. It helps you brainstorm a unique design direction in three ways:

• Option 1: Name a reference product and describe the feeling of using it, filtered through your archetype. The feeling matters as much as the reference. For example: "Like Duolingo, but calmer. Users should feel energised when they solve a case."
• Option 2: Bring a visual reference from Dribbble, Figma, or any design portfolio. Screenshot something that captures the direction you want, paste it in, and ask Manthan to extract the design principles. You don't need to articulate what you like. The tool will read the visual and name it for you.
• Option 3: Generate a mood board prompt. If you don't have a reference, Manthan can produce a prompt to use in an image generation tool and define what your home screen might look like in terms of colour, layout, and component style before any design work begins.

The output includes colours, tonal register, spatial approach, and the emotional quality you want the interface to carry. This is saved in a markdown file and shapes every screen in the prototype.

Two product teams working in the same space with the same modules but different design references and different archetypes will build completely different products. The differentiation comes from the taste and judgment you bring to this step, not from the tool.

Module 6: Turn your decisions into a clickable prototype

Module 6 turns all your ideas and research into a functional prototype.

Manthan generates a full HTML prototype with every screen, user flow, edge case, and UX copy. This is a navigable prototype you can walk through end-to-end. Review anything that doesn't hold together before investing any engineering effort like user flows that might need reordering or empty states that weren't accounted for.

Alongside the prototype, Manthan generates a set of handoff documents for relevant stakeholders:

• PM handoff: the full product rationale, decisions, and scope
• Designer handoff: visual direction, component notes, wireframes for each screen
• Tech handoff: architecture considerations, integration points, build priorities
• AI engineer handoff: system prompt rules, response constraints, and suggested evaluation metrics for non-deterministic behaviour

In the pre-AI era, the PM's job ended with the PRD. What happened between the PRD and the live product involved significant translation, back-and-forth, and decisions made downstream without the full context of why things were designed the way they were. Manthan closes that gap.

By the time something reaches an engineer, the thinking is documented at every level. Your engineering team gets a brief on what to build and why.

Think first, build fast

Craft has become more powerful in the era of AI. Every PM now has access to the same tools and the same speed. What truly sets products apart is the quality of thinking that goes into them.

The speed of generation has raised the stakes for the quality of thinking that precedes it. Two PMs running the same six modules on the same problem will arrive at completely different products based on their unique archetypes, research contexts, and design instincts.

The framework creates the conditions for structured thinking. What you put into it is what sets your product apart.