Product Team

We’re +20 people working remotely, with freedom and autonomy, enabling CBH to maintain High Quality & Speed as we scale and encounter ever more complex challenges.

Armed with a multi-year 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 our own core work (discovery, writing, planning, delivery, etc.), as well as galvanizing peers around us to execute on the path we’ve outlined.

Our Mission

As a Product organization, we are responsible for marshaling resources toward company goals. The resources that we’re managing are usually engineering hours, but they can be dollars or operational hours as well.

Armed with a multi-year 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 our own core work (discovery, writing, planning, delivery, etc.), as well as galvanizing peers around us to execute on the path we’ve outlined.

Our Product

Clipboard Health’s app-based marketplace was designed to solve the big problems that keep healthcare providers and facilities from doing their best work and fulfilling their mission.

Team Standards

High Quality And Fast

Maintaining a high quality bar and moving fast are not mutually exclusive, and, here, we do not make excuses indicating otherwise.

Beyond the Curiosity, Initiative and Ownership standard we inherit from the Company

, moving fast with high quality is our root standard and is what we expect from members of this team.

Below, we unbundle “high quality” and “speed” to create a series of standards and operating principles.

High Quality

Be an Owner

Being owners means that we internalize that the buck stops with each of us -- nobody should have to chase us because we have a SMART plan, broadcast it, and adjust it (and broadcast it again). We each own the full scope of the success of what we’re working on. We prioritize the customer and the company, and we never say “that’s not my/our job”.

We Write a Lot

We recognize that writing is thinking and good writing scales well. The need to write is a feature of remote companies that we double down on because it forces us to think harder and think more clearly (see here for how we wield the Working Backwards Document). We also read a lot, and carefully, and fully and leave comments (both inline and broad comments) that help our teammates push further faster.

Communicate Proactively and Clearly

We default to clear written communication. When we work on our plans, we quickly identify what communications are required and we effectively educate internal and external stakeholders. Our writing is clear and concise. Our specs are easy to follow and we consistently work with our engineering partners to ensure they’re both coherent and complete.

Do the Reading

In order to support the above, we need to do the reading (and hold others to that standard). That doesn’t mean we’re expected to read every WBD that the team produces, but if we’re attending a table read or if a teammate asks for our help, then we are expected to closely read.

Whether we’re investigating how a given Product process works or how another team within the company is structured, we’re expected to do the reading.

Be Intellectually Honest

A lot of the work we do can be boiled down to repeatable, thoughtful and clear decision-making. A common failure mode for PMs is that we fall in love with our own ideas, or get defensive of our designs when challenged, or try to “explain away” issues others raise rather than treat comments and feedback as clues we run down without ego.

The standard that we hold ourselves to on this team is that we will skeptically evaluate our own thinking and remove the “who” that a given idea is associated with. One of the best levers for this is the WBD exercise -- we will write our pre-mortems and assess alternatives in good faith.

It’s not about your answer, but about the best answer we can think of as a group.

One of my favorite passages on this, from Larry Ellison on Bill Gates:

“It was the most interesting conversation I’ve ever had with Bill, and the most revealing. It was around eleven o’clock in the morning, and we were on the phone discussing some technical issue, I don’t remember what it was. Anyway, I didn’t agree with him on some point and I explained my reasoning. Bill says, ‘I’ll have to think about that, I’ll call you back.’ Then I get this call at four in the afternoon and it’s Bill continuing the conversation with ‘Yeah, I think you’re right about that, but what about A and B and C?’ I said ‘Bill, have you been thinking about this for the last five hours?’ He said, yes, he had, it was an important issue and he wanted to get it right. Now Bill wanted to continue the discussion and analyze the implications of it all. I was just stunned. He had taken the time and effort to think it all through and had decided I was right and he was wrong. Now, most people hate to admit they’re wrong, but it didn’t bother Bill one bit. All he cared about was what was right, not who was right. That’s what makes Bill very, very dangerous.”
Marry Customer Conversations And Data

There will be times when particular decisions can be supported by one or the other — but in our work, here, we are expected to stay in regular contact with customers and also stay on top of the metrics related to our initiative(s). On this team, we recognize that customer conversations in conjunction with relevant data are paramount.

Be the Portfolio Manager

When allocating resources, we think in probabilistic terms. We aren’t afraid to take big, high upside swings, but we also recognize and appreciate that small adjustments are important, as well. Like all portfolio managers, we must be extremely intellectually honest about the “expected value” of each item in our portfolio.


Solve Our Core Customer Problems, Quickly

We are each accountable for surfacing customer problems to the team and ensuring we’re solving them with haste. Whether the problem is core to our ongoing initiative or it’s a customer that has reached out for help from a prior user research effort, we own the problem and treat it with urgency. We fully recognize that winning means doing this faster than anyone else.

Manage Time Well

We’re able to balance demands well and we’re expected to proactively raise our hands (as soon as you are aware) if we’re not able to deliver on a timeline or if being over capacity means we won’t be able to execute at the standard.

Challenge; Disagree and Commit

We expect and encourage debate on this team. Debate sharpens our thinking and, when wielded well, ensures we are holding ourselves accountable for solving our top customer problems as fast as possible.

If we’re not able to resolve the debate, that’s OK, but expect to be asked to disagree, and then commit. And “committing” doesn’t mean “following” the resolution. It means fully committing to an outcome. Our anti-consensus culture ensures that we make many decisions (small and large) much faster. That compounds over time and means we’re delivering on our promise of solving customer problems as fast as we can.

Run Experiments, Scrappily Validate Hypotheses

In order to get to the right answer the fastest, the standard is that we will be able to identify the hypotheses we hold that underpin our thinking and test them ahead of shipping our “fully baked” solution. Sometimes those initial hypotheses will hold, but sometimes they’ll be rejected – and that’s OK. What we expect is intellectual honesty in evaluating whether or not a) what we’re doing is working and b) it’s on the list of top customer problems we should be working on (great example being SuperNurse).

Whether it’s a new feature, an alteration to an existing flow or a decision on whether we should sunset an ongoing initiative, there should be customer conversations and/or data backing whether or not this is a change worth making.

An Aside on Speed

We talk about “speed” a lot here. The first explanation that comes to mind is “we’re a startup, speed is all we have, it’s existential.” That’s true, but, in our context, speed is even more significant. For us, this cultural focus on speed will reinforce our advantage against competitors. As we’ve discussed before, every shift request is a race against other vendors and that’s why we will continue to push on faster enrollment, faster booking, faster pay and, most importantly, moving faster internally.

How We Work

Our current practices are outlined in the bullet points below. But the nature of hypergrowth means these rituals and methods will evolve to meet the demands of the company:

Our teams are encouraged to talk to customers as much as we can
We write Working Backwards Documents (WBDs) to green light large initiatives

Keep in mind that we’re anti-consensus -- these WBDs are not attempts to make sure every stakeholder “signs off”. They exist to:

  • Pressure test our thinking ahead of rolling out a high-blast-radius initiative
  • Ensure that 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)
PMs are working in two-week “sprints”
Our teams post-release notes every week

These standards provide a good view into how we think, but if you’re a candidate reading this, then I’d emphasize that we write a lot, and writing is a vital part of how we plan and communicate. 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.

Team Structure

Today we have two arms of the Product organization (but we’re in the middle of hypergrowth, so that could change!):

Product Management

Product Managers (PMs) 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 solve problems in high leverage ways. We 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 limited to their area of focus and even work on alternative solutions to important problems that a) a teammate may already be working on and b) aren’t in their area of focus.

Our current philosophy is that PMs must be 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 and Operations

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 sits within the product team, and our 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:

  1. Monitoring and Growing the Marketplace
  2. Leading Operational Teams
  3. 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.

Product Blog

From Idea to Production in Eight Hours: How we Work at Clipboard Health

We wrote down one of our stories to give you a better idea of how we work, as seen from the perspective of our product team, Take a look!.

High Quality And Fast

We don’t think you have to compromise between moving fast and doing work that meets harsh standards. We accomplish this every day - read on to see how.

Real Problems We Tackle To get an idea for some of the actual issues we resolve from day to day (and how we resolve them), take a look at this article from our Substack detailing how we think about and deal with pricing.
Our Profile of Eli Zamora There’s nobody in the world who is a better fit for Clipboard Health than Eli. Read this profile to get an idea of how he works, thinks and constantly innovates from locations around the world.

Ready To Fix Healthcare With Us?

Remote Global Post Series C

Join Our Team:

Senior Product Manager
Product Management
Product Manager
Product Management
Clipboard Health Launch Program
Product Management
Associate Product Manager
Product Management
Group Product Manager
Product Management