I’ve built Snug Tonight — but how will I know if it’s actually working? This stage is about planning how I’ll listen to what parents tell me (and what they don’t), track the numbers that matter, and figure out what to build next.
The morning feedback — those stars, the outfit rating, the wake-ups — that’s my most important data. It tells me the one thing I need to know: did baby sleep well? If a parent tells me “too warm” three nights in a row, I know my recommendation engine needs work for that temperature range.
But morning feedback alone doesn’t tell me everything. I also need to watch what parents actually do in the app, listen to what they say in WhatsApp messages, and figure out where I’m losing them. Those three things together give me the full picture.
How often do parents open the app? Do they come back? Which features do they use? This tells me what is happening.
Morning feedback, WhatsApp conversations with beta parents, and honest reviews. This tells me why things are happening.
Where do parents stop? Which features do they ignore? Where do they leave the app? This tells me where I’m losing them.
Small tests — like changing the onboarding flow or tweaking TOG recommendations. This tells me what to change to make it better.
I've mapped out every event I plan to track to a question I need answered. I'm keeping it simple — something I can set up in a weekend — but complete enough to help me make real decisions about what to fix and what to build next.
I've designed an event taxonomy that maps every tracked action to a specific product question. Events are prioritised into three tiers: P0 (critical for understanding retention and recommendation accuracy), P1 (important for feature adoption), and P2 (nice-to-have for personalisation insights). The taxonomy covers the complete user journey from onboarding through daily use.
Snug Tonight tracks events through: (1) in-app morning feedback stored per-child (built-in to the app), (2) event logging for key user actions across the complete user journey, (3) retention and session tracking via privacy-friendly analytics. Events are tracked at each critical conversion point to identify where users drop off and why.
Not every number matters equally. Here’s how I think about my metrics — starting with the one number I care about most (do parents come back after 7 nights?) all the way down to feature-level details.
| Level | Metric | Target | Why It Matters |
|---|---|---|---|
| Primary Metric | D7 Retention | ≥ 40% | If parents return 7 nights in a row, I've created a habit. This is the single best predictor of long-term product success. |
| Health | Outfit "Just Right" rate | ≥ 85% | Measures recommendation accuracy from morning feedback. If this drops below 70%, the core promise is broken. |
| Health | Feedback submission rate | ≥ 60% | % of users who check the morning feedback. A low rate means the loop isn't working. |
| Engagement | Evening sessions per week | ≥ 5 | Active users should open the app most evenings. Measures habit strength. |
| Engagement | Multi-baby adoption | ≥ 20% | % of parents who add a second baby. High adoption = higher switching cost and retention. |
| Engagement | Wardrobe items per user | ≥ 3 | Parents who build a wardrobe are invested. This is the strongest retention predictor after D7. |
| Growth | Organic share rate | ≥ 10% | % of users who share the link. Word-of-mouth is my primary growth channel. |
| Growth | Onboarding completion | ≥ 80% | % who finish onboarding (name + baby). Drop-off here = friction problem. |
I’m planning three ways to hear from parents — each will tell me something different. The morning feedback is instant and daily. WhatsApp conversations go deeper. And watching what parents don’t do (the features they ignore, the screens they leave) will tell me what I’m missing.
| Aspect | Detail |
|---|---|
| Cadence | Daily — every morning after baby wakes |
| Input | Sleep quality (1–5 stars), outfit feedback (Too cold / Just right / Too warm), night wake-ups counter, optional notes |
| Output | 7-night history grid, sleep quality trends, "just right" ratio, pattern insights (avg rating, % just right, avg wake-ups, pattern detection like "baby runs warm") |
| Data use | Validates recommendation accuracy. Feeds personalised tips. Detects patterns in sleep quality and wake-ups. Signals when to adjust recommendations. |
| Aspect | Detail |
|---|---|
| Cadence | Weekly during Phase 1, monthly during Phase 2 |
| Method | Direct WhatsApp messages and conversations with beta parents |
| Key questions | "Was the recommendation accurate last night?" / "Would you share this with a friend?" / "What's the one thing that would make this better?" |
| Data use | Uncovers emotional drivers, trust barriers, and feature requests that analytics can't reveal. |
Here’s the journey I expect parents to take — from finding the app to becoming someone who uses it every night. At each step, some parents drop off. My job is to figure out where and why.
* Percentages marked with asterisks are step-over-step conversion rates, not cumulative.
Two to four weeks after launch, I’ll sit down and ask: what actually happened? This will be the most honest document I write — because it forces me to look at what I got wrong, not just what went well.
| Category | Questions to Answer |
|---|---|
| 🟢 What went well | Which features got the most positive feedback? What exceeded my targets? What were users surprised and delighted by? What did I ship faster than expected? |
| 🟡 What could improve | Where did users get confused? Which metrics are below target? What did users ask for that I don't have? Where was the biggest funnel drop-off? |
| 🔴 What went wrong | Were there critical bugs? Did any recommendations cause harm (overheating/cold)? Did I miss a major user need? Any technical failures? |
| 📊 Data summary | D1 retention: __%. D7 retention: __%. "Just right" rate: __%. Onboarding completion: __%. Top 3 user requests: 1) ___ 2) ___ 3) ___ |
| 💡 Key insights | What surprised me? What did I believe pre-launch that turned out to be wrong? What user behaviour was unexpected? |
| ➡️ Action items | Top 3 changes for V1.5. Top 3 features for V2. One thing to stop doing. One thing to start doing. |
Based on what I know V1 is missing, what parents are asking for, and where I want to take Snug Tonight — here’s what’s coming next, organised as Now / Next / Later.
I've identified several experiments to run once I have enough post-launch data. Each one starts with a hypothesis and has a clear success metric. Here are the areas I plan to test:
Testing different onboarding flows to maximise completion rate without hurting engagement quality. Measuring onboarding completion and D7 retention.
Testing when and how to prompt for morning feedback to increase the submission rate — the feedback loop is critical to improving recommendation accuracy.
Testing prompts that encourage wardrobe and share feature adoption, since engaged users with invested wardrobes show significantly higher retention.
Testing whether adding guideline attribution to recommendations increases parent trust and long-term retention.
This isn’t a project that ends when I ship V1. Every morning feedback entry, every pattern I spot, every feature request — it all loops back to the beginning. The product gets better because I keep listening.
Example scenarios — these are the types of insights I expect post-launch data to reveal:
| Potential V1 Learning | V2 Discovery Question |
|---|---|
| Morning feedback shows 20% "too hot" in Durban | Are my TOG mappings calibrated for coastal humidity, or just inland dry heat? |
| 70% of parents use city search, only 30% use geolocation | Should I default to city search instead of asking for location permissions? |
| Multi-baby parents retain at 2× the rate of single-baby parents | Should I target multi-child families more aggressively in my marketing? |
| Wardrobe users submit 3× more morning feedback | Is the wardrobe driving engagement, or are engaged users more likely to use the wardrobe? (Correlation vs. causation) |
| NPS comments repeatedly mention "I wish it told me what to buy" | Is shopping integration a retention feature or a growth feature? How should I position it? |
| What I'm Doing | Deliverable | Why It Matters |
|---|---|---|
| Analytics plan | 9-event taxonomy with priorities, mapped to product questions | Engineers know what to instrument. Leadership knows what I'm measuring. |
| Metrics framework | 4-tier hierarchy: Primary Metric → Health → Engagement → Growth | Different stakeholders get the right level of detail. No vanity metrics. |
| Feedback loop design | 3 channels: in-app (daily), interviews (weekly), NPS (monthly) | Quant + qual gives complete picture. Speed + depth at each cadence. |
| Funnel analysis | 7-step conversion funnel with target rates and critical conversion identified | Diagnoses where users are lost. Focuses engineering effort on highest-impact fixes. |
| Post-launch review | Structured retrospective template covering wins, improvements, failures, and actions | Institutional learning. Prevents repeating mistakes. |
| V2 roadmap | Now/Next/Later framework with 12 features across 3 horizons | Shows strategic thinking without over-committing to timelines. |
| Experiment backlog | 5 hypothesis-driven experiments with test designs and metrics | Demonstrates scientific product thinking, not guesswork. |
| Iteration loop | V1 learnings → V2 discovery questions mapping | Shows the lifecycle is continuous. Product work never "finishes." |
This case study documents all 7 stages of the Product Management lifecycle, applied to a real product that solves a real problem for real parents.
| Stage | Documentation | Key Work Demonstrated |
|---|---|---|
| 1. Discovery | User research, persona, competitive analysis | Empathy-driven research, market understanding |
| 2. Strategy | Vision, positioning, business model | Strategic thinking, market positioning |
| 3. Planning | PRD, user stories, acceptance criteria | Requirements definition, scope management |
| 4. Design | Information architecture, design rationale, pivot | Design thinking, decision-making under uncertainty |
| 5. Development & QA | Build summary, architecture, feature delivery, 5 QA review cycles | Technical partnership, trade-off analysis, quality assurance |
| 6. Launch | GTM strategy, channels, pricing, risk management | Market execution, stakeholder communication |
| 7. Measure | Analytics plan, metrics, experiments, roadmap | Data-driven iteration, continuous improvement |
By Katlego Phokela · 2026