George Markoulakis

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.

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.

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:

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.

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:

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.

See here for a list of teams and team members across Product and Development.