<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.
<aside> ✏️ Read the full doc on our group organization here
</aside>
Our product/engineering/strategy teams are 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.
Clipboard Health’s app-based marketplace was designed to solve the big problems that keep healthcare providers and facilities from doing their best work and fulfilling their mission. Nurses see more opportunities, and facilities fill more shifts.
📄 The Product Team - A primer on how we’re structured and how we view our work
đź“„ High Quality and Fast - A window into how our product team thinks
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)
