בית
למידה
קורסים
וובינרים
עוד
PM × AI
בוחר לך את הצפייה הבאה
למידה
קורסים
שירותים
וובינרים
EN
עב
צור קשר
ניווט
למידה
כל התוכן
רוב התוכן כתוב באנגלית.
← חזרה למפה
כל התוכן
חיפוש
הכול
מאמרים
סרטונים
סקילז
נושאים
AI Basics
AI for PMs
Career
Claude
Claude Co-work
Claude Co-Work
Claude Code
Claude Skills
Discovery to MVP
Git
Idea to MVP
Job Hunter
Prioritization
Product Builder
Product Discovery
Product Management
Product Sense
Roadmap
Skills
Vibe Coding
Webinar
Webinar recording
13 תוצאות
החדשים
א–ת
סקיל
idea-to-mvp
Use when a product manager has a product idea and wants to turn it into an MVP requirements doc — e.g. "I have an idea for…", "help me scope/spec an MVP", "write a PRD for…", "validate this product idea" — or wants to resume a flow (a product/<slug>/00-status.md exists in the workspace).
סקיל
pm-intake
Use when a product manager starts exploring a new product idea that hasn't been scoped yet (no product/<slug>/ folder exists for it), or asks to kick off idea discovery. Step 1 of the idea-to-mvp flow.
סקיל
pm-users
Use when identifying who a product idea is for — user segments, users vs. paying customers, target audience, "who is this for" — or when 01-intake.md exists but users haven't been defined. Step 2 of the idea-to-mvp flow.
סקיל
pm-use-cases
Use when defining what target users are trying to accomplish and where it hurts today — use cases, jobs, pain points — before any feature discussion, or when 02-users.md exists but use cases don't. Step 3 of the idea-to-mvp flow.
סקיל
pm-alternatives
Use when assessing how target users solve their problem today — competitors, substitutes, manual workarounds — and where those fall short, or when 03-use-cases.md exists and current-market context is needed. Step 4 of the idea-to-mvp flow.
סקיל
pm-solutions
Use when generating and comparing multiple solution directions for validated use cases before committing to one — solution brainstorm, concept exploration — or when use cases exist but no solution has been chosen. Step 5 of the idea-to-mvp flow.
סקיל
pm-mvp-cut
Use when deciding what is in and out of an MVP — prioritizing a feature list into must/later/won't, scoping v1, "what's the smallest version" — or when a solution direction exists but scope is undefined. Step 6 of the idea-to-mvp flow.
סקיל
pm-validation
Use when defining how to know an MVP worked — success metrics, north star, riskiest assumptions, kill criteria, validation plan — or when MVP scope exists but success is undefined. Step 7 of the idea-to-mvp flow.
סקיל
pm-prd
Use when assembling a final lean PRD / MVP requirements doc from completed discovery docs, or when a PM asks to "write the PRD" after idea-to-mvp steps (product/<slug>/ docs 01–07 exist, fully or partly). Step 8 of the idea-to-mvp flow — core steps end here; an optional Lean PMF search (steps 9–11) can follow.
סקיל
pm-lean-canvas
Use when mapping out the full business model — channels, revenue, cost, key metrics, unfair advantage — for an idea, or when 08-prd.md exists but no lean canvas yet. Step 9 of the idea-to-mvp flow (Lean PMF search).
סקיל
pm-customer-discovery
Use when designing customer discovery interviews to test problem/customer assumptions, or synthesizing findings from interviews already run, or when 09-lean-canvas.md exists but discovery hasn't started. Step 10 of the idea-to-mvp flow (Lean PMF search).
סקיל
pm-pmf-signal
Use when defining how you'll know product-market fit has been reached — PMF survey, retention target, go/no-go threshold — or when 10-customer-discovery.md exists but no PMF signal plan yet. Step 11, final, of the idea-to-mvp flow (Lean PMF search).
סקיל
roadmap-prioritizer
Turns an existing codebase into a prioritized roadmap. Reads the project's code and docs to establish a status per feature (shipped, in progress, planned), generates fresh opportunity ideas the code only hints at, gets the user's sign-off on the combined list, then recommends which prioritization model actually fits this situation — RICE, MoSCoW, Now/Next/Later, or Kano — instead of defaulting to one. Runs the chosen model as an interactive conversation in plain language (no jargon or spreadsheets required from the user) and writes a roadmap doc with status and priority per feature, rationale, and a dependency-aware build order.