Ben Newell is the former VP of Product at Miovision, a traffic management platform. He spent the first 17 years of his career at Sabre, where he started as a software developer and later owned product portfolio strategy. Ben then transitioned to a VP of products role at LTK (formerly rewardStyle & LIKEtoKNOW.it) before moving to CBRE. Before his current role at Miovision, he served as Head of Product for Digital Supply Networks at Stitch Fix.
In our conversation, Ben talks about how he empowers the entire organization to take a product-centric mindset. He discusses commonalities across the industries he’s worked in, such as themes around growth, engagement, and cost savings. Ben also shares how, based on his own mentorship experience, he empowers the next generation of product leaders.
I got my degree in industrial engineering at the University of Illinois. After graduation, I started my career in software development at a travel technology company called Sabre. It was an interesting role because when they hired me, they had an entire team of industrial engineers who were all focused on process engineering. We spent time next to our clients (travel agents, airlines, and government agencies) learning their businesses and understanding what their challenges were. We then designed, developed, implemented, and tested solutions on-site.
You never quite know how a role will shape your career, but that role impacted mine greatly. I did it for seven years, and that became the foundation of my product management experience. After that, I moved to Sabre Labs — the research and development teams at Sabre, then on to VP roles in product management. After 17 years at the company, I was ready to try something new.
From there, I worked for Founders and launched LTK (LIKEtoKNOWit). We had over a million users within the first nine months, and it’s now north of 30 million. I’ve also had the opportunity to work with large companies on B2B solutions like Nike, Oracle, Tesla, and Novartis. So, I’ve seen and done a lot of different things.
Most notably, I’ve learned that as a product leader, you don’t always have to be the expert. When you switch industries, that concept feels obvious because some people have PhDs or 20–30 years of experience in an area of your business. That can be a little intimidating, but as I learned in switching spaces, you don’t have to know everything to be effective. You do have to stop and listen to what the folks around you are saying and learn how to leverage their expertise.
When you’re a product leader, the team is really your product. That became important to me.
Yes, patterns emerge and once you figure them out, it helps you get up to speed quite quickly. For example, when talking about product strategy, North Star metrics, and measuring success, there are almost always similar themes, such as growth, acquisition, and engagement. Do people like the product? Are people happy with it? Do they retain it? Then there’s always a function of cost savings — are you getting more efficient in how you build that product, deliver it, or support it?
Figuring out what metrics are priority has helped me quickly identify ways for teams to get up on the scoreboard and start measuring their successes. However, the barriers to solving the problems associated with those metrics, and defining the strategies to remove those barriers, are what differ from role to role. That’s where it’s important to lean on your teams to figure out what you can do quickly.
I don’t think one area of the company is more important than another — it’s about how you get everyone engaged and involved together. If you try to do things just in your product team, you can make progress and do good work, but if you want to see truly empowered teams and advanced product management techniques, you have to get the whole company involved.
It’s interesting to see where a company is in this process when I enter new environments. I often say, “Product gets done no matter what,” and what I mean by that is that the ideas around setting the direction, prioritization, etc. are all getting done somewhere in every organization. I sometimes see people with product management titles who aren’t quite doing the work. The trick to solving this is to just find out where the conversations around direction and prioritization are occurring, and join them.
Maybe it’s the founder who’s setting those things. Maybe it’s engineering who’s doing the definition, and sales who’s doing prioritization. When you step into an organization where you’re trying to bring a more product-centric mindset, you want to find out who is responsible for each part of the work and work with those teams to explain how product can help improve.
A good first step is demonstrating that product management is a skill in which you can build expertise. Just like UX design, engineering, or finance, you become skilled at it, and if you’re not, it’s hard to do effectively.
Not only is it important to communicate out, but it’s also important to set up clarity in how you receive inbound communication. You have a core team, and that team has to work well together. There’s a lot that goes into that, but sometimes people get caught up in that too much.
There’s a second ring of what I call adjacent teams — account management, support, sales, etc. Depending on your organization, finance can often be there too to help you set good business cases, understand budgets, and ensure clarity in how you’re performing against revenue. Those adjacent teams are critical to getting better feedback from your customers and developing an effective product strategy.
Marty Cagan was a big inspiration for this thinking. I saw him speak at Mind The Product in 2015, and he was talking about agile product development. At the time of my career when I heard this talk, I was focused on agile methodologies and how we were working between design and product and engineering.
In the talk, about 10 minutes in, he hits this one mark and says, “That’s all terrible and you’re not really having any effect.” It was this aha moment of, “Wow, we could be really good at product design, engineering, and building things. We could be the best version of that, but if we’re not pulling back and understanding what’s happening in the context of the market, we’re not going to have an impact.”
Ever since then, I’ve been very focused on how we bring the whole organization together and how the product strategy aligns as closely as possible with the company’s overall strategy.
So much has happened over my career in the last 25 years. When I first started, technology was often represented as an IT team. Now, instead of technology supporting the business, technology is the business.
For example, at MioVision, we sold cameras and computers for intersections to detect pedestrians and track emerging traffic patterns, which helped create more efficient travel in cities. In the past, this worked as a one-to-one hardware solution — if you wanted to do something different or upgrade your system, you had to buy a new piece of hardware.
Our strategy was then to create a software platform that would allow us to activate those new capabilities via software — our founder called it the “app store” of the intersection. At Stitch Fix, we were selling clothes, but data science enabled us to ensure they were the right clothes.
As new technologies appear, there are tons of opportunities that arise. Usually, everyone is optimistic about what new technology can do and how it will change the entire world. But the main function of product management is to balance jumping to those conclusions with analysis paralysis. It’s tough because stakeholders come to you with these ideas and believe they’re right, but you have to lean on customers and look at your company’s current capabilities to decide if it’s worth our investment.
I like to lean on my engineering counterparts. I’ve found that, often, the best ideas come from those closest to the technology and those who deeply understand what’s happening. I work hard to help them understand customer problems.
For example, at LTK, we wanted to leverage computer vision to identify clothing in any image and help customers purchase that clothing. We spent a lot of time in the early days of computer vision trying to make that happen. There were so many permutations — it was difficult to get ahead of the technology. We ended up being able to use screenshots and some creative thinking to get a solution. We were able to create the magic of looking at an image and telling you what’s in it, but technologically, we worked our way around technical limitations. As a product manager, that magic is what you’re striving for. People don’t care what tech is used to give them that magic, so product managers shouldn’t get too caught up in it, either.
At Sabre Labs, their research and development team was separate from the organization and focused on new technologies or ideas. That’s certainly one way to do it because it separates people by focus. When it’s its own investment, the return is usually clear as well. The challenge with this is that it’s usually only five or six people. You have hundreds of other people working in the organization who are all capable of doing the same thing, and you need them to innovate too.
I’ve tried really hard to push innovation into the whole organization and not have it be a separate side function, but that’s difficult. Processes are an important way to make that happen. Creating space and breathing room inside a roadmap to allow teams to look for those opportunities, as well as setting expectations with team members that they should always be innovating, are really important.
I also like Hack Days as a way to break everybody’s mind out of how they work day-to-day and make them think about innovation opportunities. One theme I’ve used to focus everyone on the paper cuts that exist in the product and is a great way to push for innovation. We’ve seen some of our greatest customer impact come from that.
In terms of protecting the space and creating time to execute the crucial elements of product management, I find it helpful to flag important processes and say, “This is non-negotiable. This is how we work. This is what good teams look like, and this is how we remain innovative.” If you come in and say that, you’ll see the effects, but you do have to demonstrate those to prove it.
Some of that proof comes from storytelling. Some of that is making sure you celebrate the wins. I can say, “Hey, that’s nonnegotiable,” because I know it from my own experience, but others may not know that yet. So you have to find those things — those little wins — and share it with the organization so everyone can celebrate it together.
Two things are important there. One is an ingrained product management mindset. A lot of times, you’re not the one doing the work. We’re taught so early on to not take credit but instead defer to the team, and we forget that we do need to celebrate and speak to the value that we bring to the table, in addition to the contributions of the team. I’ve found that framing wins collectively, as “we” or “the team” goes a long way.
The second part of that, which can be harder, is that there aren’t always forums to post in. It’s a little weird if you blast the communications channel with all of these small wins that come up. So, you have to create forums where people expect to see them, either big or small, at team meetings or all-hands events.
As I’ve aged in my career, I’ve learned to think about leadership more like steering a boat than steering a car. Your eyes need to always be on the horizon. I make small adjustments to how I’m steering that organization. Of course, you need to know where you’re going, your boat needs to run properly, and you need to know what other boats are out there. But sharp turns are usually a bad idea.
One specific learning I took away from a mentor fairly early in my career was that rarely are you the one who should be presenting. This is a small thing, but it starts a chain reaction. In my first official management job at Sabre, I worked my way up the ladder from software developer to VP, and I saw it as my responsibility to always have the answer, to cover any issues, to be the one sharing the strategy, and to be the one announcing the new features.
However, on my team, I had some amazing people who’ve gone on to do amazing things.
When they presented in meetings, it gave me a different perspective. I was now able to read the room. I could lean into specific points that I wanted to make sure somebody got, or I could just let them shine. This has been really valuable as I’ve helped develop the next generation of product leaders.
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?
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.
A product evangelist educates the broader audience on what the product is about and how to get the most out of it.
Learn more →
