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.
Goals
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 three arms of the Product organization:
Product Management
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 product or new adjacent products.
Within the core staffing marketplace, we’re organized in “Groups”. Each Group is oriented around a specific set of customer problems (that will evolve over time): “Worker Customer Problems”, “Workplace Customer Problems”, “Marketplace Problems”. Each Group has a Group PM with a small group of PMs sitting within the Group. Every PM (including the GPM) works with a pod of developers to solve problems in high leverage ways.
These Groups are directional pointers to what folks may work on. We optimize around ensuring the most important customer problems are being tackled across the business.
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 we can. Software is intrinsically high leverage, but we are keen on leaning into whatever domain we need to in order 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
At Clipboard Health, Strategy & Operations sits within the Product Team. The formation of this team was emergent, but we quickly 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 have loved having this group working closely with Product Managers. Doing so means that: a) we have a close feedback loop to productize interventions that work (we’ve had members of the S&O team lead moonlight as PMs on multiple occasions), b) Strategy & Operations is integral to the Product planning process and c) PMs feel closer to day-to-day business operations (eg they get a clear window into Sales, Ops, etc). I often tell candidates that coupling S&O and PM is merely a reflection of how entrepreneurial our team is.
Today, Strategy and Operations:
Drives “New Verticals”
Embeds in Customer Ops to either solve specific problems or accelerate our path towards operational excellence
Drives “Core Growth” – this is everything from running independent experiments in the core marketplace to helping drive Sales improvements
As we grow into a marketplace that manages thousands of local markets across the globe, more and more of S&O’s role will become managing our markets at the local level (intervening as needed), as well as launching new markets.
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.
Pods choose how the execute (this blog post is apt Consistency is not a goal )
Our teams are encouraged to talk to customers as much as we can, here
We write Working Backwards 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
Each unit within the Product org holds weekly 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.
Updated March ‘24