The ask, as it landed
A founder message, paraphrased: “Make logging an entry feel alive. Users should feel like they’re building something when they log.”
No spec. No user story. No definition of what “alive” means technically. This is the raw material a PM actually works with, and most of the job happens in the gap between a sentence like that and the first ticket a developer opens.
Getting to the real requirement, before anyone else sees it
Before writing anything down, I ran three clarifying questions with the founder, not the dev team:
- Alive for the person logging, or for people viewing their profile afterward?
- Is “building something” about progress, streaks and counts, or about discovery, rare finds and new categories?
- Is a social layer intended now, or is that a phase-two trap worth naming out loud?
The answer: personal progress first, social aspirational but unfunded this phase. That one exchange kept the team from quietly scoping a social feed nobody had asked for and nobody had budget to build.
Turning it into an epic
Epic: progress system for logged entries. Give users a persistent, visual sense of accumulation from logging activity, without introducing social or competitive mechanics this phase.
Breaking it into stories with acceptance criteria
Story 1. As a user, I want a running count and a simple visual milestone after each entry, so logging feels rewarding immediately.
Acceptance criteria: the count updates and any milestone crossed triggers an on-screen acknowledgment when an entry saves successfully. Progress toward the next milestone stays visible on the profile, not just a static number. If a save fails and the user retries, the count does not double-increment.
Story 2. As a user, I want something I’ve never logged before to look visually distinct from a repeat, so discovery reads as more significant than repetition.
Acceptance criteria: a first-time entry gets flagged as new in the log and in any summary view. A repeat entry counts toward frequency stats without the new flag.
Story 3, flagged as a risk rather than committed: a map view plotting where a user has been active. Marked should-have, not must-have, pending the technical spike below.
Catching the risk before it becomes rework
Map rendering with high-volume location data can degrade on older devices as an account’s history grows. The client never raised this, it surfaced in a conversation with the dev lead during story breakdown. Logged as a RAID entry with a two-day technical spike on clustering and pagination, run before story 3 gets committed to a sprint.
The client never sees this exchange. They see that the map view shipped on time and didn’t lag.
Prioritizing and sequencing
MoSCoW for the phase: count and milestone acknowledgment, and new-entry flagging, both must-have. Map view, should-have, pending the spike outcome. Social feed, leaderboard and sharing, explicitly won’t-this-phase.
Sequenced across four weeks: acceptance criteria finalized with dev while the map spike runs in parallel, the two committed stories built in week two with the spike result feeding a go or no-go on scope, story 3 built at whatever the spike supports (full map or a simplified list-with-location fallback), then QA and stakeholder review.
What the client actually saw
One message back: “Here’s how we’ll make logging feel like progress instead of paperwork. Two features ship in two weeks. The map view depends on a quick technical check we’re running now, so we don’t promise something that ends up feeling slow later.”
No mention of the clarifying questions, the RAID entry, or the prioritization debate. That entire layer stayed invisible. Building it and keeping it invisible is the actual job.