Day in the Life of a Product Manager: Three Real Days

Alarm goes off. I live in a one-bedroom in the Inner Sunset with my cat, a gray tabby named Biscuit who has no interest in my professional life. I reach for my phone. I told myself I wouldn't check Slack before coffee. I check Slack before coffee. There's a Datadog alert from 3:47 AM about latency spikes on the deployment pipeline's webhook endpoint. Our on-call engineer, Felix, acknowledged it at 4:15 AM and said he's investigating. I stare at the thread for 30 seconds trying to figure out if this is my problem yet. It isn't, but it might become my problem if it's still happening by standup.

Coffee from the Chemex. Six-minute process, which is the only six minutes of my day that has a predictable beginning, middle, and end. I eat a banana and read Felix's update: the latency spike was caused by a third-party service (GitHub's webhook delivery system) being slow, not our code. He's monitoring. I feel the small release of tension that comes from learning that a problem is not your problem.

Bus to the office. We have a hybrid policy: three days in, two days remote. I use the commute to clear my inbox. 34 emails overnight. Most of them are notifications from Linear (our project management tool), Notion comments, and a newsletter I keep meaning to unsubscribe from. Two emails actually need attention: one from our head of sales, Marlo, asking when the team permissions feature will be demeable, and one from an enterprise prospect's security team asking about our SOC 2 compliance status. I reply to Marlo with "aiming for mid-April, will confirm after sprint planning Friday." I forward the SOC 2 question to our ops lead, Jenna.

Office. Open-plan, about 40 desks, half of them occupied because it's Wednesday. I sit next to our tech lead, Anika, who is wearing headphones and typing intensely. I do not interrupt Anika when she's wearing headphones. That's an unwritten rule I learned in my first month. I get a second coffee from the office machine, which makes coffee that tastes like someone described coffee to a machine that has never tasted coffee.

Standup. Seven people in a huddle around a whiteboard. Felix updates on the latency issue: resolved, caused by GitHub, no action needed on our side. Anika is working on the team permissions backend. She says she's blocked because the database schema for role-based access needs a migration that touches the billing table, and she wants to make sure it won't break anything for existing customers on the legacy billing plan. I ask how long the migration will take. She says "probably a day, but testing it against all the edge cases is another two." So three days for something I'd mentally budgeted at one. I make a note to update the sprint tracker.

I have a 90-minute focus block on my calendar that I put there last week. I need to write the spec for our upcoming audit log feature. Enterprise customers have been asking for it. The spec needs to cover what events we log, how long we retain them, what the UI looks like, and what the export format is. I open a Google Doc. I write a title, a one-sentence summary, and a section header. Then Slack pings. Marlo, responding to my email, wants to know if "mid-April" means before or after April 15th because the prospect has a board meeting on the 16th. I say "before, but I'll confirm the exact date by Friday." That took eight minutes. I go back to the spec. I write three paragraphs about event taxonomy. Slack pings again. A designer, Risa, sharing a Figma link for the team permissions onboarding flow and asking for feedback. I open the Figma. Spend 14 minutes reviewing it. Leave two comments, one about a button label and one about the empty state copy. Back to the spec. I've been in my "focus block" for 42 minutes and I've written about 400 words of the spec.

1:1 with my manager, Hana. Hana is the VP of Product. She has three PMs reporting to her, and I'm the most senior. We talk about the Q2 roadmap, specifically whether to prioritize the audit log or a SAML single sign-on integration. Both are enterprise features. Both are blocking deals. The audit log blocks two deals worth a combined $180,000 in ARR. The SAML integration blocks one deal worth $240,000. Hana asks which one I'd prioritize. I say SAML, because it's one feature blocking one large deal versus two features blocking two smaller deals, and the SAML integration is less engineering work. Hana agrees but says the CEO, a guy named Leon, has been talking to the audit log customers directly and has promised "something by Q2." I say "Leon promised, or Leon said we're working on it?" Hana says "you know Leon." I do know Leon. Leon's version of "we're working on it" and the customer's interpretation of "we're working on it" are different sentences.

Lunch. I eat leftover pad see ew at my desk while reading a competitor's changelog. They shipped a feature last week that's similar to something on our roadmap. Not identical, but close enough that Marlo will ask about it by end of day. She does. At 4:47 PM. I draft a response at that point.

Customer call. A mid-size fintech company in Atlanta considering our enterprise plan. Their VP of Engineering, a man named Darrell, wants to understand how our deployment pipeline handles rollbacks. I walk through the flow, show the UI, answer his questions about our canary deployment support. He asks about audit logs. I say "it's on our near-term roadmap and I'd be happy to share more details as we get closer." That's PM for "it exists in a Google Doc that I'm 400 words into." Darrell seems satisfied. The call runs 38 minutes.

Design review for the team permissions feature. Risa presents her updated mockups based on the feedback from this morning. The button label issue is fixed. The empty state now says "No team members yet. Invite your first teammate to get started." I suggest adding a line about what team permissions unlock so the user understands the value before they invite. Risa notes it. Anika joins halfway through and asks about the migration timeline again. We go back and forth about whether to do the migration in a maintenance window or as a background job. This takes 20 minutes. The design review was supposed to be 30 minutes. It took 55.

Back to the spec. I add sections on retention policy, export format (CSV and JSON), and access controls. The writing goes faster now because the customer call gave me a better sense of what enterprise buyers actually want to see in an audit log. Darrell's questions about rollback auditing pointed me to a gap in my thinking: we need to log not just what happened but who initiated it and what the state was before the change. That's a more complex data model than I'd originally scoped. I make a note to ask Anika about it tomorrow.

Marlo asks about the competitor's changelog. As predicted. I write a two-paragraph response: their feature covers basic deployment tracking, ours will be more comprehensive with full audit trail and RBAC integration. I include a comparison table. This takes about 25 minutes because I want to make sure I'm representing the competitor's feature accurately and not just saying "ours will be better" without specifics.

Wrap up. Update the sprint tracker with Anika's revised migration timeline. Write a Slack summary in #product-updates: "Team permissions backend on track but migration adds ~2 days. Audit log spec in progress, targeting draft by Monday. SAML vs audit log prioritization TBD pending conversation with Leon." Nobody reacts to the message for 20 minutes, at which point Felix drops a thumbs-up. That's the feedback.

Home. Biscuit is on the couch. My roommate Lena, who works in biotech, asks how my day was. I say "fine, meetings and specs." She says "you always say that." She's right. The gap between the actual complexity of my day and the two-word version I give at home is enormous. But explaining that I spent 55 minutes in a design review debating a migration strategy and then 25 minutes writing a competitive response to a changelog update is not a story anyone wants to hear at dinner. So I say "fine, meetings and specs" and we order Thai food.

Drive to the office. Twelve minutes door to door, which still feels surreal after three years of the G train. The office is in a building that looks like it was designed in 1997 by someone who really liked beige. Fluorescent lights everywhere. The kind that make everyone look slightly unwell. I park in the employee lot, which is free, which is another thing that would have been inconceivable in Brooklyn.

I'm the PM for the claims processing platform. It's an internal tool. Nobody outside this company will ever use it, review it, or tweet about it. There are no Product Hunt launches. There is no press coverage. There are 600 claims adjusters who use this system every day to process auto and homeowner claims, and my job is to make it less painful for them. I open Jira. There are 14 open tickets in the current sprint, 4 are in QA, 2 are blocked on a data feed from the underwriting system, and 8 are in progress. I spend 15 minutes reviewing the QA notes on a ticket about the claim summary page. The QA analyst, a woman named Bev, found that the "estimated repair cost" field is rounding to the nearest dollar instead of showing cents. It's a display bug. It shouldn't be there. I mark it as a P2 and add it to the next sprint.

Standup. My team is me, two developers (Raj and Tina), a QA analyst (Bev), and a business analyst named Curtis who acts as a bridge between us and the claims operations department. Standup is supposed to be 15 minutes. Today it's 22 because Raj discovered that the data feed from underwriting is sending claim type codes that don't match our lookup table. We have 47 claim type codes. Underwriting has 52. Five of their codes don't exist in our system, which means five categories of claims are being bucketed as "Other," which means the reporting that the VP of Claims Operations sees every Monday morning has a suspiciously large "Other" category that she's been asking about for three weeks.

I walk over to the underwriting department, which is on the third floor. Our office is on the second floor. The hallway smells like microwave popcorn. I find the underwriting systems analyst, a guy named Phil, and ask about the five extra codes. Phil says they added them in November as part of a regulatory update and notified our department via email. I check my inbox. There's an email from November 7th, from Phil, with the subject line "Updated claim type taxonomy, effective 11/15." It was sent to my predecessor, who left the company in October. Nobody forwarded it to me. Phil says "I assumed your team would pick it up." I say "we didn't have the email." He says "it was in the shared drive too." It was. In a folder called "Reference Docs 2025" that I didn't know existed. This is the job. The hardest bug to fix isn't in the code. It's in the information flow between departments that don't talk to each other.

I spend an hour mapping the 5 new codes to categories in our system. Three of them map cleanly to existing categories. Two of them are new subcategories of "water damage" that didn't exist before. I need to decide whether to create two new codes in our system or merge them into the existing "water damage" code. If I create new codes, the adjusters need to be trained, the reports need to be updated, and the lookup table in our database needs a migration. If I merge them, the data is slightly less granular but nobody has to learn anything new. I email Curtis and ask how much the claims ops team cares about distinguishing between "interior water damage" and "exterior water damage." Curtis says he'll check with Diane, the senior claims manager. This will take a day.

Weekly meeting with my manager, Lorraine. Lorraine is the Director of IT Product Management. She manages three PMs, each owning a different internal system. I update her on the claim type code issue. She asks how it fell through the cracks. I explain the email situation. She asks me to set up a recurring sync with underwriting so this doesn't happen again. I add "set up cross-department sync" to my to-do list, knowing that scheduling a recurring meeting between two departments that have never had one will require at least three emails, two calendar polls, and a conversation with Phil's manager about why this is necessary. That's probably a week of logistical overhead for a 30-minute monthly meeting.

Lunch in the cafeteria. Turkey sandwich, $4.50. Sit with Tina and we talk about a podcast she's listening to about game design. She draws a parallel between game UX and claims processing UX that's actually insightful: both involve leading someone through a multi-step process where they don't want to be. Nobody files a claim for fun. Nobody plays a tutorial for fun. The design challenge is reducing friction in a process the user is already annoyed to be in. I make a mental note of this.

The big meeting of the day. Quarterly business review with the VP of Claims Operations, a woman named Patti, and two of her directors. They present their priorities for next quarter. Top of the list: a new workflow for catastrophe claims (hurricane, flood, wildfire) that allows adjusters to batch-process similar claims instead of handling each one individually. Patti says that during the last hurricane season, adjusters were processing claims one at a time and it created a 3-week backlog of 2,200 claims. She wants the batch processing feature by September. I ask what "batch processing" means to her, specifically. She says "being able to select 50 claims that are all from the same storm event and approve them with one set of documentation instead of 50 separate sets." I write this down and immediately start thinking about the data model implications. This is not a small feature. This is a new workflow. I tell Patti we'll scope it and come back with a timeline in two weeks.

Debrief with Raj and Curtis about the batch processing request. Raj says the current database schema is designed for individual claims and that batch processing would require a new table structure to group claims by event. He estimates it's a 6 to 8 week build. Curtis says the adjusters would need training, which adds another 2 to 3 weeks. I start drafting the scope document. September feels tight.

The dropdown incident. Bev reports that the new claim status dropdown she's testing has a label that says "Pending Review" but the claims ops team calls it "Under Review." She asks which one I want. I check the style guide. The style guide says "Pending Review." I check the training materials. They say "Under Review." I check what the adjusters actually call it by Slacking Curtis. Curtis says "they call it 'in the queue.'" Nobody calls it either name. I pick "Pending Review" because it matches the style guide and I add a note to revisit the terminology with the claims ops team during the cross-department sync that I haven't set up yet. This took 20 minutes. In a product I'd see on Product Hunt, this is not a decision anyone would notice. In an internal tool used by 600 people who have opinions about every label, it's a conversation I'll have at least twice more.

Drive home. Call my mom on the way. She lives in New Rochelle. She asks if I like Hartford. I say "it's growing on me." She says "you said that six months ago." I say "it's still growing." She asks what I did today. I tell her about the dropdown. She laughs. She works at a nonprofit and says her version is arguing about the font size on a fundraising letter. I tell her about the batch processing feature and she says "that sounds important." It is. Two thousand claims in a three-week backlog is real human stress for real people waiting to fix their flooded basements. My product isn't glamorous. But it matters to someone who's sitting in a soggy living room waiting for a check. I sometimes forget that when I'm debugging claim type codes. The call with my mom reminds me.

My daughter Amara wakes me up. She's four. She doesn't know what product management is. She thinks I "play on the computer," which is not entirely wrong. My wife Keisha is already up, getting ready. She's a physical therapist at a clinic in Brentwood. I make Amara oatmeal with blueberries and check my phone while she eats. There's a text from our CEO, a guy named Barrett, from 11:38 PM last night: "Got feedback from the Haley Homes demo. They love it but need offline mode. Can we talk at 9?" Offline mode. I've been saying we need offline mode for six months. Barrett kept pushing it to "next quarter." Now a customer said it and suddenly it's urgent. I don't reply yet. I need coffee before I engage with Barrett's midnight revelations.

Drop Amara at preschool. Drive to the office, which is a converted warehouse space in East Nashville with exposed brick and a mural of Johnny Cash that someone painted before we moved in. The warehouse is cool-looking but the Wi-Fi is terrible near the back wall, which is where my desk is. I've mentioned this to Barrett four times. He says "we'll fix it next month." It's been four months.

Standup. The team is me, two engineers (Nolan and Georgia), a designer (Pia), and a part-time QA contractor named Luis who works Tuesdays, Thursdays, and Fridays. Today's focus: Georgia is finishing the photo documentation feature, which lets builders take photos on-site and tag them by room, stage of construction, and trade (plumber, electrician, framer). She's working on the tagging UI. Nolan is fixing a sync issue where the app occasionally duplicates entries when the device goes from offline to online, which is ironic because we don't even officially support offline mode yet. The app just kind of halfway works offline by accident, and users have figured this out and are using it in ways we didn't intend.

Call with Barrett about offline mode. Barrett is excited because Haley Homes is a mid-size residential builder in middle Tennessee, 45 active jobs at any time, and they'd be our biggest customer by a factor of three. Their superintendent, a man named Mike, told Barrett that his crews work on rural lots where cell service is spotty and they need the app to work without connectivity. I tell Barrett that offline mode is a 10 to 12 week project. It requires local data storage, conflict resolution for when the device syncs back up, and rethinking our authentication flow. Barrett says "can we do it in six weeks?" I say no. He says "what if we added another engineer?" I say that adding an engineer to a project that's being scoped doesn't make it faster, it makes the scoping take longer. He looks at me like I said something controversial. I didn't. I said something true.

Customer interview via Zoom. A remodeler in Chattanooga named Denise who's been using the app for four months. She runs a 6-person crew and mostly does kitchen and bathroom remodels. I ask her what's working. She says the daily log feature saves her about 30 minutes a day compared to the paper log she used before. I ask what's not working. She says she can't figure out how to add a subcontractor to a project. I walk her through it. It takes seven taps. She says "that's a lot of taps." She's right. The subcontractor flow was designed by someone (me) who has never hired a subcontractor, and it shows. I make a note to simplify it. Denise also says she'd love it if the app could generate a simple invoice from the daily log. I tell her we're considering it. We are. It's item #34 on the backlog.

Lunch from a taco truck parked on Dickerson Pike. Eat at my desk while reviewing Pia's mockups for the offline mode indicator. She's designed a small banner at the top of the screen that says "Working offline. Changes will sync when connection returns." It's clean. I like it. I leave a comment asking her to add a visual indicator for how many changes are queued, so the user knows there's data waiting to sync. This seems small but it matters: if a builder has 15 unsaved changes and their phone dies before it syncs, they need to know that risk exists.

The site visit. This is the part of my job that nobody in PM Twitter talks about. I drive 35 minutes to a job site in Brentwood where one of our customers, a builder named Marcus (different Marcus), is framing a custom home. I put on the steel-toe boots. I walk through the site with his superintendent, Troy, who shows me how they're using the app on an iPad mounted in the job trailer. Troy says the photo tagging feature is "pretty good" but he wishes he could tag photos by which wall they're documenting. I ask what he means. He takes me to a half-framed room and points at a wall and says "I need a photo of this wall before the drywall goes up, and I need to be able to find that photo six months later when the homeowner says the outlet was supposed to be three feet from the corner and it's three feet, four inches." He's describing a spatial documentation system. That's a bigger idea than a tag. I take notes on my phone while standing in a construction site wearing steel-toe boots. This is not what I imagined when I decided to become a product manager.

Drive back to the office. I use the drive to call Nolan about the sync duplication bug. He says he found the issue: when the app reconnects, it's retrying failed API calls without checking if the server already processed them. The fix is adding idempotency keys, which is straightforward but requires touching every API endpoint. He estimates two days. I tell him to prioritize it over the photo tagging polish because the sync issue is causing real data problems for users who are already using the app quasi-offline.

Back at the office. Write up the site visit notes while they're fresh. The wall documentation idea from Troy is genuinely interesting. It connects to something Denise said too, about wanting a record of what's behind the walls. If we could let builders tag photos by room, wall, and construction phase, we'd have a visual history of the building process. That could be valuable for warranty disputes, homeowner handoffs, and code inspections. I write a one-page concept brief and share it with Pia and Barrett. Barrett replies in four minutes: "This is great. Can we show it to Mike at Haley Homes?" I say "let's build it first." Barrett says "even a mockup would be enough." I tell Pia we might need a quick mockup by next week. She says she can do Friday if I give her the requirements by tomorrow. I start writing requirements at 5:15 PM.

Pick up Amara from Keisha's mom's house. Amara tells me she painted a cat today. I tell her about the construction site. She asks if I built anything. I say "not yet." She says "you should build something." She's four and she's right. I drive home thinking about wall documentation and offline sync and the seven-tap subcontractor flow and whether I'll ever work at a company where the Wi-Fi works near my desk.