A window into how our Product team thinks
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.