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
Below, we unbundle “high quality” and “speed” to create a series of standards and operating principles.
High Quality
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 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.
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.
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.
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.”
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.
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.
Fast
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.
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.
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.
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:
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
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:
- 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.
Product Blog
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!.
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.
Ready To Fix Healthcare With Us?
RemoteGlobalPost Series CJoin Our Team: