[Written as an internal memo to Plaid, but relevant to most B2B companies.]

Plaid is first a product-driven [1] and second a distribution-driven [2] company. We make decisions according to these priorities. 

1. Our first priority is to build products that customers use.
   
   Simple statement, hard to do. Building products that customers use means listening to what customers say they want, and then figuring out how to deliver something that they will actually use. We spend a lot of time developing deep relationships with our customers so they share their issues openly with us, listening to feedback, sorting through it and figuring out what their underlying needs are, building products to meet those underlying needs, and iterating based on actual customer usage. Building something customers say they want is usually not sufficient – building something they use is harder. At the end of the day, product usage is the only metric that matters.
   
2. Our second priority is to effectively distribute our products to customers.
   
   Customers don’t buy products meritocratically. The best product does not always win. Purchase decisions usually weigh product quality, but tons of other factors matter, such as relationships, pre-existing MSA’s, brand, reputation, ease of install, bundling, pricing, etc. In B2B, product quality is usually amongst the top factors in purchase decisions; in other markets (ex: consumer apps), distribution matters substantially more than product quality. 

Everything we do at Plaid should be in service building great products and distributing them effectively. Everything else in the company – all our internal functions and processes, all our team members – should be working together to support the development and distribution of great products. 

[1] “Product-driven” does not refer to the PM team or any other job title. “Product” means the tools or services that we deliver to customers. Our company’s first focus is on building great products. 

[2] Being a “distribution-driven” company is not the exclusive purview of our go-to-market teams. The best distribution is often a result of intentional product decisions. We are all responsible for sales.

Big companies are a shitstorm of processes, questions, meetings, requests, favors, offsites, social events, and more. Each of these requests-for-time seem innocent enough, and the individual making the request is certainly well-intentioned. But the volume of these requests can leave our teams buried in mounds of shit. 

The job of a manager is to be a shit umbrella. The job of a manager-of-managers is to be a bigger shit umbrella. 

And the job of an employee is to don a shit-proof jacket, and find a way to get your work done.

What do you mean by shit?

For the sake of this analogy, shit is anything that is not directly creating impact for our customers. This is not to say that things like all hands, social events, emails, etc. are unimportant – they are just less important than the hard work of creating impact for our customers. 

What do we mean by “shit umbrella”? 

Being a great shit umbrella means protecting your teams from all unnecessary things that sap their time. This differs by function and team. For some teams, it might mean simply giving them permission to ignore unnecessary emails and calendar invites. For others, you might need to work with the individual to convey the importance of focus (give them a better shit-proof jacket). And in more extreme cases, it might mean auditing someone’s calendar, and discussing their personal time allocation. You may even have to go upstream and get the relevant sources to reduce the amount of requests-for-time that they send to your team. 

Why? 

Success in a startup is entirely dependent on building products that customers want, and delivering those products to customers effectively. No startup ever wins because their team is the best at attending internal meetings or approving expense reports.

The most effective atomic teams tend to have some commonalities. 

• Stay lean. Up to a certain point, adding more team members with the required skills is wonderful. However, once a team goes beyond 8 or 9 individuals, the coordination costs start to decrease efficiency. If a team needs to be larger, consider breaking it into two smaller teams. 
• Single, sequential goals. It is much for an atomic team to execute on one goal, then move to a second once the first is completed – instead of trying to execute on two goals at once. 
• Minimal distractions. Great atomic teams have very (very) few distractions, and (often) no meetings. As much time as possible (>90% of working hours) should be spent on either building products or talking to customers. 
• Strong interpersonal connections. Depth of interpersonal relationships matters within atomic teams. Great atomic teams spend 8-10 hours per day working together, so it’s worth getting to know each other! 
• Long-lasting. Atomic teams often will stick together through multiple projects, and the unit familiarity that develops leads to better and faster outputs. Likewise, teams that can focus on a given problem space for a long time have less whiplash and stronger instincts.