What Product Management Is Actually Like

How did you end up in product management?

Through the back door. I was a customer support lead at a B2B SaaS company in Seattle for three years. And at some point I realized I was logging the same bugs every month. The same complaints, the same workarounds I'd write up for customers, the same feature requests that went into some Jira backlog and disappeared. So I started tagging all the support tickets by theme and sending the product team a weekly summary. Nobody asked me to do this. I just got tired of typing the same response to the same broken thing and figured if I organized it well enough, someone might actually fix something.

After about six months of that, the VP of Product, a woman named Carla, pulled me into a one-on-one and said "you're basically doing half a PM's job already, do you want the other half?" I said yes before she finished the sentence. Spent a year as a junior PM there, then got recruited to Portland for this role.

What does a typical day look like for you?

OK so there isn't really a typical day, which is part of the problem and also kind of the appeal? But let me walk through last Thursday because that was, like, instructive. I got in around 8:45. First thing I did was check Slack, and there were already 14 messages in the #product-eng channel. Patrick, our CTO, had sent a message at 1:07 AM that said "quick thought on the batch payments flow" followed by four paragraphs. Patrick's quick thoughts are never quick. They're fully formed opinions disguised as questions, and if you don't respond to them by 9 AM, he'll bring them up in standup as if they're already decided.

So I spent about 30 minutes reading Patrick's message, figuring out what he was actually proposing, and writing a response that acknowledged his idea without committing to it. That's a skill they don't teach you anywhere, by the way. How to say "interesting, let me think about that" in a way that doesn't mean "yes" but also doesn't trigger a 45-minute debate at standup.

Then what?

Standup at 9:30. We run two-week sprints. We're on day 4 of this sprint. My squad is me, Mei, who's the engineering manager, four engineers, and Dev, our product designer. Mei has been at the company since the founding. She's brilliant and she's protective of her team's time in a way that I respect but also find challenging, because my job is partly to ask her team to do things and her job is partly to say "that's more work than you think."

Standup took 22 minutes, which is too long. The reason it took too long is that one of the engineers, a guy named Ravi, mentioned a performance issue with the invoice rendering endpoint. Ravi brought it up as a "just so everyone knows" thing, but Mei immediately flagged it as a potential blocker for the batch payments feature we're shipping next week. And now we're in a conversation about whether this is a P1 bug or a known limitation, and whether we need to pull someone off the current sprint work to investigate. I'm watching this happen and thinking, OK, if this is real, the batch payments launch slides by at least three days, which means the demo for our biggest prospect is either delayed or I'm demoing something half-finished.

After standup I spent about an hour with Dev reviewing mockups for a new dashboard. Dev came from RISD and he makes genuinely beautiful designs. The problem is that beautiful and buildable aren't always the same thing. He wanted this animated chart transition where the bars sort of grow upward as you scroll, and I had to explain that the frontend team would need about two extra days for that animation and we don't have two extra days. He looked disappointed. I felt bad. That's, like, 15% of PM. Making someone's work slightly worse because of constraints they didn't create.

You mentioned a roadmap presentation that went sideways?

Yeah. So two weeks before this, I'd put together the Q2 roadmap. I'd scoped everything with the engineers individually. I thought I had solid estimates. The biggest item was migrating our payments API from the legacy Stripe integration to the new Stripe API. I'd scoped it at four weeks based on conversations with two of the engineers.

We had a company all-hands where I was presenting the Q2 plan. I'm three slides in, I get to the API migration, and Mei raises her hand. In front of 60 people. And she says, very calmly, "I think the API migration is closer to ten weeks, not four, because of the webhook handling for recurring invoices." And the room goes quiet. Patrick is looking at me. Our head of sales, a woman named Dana, is looking at me because she's been telling prospects that batch payments with the new API will be live by June.

And Mei was right. I'd scoped the migration without fully understanding a dependency on how we handle webhook retries for subscription billing. There's a piece of legacy code that two of the engineers didn't write and nobody fully understands, and migrating around it is genuinely complex. I should have known this. I should have asked Mei before the all-hands, not just the individual engineers. But I didn't, and instead I got corrected in front of the entire company, and the next three days were me and Mei and Patrick in a room re-scoping the whole quarter.

How did that feel?

Terrible. Not because Mei was wrong. She was right. It felt terrible because my job is supposed to be knowing the plan, and in that moment I didn't know the plan. I'd built a roadmap on incomplete information and presented it confidently, and the gap between my confidence and reality was visible to everyone. Alyssa, my girlfriend, she's a nurse practitioner. She came home that night and I was just sitting on the couch staring at my laptop. She asked what happened and I said "I got the timeline wrong in front of the whole company" and she said "did anyone get hurt?" And I said no. And she said "then it's fine." Which, from the perspective of someone who handles actual medical emergencies, is completely reasonable. But in my world, a ten-week misestimate on the biggest item in the quarter is a big deal. It changes the sales timeline, it changes the hiring plan, it changes what we demo and when.

I learned something from that, though. Now I always do a pre-review with the engineering manager before any external presentation. Mei and I have a standing 30-minute meeting every Monday where she tells me what I'm wrong about. I call it my "correction session." She doesn't think that's funny.

What do you actually build?

Nothing. That's the honest answer. I write specs. I write PRDs. I write Slack messages. I write emails. I make slides. I draw wireframes on a whiteboard that Dev then turns into real designs that engineers then turn into real software. The chain between me and the shipped product is so long that by the time something launches, my contribution is invisible. When our batch payments feature ships, the engineers will have written the code, Dev will have designed the interface, QA will have tested it, and I will have written a Google Doc eight weeks ago that said "we should build batch payments because here are 23 customer requests and here's the revenue impact." That document is the reason it exists but it's not the thing that exists.

My friend Marcus, he's a frontend engineer. When he ships something, he can open the browser and point at it. He can say "I built that." I open a browser and point at something and say "I wrote the document that led to the meeting that led to the decision that led to the ticket that led to someone else building that." That chain of causation is real but it doesn't feel like building. It feels like influencing. And some days influencing feels powerful and strategic and some days it feels like you're a ghost haunting your own product.

What's yours?

The waiting. Nobody tells you how much of PM is waiting. I wait for engineering to finish builds. I wait for design reviews. I wait for stakeholder feedback. I wait for legal to approve the privacy language on a new feature. I wait for the data team to pull the usage numbers I need for a prioritization decision. I wait for Patrick to respond to the Slack message I sent four hours ago that he reacted to with a thinking emoji but never actually answered.

In support, when a customer had a problem, I could fix it in the moment. Or at least escalate it in the moment. The loop was tight. Customer calls, you respond, it either gets fixed or it doesn't, but the feedback is immediate. In PM, I make a recommendation in March and find out if it was the right recommendation in August. The feedback loop is five months long. And in those five months, I'm supposed to make more recommendations, each of which I also won't know the outcome of for another five months. So you're always operating on a delay. You're always living in a future that hasn't arrived yet. It's like throwing a ball and not knowing if it landed for half a year. That's hard to explain to people. They think PM is exciting because you're "deciding what to build." You are. But then you wait to find out if you decided correctly, and the waiting is where you actually live.

You came from consulting. How does that show up in how you do PM?

Every day. Consulting taught me to package information for the audience. And that's honestly about a third of what I do now. Not product work. Translation work. I have the same information, let's say about the Clinical Notes Integration feature my team is building, and I need to present it three completely different ways depending on who I'm talking to.

When I talk to Ben, our principal engineer, I need technical specificity. Ben has been at this company for eleven years. He knows every system, every constraint, every terrible architectural decision that was made in 2017 and is still haunting us. If I'm vague with Ben, he'll fill in the gaps with his own assumptions, which are usually more conservative than mine, and then I'm fighting an uphill battle. So with Ben, I say things like "the FHIR endpoint for clinical notes needs to support both R4 and STU3 because Memorial Health is still on STU3 and they're 18% of our pipeline." He respects precision.

When I talk to the sales team, I need dates and customer names. They don't care about FHIR versions. They care that the Clinical Notes Integration will be demeable by June 15th because they have a $2.4 million deal with a hospital network in Pennsylvania and the champion at that account, a CIO named Dr. Farooq, has been asking for this feature since October.

When I talk to Craig, my director, I need themes and metrics. Craig is a former data analyst. He wants to know how this feature moves the activation rate, what the projected ARR impact is, how it fits into the quarterly OKR. He doesn't want to hear about Ben's concerns with the STU3 backwards compatibility. He wants a Looker dashboard that shows adoption curves.

That sounds exhausting.

It is. My husband David jokes about it. He works in commercial real estate and his running bit is, every night at dinner, he asks "did you build anything today?" And every night I say no. Because I didn't. I wrote a PRD, I presented a roadmap slide, I had a calibration meeting about prioritization scores, I responded to a customer escalation that came through the VP of Sales who'd tagged Craig who tagged me. But I didn't build anything. The building happens around me. I create the conditions for building. Which, when I say it like that, sounds important, and it is, but it also means that on the days when the conditions are hard to create, there's nothing to show for it.

Walk me through the hardest day you've had recently.

Three weeks ago. Craig asked me to present the Q3 roadmap to our SVP of Product, a woman named Katherine. Katherine is sharp and she asks the kind of questions that expose any softness in your logic. I'd been working on this roadmap for two weeks. I felt good about it.

Then, four days before the presentation, our sales team closed a deal with a regional hospital network in Ohio. Good news, right? Except the contract included a commitment to deliver the Clinical Notes Integration by September 1st. The sales team had committed to a date without checking with product or engineering. And the reason that's a problem is that the Clinical Notes feature has a dependency on a HIPAA audit of our data handling pipeline, and that audit hadn't been scheduled yet because it requires coordination with our compliance team, which is three people for the entire company. Vivian, our clinical advisor, was the one who flagged it. She used to be an ICU nurse and she has this way of saying things very calmly that makes them sound even more alarming. She said, "The audit alone is six to eight weeks, and we can't start development until it passes."

So now I'm sitting in the presentation with Katherine, and I have to say: the thing that sales just promised to a customer is not going to be ready when they said it would be. And the reason it's not going to be ready is that a compliance dependency surfaced in week six of the project that nobody, including me, had flagged earlier. Katherine looked at me and said "why didn't we know about this sooner?" And the honest answer is that compliance dependencies in healthcare software are buried in process documents that nobody reads proactively. You find them when you need them. But "I didn't read the compliance process document" is not a great answer for your SVP, so what I said was "we've identified the gap and here's the revised timeline with the audit built in." She accepted it. But I could feel the temperature in the room drop by about three degrees.

How do you deal with sales committing to dates without asking you?

Poorly. I mean, I handle it professionally. But internally I'm furious every time it happens, and it happens about twice a quarter. The sales team has a $14 million annual target. Their comp is tied to closed deals. When a prospect says "we need this feature by September," the sales rep hears "if I say yes, this deal closes." They don't hear "if I say yes, I'm committing a product team to a timeline that hasn't been scoped, with dependencies that haven't been mapped."

I've tried to fix this. Vivian and I built a process where any deal over $500,000 that includes a feature commitment has to go through a product feasibility check before the contract is signed. It works about 60% of the time. The other 40% of the time, the deal closes over a weekend or during a conference and I find out on Monday morning via a Slack message from Craig that says "great news, we closed Ohio, they need Clinical Notes by September."

I used to get angry about it. Now I just add buffer to every estimate I give internally. When Ben tells me something takes eight weeks, I tell stakeholders ten. When I think a feature ships in Q3, I say "late Q3 or early Q4." Vivian calls this "defensive roadmapping." She's not wrong.

The part nobody talks about

What's yours?

How much of the job is political, and how early it starts. I don't mean politics like manipulation. I mean that every prioritization decision has a constituency. When I put the Clinical Notes Integration at the top of Q3, I'm implicitly saying that the Patient Portal Redesign is not at the top. And the PM who owns the Patient Portal, a guy named Rahul who sits twelve feet from me, now has to go tell his stakeholders that his project slipped. Rahul is not going to be happy about that. And the next time there's a resourcing conversation, Rahul is going to push harder for his thing, and I'm going to push for mine, and Craig is going to sit between us trying to figure out which one moves the numbers more, which means I need to prepare my case, which means I'm spending time building internal slide decks to justify a decision instead of working on the product.

I'd say about 20% of my week is what I'd call "internal sales." Selling my roadmap to people inside the company. Selling my priorities to Craig. Selling the timeline to Katherine. Selling the delay to the actual sales team. I am constantly selling, and none of it is to a customer. When I was in consulting, at least the selling was to someone who might give us money. Here I'm selling to people who already work here. That feels like overhead. But if I don't do it, my projects lose resources. Rahul does his internal sales. Everyone does. It's the game underneath the job, and nobody warned me about it when I was in business school thinking PM was about "building products people love."

You applied to 31 PM jobs. That's a lot of rejection.

Twenty-seven rejections, yeah. Most of them were the same feedback: "We're looking for someone with PM experience." Which, if you think about it, is a completely circular requirement. How do you get PM experience if every PM job requires PM experience? I was a frontend engineer for three years. I shipped features. I wrote code reviews. I sat in sprint planning meetings and thought, "Why are we building this? Nobody asked for this. The thing they asked for is in the backlog at position forty-seven." But when I put that on my resume as "product thinking" or "strategic input," recruiters didn't buy it.

I got this job because Jess, our CEO, doesn't care about credentials. Jess is a former freight broker. She started this company because she got tired of tracking shipments in spreadsheets. When I interviewed, she asked me to look at the product for 30 minutes and come back with three things I'd change. I came back with five. She hired me the next day. I found out later that the other candidate had four years of PM experience at a bigger company but gave Jess a very polished, very generic answer about "user journey optimization." Jess wanted someone who'd actually look at the thing and have opinions about it. That's what engineering trained me to do. Look at the thing.

What does being the only PM at a 22-person company actually mean?

It means I'm also the product analyst, the customer researcher, the project manager, and, on bad days, the customer support person. Last Friday is a good example. I was in the middle of writing a spec for a new feature, a bulk upload tool for freight invoices. Sam, our lead engineer, had been asking me for this spec for a week. Sam is the second employee. He wrote most of the codebase. He has strong opinions about everything and zero patience for ambiguity, which means if my spec has a gap in it, he'll find the gap and he'll come to my desk and say "what happens when the CSV has a column that doesn't match?" And if I don't have an answer, he'll make a face. The face is not hostile. It's more like resigned disappointment. Like he expected this.

So I'm writing this spec, trying to make it Sam-proof, and my Slack lights up. One of our customers, a freight broker in Memphis named Ray, has called Jess directly on her cell phone to say that the shipment tracking page is showing the wrong delivery dates for three loads. Jess walks over to my desk. She's on the phone with Ray. She puts the phone on speaker. And now I'm live-debugging a production issue with an angry customer listening.

What did you do?

I opened the admin panel, looked up Ray's account, and pulled up the three shipments. Two of them had delivery dates that were off by one day. The third one was showing a date from last month, which was clearly a data issue. I traced it back to our Samsara integration. We pull GPS and ETA data from Samsara for carriers that use it, and there'd been an API change three weeks earlier that shifted the timezone handling for delivery estimates. Our code was still parsing the timestamps in UTC, but Samsara had started returning them in the carrier's local timezone. So every delivery estimate was off by whatever the UTC offset was. For Ray's Memphis shipments, that was six hours, which was pushing some estimates into the next calendar day.

I explained this to Ray in non-technical terms. I said "our tracking data source changed how it sends us time information and our system didn't adjust, so your delivery dates are showing a day late in some cases." Ray said "OK, when's it getting fixed?" I looked at Sam, who was now standing behind me because he'd heard the speaker phone. Sam held up two fingers. I told Ray two days. Sam fixed it in one. I bought Sam a coffee. That's the relationship.

You mentioned your mom still thinks you're a software engineer.

She calls every Sunday from Accra. She asks how work is going. I say fine. She asks if I'm still doing the computer work. I say yes. She doesn't know what product management is and honestly, explaining it to my Ghanaian mother who ran a textile stall at Makola Market for 25 years would require a level of abstraction that I can't generate on a Sunday morning. She understands "I make things on the computer." She does not understand "I decide what things should be made on the computer and then write documents about them and then wait for other people to make them." That doesn't translate. If I told her I get paid $98,000 a year to write documents and attend meetings, she'd ask if I'm the boss. And I'd have to say no, I'm not the boss, I'm the person who influences the boss, which is a weird thing to explain to anyone, let alone your mother on a Sunday phone call.

$98,000. Is that good for a first PM role?

In Chicago, it's fine. My engineer salary in Seattle was $112,000, so I technically took a pay cut to move into PM, which is a thing nobody warns you about. When people talk about PM salaries they're usually talking about senior PMs at big tech companies making $200K plus. The entry-level PM salary at a seed-stage startup is, you know, it's fine. It's not the lottery ticket people imagine. Jess gave me 0.3% equity, which on paper is worth something if we raise a Series A and the valuation goes up, but I've worked at startups before and I know what 0.3% is usually worth, which is conversations about what it might be worth.

What's yours?

How lonely it is to be the only one. At my old company, there was an engineering team. If I got stuck on something, I could turn to the person next to me and say "does this regex look right?" and they'd look at it and we'd figure it out together. The feedback was immediate and mutual. You're in it together.

Being the only PM means there's nobody who does what I do. Sam is an engineer. Jess is the CEO. Our designer Lina works three days a week on contract. There is no other PM to ask "is this spec detailed enough?" or "how would you prioritize these four features?" or "is Jess's feedback on this feature a strong opinion or a passing thought?" I have to figure all of that out alone. And the loneliness isn't dramatic. It's not like I'm crying at my desk. It's more like, there are moments where I make a decision, a prioritization call, a scoping choice, and I have no peer to sanity-check it with. I just make the call and hope I'm right. When I'm wrong, I find out weeks later, after the thing has been built. And there's nobody to share that failure with either, because nobody else was in the room when the decision was made. It was just me, my Google Doc, and the blinking cursor.