GARETT HARPER · PRODUCT CINCHPRODUCT CINCH
A personal operating system for managing product work across brands, platforms, and communication channels.
I had a mature process for items once they entered the product queue. What I was missing was the same structure for everything around it: meeting follow-ups, stakeholder requests, Jira updates via email, ad hoc asks, administrative work, and product discovery.
Jira managed the product queue. Nothing managed the rest of my PM workload.
Shared development work already had intake, scoring, sizing, priority, status, and sprint visibility. Everyday product work was still scattered across conversations, inboxes, transcripts, and memory.
Already in the queue
- Jira ticket
- BRICE scoring
- T-shirt size
- Priority and due date
- Sprint status
Still unmanaged
- Meeting action items
- Stakeholder requests
- Admin work
- Pre-sprint discovery
- Ad hoc follow-ups
I was managing the system instead of the work.
A request could come from any brand, on any platform, through any channel. The work itself was manageable; the constant verification was not.
The information already existed. It just wasn't actionable.
Krisp was already recording meetings, producing transcripts, and surfacing action items. The gap was that those action items had nowhere operational to go.
“Can you follow up on the app-store item and make sure the stakeholder update goes out this week?”
Task: Follow up on app-store item
Context: stakeholder update
Status: New
Every request needed one destination.
I chose Airtable as the source of truth and designed ingestion paths around the channels used daily, including a workaround for corporate restrictions that prevented Claude from connecting directly to Outlook or Teams.
Capturing work wasn't enough. The system had to help me decide.
New items were highlighted after each scan, and Claude prompted me for the metadata needed to make them actionable: due date, priority, and scope. Airtable then organized the work into a ranked queue.
Due date? Priority? Size?
I stopped managing the database. I started talking to it.
Once Airtable had the structure, Claude became a natural-language interface over the workload.
A ranked backlog still didn't tell me whether the week would fit.
After capture and prioritization were working, the next problem became capacity. I needed the prioritized work to land on my calendar around existing meetings.
The systems eventually became one work surface.
Airtable held the truth. Claude handled capture and orchestration. FlowSavvy turned priorities into time. But I still needed one place to run the day.
24
7
3
11
Ranked workload with priority, scope, due date, and links to Jira or docs.
Meetings and time-blocked work in one view.
Ask what's next, start the day, end the day, or generate a weekly summary.
Ask about your action items…Blocked, overdue, or missing metadata surfaced before they disappear.
Interactive demo with sample data: demo.garettharper.com
From managing the system to managing the work.
- Requests scattered across channels
- Repeated verification and context switching
- Friday status reconstructed from memory
- Task list separate from calendar
- One ingestion path into Airtable
- Ranked priorities and structured metadata
- Daily and weekly summaries generated from completed work
- Backlog connected to a time-blocked week
The best automation leaves the right decisions manual.
Pick which system gets to be right, and make everything else a mirror or downstream view.
Corporate tool constraints were part of the system, so the manual path needed to be intentional.
AI can capture, extract, organize, draft, and summarize. Priority and external communication still deserve review.