Product Management Frameworks
How modern tech companies decide what to build, for whom, and in what order. The role that bridges customer needs, business goals, and engineering capability.
What is Product Management?
Product Management (PM) emerged as a formal discipline at P&G (1930s brand managers), evolved through tech companies (Microsoft, Apple, Google), and became the central role in modern SaaS companies.
The PM’s job: Define and deliver the right product to the right users at the right time.
What PM is NOT:
- Not a mini-CEO (common misconception)
- Not someone who tells engineers what to build (that’s a manager/tech lead)
- Not a project coordinator (that’s a Scrum Master)
What PM IS:
- The person who understands customer problems deeply
- The person who sets priorities and explains why
- The bridge between business, user, and engineering
As a founder, you ARE the PM for all your products. Knowing these frameworks prevents you from building things users don’t want.
The Product Trio (Marty Cagan’s model)
Every product decision requires three perspectives:
- Valuable — does the customer want it? (PM’s job)
- Viable — does it fit our business model? (PM + Business)
- Feasible — can we build it? (Engineering)
- Usable — can users actually use it? (Design/UX)
The PM ensures all four questions are answered before committing to build.
Discovery vs Delivery
DUAL-TRACK AGILE
────────────────────────────────────────────────────
Discovery Track ←→ Delivery Track
(Continuous) (Sprints / Waves)
→ User interviews → Building validated features
→ Prototype testing → Testing and QA
→ Data analysis → Deployment
→ Market research → Monitoring
→ Assumption testing → Iteration based on data
Goal: Never enter Delivery Goal: Ship reliably
without validated learning what Discovery approved
────────────────────────────────────────────────────
Biggest PM mistake: skipping Discovery and going straight to Delivery. This creates features users don’t use. Your GymOS is correctly parked — no Discovery signal yet.
The Product Discovery Process
Step 1: Opportunity Assessment
Before any feature, answer:
- What problem are we solving?
- For whom specifically?
- How big is this problem? (urgency, frequency, cost of not solving)
- How will we know we’ve solved it?
- What’s the alternative if we don’t build this?
Step 2: User Research Methods
| Method | Best for | How |
|---|---|---|
| User interviews | Understanding problems, context, motivations | 30–45 min conversations, open-ended questions |
| Usability testing | Finding UX problems | Observe users completing tasks on prototype |
| Surveys | Quantifying what you already suspect | 5–10 questions, large sample, structured |
| Contextual inquiry | Observing real work environment | Watch user in their natural context |
| Jobs to be Done (JTBD) | Finding the “job” the product is hired for | ”When I [situation], I want to [motivation], so I can [outcome]“ |
| A/B testing | Comparing two options with real users | Statistical significance required |
| Analytics | Understanding actual behavior | Funnel analysis, retention cohorts |
Step 3: Opportunity Sizing
- TAM (Total Addressable Market): entire market if 100% captured
- SAM (Serviceable Addressable Market): segment you can realistically reach
- SOM (Serviceable Obtainable Market): realistic target in 1–2 years
For DigiTPME: TAM = all Moroccan SMEs (~600,000). SAM = tech-aware SMEs with 10–50 employees in Casablanca/Rabat (~15,000). SOM = 150–300 in Year 1.
Prioritization Frameworks
RICE Scoring
RICE = (Reach × Impact × Confidence) / Effort
| Factor | Description | Scale |
|---|---|---|
| Reach | How many users affected per quarter | Number (e.g., 200 users) |
| Impact | How much does it improve the metric? | 3=massive, 2=high, 1=med, 0.5=low, 0.25=minimal |
| Confidence | How sure are we? | 100%=high, 80%=med, 50%=low |
| Effort | Person-months to build | Number (e.g., 2 = 2 person-months) |
MoSCoW
- Must have: without this, the product fails
- Should have: important but not blocking
- Could have: nice to have if time permits
- Won’t have: explicitly out of scope (this time)
Kano Model
| Category | Description | Example |
|---|---|---|
| Basic needs | Users expect it; absence = dissatisfied; presence = neutral | Login/auth in any app |
| Performance needs | More = more satisfied | Faster lab results in SijiLab |
| Excitement needs | Unexpected delight; absence = neutral | AI-powered anomaly explanation in IEIA |
| Indifferent | Users don’t care either way | Internal implementation details |
Opportunity Scoring (JTBD + Ulwick)
Survey users: “How important is [outcome] to you?” and “How satisfied are you with current solutions?”
Opportunity Score = Importance + max(Importance – Satisfaction, 0)
High importance + low satisfaction = high opportunity.
The Product Roadmap
What it is
A communication tool (not a project plan) that expresses product strategy over time. Shows direction, not a detailed schedule.
Roadmap Types
| Type | Best for | Timeframe |
|---|---|---|
| Now / Next / Later | Early-stage startups | Flexible |
| Quarterly themes | Mid-stage SaaS | 3-month horizons |
| Feature-date roadmap | Committed enterprise contracts | Specific dates |
| Outcome-based | OKR-driven teams | Quarterly outcomes |
Now/Next/Later (recommended for your stage)
NOW (this quarter)
→ SijiLab Wave 3 (Billing, Invoice, Quality modules)
→ DigiTPME diagnostic questionnaire UI
NEXT (next quarter)
→ SijiLab Wave 4 (Reports, Portal)
→ DigiTPME PDF report generation
→ SijilPharma ML fix (overfit R² from 0.31 to 0.7+)
LATER (6+ months)
→ DigiTPME benchmark (cross-SME comparison)
→ SijiLab multi-lab (multi-tenant)
→ NOTQIN IEIA external pilot
Anti-patterns
- ❌ Feature factory roadmap: packed with outputs, no outcomes
- ❌ Waterfall disguised as roadmap: rigid dates 12 months out
- ❌ Roadmap as commitment: stakeholders treat it as a contract
Jobs to be Done (JTBD) Theory
Author: Clayton Christensen (Harvard, 2003), refined by Bob Moesta and Alan Klement.
Core insight: Customers don’t buy products — they hire products to do a job in their lives.
Classic example: McDonald’s milkshakes. Research found customers hired milkshakes for their morning commute (long, thick, can sip slowly, one hand, not messy). Competitors were other milkshakes. But the real competition was… bagels, bananas, and granola bars. The job was “keep me busy and not hungry during a boring 30-minute drive.”
JTBD Interview Questions
- “Take me back to the day you first realized you needed [product]. What was happening?”
- “What were you doing before you found [product]? What was painful about it?”
- “What made you finally decide to switch / buy?”
- “What would you use instead if [product] disappeared tomorrow?”
Applied to SijilPharma
The job pharmacy owners hire ERP software for is NOT “manage inventory” — it’s “not get caught with expired drugs and be able to close my books at month-end without errors.” This reframing changes what features matter most.
Product-Led Growth (PLG)
Definition: A go-to-market strategy where the product itself — not sales and marketing — drives user acquisition, conversion, and expansion.
Examples: Slack, Notion, Figma, Canva, Dropbox.
PLG Mechanics
FREE / FREEMIUM → AARRR funnel
Acquisition: user discovers product without salesperson
Activation: user experiences "aha moment" quickly
Retention: product is useful enough to come back
Revenue: user hits limit → upgrades to paid
Referral: user invites others (viral loop)
Aha Moment
The moment the user first gets the core value. Must happen as early as possible.
- Slack: send your first message to a colleague and they respond instantly
- Dropbox: see your file on multiple devices
- SijiLab: see a patient’s complete lab report generated automatically in 60 seconds
Design your onboarding flow to reach the Aha Moment in <5 minutes.
PLG Metrics
- Time to Value (TTV): time from signup to first Aha Moment (lower = better)
- Product Qualified Lead (PQL): user who has experienced enough value to be sales-ready
- Activation Rate: % of signups who reach Aha Moment
- Feature Adoption Rate: % of users using a specific feature
The North Star Metric
One single metric that best captures the core value your product delivers to users. Everything else is either a leading indicator (inputs) or lagging indicator (outputs) of the North Star.
Examples:
| Company | North Star Metric |
|---|---|
| Airbnb | Nights booked |
| Spotify | Time listening per user per day |
| Slack | Daily active users who sent messages |
| Messages sent per day | |
| DAU (Daily Active Users) |
For your products:
| Product | North Star Metric |
|---|---|
| SijiLab | Lab requests processed per month |
| SijilPharma | Prescriptions dispensed per pharmacy per month |
| DigiTPME Diagnostic | Diagnostics completed and converted to paid action |
| NOTQIN IEIA | Energy anomalies identified + acted upon |
Product Analytics Stack
| Layer | Tool | Purpose |
|---|---|---|
| Instrumentation | Mixpanel, Amplitude, PostHog (OSS) | Track user events and flows |
| Funnel analysis | Funnel charts in Amplitude | Where do users drop off? |
| Retention analysis | Cohort tables | Who comes back after Day 1, 7, 30? |
| Session replay | FullStory, Hotjar | Watch real user sessions |
| Error monitoring | Sentry | Track client-side errors |
| Feature flags | LaunchDarkly, Unleash (OSS) | A/B test and gradual rollouts |
For your current scale: PostHog (open source, self-hosted) covers everything. Add it to SijiLab and DigiTPME diagnostic from day one.
Product Spec Formats
PRD (Product Requirements Document) — what you already use
Captures: problem statement, user stories, functional requirements, non-functional requirements, acceptance criteria, open questions.
One-Pager
Shorter: problem, solution, why now, success metrics, risks. Used for quick alignment before writing a full PRD.
User Story Map
Visual: personas × journey stages × stories. Helps see the whole product as a user flow.
Connecting to Your Role
As a founder-PM-engineer:
- Wear the PM hat during Discovery (interview users, shape features, say no)
- Wear the engineering hat during Delivery (write code, review PRs)
- The danger: you’ll be tempted to skip Discovery and build what you imagine users want
- The discipline: minimum 2 user interviews per wave before writing any code for new features
See Also
- Agile & Scrum
- OKRs — Objectives & Key Results
- Lean Startup & Business Model Canvas
- SaaS Business Model & Metrics
- DigiTPME Diagnostic Platform
- DigiTPME MVP — Product Specification v1
- Product Strategy