Just the Highlights: The Big Interview Takeaways

We conduct these interviews for product teams: product managers, UX professionals, and developers who are responsible for shipping great products. We understand it’s difficult to take time away from your job to digest content. That’s why we’ve highlighted the key insights for you below. We highly recommend you read the entire interview for more advice and recommendations from Jeremy.

1. When a customer tells us they want to build a feature, we don’t just build it. Instead, our product teams focus on digging deep into The Why question. We start by asking a lot of questions.
   
   
2. HubSpot provides the product teams with extremely high levels of autonomy and ownership. Our small teams own their area of the product. There is no formal approval or review process.
   
   
3. HubSpot has invested heavily in a development support platform. They have an entire team dedicated to building tools and infrastructure for developers.
   
   
4. On each cross-functional team, HubSpot has a Tech Lead, two engineers, one product manager and one designer.
   
   
5. The HubSpot teams communicate regularly to ensure consistency across product lines. They spend a lot of time in what they model after Trade Groups or Guilds.
   
   

Full Interview with Jeremy Crane

Jeremy Crane brings more than 15 years of experience in marketing and product development to HubSpot. As VP of Product Development, Jeremy leads product development and design for HubSpot’s marketing platform.

What brought you to HubSpot?
I have spent the majority of my career working with marketers in the Online Media space. I started out in Professional Services at Compete, working with companies like Google and Microsoft to help them understand how users interact with their offerings.

While at Compete, I got involved in Product Development and eventually landed at oneforty, a Boston-based startup that provided a marketplace for Twitter applications. After running product for a year and half, we were acquired by HubSpot. At HubSpot, my team was responsible for building the content platform and I started managing HubSpot’s marketing product about 2 years ago.

How do you describe HubSpot’s product offerings?
We have two main product lines at HubSpot: a core marketing product and a sales product. Our marketing product is an all-in-one marketing platform serving mid-market customers. The platform is designed to help marketers get their everyday jobs done and consists of an entire suite of offerings for marketers.

Along with a content management system, we have tools for sending batch and automated emails, creating landing pages, managing contacts, building lists, creating dynamic content, social publishing, social monitoring, analytics and reporting.

HubSpot focuses on the changing environment of the sales and marketing world and how business is done in an online world. The reality is that old methods of marketing, such as buying advertising, don’t work anymore. We help marketers rethink their go-to-market approach, what value they offer, and how they engage with a more informed purchaser. At the core we help small and midsized companies grow.

What is the biggest challenge your product teams face when striving to build best-in-class products?
It’s very easy with an all-in-one platform to say we’ll keep adding functionality and try to add everything. But if we take that approach, we start getting into big complexity challenges with a product that is overwhelming for customers. It’s been a challenge trying to battle that complexity.

Where does the pressure and demand come from to add features?

When you have an all-in-one platform, you want to be the one tool besides email that a marketer logs into in the morning and uses all day. That means we have to cover all bases.

There is some internal feedback that we should sell, build, or market specific features. However, the majority of feedback comes from customers. We have 15,000 customers and, for a B2B platform, this is definitely on the high side.

In our experience, when customers tell you they want a specific feature, that feature isn’t necessarily what they really need. How do you ensure you focus in the right areas?

When a customer tells us they want to build a feature, we don’t just build it. Instead, our product teams focus on digging deep into The Why question. We start by asking a lot of questions. Why would they like the feature? What are they trying to accomplish? What is the thing they can’t do now that they would like to do? By asking these questions, it allows us to delve deeper into the true needs and better understand what customers hope a feature will enable them to accomplish.

We are laser focused on building for the customer, which means we rely heavily on customer channels for feedback. We spend a lot of time watching people work and visiting them to see where their big pain points are. This allows us to identify use cases and opportunities to solve these challenges.

We tackle the use cases and problems from a broad perspective. Instead of building a feature to address a single use case, we work to find ways to address a large number of use cases with creative solutions. Instead of adding feature after feature, we’re adding unique flows in the product that allows users to accomplish their goals in a way they haven’t thought of before. That’s what we strive for.

What accomplishments have most contributed to your product’s success?

There are three things that contribute to our success.

We provide our teams with extremely high levels of autonomy and ownership. Our small teams own their area of the product. There is no formal approval or review process. While management pushes the teams and gives them big, challenging goals to accomplish, we don’t tell them how to attack the challenges or specify how long it should take.

We have small cross-functional teams dedicated to problem areas. The only way the autonomy works is by having small teams with high levels of ownership. This allows the teams to be nimble and dynamic and there is no design by committee. At HubSpot, you will never have 10-15 people in the room giving you a go no go on the UI. It’s just design feedback, not managerial approval.

Finally, we have an unbelievable development support platform. We have an entire team dedicated to building tools and infrastructure for our developers, which gives them the ability to deploy their product into production at any time of day. Developers can deploy at will with no formal release process to get into production. It’s essentially the click of a button to deploy the product.

How has the development support platform contributed to the success of teams?
We have made a big investment in our robust platform and it results in less distraction for our developers. They can focus on building the product instead of getting bogged down in process. They don’t have to worry about choosing architecture, how they will deploy or monitor, or how they will set up systems for dealing with errors and rollbacks. Instead, our backend engineers can dedicate time to building APIs that make the product more robust and fast, and our front-end engineers gets to work on the product’s look and feel and interactions.

It was important for us to invest in these three areas: Total team control, small teams, and removing unnecessary development processes.

How are the teams structured?
We are an Engineering-driven organization, which means the center of our universe is the Tech Lead and the Technical Team of developers.

On each small team, we typically have a Tech Lead, two engineers, one product manager and one designer. The Tech Lead is typically a full stack developer who can guide the team. One developer often has deep back-end experience and one developer is typically a strong front-end engineer.

The product manager and designer typically have 1-3 technical teams they cover.

What is the ratio of engineers to designers?
It’s about 6:1. We would like to get closer to 4:1, which would be ideal. Our biggest goal is to ensure all teams are balanced and we have the right amount of coverage on each team.

With 30 or so small, cross-functional teams, how do you ensure all of the teams take a holistic approach to the product?

This is a big challenge. We set our structure up with the small teams because this is most important thing to us. No energy needs to be dispensed on being fast and nimble.

With approximately 30 teams, we need to focus our energies on the big picture and how we connect the dots between the teams. It’s important to ensure we don’t have 30 completely different applications under one navigation menu.

We dedicate a lot of time to ensure we have common interfaces and patterns and move in a shared direction from a strategic perspective. We accomplish this by encouraging our teams to talk with each other as much as possible. In my role, I spend a lot of my time meeting weekly with the product managers and tech leads to ensure they are connecting the dots. Most of my day is spent pattern matching between the teams and ensuring they are communicating.

How frequently are the teams communicating with each other?
We spend a lot of time in what we model after Trade Groups or Guilds. For example, all of the designers at HubSpot meet two times a week for design reviews and standup-style updates. This allows the designers to all have visibility into each other’s work. Similar conversations happen amongst product managers, front-end engineers, and back-end engineers. They all have their “guild” to support them.

It’s tempting for organizations when they reach the scale of a HubSpot, to try and put formal systems and processes in place to combat the communication issues. But we have made a concerted effort to stay away from that. We are willing to put in the extra work by communicating as much as possible with each other.