This week on Product Love, I sat down with Ben Keyser, VP of product at Contentful, the API-first content management platform for creating, managing, and publishing content on any digital channel. He’s been a product manager for the last fifteen years, and his career has spanned six countries and three different global SaaS products. Pretty amazing, right? Ben describes his background as a “speckled past” in which he’s dabbled in product design, engineering, and content strategy. And he was even a bartender at Yellowstone (which is super cool, if you ask me).
Despite all the different jobs he’s had, product management won out in the end. While the role is definitely challenging, the complexity and variety of problems he gets to work on fascinates him.
This week on Product Love, we talk about product management and delivery, as well as frames of reference.
Product management and delivery
Ben’s team follows a model that allows for product ownership. Historically, product owners have been the team motivators and the advocates for business requirements. They’re expected to talk to customers and take care of delivery. Early-stage startups typically use this model because everyone is learning how to work together.
But once you start to scale, that changes. As you grow, the trade-off is that you have to give product managers a different space to work in separate from engineering and design. Product managers stay in their own lane of problem discovery, whereas design and engineering solely focus on solution discovery.
Ben believes that these two groups of people need to be masters of their own roles. Specialization is key, as it allows the team to grow along with the company.
Now, lower the pitchforks. Ben knows exactly what it sounds like: “You’re asking the (engineering) team to make software and you don’t want their opinion.” But he doesn’t mean that. To him, separating the two groups actually improves collaboration. The PM should be an expert in all things customer-related, staying knowledgable and empathetic enough to react to the delivery team’s solution.
The delivery team also has greater creativity and freedom when coming up with a solution because they’re divorced from the customer. The PM is “married” enough that they can guide them back if needed. It’s not about product managers telling devs what to do. It’s more about allowing people to flourish in their own spaces.
Frames of reference
If you haven’t heard of Jobs-to-Be-Done and don’t know why milkshakes are relevant to product management, may we suggest this Clay Christensen video? Please watch it sometime today.
It’s one of Ben’s favorite frameworks because it’s so relevant. This frame of reference encourages product people to zoom out and ask: What is the customer trying to do? How can we help them do that?
We also talked a bit about how some teams only see customer problems through the lens of revenue. According to Ben, this is the wrong way to think about it. A PM’s only goal should be to solve problems. If revenue follows, then great.
Now, how is this relevant to engineering and design? Ben says it encourages those groups to think beyond their backlog. It’s easy to look at any backlog and start to reduce them to yet another list of coding tasks. But the JTBD framework changes the team’s mindset. It pulls people back to thinking about the value they could provide to their customers.
If you want to hear more from Ben about product management at scale-up companies or how Ben thinks about product management in a remote environment, check out the episode above. Let me know if you enjoy it at @eboduch or @Product_Craft.
You might also like
