Listen to the podcast on iTunes or SoundCloud.
Every company in the world will tell you they are customer-driven. They’ll believe in the principle. They’ll have framed posters on the wall about it. “Solve for The Customer.” But none of that means anything unless you actually make the structural decisions to ensure it.
When I rebuilt the product team at HubSpot, back in 2011, I wanted to see if we could get beyond slogans and mantras to structure it in a way that intrinsically placed the customer ahead of everything else. I made a few decisions, in form, process and culture, that were designed to safeguard the team against misdirection and ensure that customers remained central.
Units not Divisions
When you spend more time talking to “internal stakeholders” than your customers, you’ve lost the ship. That’s the truth. It’s a failure that can sneak up on you. One of the highest impact decisions we made at HubSpot was to constrain both the size of the teams working on a product and the scope of work they undertook. Small teams mean fewer distractions, less risk of getting mired in pet rocks, and a singular shared focus on the customer problem at hand.
We started with a tight technical core of three people. No more. These small teams were hyper-focused and autonomous, owning both the product and the process for shipping it. Of the three developers, one takes the role of Tech Lead for the team. The Tech Lead drives timelines and project management, something other companies typically leave in the realm of the PM.
That shift means that PMs, who work across dev teams, can focus solely on customers and vision. As Product VP Jeremy Crane explained in a recent post, “At HubSpot the product manager owns the ‘problem’ and the technical team owns the solution.”
Embedded resources
There’s an important distinction I want to call out here that small should not mean narrow when it comes to structuring product teams. While we kept the core technical team tight, they were bolstered by the presence of embedded product marketers and UX designers all fixed on the same problem and solution. Designers and UX researchers informed the product teams from the point of mockups, through testing phases, to the ultimate release and support the product. Similarly product marketers were embedded with the teams from day one working with product managers to understand the problem, develop the customer-focused positioning and execute a go-to-market strategy. The upshot here is that product teams become wholly self-sufficient organisms. They are small enough to retain customer focus but still have the skilled resources they needed to design, test and market the solutions they developed.
Autonomy and Ownership
Ownership at HubSpot means that dev teams are responsible for the entire product including supporting the apps. There are no separate QA or release engineering teams. No fragmented view into whether or not their solution worked. Developers see products through. When a product succeeds, they own that. When a product falls short of solving a customer problem, they carry that weight too. And the iteration process begins. That’s why we shipped quickly and without a lot of executive interference. It’s about the relationship between the customer, his or her problem, and the product team trying to find a solution. We ship quickly, hear from the customer, regroup and ship again. It is this autonomy, fast learning and eventual mastery that drives us.
There is no end-goal. The end-goal is evolution.
At HubSpot I made the decision to not set a public product roadmap. For a company that values transparency, it was a decision that led to a fair amount of hand-wringing from those wanting a reliable way of knowing what was coming next. The problem with product roadmaps however is that they often satiate company curiosity more than they solve customer problems.
I’ll give you an example. Let’s say as part of a public roadmap we commit to creating a certain app or feature. Once stated, the completion of that app becomes the end-goal. The sales team previews it. The business readies for it. But then in talking with customers and testing, let’s say we discover that the app doesn’t solve the problem at all. It’s a false approach. We’ve then got a dichotomy of needs on our hands. Do we serve the company who in stating it publicly has built up an appetite to see this app in the wild? Or do we serve the customer, abandon the approach and build the thing that’s actually going to work?
Roadmaps solve for the company not the customer. What solves for the customer is non-stop testing and a continuous improvement. Instead of having 2-3 releases a month, we had 1000s. Instead of building up a release for months, we got it into the hands of beta users immediately, often before a HubSpot executive had seen it, so that the customer could help us correct and iterate on our direction.
The framed poster on the wall would tell you customer happiness is everyone’s responsibility. Maybe, but that’s a really unproductive way to achieve it. As the old axiom says, if everyone is responsible, no one is responsible. By keeping teams small and autonomous, and giving them concrete ownership of specific problems rather than abstract ideas, we were able to build a product team that truly solved for the customer.