Finishing What We Started

I'm breaking my promise...

I made a promise this past weekend to the friends who had signed up for my newsletter that I was ditching my personal blog. My intention was to focus on my newsletter over my blog as a way to finally get back to writing. Well that promise did not last long.

 I want to publicly comment on some questions that have come up this week as the news of what we have been working on at Driftt has finally been made public. Just yesterday we had a great article published on BostInno and this morning I woke up to see that we had been hunted on Product Hunt.

For the last year at Drift we have been exploring how modern consumers and companies communicate. If you're interested in reading more about our exploration phase checkout the 3 phases of exploration post on our blog.

So where are we?

We're back to what we started back in the Fall of 2009.

We went "Back to the Future", back to where our obsession with building customer-driven companies, teams and software all started. Back to focusing every day on helping our customers delight their customers.

In 2009 we started Performable with a vision of bringing a unified customer view to Marketing teams in order to have them drive better experiences for their customers. 

In the summer of 2011 Performable was acquired by HubSpot. At HubSpot we narrowed our focus down to the first few steps in the customer lifecycle - attracting more leads (marketing) and converting them into customers (sales). Narrowing our focus was the right thing to do at the time and that focus turned out to be very successful for us at HubSpot. 🙏

After leaving HubSpot we spent a lot of time talking to companies everywhere trying to learn what had changed in the market. What we learned over the last year was that no company had successfully delivered at scale on the second half of the customer story we saw at Performable.

What happens after someone becomes a customer is even more important today than it was in 2009. I believe that Subscription Revenue Models are Eating the World across software, mobile, device (IoT) and offline businesses everywhere. 

With that massive shift happening and more companies depending on their customers to deliver a larger percentage of their revenue we decided to go back to finish what we had started in 2009 - helping companies better enagage with their customers.

At Driftt we believe that marketing to your customers and not strangers is the future of marketing. We call this Relationship Marketing and believe all businesses can do a better job at matching how modern customers want to experience their products and services. 

If you're interested in learning more I invite you to check us out at Drift.

P.S. This morning I found this old video (from early 2011) describing our vision at Performable. With your help we can finish this story at Driftt.

Read More

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

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