Featured Work
I. PRD.ai : Feature-Level Documentation Intelligence Engine
PRD Intelligence Engine is a lightweight AI-powered prototype that transforms rough product ideas into structured Product Requirement Documents in seconds.
Watch Demo Video -
Live Prototype -
Lightweight client-side prototype demonstrating structured generation logic (no backend integration).
Problem
As a Product Manager, I’ve spent countless hours writing PRDs. On average, it can take 5–10 hours a week to draft, structure, refine, and align on a single feature document. The work is important but much of it is repetitive:
-
Rewriting similar executive summaries
-
Reframing known user problems
-
Structuring user stories
-
Formatting functional requirements
-
Ensuring no critical section is missed
When documentation isn’t structured well, the impact is immediate:
-
Engineers come back with clarification questions
-
Sprint planning gets delayed
-
Teams interpret scope differently
PRDs are critical for alignment but the drafting process is largely manual and template-driven. That inefficiency felt like an opportunity.
Opportunity
Most PRDs follow a predictable structure. So I asked:
-
What if documentation sections were modular?
-
What if structured inputs could generate a strong first draft?
-
What if we could compress drafting time from hours to minutes?
The hypothesis was simple:
A structured, AI-assisted drafting workflow can dramatically reduce documentation time while preserving clarity and rigor.
Solution
I built PRD.ai, a lightweight prototype that generates structured PRD drafts based on a few core inputs:
-
Feature name
-
Description
-
Target users
-
Primary goal
Users can select which sections they want (Executive Summary, Problem Statement, User Stories, etc.), generate a draft instantly, and export it as Markdown. This project focuses on workflow acceleration, not just AI novelty.
Important clarification: This version simulates structured AI generation logic. A production version would integrate OpenAI API for real-time contextual drafting. I intentionally scoped this as a client-side prototype to validate the concept before investing in backend or API infrastructure.
Key Product Decisions
1. Modular Sections Instead of Full Auto-Generation: PMs don’t always need a full PRD. Sometimes they just need user stories or success metrics. Giving users control over which sections to generate increases flexibility and mirrors real-world workflows.
2. Structured Template Logic (Prototype Phase): Instead of integrating a live AI API immediately, I used structured dynamic generation logic. Why?
-
Zero API cost
-
Safe for public deployment
-
Faster iteration
-
Clear demonstration of concept
This allowed me to validate the workflow before scaling complexity.
3. Fully Client-Side Architecture: The app runs entirely in the browser.
-
No backend
-
No database
-
No authentication
-
No API keys
This made deployment simple and eliminated operational overhead while showcasing product thinking and execution.
4. Markdown Export: PRDs are often shared in GitHub, Notion, or internal documentation tools.
Supporting Markdown export makes the output immediately usable — not just visible.
Trade-Offs
This was a deliberate prototype, not a production product. Here is what I chose to give up, and why.
-
Template logic instead of a live AI model: What I gave up: drafts are predictable but less tailored to each feature. Why: it costs nothing, is safe to make public, and let me test the workflow before paying for anything. I'd revisit it when: people tell me the drafts need heavy editing. Then I'd connect an AI API.
-
Everything in the browser, with no saved history: What I gave up: it can't remember past PRDs or personalize results. Why: there's nothing to secure or maintain, and nothing is stored about users. I'd revisit it when: users want to return to earlier drafts.
-
Open access with no login: What I gave up: no control over who uses it. Why: it's a demo with no sensitive data, and a login would only slow visitors down. I'd revisit it when: it handles real company information.
I prioritized speed, zero running cost, and proving the concept over production-grade infrastructure.
Deployment and Technical implementation
This prototype was built as a fully client-side web application using HTML, CSS, and JavaScript, and deployed via Netlify. The source code is publicly available on GitHub to demonstrate implementation transparency and architectural decisions. The application runs entirely in the browser with no backend dependencies, API calls, or database integrations, a deliberate choice to validate workflow value before investing in infrastructure.
Success Metrics and What's next
This prototype doesn't track usage. In a pilot, these are the measures I'd use.
-
Main measure: time taken to go from a rough idea to a first draft the PM is happy to share.
-
Supporting measures: clarification questions from engineers per PRD, share of generated sections kept with only light edits, and sprint planning delays caused by unclear requirements.
-
Safety check: how often a faster draft was later found to be missing a critical section or leaving scope unclear. If that number is high, speed is coming at the cost of quality.
-
What I'd do next: Connect a real AI model, once testers say the template drafts need heavy editing. Test it with real PMs and compare drafting time with their usual process.
II. Release Readiness Copilot
A simple tool that helps teams make a clear go / no-go call before a release.
Watch Demo Video -
Live Prototype -
Problem
In several organizations I worked in, go/no-go decisions were rarely written down in a consistent way. Some teams tracked things in Excel, and many decisions were made in face-to-face conversations. Important points were sometimes missed, and it was hard to look back and see why a decision was made.
Opportunity
Release managers, QA leads, and product owners need one shared view of release risk, the same criteria applied every time, and a written record of the decision. This matters most in regulated areas like healthcare and pharma, where you may have to explain why you released.
Solution
You enter eight release signals, such as test results, open bugs, and compliance status. The tool gives you:
-
a Go, Conditional Go, or No-Go verdict with a readiness score
-
a plain-language explanation for each check
-
a "What would change it" list showing what to fix, in order, to move toward Go
-
a stakeholder view that shows only the decision, the reasons, and the recommended action, with a memo you can copy or print
-
an Override this call option, where the team can choose a different decision but must write a reason, which appears in the memo
Key Product Decisions
-
Some issues always block a release. An open critical bug or an open security or compliance issue means No-Go, no matter how good everything else looks.
-
Three outcomes instead of two. Real teams sometimes ship with a clear plan to handle known risks, so "Conditional Go" reflects that.
-
Every verdict is explained. The tool supports people's judgment. It doesn't replace it.
-
Two views for two audiences. Teams enter data. Stakeholders just need the decision.
-
Plain words everywhere. Each input has a one-line explanation, so non-technical people can use it without training.
-
People keep the final call. The tool gives every release the same starting point, but the team can override it. An override needs a written reason, and it shows up in the memo. Without this, people would either ignore the tool or adjust the inputs until it said what they wanted.
Trade-Offs
-
Simple rules instead of a prediction model: What I gave up: the scoring is my judgment, not learned from data. Why: I had no past release data, and people trust what they can read and check. I'd revisit it when: I can compare scores against real release outcomes.
-
Manual entry instead of connecting to tools like Jira: What I gave up: more typing for the user. Why: it stays free and works instantly, with no setup. I'd revisit it when: people say the typing is the main obstacle.
-
Fixed scoring instead of custom settings: What I gave up: teams can't adjust weights or thresholds. Why: I built adjustable settings and a strictness toggle first, then removed them. There was no evidence anyone needed them, and they made the tool harder to explain. I'd revisit it when: real users ask for different standards.
-
Letting people override the tool: What I gave up: the tool's call isn't final, so a poor decision can still be made. Why: today, disagreements get settled quietly in meetings. Here they're visible, need a reason, and are recorded. I'd revisit it when: overrides become common. That would tell me the scoring needs fixing.
Deployment
It's a single web page hosted for free on Netlify, with my own address under my domain. It runs completely in the browser, so no release data is stored or sent anywhere. That matters when release information is sensitive.
Technical Implementation
-
Built with plain HTML, CSS, and JavaScript. No frameworks and no build step.
-
Each check is scored as pass, watch, or fail, and the points are added up to a score out of 100.
-
The "What would change it" list fixes blockers first, then the biggest point gains, and recalculates the verdict after each step.
-
Works on phone and desktop, in light and dark mode, with a sticky verdict bar on mobile.
Success Metrics and What's next
This prototype doesn't save any decisions, so none of this is tracked today. In a pilot, these are the measures I'd use.
-
Main measure: share of releases with a written, criteria-based decision.
-
Supporting measures: time taken to reach a go/no-go decision, bugs found after release, and number of rollbacks.
-
Safety check: how often a release was cleared but later had a serious incident.
-
Override check: how often the team overrides the tool, and how those releases turned out. A high override rate is a signal to review the scoring.
-
What I'd do next: Save each decision with who made it and when, so the override rate can actually be measured. Test it with real release teams and compare the scoring against past releases and incidents.