According to David Cancel, CEO of Drift, the optimal number of members in a product team at a young startup is three.

But if you’re focused on the number to begin with, you’re missing the point.

“What was the theory behind three? I just made it up,” he said on an episode of his podcast, Seeking Wisdom. (Worth the subscribe.)

Before you panic, remember: Action trumps agonizing, and you can always change the number. That’s how David feels too. The point isn’t “to organize a product team better.” The point is to focus on the customer better.

“All of the products and services that we create are ultimately connected with the customer. The way we build software in the modern world should reflect that change.”

After a lot of testing, David has landed on a specific model with three engineers to a team. (What about product and design? We’ll get there.)

David is a serial entrepreneur whose recent ventures prior to Drift include founding Performable, which was acquired by HubSpot, then completely overhauling the HubSpot product and engineering team and ethos as Chief Product Officer.

Across his teams, he focuses first and foremost on instilling one truth: Everything you’re building is wrong. And the only way to figure out what’s right is to constantly talk to and involve customers. And thus his model for product teams was born.

 

First, be wary of waterfall and agile. (Yes, really.)

Despite the popularity of waterfall and agile, David has tried to distance his company from them. While powerful, he says that these things were born before the era where everything was so customer centric. There’s no excuse for every team at a company to not talk to customers, and rarely if ever are products being built that don’t in some way touch the customer, particularly in the SaaS and broader software worlds.

Nowhere does the abuse of the established models show up more than in the use of points. One of David’s biggest gripes with waterfall and agile is that the development sprints inherent in these models become a point-driven “game.” In the process of creating the product, developers often get caught up in a competition around these points and use them to discuss productivity and success. It’s easy to forget about why you’re doing the work in the first place.

David affirms that the real purpose is to create something great that people want to use, not to chase points.

The waterfall and agile models were great for their time, he said, but they are now outdated for the modern product development team. The best reason David sees to make use of smaller product teams with a new structure is to start by building a customer-centric organization, rather than a product-centric one.

 

Second, reorganize around customer and team happiness. (Yes, really.)

So with all the talk of customer focus, what does such an organization look like? According to David, the goal was to organize a team that he and his current and past cofounders would have wanted to work in — they were used to autonomy and freedom and wanted an environment that they would love to work.

 

 

In this customer-driven model, a tech lead acts as the highest in command. The tech lead is not a manager, however—the position is intended to be a contributing position for 80-90% of their time. Two software engineers, either back-end or front-end, report into the tech lead.

In this setup, the engineering team runs the product organization. They own the solution. This includes how they build the product, deciding to focus on bugs or new features, and project management of the product.

In this model, the product manager, the typical owner of the solution and the process, instead owns the customer relationship — getting ahead of the engineers to get feedback, wireframe, prototype, and so forth. The PM, along with one or multiple designers, are embedded among the engineers and get shared across multiple teams. They’re typically shared among one “family” — a group of products that are similar in the customer type or problem they solve.

In the end, the goal and the glue are the same: more freedom for the teams. Those closest to the problem can come up with the solution, test them with the customer, and iterate from there.

In addition to the results customers achieve, you can see the results of these teams by looking at employee retention, as well as measure happiness with a regular NPS survey to the team. (NPS = Net Promoter Score; for employee happiness, you might ask it this way: “On a scale of 0-10, with 10 being the best score, how likely are you to recommend our company as a place to work to a friend or family member?”)

So while waterfall and agile are still abundant in the corporate world today, those methods might be a bit outdated for the modern consumer’s needs. The best way to reach a customer base—and, in the process, create something that people want to use—is to let those closest to the customers run the show.

 

Listen to the entire episode of David’s podcast discussing this topic: