For more reading on our Product Team, read our publicly available Team Standards.
There are two goals for this document:
As a Product organization, we are responsible for marshaling and shepherding company resources towards our goals as a company. The resources that we’re managing are usually engineering hours, but they can be dollars or operational hours as well.
We’ve alluded to this idea before, but, armed with a multiyear vision, it’s our responsibility to figure out what we need to invest in over the near term that will get us there as fast as possible. Once we have determined and committed to that near-term path, we are responsible for executing on our own core work (discovery, writing, planning, delivery, etc.), as well as galvanizing peers around us to execute on the path we’ve outlined. Those peers span across the company, with some examples being our engineering teammates (who are building for the user pain we’ve outlined), our support teammates (who are tasked with fielding inquiries that gaps in our product might not cover), and our operations teammates (who execute on critical tasks that power the machine).
The vast majority of our work can be boiled down to thoughtful and clear decision-making. Our curiosity and initiative are the two biggest inputs that empower us to talk to customers, evaluate tradeoffs, and dig into the data. We aim to continuously ask ourselves “Are we solving the most important customer problems right now? Are we doing so in ways that align with our overarching strategy?”
Today (with “today” being the operative word given we’re in the middle of a hypergrowth period), we have two arms of the Product organization:
The Product Management arm is what folks will traditionally associate with “Product”.
Product Managers (PM) 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 engineers to work within a focus area with flexible boundaries to solve problems in high leverage ways. I qualify the boundaries 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. PMs here are encouraged to not feel boxed into their area of focus and even work on alternative solutions to important problems that a) a teammate may already be working on and b) isn’t in their area of focus.
We also think a bit differently in that “PM’ing” doesn’t start and stop at working with our suite of software products. We think first and foremost about solving customer problems in high leverage ways as fast as we can. While software is intrinsically high leverage, we are keen on leaning into whatever domain we need to solve these customer problems. Sometimes that means getting our hands dirty in what others might classify as “not what PMs do”, but that’s OK -- we like that.