Leader Spotlight: Falling in love with the problem, with Calvin Marshall

Calvin Marshall is the former Principal Business Product Manager at Jenzabar, a technology suite for higher education. His career includes stints as a product manager at global shipping and logistics giant DHL, as Director, Product Operations and Planning at Kaplan, and Principal at Four Peas Consulting. Before his most recent role at Jenzabar, he worked in product strategy and product marketing at ADT.

In our conversation, Calvin talks about finding the voice of the customer and incorporating it into your product development process. He discusses the concept of NIHITO, or “nothing interesting happens in the office,” and how it emphasizes getting out of the office and going to where customers are to get insights. Calvin also shares how working on end-of-life products differs when you’re in a B2B business versus B2C.

Removing barriers to keeping customers happy

You have a very interesting background. How did you arrive at product management as a career?

I was working at a global shipping and logistics corporation and came into product management by way of marketing. At the time, marketing was more strategic in nature — in addition to roles that focused on the promotional aspect, many roles also focused on tackling customer needs. My segue into product management came from that marketing background of solving problems and creating solutions that make it easier for customers to interact with the company.

How have you seen your career trajectory change over time?

The trajectory, for me, has always been about solving problems. What problem are we trying to solve at this moment and how can we do so in a way that’s most valuable to the customer? Ultimately, if we don’t have customers, we don’t have a business, and my career trajectory has always been about looking at how we can remove these barriers and keep our customers happy.

In general, I’ve been thrown in different types of roles, from ideation — where there’s no product available and I’ve needed to define what it does and doesn’t look like — all the way to supporting end-of-life products that have outlived their usefulness.

The nuances of working on end-of-life products

You mentioned working on end-of-life products. What does that stage look like as a product winds down, and what does the role entail?

End-of-life is tough, especially for business customers. For consumer products, it’s fairly straightforward — you tell customers, “Hey, we’re not going to support this any longer and this is the last version.” For example, think of the Apple iPod from years back. I really loved the iPod. I was an early adopter of it. But at some point, Apple said, “This is the last version. Come and get them now because we’re not going to sell or support these anymore.”

It’s a little bit tougher on B2B because oftentimes, you have a customer who has created their business around your solution. Your product is integral to how they manage their business, so to tell them, “We’re not going to support this as much anymore because we’re moving on to bigger and better,” a lot of times, is frustrating for them. You’re forcing them to make a change.

How has that experience taught you about moving customers to new products, or working with customers to adopt new features or workflows within an existing product?

In B2B implementation, the process is critical to how they manage their business. Or, oftentimes, they’ve either built on top of or around your product, or we’ve created custom applications in order to help them manage their business. There have been times when I’ve been at companies where we said, “You know what? Keep doing what you’re doing. We’re going to maintain it. We’re not going to continue to enhance it, but you can use it as you like because we don’t want you to churn.”

We especially do this for our larger or highly profitable customers. If they can bolt on or enhance the product that we’ve offered to them, have their own IT partners or team, or they’re creating something in partnership with their own third-party vendor, this means that not only do they have deep pockets, but also that they’re a larger customer. We always have to think about the bottom line.

‘Building technology just for the sake of it’

You’ve described the role of a PM to ‘be the translator for a product’s coolness’ and, from that, to create an offering that generates revenue or reduces friction. How do you ensure that you’re creating a solution for a problem instead of trying to find a problem that your product solves?

It’s interesting. I’ve spoken with some organizations who say “we need an AI solution” — they’re looking for a solution that uses AI without understanding how it is going to benefit them, what the problem is that they’re trying to solve, etc… It almost like they’re looking to bring in technology and then trying to find a problem that can use this new technology. I recently read a report that stated — and I’m summarizing — that an estimated 80 percent of features in products are not used or are not known by users. Even if the percentage is only 50 percent, that’s half of the features being built that go unused. Like the case with some organizations, they’re building new technology just for the sake of it.

As product managers, we need to understand the tool, but we also need to understand the solution it provides. I had an interesting conversation with a friend of mine about this. She lives out in the San Francisco Bay Area, and she talked about how some companies build a solution primarily with the goal of getting acquired — the technology is at the forefront, while the business aspect is in the background. At some point, whatever is being built has to generate revenue. It may not be the company or the startup that you’re working on, but whoever is buying it has to see some type of value in it and put their money behind it.

You mentioned building technology for the sake of it, and of acquisitions just for the sake of acquisitions. Do you have thoughts on that?

A Harvard Business Review article estimated that 70 percent of acquisitions fail. This seems to be an age-old issue; I remember discussing this in a strategy class in business school. The issue seems to be finding acquisition targets that add value, that don’t cannibalize existing products, and that potentially position you in a new or adjacent market. It’s understanding the market or customer problems to solve and how the combined company can help to solve the problem either better, cheaper, or as part of a chain of activities.

On the other hand, it may be as simple as acquiring to increase market share…or acquiring a company’s intellectual property. However, I think what’s interesting is identifying why an acquisition fails. From that angle, and in my own experience, the issues seem to be purely a business rather than a technology angle.

Product managers often think from that business angle. How do you think about the balance of the business side with the product and engineering side?

It depends on several different factors, but we have to ask, “Are we building to be acquired? Are we building to grow? How are we solving the customer problem?” Something else I’ve been talking to other product leaders about is the question, “Is the technology the product, or is the technology the enabler of the product?

For example, at Jenzabar, the product was an online technology solution — enterprise software — but when working in a transportation company, the goal is to enable overnight shipping, same-day shipping, or shipping in five days, etc. So the technology here was the enabler of the solution: you have different methods of transportation, whether you’re looking at ground using a van or a truck versus an airplane. You’re paying for how fast you can get your item from point A to point B. You’re paying for the service level.

The technology is not the product here, but it enables how you track a package, or how you know the delivery person has picked it up. It’s how the barcode information gets uploaded to servers once the package gets scanned, and then you, as the recipient, can check it online and track where it is. That’s an enablement standpoint, but the technology is still needed. I like to keep that in perspective.

Collecting feedback and going to where the customers are

Going back to your points about how successful companies are the ones that understand their customers and pain points, how have you stayed connected to customer feedback in your prior roles?

Well, there’s an interesting saying that has gone around product management circles — NIHITO, or “nothing interesting happens in the office.” What that means is that customers aren’t walking through our front doors. They’re not walking around our home offices. We, as product managers, have to get out of the office and go to where customers are. We have to listen to their problems and see how they’re using our products to have important conversations.

In the past, and this was before UI was its own kind of segment, I spent time watching customers work to determine how they were processing shipments. This helped me identify how we could streamline the process. Someone’s job is to sit in a warehouse and send out 300 packages a day at the end of their shift. If we can streamline that process to shave 20 seconds off per package, that becomes a lot of time at the end of the day that someone can get back.

It is about getting outside of the office and seeing where the work is being done, and that doesn’t mean managing Jira tickets. That means talking with people who are paying to use your product and understanding how you can make the product that they’re using better for them.

How do you communicate those ideas and insights to higher-ups — especially those who may not see your suggested changes as a big enough priority?

It all ties back to communicating efficiency gains or revenue growth, as well as being able to improve. What’s really valuable, especially as you look at leaders and manage upward, is being able to quantify revenue. You want to be able to say to your C-suite, “We just grew revenue by X amount because we’re doing this. We just streamlined this by X percent and saved Y dollars.”

When collecting feedback, do you also talk to folks within your industry that aren’t using your products, but perhaps use a competitor’s products?

Absolutely. I was out on the road doing this last year at Jenzabar. I was in Orlando three times in six months, and unless you live there or you’re a Disney fan, no one should have to do that. But that was where the customers were at the time. I talked to competitors’ customers there to understand where their challenges were. I think this is extremely important.

There’s a reason why competitive customers aren’t choosing your product. You want to know why that is. They already have a problem that they’re trying to solve, but they’re not using your solution. They’re using somebody else’s solution, so really understanding what that is, why, what’s missing, and where there are opportunities is key.

Falling in love with the problem

What would you say is most important for product managers to bring to the table when considering how their work impacts and prepares the engineering team, as well as influence the business?

Steve Johnson, a product management thought leader, says you can bring two things: curiosity about what we’re trying to offer to a customer, and the ability to fall in love with the problem, not the solution.

In the example that I used about shipping and trying to speed that up, how do we make this easier for a customer? What does that look like? It’s about really falling in love with that.

How would you say you’ve evolved your product philosophy as you’ve grown in your career?

Let me preface this by saying that if you look around product-led departments or product managers, more often than not, product managers come from engineering and development backgrounds — it becomes a different mindset with a tendency to be more technology-driven..

My approach of late has been to lean into the business side, the discovery and the product-market fit. It comes back to the problem we’re trying to solve. Who are our customers? What is it that they need? What is it that they don’t need? What are their challenges and their pain points?

Lastly, what has been motivating you for the next year and beyond within product management?

With some of the product groups that I’m involved in, as well as being in transition between roles, I’ve forced myself to network a little bit more because I’ve had time. I’ve been really getting connected with a lot of different thought leaders and new, fresh perspectives. It’s been a great opportunity for me to learn from others — from some real industry leaders — and that’s been enjoyable because it just strengthens my knowledge around product.

When I talk to other product managers, other thought leaders, other peers, etc., it gets me excited about what I’ve done and the opportunities ahead of me.