A window into how our Product team thinks
These are the Product Team standards that are copied/pasted from our internal Confluence. As a result, many links are to internal Confluence pages and thus not publicly available. These standards are a reflection of how we work and what we value.
Maintaining a high-quality bar and moving fast are not mutually exclusive. At Clipboard Health, we do not make excuses indicating otherwise.
In a post on his Linkedin that has since been archived, Frank Slootman put it this way:
When stepping up the pace, inevitably excuses are made about quality. We can’t possibly move this fast, and maintain quality? We would agree because we are going to move faster and raise quality. It has a compound effect on productivity. It’s not defying gravity, it’s beating reams of slack out of the system. Until the pressure is on, we don’t even know how much better and faster we can be.
Beyond the “Curiosity, Initiative and Ownership” standard derived from our Company Values, an expectation to move fast while maintaining a high-quality bar is our most fundamental standard and what we expect from members of this team.
Below, we unbundle “high quality” and “speed” to create a series of standards and operating principles.
An Aside on Speed
We talk about “speed” a lot here. The first explanation as to why 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. That’s why we will continue to push on faster enrollment, faster booking, faster pay, and - most importantly - moving faster internally.
What Does “High Quality” Look Like Here?
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 already an emphasized feature of remote companies, something that is infinitely more important in a company that needs to communicate across continents. We double down on writing, going even further 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 of our colleagues’ work carefully and comprehensively so we can leave 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 to make sure we effectively educate internal and external stakeholders. Our writing standards demand we be clear and concise. Our specs are purposefully easy to follow and we consistently work with our engineering partners to ensure they’re both coherent and complete.
Do the Reading
To support the above, we need to do the necessary 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 in a way that enables us to provide real, usable feedback and help.
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, 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 (we’re logging through our outreach efforts) and to 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.
What Does “Fast” Look Like Here?
We 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 is revealed by 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 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.
We 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.
We Run Experiments and Scrappily Validate Hypotheses
To get to the best answer the fastest, our 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 a) what we’re doing is working and b) it’s on the list of top customer problems we should be working on (a 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.
↓ Featured Articles