The Product Team
A primer on how we're structured and how we view our work
For more reading on our Product Team, read our publicly available Team Standards.
There are two goals for this document:
- Answering “what’s Product” questions that new (or existing) members of the organization may ask
- Answering some frequently asked questions from external Product candidates in an effort to present more useful information ahead of the interview process
What We Do
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?”
How We’re Structured
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.
Lastly, our current philosophy is that it's important that PMs are 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.
Strategy & Operations
Here, Strategy & Operations sits within the Product team. This team has evolved organically over time and the inspiration was from our Product Analyst (PA) team. But that was a bit of a misnomer. The original thinking was that PAs would provide leverage for PMs, but over time we realized how high leverage it was to have a diverse group of problem solvers working across functions to experiment and solve critical problems for the company. We also quickly realized how valuable it was to have this group working closely with Product Managers, as that channel helps ensure we quickly productize high-impact solutions across the company.
Given the success we saw with the PA team, we are doubling down on what we saw as successful and incubating this Strategy & Operations team within Product.
Strategy and Operations:
- Owns core metrics that span across focus areas (e.g., retention)
- Embeds in different functions and solve problems across teams
- Works in tandem with PMs in experimentation
- Experiments with and launch new businesses that are outside of the core product
We are looking to continue to build this team into a cross-functional (ops, data science, engineering) unit that accelerates the rate at which we learn and solve high-priority customer problems.
How We Work
I recommend you read our Standards to get a better sense of some principles we abide by in our work, but our tactical practices are outlined in the bullet points below. Once again, we acknowledge that the nature of hypergrowth means these rituals and methods will always be evolving to meet the demands of the company:
- PMs are working in two-week “sprints” -- I would read about our Software Development Lifecycle
- Our teams post-release notes every week
- Our teams are encouraged to talk to customers as much as we can
- We write Working Backward Documents (WBDs) to greenlight large initiatives
- Important to note that we are relatively anti-consensus -- these WBDs are not attempts to make sure every stakeholder “signs off”, but they exist to:
- pressure test our thinking ahead, rolling out a high blast radius initiative
- ensure we’re building with the ideal experience in mind
- We have a Weekly Product and Development Review meeting where we dive deep into one area or project with a cross-functional group
- We have Weekly Product Team meetings where everyone prepares a weekly write-up and we read, reflect, collaborate and press each other on our current projects (or other areas of discussion)
The standards doc we listed above provides a good view into how we think, but if you’re a candidate reading this, then I’d emphasize the “We Write a Lot” point. If you don’t enjoy writing (or reading), you likely won’t enjoy your time here. We are meeting-light and rely heavily on asynchronous communication.
Who We Are
See here for a list of teams and team members across Product and Development.