Most engineers stepping into a product role stumble on the same five things. Not because they're hard, because nobody ever answers them cleanly. This page is the clean version: the work hierarchy, the two role distinctions that get blurred, the one artefact that holds a project together, and the soft skill that decides whether your transition sticks.
Context This reference distils a Q&A I've run several times with engineers stepping into product roles inside data and AI platform programmes. The worked examples are anonymised. The patterns are not.
The starting brief
A target objective like this one
Own end-to-end delivery of an enterprise data and AI platform, covering data models, solution architecture, reports migration, new dashboards, and advanced use cases (ML/AI algorithms).
Your current workload, split
A useful exercise to do early: map your current workload into two buckets, and flag it as a snapshot. If the team is still recruiting (engineers, a BA, a tech lead), work that would normally sit elsewhere will be on you for now. Naming that explicitly is the first step.
PM vs non-PM work, today
Transition state, some of this will graduate to other owners
Non-PM · non-AI deliverables
Work an engineering lead or BA would normally own, currently absorbed because hiring is in flight.
- Review data model built by the engineering team
- Review the business glossary
- Prepare security / access management requirements for the platform solution
- Review Tableau output, dashboards and reports
PM · AI deliverables
The real remit once the team is fully staffed.
- Requirements gathering and ideation for advanced use cases, shaping and shaping-review meetings with business + technical teams
- Backlog prioritisation
- Chasing vendor-blocked items with internal teams (access, network, infrastructure)
- Putting together PoCs for new agentic AI initiatives and products
Quick mentor read Two things worth flagging. One: the non-PM column is not wasted work, it builds your domain authority. When you later push back on scope or chase a blocked dependency, you'll be taken more seriously because you've read the data model yourself. Don't frame it as a distraction. Two: the risk is drift. If you hold the non-PM work for too long, senior management quietly normalises it and you never graduate to the PM work on the right. That's the subject of Question 5.
The questions you sent
| # | Your question (cleaned up) | Answered in |
|---|---|---|
| 1 | Can you give me a clear anatomy of the agile hierarchy (initiative, epic, story, task, milestone) so I know what sits on top and what sits at the bottom? | Question 1 |
| 2 | Is there a clean distinction between Project Manager and Product Manager? (Your own read: it's about whether scope is defined.) | Question 2 |
| 3 | Is there a clean distinction between Product Owner and Product Manager? | Question 3 |
| 4 | What does a good solution document look like, is there a template I can adapt? | Question 4 |
| 5 | How do I avoid wrong expectations from senior management who assume I'll pick up dev work once the project goes live? How do I flag that early? | Question 5 |
| 6 | How do I actually build a roadmap for my context? | Roadmap Toolkit → |
Question 1. The agile hierarchy
Original question
I'm always getting confused about the anatomy of the agile framework, milestone, epic, story, task. Is there a clear breakdown from top all the way down to the tasks developers work on?
The confusion is usually because Jira-style tools mix hierarchy (what contains what) with markers (date-based checkpoints). Two different things.
The hierarchy
Initiative , strategic theme, multi-quarter └── Epic , large body of work, weeks to months └── Story , user-facing unit, done in a sprint └── Task / Sub-task , technical work to deliver the story
An example shape
Initiative: Enterprise data and AI platform ├── Epic: Migrate legacy reports to new platform │ ├── Story: As a risk analyst, I can access the daily exposure report │ │ ├── Task: Build Tableau data source │ │ ├── Task: Configure access permissions │ │ └── Task: UAT with risk team │ └── Story: As an auditor, I can export historical reports to CSV └── Epic: AI PoC for internal document triage ├── Story: Ingest submitted documents into vector store └── Story: Classify document type with LLM
Milestones, not in the hierarchy
A milestone is a date-based marker that cuts across the hierarchy. It's a commitment or a checkpoint, not a unit of work.
- "Platform Go-Live, 15 June"
- "Compliance sign-off complete, Q3"
- "PoC outcome review, end of sprint 4"
A milestone might require finishing several epics and stories from different initiatives. That's fine. It's a calendar thing, not a containment thing.
Quick rule of thumb Initiative = the big bet, shows up in the strategy deck · Epic = a chunk of work someone owns end-to-end · Story = something a user or system can do when it's done · Task = a developer's to-do list item · Milestone = a date on the calendar that matters.
Question 2. Project Manager vs Product Manager
Original question
Is there a clear distinction between Project Manager and Product Manager? My own read: scope defined or not defined.
Your own read is exactly right. Here's the full version:
| Project Manager | Product Manager | |
|---|---|---|
| Scope | Defined upfront. SOW, contract | Evolves as you learn |
| Primary question | How do we deliver this? | What should we build, and why? |
| Success | On time, on budget, to spec | Product achieves outcomes, adoption, value, retention |
| Time horizon | Fixed, project has an end date | Continuous, product lives on |
| Manages | Scope, time, budget (the triangle) | Outcomes and trade-offs |
| Team | Disbands when project ends | Persistent, long-lived |
Why this matters for you
Many enterprise environments are framed project-style. There's a vendor SOW, defined deliverables, acceptance gates, a go-live date. That's not wrong. It's how procurement-led delivery works.
But your role needs to be product-style. You're not just shepherding a SOW to completion. You're the person asking:
- Is what we're building still the right thing?
- What did we learn from the last sprint that should change scope?
- What happens after go-live, who owns outcomes?
The trap In orgs like yours, senior management assumes the project ending equals your job ending, or shifting back to dev work. Part of your transition is actively shaping the narrative that the product continues after the project wraps. Question 5 goes deep on exactly how.
Question 3. Product Owner vs Product Manager
Original question
Is there a clear distinction between Product Owner and Product Manager?
The textbook distinction:
| Product Owner (PO) | Product Manager (PM) | |
|---|---|---|
| Focus | Backlog, sprint, execution | Strategy, discovery, outcomes |
| Zoom level | Next 2–6 weeks | Next 1–4 quarters |
| Key question | What are we building next sprint? | What's worth building, and why? |
| Closest to | Engineering team | Customers, stakeholders, market |
| Origin | Scrum framework | Pre-dates Scrum, broader role |
The honest reality
Nomenclature varies wildly. Some companies call everyone PO. Some call everyone PM. Some have both with a clear split. Some use PO as a junior PM title.
What matters isn't the label. It's knowing which responsibilities you own. In smaller teams, immature product orgs, or your context, the same person usually does both. That's normal. The risk is only doing the PO slice (backlog grooming, sprint planning) and never lifting your head to do the PM slice (why, for whom, what outcome).
Question 4. The solution document
Original question
How do you write a solution document? Can I have access to a template?
A solution doc is how you get alignment before work starts. It forces clarity and becomes the reference everyone points to when scope questions come up later. There's a deeper treatment on the Solution Document page; the version below is the condensed template.
Template, 11 sections
01
Opportunity / Problem
What's broken, missing, or possible? Plain language, no solution yet.
02
Objectives
What does success look like? 2–4 bullets. Outcome-oriented, not output-oriented. Bad: "build a dashboard." Good: "risk analysts can identify exposure concentrations in under 2 minutes."
03
Current state
How is this handled today? What's the workaround or manual process?
04
Proposed solution
High-level description of what you're proposing. Not a technical design, a capability description a business stakeholder can understand.
05
Beneficiaries / Users
Who benefits, and how? Name the roles or teams.
06
Business value
Why is this worth doing? Tie to strategic goals, cost saving, risk reduction, regulatory obligation. Quantify if you can.
07
Scope, in and out
Out-of-scope is the most important section in any procurement-led context. It's what you'll point to when scope creep starts.
08
Assumptions
What are you assuming to be true? List them so they can be challenged.
09
Risks and mitigations
Problem + proposed mitigation + owner. One line each. Use a risk log format.
10
Acceptance criteria
How will we know this is done? Specific, testable.
11
Open questions
What still needs to be answered? Who owns answering it, by when?
Worked example: AI PoC for internal document triage
Illustrative shape, not spec. A composite of the kind of PoC PMs are commonly handed. Adapt freely.
Question 5. Managing expectations with senior management
Original question
How do I avoid wrong expectations from immature senior management when they assign me irrelevant tasks? For example, they expect me to go back to dev work once the current project is live. How do I flag that early so it doesn't harden into an assumption?
This is the single most important soft-skill question in your transition. Most PMs who fail this transition don't fail on frameworks, they fail on expectation management.
Why this happens
Senior managers, especially in organisations newer to product discipline, don't hold a picture of "what a PM does" in their head. They hold a picture of "what Victor-the-person does", and that picture is whatever you did last quarter. Pick up dev tickets to unblock a release? You become the person who picks up dev tickets. Own the solution doc and vendor governance? You become the person who owns solution docs and vendor governance.
You are being implicitly promoted or demoted every week based on what you accept.
Three moves that work
1 Reframe every non-PM task as temporary scaffolding.
When you take on a non-PM task, say so out loud. Not defensively, matter-of-factly.
"Happy to review the data model while the engineering lead role is open. Once [name] is onboarded, that review sits with them and I'm back on shaping the advanced-use-case backlog."
You've just done two things: accepted the work (good, you're not being precious) and set a return condition (great, the expectation has a visible expiry).
2 Publish a target operating model, early, in draft, as a thinking piece.
Don't wait until post-go-live to have the "what does Victor own next" conversation. Write a one-pager now:
| Today (transition state) | Steady state (team fully staffed) | |
|---|---|---|
| You own | PM work + non-PM overflow (data model review, glossary, security reqs, Tableau review) | PM work only, shaping, backlog, vendor governance, PoCs |
| Someone else owns | [Engineering lead role, open] [BA role, open] | Engineering lead: data model, Tableau output BA: business glossary, requirements capture Security lead: access management reqs |
Share it with your line manager as a draft. Ask: "does this match your mental model?" If they push back, you've surfaced the disagreement early. If they agree, you now have an artefact to point back to in six months.
3 Talk about outcomes, not tasks, in senior forums.
When you're in front of senior management, don't describe your week as tasks. Describe it as outcomes.
| Task framing trains them to see a doer | Outcome framing trains them to see a PM |
|---|---|
| "I reviewed the data model, chased infra access, and sat in three shaping meetings." | "This week: shaped the AI PoC enough to enter build; unblocked two vendor-side dependencies; reports migration stayed on track for its acceptance gate." |
Same underlying work. Completely different perception. The second framing trains senior management to see you as the person who delivers outcomes (the PM role). The first trains them to see you as the person who does tasks (the dev role they want to slot you back into).
When the "pick up dev work after go-live" comment lands in a meeting
Don't swat it down, that creates resistance. Reframe calmly, in the moment.
"The bigger opportunity after go-live is the advanced-use-case backlog. That's where the platform starts paying back. I'd rather spend the cycles shaping those than on dev. Can we sketch what the post-go-live priorities actually look like so we can plan properly?"
You have acknowledged their underlying concern (what will the PM do after go-live?), replaced their assumption with a better one (advanced use cases > dev work), and turned a one-liner into a planning conversation. That planning conversation is where your future role gets decided.
The harder truth Some of this won't land until you produce a roadmap they can see. A good roadmap is the single best tool for shifting how senior management sees your role, because it forces the conversation from tasks to strategic priorities. See the Roadmap Toolkit for the rest of that answer.
What to read next
Once the five questions above feel stable, the next layer is learning to plan and communicate what's coming. Go to the Roadmap Toolkit for Now / Next / Later, and read Stakeholder Management to map the humans around you. The Solution Document is the artefact you'll reach for the most in the first month.
That's the work.