Give teams clear users to serve
⏱ Untimed topicPearl describes Calendly's interview-era core, enterprise and platform groups. Core covers end-user features and growth; enterprise serves IT and departmental admins; platform works on integrations and APIs. The structure follows users and problems rather than a universal organizational template.
Move beyond siloed objectives
⏱ Untimed topicShe recounts a progression from little shared strategy, to product-team OKRs, to company OKRs with integrated plans. The value she describes comes from knowing how work fits together and mapping dependencies. Merely adopting the acronym does not create that coordination.
Narrow the target market
⏱ Untimed topicPearl says serving a broad set of users made prioritization difficult. The team selected sales, recruiting and customer-success personas as its core focus. Work can still help other people, but the explicit target makes tradeoffs easier to explain.
Make strategy a set of choices
⏱ Untimed topicShe uses Playing to Win to discuss winning aspiration, where to play and how to win. Choosing where not to play is part of the strategy. Product teams can then direct resources toward a defined audience rather than trying to make an average product for everyone.
Connect allocation to the longer-term direction
⏱ Untimed topicPearl describes changing resource shares across three horizons as the strategy developed. Those percentages are her account of Calendly at the time, not recommended allocations for every team. The transferable question is whether the work and resources match the declared strategy.
Turn annual goals into nearer milestones
⏱ Untimed topicIn her planning account, company key results are annual, with quarterly milestones and product roadmaps supporting them. This creates more frequent opportunities to judge progress. It also connects a specific delivery plan to the business result it is meant to serve.
Commit dates within your control
⏱ Untimed topicPearl distinguishes discovery, testing possible solutions and engineering delivery. A team may commit to finishing research before knowing whether it should build at all. Delivery estimates become more useful after the problem and solution are understood; avoid confident promises for distant, unexplored work.
