I'm a product manager with a mechanical engineering background. I write PRDs, not Python. I architect systems, not servers. And yet, in 2025, I shipped a working AI planning tool called InstantPlan — live at instantplan.online.
Here's exactly how I did it, why I did it, and what I learned. No hype. No gatekeeping.
The problem I was solving
Every PM I know wastes time on the same thing: turning a rough idea or a meeting into a structured plan. You know what needs to happen — kick-offs, PRDs, timelines, stakeholder alignment — but organizing it takes hours.
I was doing it manually, every week, for years. I kept thinking: this is a pattern-matching problem. LLMs are good at pattern-matching. Why isn't there a tool that just does this?
I looked around. Nothing fit. Existing tools were either generic AI assistants (too broad) or project management software (too heavyweight). Nobody had built the thin layer in between — take "I want to launch a feature" and return a structured 30-60-90 plan you can execute.
So I decided to build it myself.
The decision: build vs wait
The honest version: I could wait for someone else to build it, or ship a version that proves the concept.
I chose to ship. Here's why that matters for any PM reading this:
Building something — even a rough version — forces clarity that planning never does.
The moment I started building InstantPlan, I had to answer questions I'd only been vague about:
- What exactly does the user input?
- What exactly does the output look like?
- What's the failure mode when the LLM misunderstands?
- Who is the primary user — a solo PM or a team?
Two weeks of building answered these faster than two months of discovery would have.
The stack: no engineering degree required
| Layer | Tool | Why |
|---|---|---|
| LLM backbone | Claude API (Anthropic) | Best instruction-following for structured output |
| Frontend | Next.js + Vercel | Deploy in minutes, zero server management |
| UI components | shadcn/ui + Tailwind | Production-grade, no designer needed |
| Prompt logic | Custom system prompts | The real IP — PM thinking baked in |
| Prototyping | Claude Artifacts | Test prompt ideas before writing code |
| Version control | GitHub | Non-negotiable, even solo |
Total infrastructure cost: ~$0/month to start (within free tiers).
How I approached the prompt architecture
This is where I spent 80% of my time. The mistake most people make: they treat the LLM as a magic box. That's not product thinking. That's wishful thinking.
I approached the prompt as a PRD.
My process:
-
Define the output format first. Before writing a single line of prompt, I wrote what the ideal output should look like. Sections, headings, depth, tone. Treated like a product spec.
-
Work backwards from failure. What are the 5 ways this output could be wrong? Too generic. Wrong scope. Misses key stakeholders. Wrong timeline. Confusing structure. Then I wrote the prompt to prevent each failure mode.
-
Iterate in Claude Artifacts before building. Tested 20+ prompt variations entirely inside Claude — no code, no deployment. Only when output was consistently right did I move to actual code.
-
Use structured output. Forced JSON output from the LLM and rendered it on the frontend. Decouples the AI layer from the UI layer. Debugging is 10x easier.
The system prompt architecture I landed on:
Role definition → Context about the user →
Output format spec (JSON schema) →
Constraints and guardrails →
Examples of good and bad output
Same skills as PM work. Different application.
The build: 4 weeks in reality
Week 1 — Prompt design 20+ iterations in Claude chat. Got consistent output quality before writing code.
Week 2 — MVP build Scaffolded Next.js, integrated Claude API with streaming, basic UI, deployed to Vercel on day 3.
Week 3 — Edge cases Failure states, copy-to-clipboard, mobile responsive, input validation.
Week 4 — Build in public Shared on LinkedIn. First users gave feedback. Two things broke immediately. Fixed them. Shipped again.
Total time: ~60-70 hours across evenings and weekends.
What build in public actually means
It does not mean sharing a polished product and pretending it was easy.
It means showing the real arc: the original idea, the first ugly version, the specific problems, what you changed and why, what's next.
I started sharing InstantPlan before it was finished. The first LinkedIn post showed a screenshot of the output — rough, no styling, just the data. The response told me whether the concept was worth continuing.
It was.
What I learned building as a non-engineer PM
1. The prompt is the product. The UI is packaging. Invest in output quality first.
2. Ship ugly, fast. The gap between "not done" and "done" is infinite. "Ugly live" to "polished live" is fixable.
3. Claude Code changes the game for PMs. I used it for implementation — not to generate code I don't understand, but code I review and can modify. The PM who can direct AI to build is a force multiplier.
4. Building is the best user research. The friction points in building are often the friction points for users.
5. Non-engineers have a PM advantage. I think about user flow, edge cases, and output quality differently. I'm not faster at building. But I'm better at defining what to build and knowing when it's good enough.
What's next for InstantPlan
- Team collaboration: shared plans, comments, version history
- Templates by planning type: product launch, sprint planning, OKR setting
- Notion and Jira export
- Voice input: describe your project out loud, get a plan back
I'm building this in public. Follow along:
- Tool live at instantplan.online
- Weekly updates on LinkedIn
- Full portfolio at sujitbuilds.com
Sujit Chankhore is an AI Product Manager and founder based in Pune, India. 42,000+ users across 26+ institutions. Open to Senior AI PM and Director of Product roles globally.