8 min read

Core Dinner: Product Leaders

This guest post was written and published by Matt Bilotti, Product Manager at Drift.

Last week some of the top product leaders across Boston gathered as part of the Core community. We discussed challenges we face as we grow our product organizations and shared experiences and theories about solutions.

The Underscore team has invited up-and-comers in the Boston community to these dinners and that happened to include me. It’s a fantastic initiative that I know they will continue to do in the other Core meet ups. As I was given the opportunity to be a peer at the table, I wanted to share the wealth of knowledge with others.

There were a few themes of the conversation that spanned scaling the actual product to offering customization as a service for your customers. Let’s talk about each theme and the major takeaways.

Balancing customer growth vs. product growth

As a product finds its market fit, especially in the B2B world, you start facing this challenge of bigger enterprise deals trying to pull you in 20 different directions with certain custom features. How do you handle this sort of push and pull while maintaining a focus on your core product?

  • Samuel Clemens, Co-Founder and CPO at InsightSquared talked about how they’ve built out professional services groups. They allow those groups to write code or “hooks” that execute after the product loads that enables custom features to operate within the core product, which helps land and support those larger enterprise deals without making major tradeoffs to the core product.
  • One advantage is that the Product Team can then look for patterns amongst the hooks being built. When they see a pattern, they build it into the core product. This signal is particularly valuable because it has demonstrated a measurable willingness-to-pay behind it.
  • Some companies have put a flag in the sand and said that they don’t support customization — they’ll only build something into the core product when the requests for a feature hit a tipping point around potential revenues.
  • Adam Medros, SVP of Global Product at TripAdvisor put the concept of customization in a very elegant way. He said that if you spin up another team that focuses entirely on customization, the goal is to sell the customization and then amortize the costs of that team’s existence by ultimately taking that customization that’s been built and putting it in the core product.
  • Another leader mentioned the foundational question around product customization request is the following…
  • Is the ask something that’s already along the way to your ultimate product goal and vision? If so, bite the bullet and build it.
  • Is the ask more of a detour from where you know the product is heading? If so, stomach the churns and lost deals and keep your team focused.
  • At Drift, when we get multiple requests for a piece of customization that we know is along the way with where the product is heading, we’ll quickly expose the ability to do what the customer is asking via an API. As we monitor the usage, once it reaches a certain point of utilization, we’ll productize the solution that people were using API to accomplish.
  • One other important note here that Mark Herrmann, Co-Founder and CPO of SessionM, brought up is that this is all very dependent on the industry and the size of deals. If you’re chasing a small volume of customers at six or seven figure deals, customization building is partly a fact of life.

Scaling a product organization

Inevitably, we began talking about the challenges and pains of scaling up an actual product team. We had people in the room from all sizes of product organizations, from 20 to 400.

  • Jeremy Redburn, Co-Founder and VP of Product at Salsify, kicked off the conversation by saying something he’s learned the hard way when hiring product managers is that he used to overvalue domain expertise. When pressed on it, he explained that people who have domain expertise often get too trapped in their own version of a solution and lose the empathy for the customer that’s so critical in building a great product.
  • Rob Strechay, VP of Product at Zerto, shared that at his previous company there was a product team overseas that nobody had visited in person in years. He stressed the importance of face-to-face communication (as great as things like Slack are) at scale. And how, especially as you build a distributed, global team, you have to put time aside to go to the remote offices and be a part of the team.
  • Tom Wilde, Chief Product Officer at Cxense, shared the same viewpoint as his company is headquartered in Oslo. And as the team grows and the product moves towards his vision, he needs to be there to help push the team in the right direction.
  • Adam from TripAdvisor summarized the role of a product leader well, and it’s this…
  • Set context, set context, set context. They have to continually set context for the decisions being made and the upcoming priorities
  • Realize that as your company and product grow, certain people won’t be as good at different stages of the company. And that a product leader who operated well on a 10 person team at a 10 person company may not work the same way on a 10 person team at a 600 person company. And these things need to continually be accounted for and addressed

Experimental Product Teams (Labs)

As we talked about product teams scaling, we hit on the idea of experimental product teams that tinker with concepts outside the core offering. There was a clear line of thinking that most at the table felt…

  • Usually, they don’t work. They are extremely hard to pull off.
  • This is because the larger company is constantly, and even if unintentionally, interfering with that product team’s ability to freely explore different solutions and craft their own processes for building and scaling products. Larger organizations often accidentally stifle this sort of innovation by trying to push too much progress too quickly, or expecting that team to operate too much within the existing flows at a company.
  • Adam Medros had some insights on this…
  • In order for an experiential product team to be successful, whether or not they’re coming employee-up or top-down, they should have an internal “board” of sorts.
  • The goal of that board is to guide the team and steer the eventual assimilation of that product team into the larger organization (without forcing this to happen too soon).
  • I was a part of the Signals/Sidekick/HubSpot CRM teams at HubSpot from when they were first crafted, and I saw all of the points Adam made put into play. Our team had a bubble around us and we were given our own marketing people, our own support people, our own sales people. This let this team find their own market and their own product and ultimately assimilate into the core product in a great fashion over the years.

No meeting of product people is complete without discussing continuous delivery and shipping speeds…

Michael J Skok, Co-founder and Partner at Underscore, brought up that he knows that continuous delivery can challenge customers ability to absorb innovation when the product is constantly changing. He asked us what we thought was emerging best practice for developing, packaging and delivering for customer acceptance.

  • Samuel Clemens talked about modifying an existing feature gating system they’ve built out at InsightSquared.
  • To him, there are two types of product changes…
  • Additive (adding a new button, changing the way something’s style looks like, building out a new feature)
  • Disruptive (re-organizing the way a page functions)
  • If a feature is additive, he’ll generally have his team send it right to production
  • If a feature is disruptive, they push it through a rough 4-stage gating process
  1. The feature is live, but nobody has it yet. Generally this means the feature will be on a hidden URL
  2. The feature is live, and all new customers have it
  3. The feature is live, and some existing customers get access to it, the adoption and changes in behavior are studied and measured
  4. The feature is live for all accounts
  • Ideally any feature gating switch is killed after 2 months.
  • Most B2B SaaS leaders at the table agreed that continuous delivery is worth it for the data gains you get, even though some customers may get a bit frustrated over time.
  • The goal of continuous delivery is that you can basically lower the cost of testing by doing it in production rather than in other environments or places and adding time to the shipping cycles.

A product organization’s defining features

One of the things we touched on briefly were the four key elements of any product organization. Those are as follows

  1. What’s the ratio of developers to product managers?
  • Most in the room were around 4:1, some were as high as 27:1
  1. Who owns design? The product leader or the marketing leader?
  2. How often do you deploy code?
  3. Who does product report to? The CTO, the CEO, or somebody else?

Roadmaps, roadmaps, roadmaps

Roadmaps are sometimes a touchy subject. We had basically a split room on the amount of leaders that adhere to a product roadmap vs. those who don’t have one at all.

  • There are three major components of any company’s view on roadmaps…
  • Do you have one? (Yes/No)
  • How far out does it go? (2 months, 6 months, 2 years, etc)
  • Who has visibility into it? (Internal-only, customer-facing, internal and external)
  • We came to a conclusion that the need for a roadmap greatly depends on the type of customer that’s being sold to and how big those deals are.
  • For example, BitSight Technologies has large revenue deals, so a roadmap makes more sense for their type of business than it would for a company like Drift where plans start at $25/month.
  • We agreed that the biggest challenge around roadmaps, and one of the things that makes a roadmap useful/necessary in some degree, is giving marketing teams a heads up on what’s coming down the pipeline so they can plan launches and messaging around the features/product updates.
  • David Chang, Co-Founder and SVP at Actifio, talked about how he has hundreds of versions of a roadmap and uses it as a canvas to test theories with customers. He’ll visit them, pull out a version of a roadmap, and use it as a way to guide the conversation and see where there’s excitement and pushback.

All in all, it was an incredibly informative and engaging conversation to be a part of as somebody who is learning to become a product leader (or already is). Thanks for reading and thanks again to Underscore for the invite!