-
Notifications
You must be signed in to change notification settings - Fork 18
Add 90-day onboarding plan to TPM job description #4501
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
0edb7c3
ea2e06a
d9825d8
34b81d2
7e3a588
ff2555b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,167 @@ | ||
| --- | ||
| navTitle: Technical Product Manager | ||
| navGroup: Job Descriptions | ||
| --- | ||
|
|
||
| # Technical Product Manager | ||
|
|
||
| ## Job Description | ||
|
|
||
| At FlowFuse, the Technical Product Manager (TPM) bridges product strategy and technical execution. They turn complex technical challenges into measurable product outcomes, ensuring engineering delivers solutions that meet customer needs and quality standards. | ||
|
|
||
| This role blends technical depth and product acumen. The TPM dives into architecture, weighs trade-offs, and uses data to guide decisions on debt, scalability, and performance. | ||
|
|
||
| The Technical Product Manager reports to the Director of Product and is primarily responsible for: | ||
| * Bridging strategy and execution: Translate product strategy into clear, measurable technical outcomes and objectives. | ||
| * Defining requirements: Partner with engineering to balance user needs, feasibility, and business impact. | ||
| * Delivering outcomes: Set success metrics/KPIs, measure progress, and connect decisions to results. | ||
|
|
||
| ### Core Tasks and Responsibilities: | ||
| * Own metrics: Define, track, and report adoption, performance, reliability, and business impact. | ||
| * Plan sprints and releases: Align roadmap, priorities, debt, and infrastructure with product strategy. | ||
| * Shape specs/architecture: Co-create technical specs and provide architectural input. | ||
| * Translate across teams: Bridge product, engineering, sales, and customer success. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My understanding is that a TPM is embedded in a team. As such they're to be a bridge between "Engineering and Product" and on the other side "Sales & Customer Success"?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. true though in an org like this I would not want to keep a TPM away from informing sales/customer success on upcoming changes to experience, for example. |
||
| * Prioritize with data: Use usage data, customer feedback, and capacity signals. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would be nice to move it below line 21, as it's the same topic |
||
| * Assess feasibility: Evaluate complexity, approaches, and technical risk. | ||
| * Advocate quality: Set and monitor quality, performance, and reliability targets. | ||
|
|
||
| ### What is the Technical Product Manager not responsible for? | ||
|
|
||
| - Writing production code or implementing features directly. | ||
| - Managing engineers or individual performance. | ||
| - Final technical architecture decisions (owned by CTO/engineering leadership). | ||
|
|
||
| ## 90-Day Plan | ||
|
|
||
| We believe setting clear expectations enables new teammates to thrive. Here's what success looks like in your first 90 days at FlowFuse: | ||
|
|
||
| ### Days 0–30: Learn, Map, Build Trust | ||
| **Theme: Context before control** | ||
|
|
||
| **Primary Objective**: Build deep understanding of product, users, architecture, and team dynamics. | ||
|
|
||
| #### Product + Customer Immersion | ||
| * Review positioning and roadmap | ||
| * Understand core personas | ||
| * Join customer calls or review recordings | ||
|
|
||
|
|
||
| #### Technical Architecture Familiarity | ||
| * Walk through platform components | ||
| * Identify leverage vs fragility | ||
|
|
||
|
|
||
| #### Team Integration + Operating Rhythm | ||
| * Build relationships via 1:1s | ||
| * Observe planning, refinement, release | ||
|
|
||
|
|
||
| #### Backlog Current State Review | ||
| * Audit backlog structure and hygiene | ||
| * Identify quick wins | ||
|
|
||
| **Success Signals by Day 30**: | ||
| * Trusted relationships with engineering leads | ||
| * Clear product/customer value understanding | ||
| * Backlog structure understood | ||
|
|
||
| **Deliverables**: | ||
| * ✅ FlowFuse User + Value Map | ||
| * ✅ Architecture mental model + glossary | ||
| * ✅ "How FlowFuse Ships" overview | ||
| * ✅ Backlog health assessment | ||
|
Comment on lines
+69
to
+72
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @copilot Remove the emoji please, and style this document like other job descriptions in the handbook. |
||
|
|
||
| --- | ||
|
|
||
| ### Days 31–60: Align, Clarify Priorities, Start Driving | ||
| **Theme: From understanding → influence** | ||
|
|
||
| **Primary Objective**: Shape execution via alignment, backlog clarity, and problem definition. | ||
|
|
||
| #### Define "What's Important Now" (WIN) | ||
| Partner with leadership and engineering to set top quarterly priorities in your swimlanes. | ||
|
|
||
|
|
||
| #### Establish Execution Cadence | ||
| * Weekly backlog refinement | ||
| * Sprint goal alignment and dependency surfacing | ||
|
|
||
|
|
||
| #### Improve Discovery → Delivery Flow | ||
| * Problem framing before solutioning | ||
| * Clear acceptance criteria and feedback loops | ||
|
|
||
|
|
||
| #### Lead Backlog Refinement | ||
| * Break initiatives into deliverable slices | ||
| * Ensure tickets are actionable | ||
|
|
||
| **Success Signals by Day 60**: | ||
| * TPM drives clarity, not just observing | ||
| * Engineering trusts prioritization inputs | ||
| * Backlog is execution-ready | ||
|
|
||
| **Deliverables**: | ||
| * ✅ WIN priorities + narrative | ||
| * ✅ Shared working agreement + operating rhythm | ||
| * ✅ Updated Epic/PRD template | ||
| * ✅ Engineering-ready epic(s) owned end-to-end | ||
|
|
||
| --- | ||
|
|
||
| ### Days 61–90: Execute, Own Backlog, Drive Delivery | ||
| **Theme: Shared ownership and momentum** | ||
|
|
||
| **Primary Objective**: Own execution: prioritize, manage backlog, and ship with engineering. | ||
|
|
||
| #### Backlog Ownership with Engineering Leads | ||
| Co-own priority ordering, sprint readiness, and tradeoff decisions. | ||
|
|
||
|
|
||
| #### Roadmap Execution Visibility | ||
| * Sprint goal tracking | ||
| * Outcome-based roadmap updates | ||
|
|
||
|
|
||
| #### Ship Meaningful Customer Value | ||
| Drive at least one major platform or customer-facing improvement to release. | ||
|
|
||
|
|
||
| #### Institutionalize Collaboration | ||
| Solidify operating model and learning loops. | ||
|
|
||
| **Success Signals by Day 90**: | ||
| * TPM + engineering leads run backlog prioritization | ||
| * Sprint planning is outcome-driven | ||
| * Execution cadence is faster and clearer | ||
|
|
||
| **Deliverables**: | ||
| * ✅ Backlog actively managed weekly | ||
| * ✅ Now / Next / Later execution view | ||
| * ✅ Release + feedback capture | ||
| * ✅ FlowFuse Product Delivery Playbook v1 | ||
|
|
||
| **Goal**: By day 90, the TPM has moved from learning → alignment → execution → shared backlog ownership, with clarity on WIN priorities and active backlog management. | ||
|
|
||
| ## Skills | ||
|
|
||
| What the Technical Product Manager brings to the table: | ||
| * Technical depth: Understand architecture, APIs, databases, and SDLC; low-code/Node-RED is a plus. | ||
| * Outcome orientation: Define KPIs and use data to drive decisions and impact. | ||
| * Product/engineering fluency: Comfortable with user stories and technical implementation. | ||
| * Strategic to tactical: Convert strategy into deliverables and milestones. | ||
| * Analytical: Use qualitative and quantitative inputs for prioritization. | ||
| * Technical communication: Translate across technical and non-technical audiences. | ||
| * Collaborative problem solving: Partner with engineering to find pragmatic solutions. | ||
| * Trade-off judgment: Balance debt, features, performance, scalability, and business priorities. | ||
|
|
||
| ## Hiring Plan | ||
|
|
||
| 1. Resume screening by hiring manager. | ||
| 1. 20‑minute [screening call](https://flowfuse.com/handbook/peopleops/hiring/screening-call/) with recruiter. | ||
| 1. Director of Product interview (45m): product, technical fit, outcomes, communication. | ||
| 1. CTO interview (45m): technical depth, collaboration, trade-offs. | ||
| 1. Engineering Manager interview (30m): technical collaboration and requirements clarity. | ||
| 1. Technical case study presentation with metrics and lessons learned. | ||
| 1. Final interview (**optional**) with VP of Sales or stakeholder. | ||
| 1. Offer. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm missing a reference to the Iteration value we probably want to capture here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you clarify what you mean? Or feel free to suggest an edit