The startup heartbeat

Orchestrating product, marketing, sales, and finance

Photo credit: Diuno

In a recent post, David Sacks ex-COO of PayPal (in the “PayPal mafia” days) and founder and CEO of Yammer (acquired by MSFT for $1.2B in 2012) laid out an integrated framework for orchestrating the operations of the four major departments of every SaaS startup: product, marketing, sales and finance. 

The Cadence: How to Operate a SaaS Startup 

While some design elements can be modified to meet the differing needs of non-SaaS startups, this framework is a fantastic starting point, that can save many startups years of discordant operations and cross-departmental friction and missed hand-offs. I’ve taken a stab at summarizing it below: 


  • In a SaaS context quarterly goals (and therefore, planning) seems to be ideal time-frame. Yearly is too rigid/unresponsive and monthly is too volatile. This dictates the heartbeat for everything else.  
  • The quarter begins with a Sales Kick-Off (SKO) where the sales team receives their new quotas, commission plans, and territories. Learnings from the previous quarter are shared, and Product demos the latest version of the product and reviews the roadmap for the current quarter.  
  • Once the plan is clear and in play, sales leadership focused on pipelines review and support. The sales team is immersed in active sales efforts supported by news, awards, and recognition generated by the marketing team. 
  • The third month is dedicated to heads-down closing and making the numbers with minimal interruptions.


  • Synchronizing the finance calendar with the sales calendar simplifies and clarifies financial reporting since the numbers then reflect a complete quarter’s sales activity.
  • A fiscal year ending on Jan 31 rather than Dec 31 avoids the end-of-year holiday crunch and disrupts customer expectations around end-of-year discounts.
  • Board meetings occur two to three weeks after the end of the previous quarter allowing for


  • The product roadmap gets reviewed and prioritized quarterly with external input from the board meeting and a customer advisory board informing the process. 
  • The goal is to align on the “major rocks” of each release, giving individual PMs a lot of autonomy in determining the “pebbles” and “sand” that fill up the overall capacity. 
  • Development projects are scope so that they can be shipped within one quarter. The rule at Yammer (where Sacks was CEO) was that projects would be assigned 2 to 10 engineers for 2 to 10 weeks. This is conceptually very similar to Basecamp’s 6-weeks model and other incremental software delivery approaches. 


  • The overall marketing approach should be event-based — orienting around a central quarterly event that can combine launch announcements and demos of new features with news about customers, financing, market share, metrics, or other milestones.
  • There’s a benefit to tying the product and marketing calendars together so the externally committed deadline can become a motivating factor. A lot has been said about the delicate balance that’s required in order to avoid the downside of this coupling. The product approach outlined above (projects’ scopes + release planning) is one essential component in enabling that coupling. 
  • Not all four quarterly marketing events have to be big ones. An annual user conference + three smaller webinars/city events can sufficiently drive the desired discipline around product delivery. 

Putting it all together 

Shifting to this orchestrated heartbeat starts with determining the fiscal year (Dec 31st. vs. Jan 31st, etc.) which derives the fiscal quarters. Sales plans are then lined up with the fiscal quarter, deriving the timing for SKOs and quarterly closing. Scheduling the marketing event in the middle of the quarter offsets the marketing calendar from the finance and sales calendar by 45 days, positioning the surge in marketing activity to best support on-going sales efforts. Lastly, the product cycle is aligned with the marketing calendar to hit the event deadlines. 

The coordinated heartbeat creates natural opportunities for internal “all-hands” meetings (not all should be used): after the books are closed, after the board meeting, before/after the launch event.  

This is another example where a picture is worth a thousand words, and in this case, the final picture looks something like this: 

The startup heartbeat

The best kind of CEO shadow

This program for top performers is a true win-win

Photo by Daniel Polo on Unsplash

The shift towards distributed/remote is causing many companies to revisit their core HR programs with the realization that simply “doing what we did before, but virtually” is not a long-term solution. In particular, engaging, developing and retaining top talent has been top of mind for many leaders since this shift unlocks new opportunities for these individuals, creating a critical “shields down” moment. 

 Luckily, this is another area where many companies can (should?) take a page out of GitLab’s handbook (pun intended) and consider implementing a CEO shadow program for their top talent: 

GitLab’s CEO Shadow Program 

In typical GitLab fashion, the link above describes their CEO Shadow Program in full transparency and almost-excruciating level of detail, resulting in an 8,5000-word document. Below I’m hoping to do my best in highlighting the key design elements that are worth considering when implementing a similar program elsewhere, using 95% fewer words. 


The goal of the program is to help participants globally optimize their work by gaining a deeper understanding of how GitLab works, and what it aims to accomplish, as well as building cross-functional relationships with other members of the program’s cohort. For the CEO, it’s an opportunity to build a personal relationship with team members across the company and learn about challenges and opportunities through their unique perspective. 

Eligibility & Application

In addition baseline tenure (at least 1 month, preferably 3) the eligibility criteria aim the program at employees on the managerial track with large spans of control, senior individual contributors, cultural leaders and under-represented groups (both minorities and geographies). The application process is driven by the employee, requesting a particular slot on the schedule, highlighting how they meet their eligibility criteria and providing confirmation from their manager that they meet the criteria.  


The program runs on an on-going basis with a few rare exceptions (CEO PTO, etc.). Participants shadow the CEO for two weeks with one week overlap, so during the first week a participant is trained by the outgoing person and during the second week, they train the incoming person. This is a good place to highlight the extra consideration that GitLab made for parents — highlighting specific “parent-friendly” slots in which full week participation is not required or the weeks are inconsecutive, and paying for childcare while parents participate in the program. 


Participants are expected to prepare for their time in the shadow program by connecting with co-shadows and program alumni, preparing a formal onboarding program (off a template), and getting up to speed on the work currently in-flight (projects and calendar) and the CEO himself. 


The format is pretty straight forward. Participants are expected to perform a set of small administrative/operational/documentation tasks that can be completed during their time in the program and be part of almost any conversation that the CEO is having with a very small subset of explicit exceptions. Detailed guidance is available on everything from what to wear, through how to present yourself and act during meetings, to how to navigate the CEO’s home office (aka “Mission Control”). Of note is the awesome expectations to “speak up when the CEO displays flawed behavior” which probably merits a post of its own. The specificity in both describing them and validating/inviting the way you can respond to them is truly inspiring. 

In Sum

A CEO shadow program can be a phenomenal opportunity to help retain top talent. If you’re considering starting such a program in your own organization, the GitLab handbook page is a comprehensive jumping-off point that can help ensure that you got all your bases covered. You can refine, modify and iterate from there.

The best kind of CEO shadow

Does your team discuss the undiscussables?

The 4 types of team undiscussables teams should start discussing more 

Source: MIT Sloan Management Review

A neat piece by Ginka Toegel and Jean-Louis Barsoux expanding on element from the psychological safety piece from a few weeks back: 

It’s Time to Tackle Your Team’s Undiscussables

Tackling undiscussables, a set of issues that are holding the team back but the team is reluctant to discuss, is a good example of taking an interpersonal risk in support of the greater benefit of the team. The reluctance to discuss them often stems from fear that doing so will sap the team’s energy, surface unresolvable issues, or expose the person to blame for the part they played in creating the issue. Where in fact, it is often the case where tackling the undiscussables brings relief, boosts the team energy and generates team goodwill. 

Toegel and Barsoux offer a taxonomy with 4 types of undiscussables, differing in their source, the way they should be approached, and the sequence in which they should be tackled: 

  1. You THINK but dare not say — risky questions, suggestions, and criticisms that are self-censored out of fear of the consequences of speaking. Often due to past erratic or uncharitable responses from team members. Beginning the fix: leaders can explicitly acknowledge they may unwittingly have created a climate of fear or uncertainty, invite discussion about sensitive issues, draw out concerns, promise immunity to those who share dissenting views, and lighten the weight of their authority in the room.
  2. You SAY but don’t mean — spoken untruths. Discrepancies between what the team says it believes or finds important, and how it behaves. These issues are often left undiscussed not based on fear as much as on an unquestioned and distorted sense of loyalty to the team, its leader, or the organization. The intent is to maintain the team’s cohesion, even if that cohesion is based on a shared illusion. Beginning the fix: leaders need to make the hypocrisy of saying but not meaning explicit and acknowledge their part in the charade. Collecting anonymous examples of empty proclamations (“We say we want to…, but in fact, we….”) and challenging the overprotective mindset that inhibits the airing of criticism can kick-start the fixing process. 
  3. You FEEL but can’t name —negative feelings that are difficult for team members to label or express constructively, often failing to see the difference between manifesting one’s anger or resentment and discussing it. At a more basic level, they are not discussed because the antagonists experiencing negative emotions don’t test their inferences. Based on their own worldviews and self-protective instincts, they presume they know why the other party is acting in a particular way and let that drive their behavior. This leads to escalating tensions. Beginning the fix: help the feuding parties investigate the differences — in personality, experience, and identity — that sustain and fuel their apparent incompatibilities, rather than ignore the feud and the negative emotions associated with it. Enable them to share their experience while staying on their side of the net.  
  4. You DO but don’t realize — collectively held unconscious behaviors, such as instinctively developed defensive routines to cope with anxiety. Beginning the fix: Warped interaction patterns may be readily discernible to outsiders. A trusted adviser or an external facilitator can be invited to observe the team and give feedback on their communication habits through humble inquiry

Toegel and Barsoux recommend tackling the “SAY but don’t mean” undiscussables first, as the gap is between two elements that are visible to all team members — the things we say and the things we do. And leaving the “Do but don’t realize” undiscussables for last, as they require outside intervention that will predicate on enough internal goodwill being built by tackling the other undiscussables first. 

Lastly, Toegel and Barsoux offer a lightweight diagnostic tool, to help identify what type of undiscussables may be present in a certain team, based on the most common symptoms and team patterns: 

Source: MIT Sloan Management Review
Does your team discuss the undiscussables?

HEY, it’s about time we reinvented email

Basecamp’s new email client is a tour de force of the “jobs to be done” approach in all aspects but one

I rarely cover specific products in this publication, but decided to make an exception this time for the following reasons: 

  1. It’s a collaboration product, and collaboration is a core organizational need.
  2. It’s quite transformative in the way it approaches some big challenges with the existing solution (email). 
  3. Many of the issues it’s addressing and the approaches that it’s taking to solving them apply to broader collaboration mediums that extend beyond email.

You can check-out the feature-by-feature overview here or watch this tutorial video. I’ve decided to take a stab at organizing the features by the challenges that they are addressing. 

Screen and triage

Emails from new senders arrive at a “screen queue” where they can either be rejected or accepted and triaged to one of a few “work queues”: 

  • Imbox (default)
  • Reply later — non-urgent emails that require a response.
  • The feed —newsletter and other non-urgent recurring communications.
  • Set aside — short-term reference: information about an upcoming event/meeting, document that needs to be reviewed, etc. 
  • Paper trail — long-term reference: receipts, reservation confirmations, etc.

Read and respond

Each work queue supports a slightly different workflow for handling the emails in it: 

  • Imbox — split between “new for you” (unread) and “already seen”. A “read together” feature opens all unread emails in a single screen enabling the batch review of all unread emails together. 
  • Reply later — offers a “focus and reply” feature, with similar UX to “read together” but adding a reply box to the side of each email. 
  • The feed — a news feed view with the most recent email at the top offering a preview of each email and an ability to expand (“show more”) the whole email. 
  • Set aside and Paper trail — a Pinterest board view with a visual digest of each email 
HEY “focus and respond” workflow

In addition, email threads have the following additional features, impacting only the particular user (not all thread recipients): 

  • Rename the subject line.
  • Merge threads of the same topic.
  • Notify when new responses are added to the thread or when an email is received from a specific sender. (notifications are off by default).
  • Clip (save for later) a portion of the email. 
  • Add a “note to self” to the thread — “response” that only the user can see.
  • Add a “sticky note” to the thread that shows up under the subject line in the various work queues. 
  • Send large files. 
  • Unfollow (mute) — feature parity with existing solutions.
  • Labels (tags) — feature parity with existing solutions.
HEY “note to self” feature


Finally, recognizing that email is also used as an archiving system, HEY added the following features: 

  • “Paper trail” queue (discussed above).
  • List of all the content clipped from emails. 
  • Contact view showing all correspondence that involved that contact, surfacing files separately.
  • Files-only view 
HEY contact view surfacing files separately and supporting granular notifications

There’s also a neat privacy feature proxing all images and therefore preventing unauthorized data collection using a tracking pixel

There is, however, one area where HEY misses the mark and fails to extend the “jobs to be done” approach into a critical element of the user experience: migrating work into the service. It is unlikely that users will rush to leave their native email address and immediately start using they address. For many of us, our email addresses serves as a better unique identifier than our physical address. We change apartments more frequently that we change our email address and therefore this change is associated with non-trivial switching costs. While HEY does support auto-forwarding of email from your native email address, it does not (as of the writing of these lines) support defining a different “reply from” email address. Therefore, email responses from HEY will go out from the email address, creating a confusing and discontinuous experience to the email recipient. 

In sum, HEY creates a transformational email experience by acknowledging three deep truths and building them into the user experience:

  1. Different emails, different use cases — users engage with different types of emails in a different ways. We engage with an email from a good friend, a newsletter and last month’s internet subscription receipt differently. Therefore, the email client should support different workflows.  
  2. Different users, different preferences — traditional email forces complete symmetry in the way two people view the same email thread. HEY breaks that symmetry and allows users to modify and annotate the threads in a way that makes sense to them. 
  3. Communicate AND document — building on the framework I covered here, while email is primarily used to communicate, it’s a sufficiently good system of record for documenting/archiving some critical content. Supporting that secondary functionality needs to go beyond good indexing and a search box. 

If we zoom out, these truths apply to other non-email collaboration tools such as chat and discussion boards as well. Therefore, considering similar approaches to addressing them in those other mediums opens some thought-provoking opportunities. 

One of the beautiful things about HEY is that it’s a “dumb” email client from a technical standpoint. There’s no AI/Machine Learning involved in any of the features I listed above. It screens the emails you tell it to screen, it triages emails to where you tell it to put them, it notifies you about emails you tell it you want to be notified about. 

On the one hand, it’s an incredible testament to how far just deeply understanding what your customers are trying to do with your product can take you. 

One the other hand, it may also be HEY’s biggest business risk. A HEY subscription currently costs $100/yr. But if HEY starts getting serious traction, how hard would it be for Gmail to catch up? 

HEY, it’s about time we reinvented email