Amit chakraborty

Posted on Oct 14 Originally published at amitchakraborty.dev

Product management for engineers · 1. What a product manager does all day

#tutorial #product #productmanagementforengineers #whatapmactuallyowns

Product management for engineers · Chapter 1 of 10 · Product · new chapter every Wednesday morning

By the end of this chapter: Replace the caricature with an accurate model of the role.

The problem

You are a senior backend engineer on a fast‑growing SaaS startup. The next sprint is due in two weeks and the team has a feature – “custom report scheduling” – that the sales team has promised to a key prospect. The product manager (PM) you work with, Maya, has been in the meeting room all morning, shuffling between a stakeholder‑alignment call, a user‑research debrief, and a data‑review session. By 11 am she emails the engineering channel: “We need to push the UI changes to the API tomorrow – the client is asking for a demo on Friday.” At the same time, a separate Slack thread shows her updating the roadmap to move the “export to CSV” work to Q3.

By the end of the day the team has spent three hours re‑estimating the API work, two hours on a meeting that could have been an email, and a half‑day fixing a design spec that never made it to the UI team. The sprint goal is now at risk, the release date slips, and the engineering manager has to push back on the sales forecast.

The cost is concrete: a missed demo, a potential $250 k contract, and a week of extra engineering effort that could have been avoided if the PM’s day had been understood and coordinated with the team.

Before you start

Prerequisites – You have read the introductory chapter on “Cross‑functional communication basics” (Chapter 0) and you have access to the team’s project‑management board (Jira 8.13) and Maya’s calendar (Google Calendar).
Tool check – Run the following command to verify you can query the board’s API:

curl -s -H "Authorization: Bearer $JIRA_TOKEN" \
  "https://yourcompany.atlassian.net/rest/api/2/search?jql=project=PROD&maxResults=1" | jq '.issues | length'

You should see 1 (or any non‑zero integer). If you get an authentication error, obtain a personal access token from the Atlassian admin console.

Once the API call succeeds, you can proceed.

What a PM actually owns

1. The “decision‑pipeline” – not a single decision

A common caricature is that the PM is the sole decision‑maker for the product. In reality the PM curates a pipeline of decisions that flow from three sources:

Source	Typical artefact	Frequency
Market / sales signals	Opportunity brief, ARR impact estimate	Weekly
User research / data	Personas, usage heat‑maps, cohort analysis	Bi‑weekly
Technical constraints	Architecture review notes, capacity plan	Ongoing

The PM’s job is to collect, prioritise, and communicate these artefacts so that each downstream stakeholder (engineers, designers, sales) can act on a single, agreed‑upon decision. The decision‑pipeline is a living document, usually a Confluence page titled “Product Decision Log”.

2. Time allocation – where the hours really go

Maya’s calendar shows the following pattern (averaged over the last month):

Activity	% of time	Typical output
Stakeholder alignment (sales, support, ops)	35 %	Updated roadmap, stakeholder‑impact matrix
Data & discovery (analytics, user interviews)	25 %	Insight deck, hypothesis list
Specification & grooming (writing PRDs, backlog refinement)	20 %	Draft PRD, acceptance criteria
Coordination & blockers (stand‑ups, ad‑hoc syncs)	15 %	Issue triage, risk register
Administrative (status reports, OKRs)	5 %	Weekly status email

Understanding this split explains why a PM can appear to “jump” between unrelated topics – they are moving the most constrained resource (their time) to the activity that currently has the highest impact‑to‑effort ratio.

3. The “single source of truth” myth

Engineering teams often treat the Jira board as the single source of truth. For a PM, the roadmap (usually in a product‑management tool like Aha! 3.14) is the authoritative view of what will be shipped when. The board reflects how the work is broken down, but the roadmap drives why a piece of work is scheduled.

If the roadmap and board drift, the PM will spend time re‑aligning them – a hidden cost that appears as “last‑minute changes” to engineers.

How to replace the caricature with an accurate model

1. Map the PM’s day

Export the calendar – In Google Calendar, click Settings → Export and download the .ics file for the last two weeks.
Parse the file – Use the icalendar Python library (v5.0) to summarise time spent per activity:

   pip install icalendar==5.0
   python - <<'PY'
   import sys, collections, datetime, icalendar
   cal = icalendar.Calendar.from_ical(open('export.ics','rb').read())
   buckets = collections.Counter()
   for ev in cal.walk('vevent'):
       summary = ev.get('summary')
       start = ev.decoded('dtstart')
       end = ev.decoded('dtend')
       duration = (end - start).total_seconds() / 3600
       if 'sales' in summary.lower():
           buckets['Stakeholder'] += duration
       elif 'research' in summary.lower() or 'interview' in summary.lower():
           buckets['Discovery'] += duration
       elif 'groom' in summary.lower() or 'spec' in summary.lower():
           buckets['Specification'] += duration
       else:
           buckets['Other'] += duration
   for k,v in buckets.items():
       print(f"{k}: {v:.1f}h")
   PY

Expected output (example):

   Stakeholder: 12.5h
   Discovery: 9.0h
   Specification: 7.5h
   Other: 2.0h

This concrete breakdown lets you see the PM’s focus, not guess it.

Validate with the PM – Schedule a 15‑minute sync, share the chart, and ask “Does this reflect how you spend your time? Anything missing?” The PM’s confirmation turns the model from speculation into a shared reality.

2. Identify the decision‑pipeline artefacts

Locate the Decision Log – In Confluence, the page is usually titled “Product Decision Log”. Verify it exists:

   curl -s -H "Authorization: Bearer $CONFLUENCE_TOKEN" \
     "https://yourcompany.atlassian.net/wiki/rest/api/content?title=Product%20Decision%20Log&spaceKey=PROD" | jq '.size'

Expected output: 1.

Extract the last five entries – Use the Confluence API:

   curl -s -H "Authorization: Bearer $CONFLUENCE_TOKEN" \
     "https://yourcompany.atlassian.net/wiki/rest/api/content/$(jq -r '.results[0].id' <<<$(curl -s -H "Authorization: Bearer $CONFLUENCE_TOKEN" "https://yourcompany.atlassian.net/wiki/rest/api/content?title=Product%20Decision%20Log&spaceKey=PROD"))?expand=body.storage" | \
     jq -r '.body.storage.value' | grep -A2 '<h2>' | head -n 10

You should see headings like “2024‑09‑01 – Add custom report scheduling – Decision: ship in Q2”.

Map each entry to a stakeholder – For each decision, note the primary driver (sales, research, engineering). Create a simple CSV:

   date,feature,driver,impact_estimate
   2024-09-01,custom report scheduling,sales,$250k
   2024-09-05,export CSV,engineering,technical debt reduction

This artefact list is what the PM uses to justify prioritisation.

3. Align the roadmap with the board

Export the roadmap – In Aha! 3.14, use Export → CSV for the current quarter.
Export the Jira sprint backlog – Run:

   curl -s -H "Authorization: Bearer $JIRA_TOKEN" \
     "https://yourcompany.atlassian.net/rest/agile/1.0/board/42/sprint/7/issue?maxResults=200" | \
     jq -r '.issues[] | [.key, .fields.summary] | @csv' > sprint.csv

Diff the two – Using csvdiff (v1.1.0):

   csvdiff roadmap.csv sprint.csv --output diff.txt

Open diff.txt. Any rows that appear only in the sprint file indicate work that was not on the roadmap – a red flag for “last‑minute changes”.

Create a reconciliation ticket – In Jira, open a ticket “PM‑Roadmap sync – Q4” and attach the diff. Assign it to the PM. The ticket becomes the visible contract that the PM will act on.

4. Communicate the model to the team

Draft a one‑page “PM role model” – Include the time‑allocation chart, the decision‑pipeline diagram, and the roadmap‑board sync process.
Present at the next sprint‑planning – Use a 5‑minute slot. Ask the team: “Given this model, where can we surface blockers earlier?” Capture feedback and iterate on the model.

By completing these four steps you have replaced the vague caricature (“PM is a wish‑maker”) with a concrete, observable model that the whole team can reference.

Build it

Export Maya’s calendar – Follow the instructions in “Map the PM’s day”. Confirm you have an export.ics file of at least 10 days.
Run the Python summariser – Execute the script exactly as shown. Verify the output sums to roughly the total working hours (≈ 80 h for two weeks).
Locate the Decision Log – Run the Confluence API call. If the response size is 0, ask the PM for the correct page title or space key.
Pull the last five decisions – Run the second Confluence command. Verify you see at least five decision headings with dates.
Export the roadmap – In Aha! export the CSV for the current quarter. Ensure the file contains a “Feature” column and a “Target release” column.
Export the sprint backlog – Run the Jira curl command. Verify sprint.csv contains at least 10 rows (your sprint size).
Diff the two CSVs – Run csvdiff. Open diff.txt. You should see lines prefixed with - (present only in sprint) or + (present only in roadmap).
Create the reconciliation ticket – In Jira UI, click Create → Issue; set Project = “PROD”, Issue Type = “Task”, Summary = “PM‑Roadmap sync – Q4”, attach diff.txt. Assign to Maya. Confirm the ticket appears in the board’s “To Do” column.
Draft the one‑page model – Using any markdown editor, create pm-model.md with three sections: Time Allocation, Decision Pipeline, Roadmap‑Board Sync. Include the output from steps 2, 4, and 7 as inline tables. Save.
Present – At the next sprint‑planning meeting, share pm-model.md via screen share. Note the reactions; capture any action items in the meeting notes.

When you have completed step 10, the team now shares a common, evidence‑backed view of the PM’s day, the decision artefacts they own, and the process that guarantees the roadmap stays in sync with the engineering backlog.

When this breaks

Symptom	Cause	Fix
“Export.ics is empty” – the file contains only the calendar header.	The PM’s calendar is set to private for the past two weeks.	Ask the PM to temporarily share the calendar with “Anyone with the link can view” or export the last two weeks manually via the UI.
Confluence API returns `size: 0`	The page lives in a different space (e.g., `PROD‑PM`) or the title includes a trailing space.	Use the Confluence search endpoint: `GET /rest/api/search?cql=type=page%20and%20title~"Decision%20Log"` to locate the correct `spaceKey` and `id`.
`csvdiff` reports “different number of columns”	The roadmap CSV uses a semicolon (`;`) delimiter, while the sprint CSV uses commas.	Re‑export the roadmap with “Comma” as delimiter, or run `sed 's/;/,/g' roadmap.csv > roadmap_fixed.csv` before diffing.
Reconciliation ticket never moves out of “To Do”	The PM is not notified because the ticket lacks a watcher.	Add the PM as a watcher via the Jira UI (`More → Watchers`) or include `@Maya` in the ticket description.
Team rejects the model as “too much work”	The model was presented without a clear benefit (e.g., “reduces last‑minute changes”).	In the presentation, explicitly tie each artefact to a pain point: “The diff file caught two items that caused yesterday’s re‑estimate”.

What it costs

Aspect	Cost	When to avoid
Time spent mapping – ~4 h for calendar export, scripts, and reconciliation ticket.	Reduces engineering capacity for the current sprint.	If the team already has a mature PM‑engineering sync (e.g., weekly alignment meeting) and recent incidents are rare.
Process overhead – Maintaining a Decision Log and roadmap‑board sync adds a recurring 30 min ritual.	Consumes PM’s limited time, potentially delaying rapid experiments.	In a very early‑stage startup where the product is still being defined by founder vision rather than data.
Visibility risk – Publishing the model makes internal friction visible to stakeholders.	May surface disagreements that require diplomatic handling.	If the organisation’s culture penalises “questioning authority” and the PM is not empowered to act on feedback.
Tool dependency – Requires access to Google Calendar, Confluence, Aha!, Jira, and the ability to run scripts.	Increases onboarding complexity for new hires.	In teams that deliberately limit tooling to a single source (e.g., only Jira).

The trade‑off is clear: you invest a few hours now to gain a shared mental model that prevents costly re‑work later. The approach shines when the team suffers from “PM‑engineer misalignment” more than from “lack of speed”.

In the interview

Interviewer: “Can you walk me through how you would get a realistic picture of what a product manager does day‑to‑day, and why that matters to an engineering team?”

A weak answer might say: “I’d ask the PM what they do and read the job description. It’s important because we need to know who to talk to.” This is weak because it shows no concrete method, no evidence, and no understanding of the impact on delivery.

A strong answer includes:

Trade‑off – “Spending a few hours mapping the PM’s activities costs engineering time but prevents larger re‑work later.”
Constraint – “The PM’s time is split across stakeholder alignment, discovery, and specification; we need to know which bucket is currently dominant.”
Failure mode – “If we ignore the decision‑pipeline artefacts, we’ll ship features that were never approved, leading to scope creep.”
Numbers – “In my last team, a 2‑hour mapping exercise reduced sprint‑re‑estimate time by 30 % (from 12 h to 8 h) over the next two sprints.”
Process – “I’d export the calendar, parse it, locate the Decision Log via the Confluence API, diff the roadmap against the sprint backlog, and create a reconciliation ticket. Each step is verifiable with a command and expected output.”

Senior vs junior expectations – A junior candidate should be able to describe the steps (export calendar, look at the decision log) and why they matter. A senior or staff candidate must also discuss the cost of the exercise, how to automate it (e.g., a CI job that runs the diff nightly), and how to embed the outcome into the team’s cadence. A director‑level interview will probe the strategic impact: “How does this model influence product‑strategy alignment across multiple squads?”

Follow‑up to separate theory from practice – “Tell me about a time you discovered a misalignment between the roadmap and the sprint backlog. What was the symptom, how did you detect it, and what was the outcome after you introduced a reconciliation process?” An answer that references actual commands, output, and a measurable improvement demonstrates lived experience.

Your tasks

Map a PM’s calendar – Export the calendar of a PM you work with (or a mock .ics you create) and run the summariser script. Verify the output adds up to ≈ 80 h for two weeks. Done when the chart matches the PM’s self‑report.
Locate the Decision Log – Use the Confluence API to fetch the page titled “Product Decision Log”. If the page does not exist, create a minimal version with a table of three recent decisions. Done when the API returns a non‑zero size and the page contains at least three rows.
Detect a roadmap‑backlog drift – Export the current quarter roadmap from Aha! and the current sprint backlog from Jira. Run csvdiff and identify at least one item that appears only in the sprint backlog. Create a Jira ticket to reconcile it. Done when the ticket is visible on the board and assigned.
Present the model – Draft a one‑page markdown document that includes the time‑allocation chart, a diagram of the decision‑pipeline (you can use Mermaid syntax), and the diff result. Present it at a team meeting and capture at least one action item (e.g., “Add weekly sync”). Done when the meeting notes record the action.
Break and diagnose – After the presentation, deliberately remove the “Stakeholder alignment” entry from the calendar export and re‑run the summariser. Observe the missing bucket, then explain to the team why the omission matters and how it could hide a risk. Done when you can articulate the impact and propose a guard‑rail (e.g., a checklist ensuring each stakeholder meeting is logged).

Your tasks this week

Do the exercises above before the next chapter. Reading a tutorial and doing
one are different activities and only one of them changes what you can build.

Stuck on any of them? Say so — describe what you tried and what happened:
tell me where you got stuck. I read every one, and the questions
that come back more than twice get answered in the next chapter.