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 two arms of the Product organization:
1. 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 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.
2. Strategy & Operations
At Clipboard, the Strategy and Operations Team sits within the Product Team. We expect S&O Team Members to take ownership over problems. These problems can range from sets of underperforming markets, leading functional teams, or building new lines of business.
Our S&O team’s proximity to the product team allows us to understand and solve problems locally before deploying productized solutions globally. These solutions can be delivered by working with an ops team, working with a PM, or grabbing an engineering team and acting as a PM. No matter the path forward, it’s the S&O team’s responsibility to solve problems.
Strategy and Operations members typically interact across several cross functional teams. Most problems that the team handles falls into one of three buckets:
Monitoring and Growing the Marketplace
Leading Operational Teams
New Lines of Business
Monitoring and Growing the Marketplace requires analysis and action. Members of the team are expected to dive deep into the data, design experiments to intervene, and then measure the outcomes and verify that the data is telling us the same story that we hear on the ground from our customers directly. Those leading operational teams have a different problem set but the approach is very similar.
They’re expected to look at metrics, understand and define what “success” would look like for that team and how that will impact our customers positively, and then implement solutions they have designed to deliver value to customers as quickly as possible. No matter what a member of the team is tasked with, everyone is expected to dive into the numbers and to speak directly with our customers to implement solutions that will improve our marketplace.
By design, the S&O team has a lot of freedom to move and is focused on the most important customer problems; members of the team are encouraged to pick up threads all over the business rather than in one specific focus area.
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 work in two-week “sprints”
Our teams post-release notes every week
Our teams are encouraged to talk to customers as much as we can
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
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 here for a list of team members from Strategy and Ops.