Case study 03
Two segments, one device: pricing and roadmap under constraint
Same hardware, two jobs-to-be-done, two subscription ladders — then a V1–V3 roadmap under a rule that bans every partnership. The brief also required showing the AI’s first draft and the corrections that made it shippable.
- Context
- IIM Bangalore · Software Product Management (Assignments 1 & 2)
- Year
- 2026
- Contribution
- Solo
- Frameworks
- JTBD segmentation · Bain Value Pyramid · Crossing the Chasm · MoSCoW × Kano
What this is: IIM Bangalore coursework — a strategy exercise on a hypothetical brief. Not affiliated with, commissioned by, or endorsed by Apple. Every feature, tier and price below is a student proposal, not an Apple product or an Apple price.
The roadmap: MoSCoW × Kano
MoSCoW enforces release strictness (Must = V1, Should = V2, Could = V3); Kano explains why each feature earns its slot.
| Kano \ MoSCoW | Must — V1 core loop | Should — V2 expansion | Could — V3 scale |
Basic expected value | Longevity Score · effort-based screen unlock · automatic effort verification · tamper-resistant activity detection | — | — |
Performance more = better | Joint-load monitoring · recovery-debt indicator | Muscle-retention tracking · cardio efficiency trends · fatigue-aware screen limits · sleep-linked access controls | — |
Excitement delighters | — | Consistency streak metrics | OCR machine-console logging · adaptive deload guidance · adaptive rule engine |
The sequencing logic: V1 buys interpretability and trust (one metric, credible anti-cheat). V2 adds longitudinal depth once baseline telemetry exists. V3 introduces the high-variance components — OCR and adaptive systems — only after robustness has been proven against real gym conditions.