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.
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.
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.
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.
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.
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.
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.
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.
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.
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.”
Whatever those quantifiable metrics are for the business that you’re in, you need to be able to identify how to improve the customer experience. And when you’re communicating with executives, most of these quantifiable metrics are defined by revenue.
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.
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.
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?
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.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
Insight management is a systematic and holistic process of capturing, processing, sharing, and storing insights within the organization.
While agile is about iterative development, DevOps ensures smooth deployment and reliable software updates.
Aashir Shroff discusses how to avoid building features or products that replicate what’s already in the market but, instead, truly stand out.
Impact mapping is a lightweight, collaborative planning technique for teams that want to make a big impact with software products.
Learn more →
