Creating A Customer-Driven Product Machine

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.

(Note: This post first appeared on the Drift blog, where we share our thoughts on building customer-driven products, and teams.)

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.

Read More

Micro Experts

“The only true wisdom is in knowing you know nothing.” - Socrates

It feels like everybody is an expert these days -- actually, more like what I call a “micro expert” because their “expertise” usually only covers a niche within a niche.

I was reminded of this recently while reading a piece in the New York Times. In an online conversation between two Times writers who have recently left San Francisco after many years of living there, one of them recalled a colleague walking out of a popular coffee shop because:

“I was just standing in line behind two entrepreneurs that couldn’t be more than 19 years old and they were giving each other advice on how to fire people and run a company...”

I’ve overheard many similar conversations recently. Maybe we were always surrounded by “micro experts,” "growth hackers," "talent hackers," and the like. It could be that social media has just amplified the phenomena or maybe social media actually helped create it. Regardless, it is interesting to see the surge during this period in my life, especially since I personally am moving in the opposite direction: as I’ve accumulated more experience (AKA grown older), I realize each day how little I know.

I’ve been fortunate to work on projects about which I am passionate, and to spend my time learning new things on a regular basis. Originally, that meant writing software; more recently I have continued in creating products, starting companies, and, most importantly, helping to build and develop great teams and leaders who embody the principles of servant leadership.

It’s taken me five startups and many years to finally see my own pattern of when I start, and later leave, companies. Looking back, I always started a company when I was obsessed about learning how to solve a market problem, and I always left when I felt that I had stopped learning. It’s so clear now but it wasn’t during all those startups. I figured my timing was random. It wasn’t. All my decisions were based around learning opportunities. They still are.

Continuous learning has always been my main focus -- the kind of learning you can’t get from just ingesting information on Twitter or from reading blogs (including this one). True learning is acquired through constant practice and reflection over a long period of time.

I guess that’s why the idea of so many “micro-experts” irks me. The idea that you could become an expert in anything overnight, or even over a year or two, just doesn’t exist in my world. More specifically, the idea that someone would think they could become an expert misses the whole point. Becoming an expert shouldn’t be the goal; always learning and practicing should be.


Read More

My Golden Rule for Pitching Your Startup or Product

There's a simple rule I use when pitching a product or even a company to someone. I call it "No Ands."

The "No Ands" rule is simple: You have to be able to describe your idea in a single sentence without using the word "and."

I believe "ands" are crutches -- they add confusion and show you don't really understand your value proposition.

The reason I've used this crutch in the past is probably the same reason that you've used it: I'm so excited about how big an idea can be that I want to share my excitement with everyone I talk to. I never want someone to walk away from a pitch unimpressed. I want them to see the same big idea that I see. So I try to convince them with lots of "ands."

But the problem with using "ands" is that they often confuse ideas instead of clarifying them. What's a better way to describe

a. The largest online store on the planet for almost any product you'd want to buy.
b. An ecommerce store and a maker of hardware devices (Kindle, etc) and also a cloud computing provider and a marketplace where you can sell goods (digital and physical) and ...

As ridiculous as that example may seem, it's not far off from the pitches I've heard from entrepreneurs describing their company or someone describing the product they are building.

The "No Ands" rule is a simple constraint that you can use to focus your pitch. Constraints in my opinion are a critical ingredient for innovation and creativity. Try introducing this constraint the next time you pitch an idea to someone. I think it will teach you to clarify your positioning and, hopefully, result in fewer glazed-over eyes and confused recipients.

Read More

Like this post? Subscribe by email or say hello on Twitter: @dcancel.