You’ve heard of Romeo and Juliet. You’ve heard of Bonnie and Clyde. This is the story of a slightly more modern, infinitely geekier romance: Me and my AI “Engineering Team.”
Let’s be real: I’m a Product Manager. I’m professionally obsessed with solving problems. And I had a big one: gym tracking apps are an absolute nightmare.
So, I decided to build my own.
- My Role: Product Manager, Designer, QA, and User #1.
- My “Engineering Team”: A brilliant, if unusual, trio of Claude, Gemini CLI, and Codex.
- The Timeline: An absurd 2-week sprint.
- The Outcome: A production-ready iOS app with 15+ features that actually solved my problems.
This isn’t just another side project. This is a story about how the core principles of product management—the frameworks, the thinking, the prowess—are universal. Whether you’re leading a team of 20 human engineers or collaborating with an AI, the job is the same.
And spoiler alert: the AI was a fantastic collaborator.
Act I: The Villain (Or, Why 23 Pain Points is 22 Too Many)
Like any good PM, I didn’t just jump to “I’ll build an app!” I started with discovery. I went to the gym and used the existing solutions (MyFitnessPal, Strong, JEFIT, you name ’em).
After one week, I had a list of 23 documented pain points. I synthesized them into three core problems:
- Progress Loss: You accidentally close the app, and poof—20 minutes of data entry is gone. The emotional frustration was high.
- Feature Bloat: I wanted to track my lifts, not scroll a social feed, log my kale smoothie, or dodge premium upsells. The cognitive overhead was slowing me down.
- Inflexibility: The equipment for my next exercise is taken. Why can’t I swap it for just today without permanently wrecking my routine?
This led to my Jobs-to-be-Done (JTBD) insight. The job I was “hiring” an app to do wasn’t just “track workouts.”
The Real Job: When I’m at the gym with limited time and mental energy, I want to record my workout with zero friction, so that I can focus on lifting and see my progress over time.
The key insight? The job is reducing cognitive load while preserving data.
Act II: The First “Date” (PM Meets Engineering)
I opened Claude and typed the classic, vague, terrible first prompt: “I want to build a gym tracking app.”
This was my first test. Could I, as a PM, articulate a clear vision to my new “engineer”?
I didn’t just dump features. I structured the conversation like a true requirements-gathering session:
- I gave context first: “Here is my exact weekly workout routine.”
- I explained user behavior: “Some days I do variations and need to swap exercises.”
- I clarified the need: “The swap should be for that day only, but it should keep a record.”
The AI, like a good engineer, asked clarifying questions:
- “Should we track sets, reps, and weight?”
- “Should swaps be permanent or one-time?”
- “Should new exercises be saved to a library?”
This is where PM thinking is crucial. I didn’t just say “yes.” I answered with intent:
- My Answer: “Yes, track sets/reps/weight.”
- The PM Why: Because progressive overload is the whole point, and that requires historical data.
- My Answer: “One-time swap.”
- The PM Why: It preserves the routine’s structure (the source of truth) while allowing real-world flexibility.
This is what separates a good PM from a “feature requestor.” I defined the P0s (Must Ship) like core tracking and progress persistence, and deferred the P2s (V2) like charts and an Apple Watch app. That’s scope management.
Act III: The Iteration Dance (And My 7 Bug Reports)
I gave my “design brief” with my signature quirk: “I want your creative style, bro, like a professional one with clean UI, a proper design language.”
My AI teammate translated this PM-speak perfectly:
- “Professional” = Modern iOS patterns (New Glass Design).
- “Clean UI” = Strong information hierarchy, clarity.
- “Design language” = A consistent system, not ad-hoc styling.
It built the app. And… it had 7 bugs.
This is a critical moment for a PM. Do you say “it’s broken, fix it”? No. You provide structured, prioritized feedback.
My “bug report” looked like this: “Here are simple changes:
- The days are not in order; need to fix that
- Even though I do not do the exercise… It’s getting logged
- Some UI elements are not visible…”
Why this matters:
- It’s prioritized (“simple changes” = P0).
- It describes behavior vs. expectation (my “repro steps”).
- It’s actionable, not emotional.
The AI fixed all 7. We were dancing. Then I added a new spec, showing an eye for detail: “In each exercise, I should be able to add more sets or delete, like swipe left to delete.”
This is platform awareness (a native iOS pattern) combined with feature completeness (thinking of both add and delete). It was implemented perfectly on the first try because the spec was crystal clear.
Act IV: The “PM Magic” Moment That Saved My Gains
This is my proudest PM moment of the whole project. It’s all about the “Progress Saving” feature.
It started with my bug report: “Even though I do not do the exercise… it’s getting logged.”
A simple fix, right? But then I thought deeper. I put my user hat on. What was really happening? This wasn’t a bug; it was a missing feature.
I went back to my AI “engineer” with a full-blown user journey.
My V2 Requirement: “First, the user clicks on the day. Clicks on start workout. Then, if he saves and exits, it should just save the progress and not log anything; only after reaching the last exercise and clicking finish workout, then it should log the day.”
This is PM gold. Look what this single requirement defines:
- A Clear User Journey: Click-by-click.
- Behavioral Distinction: “Save and exit” (I’m interrupted) vs. “Finish workout” (I’m done).
- State Management: It defines two states: “in-progress” (temporary) and “logged” (permanent).
- An Implicit Feature: The ability to resume a workout.
My AI partner picked up on it immediately: “They should be able to resume the saved progress next time?”
My reply: “Yes, only if they click on finish at the end, it will log it.”
BOOM. Ambiguity eliminated. Because the requirement was so clear, the AI built the entire resume system, complete with a beautiful orange “Resume Workout” button, without any further back-and-forth.
That is product management.
Act V: The $99 Reality Check (When to Hold ‘Em, When to Fold ‘Em)
The project was flying. The app was working. Then I hit a wall: The Apple Developer Program.
To keep the app on my phone for more than 7 days, I’d have to pay $99/year.
A lesser PM might panic or get emotionally attached to the solution. A good PM stays pragmatic. I ran a quick cost/benefit analysis:
- Option 1: Pay $99. (Con: Questionable ROI for a personal app).
- Option 2: Rebuild every 7 days. (Con: Data loss. A non-starter).
- Option 3: Pivot.
I chose Option 3. I told my “team,” “For now, let’s keep this on hold.” I recognized the constraint, found a (less elegant) HTML workaround for my own use, and celebrated the win. The goal was to solve my problem and prove my PM process, not necessarily to launch on the App Store.
A good PM knows when a pivot is smarter than pushing through a constraint.
The Final “So What?”: My PM Prowess, Unpacked
This 2-week sprint with an AI team proved my core thesis: Product management is a mindset, not a role.
I was applying proven PM frameworks without even thinking about it. That’s when you know you’ve internalized them.
- Design Thinking? I empathized with my own pain, defined the problem, ideated, prototyped, and tested.
- Lean Startup? My build-measure-learn loops were 3-4 days long.
- Kano Model? I knew “tracking sets” was a Basic Expectation, but the “Resume” feature was a Delighter.
- RICE? I instinctively prioritized high-impact, low-effort fixes first.
This project shows my unique approach as a PM:
- Specificity is My Superpower. I didn’t say “add equipment.” I said, “Equipment should be a dropdown with 5 options: Machine, Dumbbell, Barbell, Cable, Kettlebell.” Vague requirements lead to vague products. I don’t do vague.
- Constraints Drive Innovation. The $99 fee wasn’t a failure; it was a forcing function that made me re-evaluate the product’s true value and my own goals.
- Shipping > Perfection. I shipped a V1 that solved my core problems in 2 weeks, rather than spending 2 months building charts and analytics nobody had asked for.
What I actually demonstrated wasn’t just “how to build an app.” It was end-to-end product ownership: from strategic vision and user research all the way to detailed specs, iterative feedback, and metrics-driven validation.
If I can ship a complex, high-quality product by managing an AI, imagine what I can do with a team of brilliant, passionate humans.
The frameworks don’t change. The thinking doesn’t change. The discipline doesn’t change.
That’s what makes a great Product Manager.
Let’s build something together.