<aside> đź’ˇ Our current philosophy is that PMs must be singular owners across the spectrum of product discovery to product delivery. That means PMs here perform their own user research, write their own tickets, create their own project plans, oversee product delivery and evaluate post-launch success.
</aside>
Product Managers (PMs) on the team interact directly with pods of engineers to work on our core staffing marketplace products or new adjacent products. Each PM works with an engineering manager or tech lead and a group of incredibly talented engineers to solve problems in high-leverage ways.
We qualify the boundaries of the role as “flexible”, because even though our team is currently distributed across the core flow of our healthcare-professional-facing mobile app (Onboarding, Booking Shifts, Pricing, Payments, Billing), what’s most important is that high-priority customer problems never fall through the cracks.
Clipboard Health PMs here are encouraged to not feel limited to their area of focus and to work on alternative solutions to important problems even when a) a teammate may already be working on the same problem and b) the problems aren’t in their usual area of focus.
The Product team is structured into various groups oriented around a set of customer problems (“missions”). Those missions are not fixed or even exclusive; there might be times when multiple Groups are attacking the same problem. That’s both acceptable and (on the margin) expected.
A group is a cross-functional unit led by a Group Product Manager alongside one or more Engineering Managers and strategy team members.
These missions are not a collectively exhaustive list of what could be worked on, but simply what we’ve deemed to be the most important missions at this moment in time.
Our Product - Culture @ Clipboard Health
đź“„ High Quality and Fast - A window into how our product team thinks
đź“„ From Idea to Production in Eight Hours: How we Work at Clipboard Health
đź“„ How The Product Team Works
Product Teams Group and Structure
Our CBH Working Backwards Document is to be used for substantive Feature Specs (such as Matching Algorithm) and other Major Initiatives. A Working Backwards doc tests the customer value of your ideas and helps you crystallize what you want to do and why in customer-centric terms that anyone can understand
đź“„ Working Backwards Document - How We Ship Features: The Framework
đź“„ Working Backwards Document - How We Ship Features: OverFilling (WBD)