When it comes to building products, Agile and Waterfall just don’t cut it anymore.
It’s 2016.
Both of those things were popular in an era when talking to customers and getting feedback was hard. But today, there’s no excuse. Every team at your company should be talking to customers daily.
Your customers don’t operate in six-week release cycles.
They don’t think about weekly sprints.
They don’t want to hear “it’s on our roadmap for next quarter.”
Customer expectations have changed along with the rise of software-as-a-service and the on-demand economy.
And with so many options and competing products for your customers — do you honestly think customers are going to stick around until you fix that bug in your next release cycle in six weeks?
I wouldn’t stick around. And your customers won’t either. As a result, the way that we build our products and structure our product teams needs to change too.
How A Modern Product Team Should Work
After HubSpot acquired my last company Performable in 2011, I wanted to see if we could do things a little bit differently — even at a company that was already starting to get “big.”
Everyone says they’re customer-driven. But I wanted us to get past just saying it — past the slogans and the mantras.
I wanted to structure our product team in a way that forced us to place the customer ahead of everything else. And that included changes to our culture, our process, the size of each team and more.
We started this at Performable, then brought it to HubSpot and now we’re continuing to evolve it as we build Drift, but the core principles are the same.
Keep Teams Small
One of the highest impact decisions we made at HubSpot keep both the size of the teams working on a product and the scope of work they undertook small.
Small teams mean fewer distractions, less risk of getting caught up with pet rocks, and a singular shared focus on the customer problem at hand.
Small teams also help stop some of the BS that comes when teams get big — it forces everyone to talk to each other and work together. Not hide behind the Wiki or in Slack. There are fewer excuses for not being able to get things done because of internal politics when teams are small.
So 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 Product Manager. That shift means that PMs, who work across dev teams, can focus solely on customers and vision.
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. When you keep teams small, you can avoid a lot this.
No Shared Resources
Want to move slow? Want to deal with politics? Have your product teams share resources.
This was the main reason why each team had dedicated PMs and Designers.
With embedded resources, 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.
Additionally, keeping teams small should not mean keeping teams narrow. So while we kept the core technical team tight, they were bolstered by the presence of those embedded resources — everything from product marketers to 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 Key Ingredients Are Autonomy And Ownership
At HubSpot and now at Drift, autonomy and ownership mean that development 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 then 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.
But beware: autonomy without accountability is tyranny. That’s why ownership is such a key ingredient here.
At The End Of The Day, The End Goal Is Learning
I’ve never believe in setting a public product roadmap.
The problem with product roadmaps 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’re shipping daily. This way, the customer could help us correct and iterate on our direction — not approval from an executive.
The end goal is learning. Evolution is a hugely important part of being customer-driven. Your team needs to be able to move fast enough to make changes based on customer feedback and usage — not because something is next on the roadmap.
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.
These are the steps that we’ve taken to creating a customer-driven product machine, and this is the topic that I’ll be talking about at this year’s Business of Software conference here in Boston.
And we’ll probably have evolved more since then, too.
David Cancel is a five-time entrepreneur, two-time CEO, angel investor, and currently the CEO at Drift, a startup that’s making it easier for businesses to talk to their customers. Prior to Drift he was at HubSpot where he served as Chief Product Officer after HubSpot acquired his last company, Performable.