A prototype isn't about proving that my idea is right; it's about learning what's wrong with it before I invest more time and resources.
I note that OKRs define the outcomes we want to achieve.
I note that Objective: What do we want to achieve?
I note that we must not confuse shipping features with delivering value.
I note that Tasks describe the work we need to do.
I note that KPIs help us monitor ongoing performance.
I note that Key Results: How will we measure whether we're achieving it?
I note that a prototype can be: • A simple sketch • Wireframe • Figma clickable flow • Interactive mockup • AI‑generated working interface.
My process flow is: Problem → Idea → Prototype → Test → Learn → Improve → Build.
Product Discovery is not a one‑time phase that ends when development begins.
Metrics should be discussed before building, not after launching.
The hardest part is often deciding what NOT to build.
A feature is not successful because users can use it. It’s successful when it changes a meaningful user behavior or outcome.
I treat prototypes as learning tools rather than validation of an idea.
A prototype isn’t about proving that your idea is right.
It's about learning what's wrong with it before you invest more time and resources.
I complement the “learn before building” mindset with Objectives and Key Results (OKRs) to align teams around measurable outcomes rather than merely shipping features.
- OKRs stand for Objectives and Key Results. ^e1
- Example OKR for a productivity app:
- Objective: Help users consistently make meaningful progress on their goals.
- Key Result 1: Increase weekly users achieving a meaningful goal from 200 to 350. ^e4
- Key Result 2: Improve onboarding completion from 45% to 70%. ^e5
- Key Result 3: Increase four‑week retention from 20% to 30%. ^e6
By separating tasks from outcomes, I avoid the common trap of equating feature shipping with value delivery. I regularly track progress against the Key Results while monitoring KPIs as health signals.
- Objective: What do we want to achieve? ^e2
- Key Results: How will we measure whether we're achieving it? ^e3
A PRD defines the problem, target users, goals, requirements, and expected outcomes of a product or feature.
It creates a shared understanding across Product, Design, and Engineering.
Align stakeholders around a common goal.
Reduce ambiguity and unnecessary rework.
Because AI outputs can be unpredictable, defining how we evaluate quality and handle incorrect responses is just as important as defining the feature itself.
- Expected AI behavior and limitations
- Data and contextual requirements
- Response quality and evaluation
- Hallucinations and failure handling
- Privacy, latency, cost, and safety
The purpose of a PRD is to "align teams, reduce ambiguity, prioritize effectively, and avoid building features that don't solve real problems".
A PRD should be created "after discovery provides enough clarity about the problem and before committing to detailed implementation".
- problem statement
For AI‑first products, a PRD must also define AI behavior, response quality, evaluation, hallucination handling, privacy, latency, cost, and failure handling.
- user stories
- requirements
- scope
- success metrics
- risks
- acceptance criteria
- "Don’t build first. Learn first."
- "Good Product Managers don't just ask “Can we build it?”"
- "They also ask: “What can we learn before we build it?”"
A prototype helps a PM answer: “Are we solving the right problem, and does this solution make sense to the user?”
Process flow: Problem → Idea → Prototype → Test → Learn → Improve → Build
Prototype forms can be: A simple sketch, Wireframe, Figma clickable flow, Interactive mockup, AI‑generated working interface.
Decision: Create low‑fidelity prototypes early to get fast feedback and avoid building unvalidated solutions.
My biggest takeaway is: Don't build first. Learn first.
I reflected on my experience moving from DevOps to AI product management and realized that deciding what NOT to build is far harder than building itself.
- I decided to prioritize not building over building, to define success metrics before development, and to use user interviews as the primary discovery tool.