Charles Battle is Head of Product at Ibotta, a Denver-based performance marketing platform known for its cash back offers and digital coupons. He leads a 50-person product organization that oversees various disciplines, including product management, product design, product analytics, and UX research. Charles started his product management career at TouchTunes Interactive Networks and has since worked for several financial technology companies, such as American Express, LendingTree, and Guaranteed Rate.
In our conversation, Charles explains how the pursuit of perfection can preclude teams from releasing solutions that real customers want to see. He shares how he encourages his teams to pursue rapid experiments and discusses the famous mantra of being “embarrassed” by your MVP.
Most people know us as a mobile app. We have millions of monthly active users on it. You download the app and unlock offers for everyday items, with grocery being the biggest category that we serve. There are cash back offers associated with certain items that you can redeem at the store next time you’re shopping. You can do this in two ways: by linking your loyalty account with that store with Ibotta, or by scanning your receipt.
We get that transaction on the backend and then we compare that data with the data for the offer that you unlocked. When we see a match, we will credit your account with the cash back. That grocery use case in our D2C mobile app is probably the most common.
Basically, we white-label the content and distribute it through our network of partners, which include some of the largest retailers and brands in the world, including Walmart and Dollar General. These partners use Ibotta’s platform to efficiently deliver thousands of digital offers to their consumers.
Say you’ve got an offer in the Ibotta app that’s 50 cents off of Heinz Tomato Ketchup. You can now see that same offer on one of Ibotta’s retailer publishers, like Walmart. You can click to select that offer on the retailer’s property without ever knowing that the Ibotta app exists, and then redeem that cash back offer when you make that purchase at that retailer. Ibotta processes that redemption on the backend and gives you the cash back, except we do it in the retailer’s currency, which in this case is Walmart Cash.
We operate in squads within the technology umbrella. We aim for one product manager and one designer to 5–7 engineers. Architects are spread out a little bit more and typically serve a larger group of people. We have a small UX research team, so they operate more on an agency model where they jump into areas where there’s a high need for research and expertise.
On the product analytics side, we try to staff the big areas of our business, but oftentimes some folks operate more like rovers. They’ll jump around and see where there’s a need for more robust analytics expertise.
People talk about the triad between design, engineering, and product. We’ve expanded that to include not only design and engineering, but also architecture, analytics, and UX research. We think of this as a leader team that we put around any core area of our business. That could be at the squad level, or a level up at the group level.
For example, I have leaders who run our D2C business and our B2B, which we call rewards-as-a-service. And at every layer, if you decompose those different business lines, there’s going to be a cross-functional group of leaders. We empower them to make all the important strategic decisions for their area. We have to make sure that the team understands the context within which they’re operating, so we set the high-level company OKRs, the annual strategy, and from there, we challenge our teams to come up with their own OKRs that ladder up to what we’re trying to do as a business writ large.
It’s embedded in everything we do. We are very much a customer-centric product company. When I think about design thinking, I think about a few things: customer centricity, rapid iteration, and falling in love with the problem and not the solution.
As a product team, we’ve taken some design thinking concepts and made them part of our team’s operating principles. My team and my leaders actually spent some time last year revisiting our team principles. How do we want to operate? What do we want the team brand to be? And a couple of those things are very much rooted in design thinking. Customer obsession is one of them.
We want to be very aware of what our customers are feeling and how we can bring joy to their lives. We focus on the problem first rather than on the solution. A lot of teams fall victim to this. You fall in love with this thing that you’ve created and then you shape the research and the problem to fit the solution that you have in mind. We try very hard to make sure that we have a well-thought-out and intentional problem statement for everything that we work on as a team.
We also feel strongly that the team that experiments the fastest is the team that wins. It’s not who has the best ideas or the genius on the mountaintop, it’s teams that have a process and have created a culture where experimentation can flourish. That requires psychological safety and celebrating failure and appreciating the learnings that come from failure.
I believe that any bet can be a good bet to make, as long as it can be made quickly and it’s rooted in data. If we have a feel for what customers want or an indication from our reporting that this is a problem we should solve, the faster we can validate that assumption, the better. If we can do quick experiments, I’m in for that all day long. We encourage our teams to do that.
Where teams often fail is they let perfect be the enemy of good. There are always things that you’re not going to figure out or would take way too long to figure out. You’re never going to learn in an echo chamber with three of your colleagues — you’re only going to learn by putting it in front of real customers.
We can do some of that early in prototype testing, and we do, but at some point, you have to just let it rip. Put it out there and see what happens. The beautiful thing about testing is that you don’t know what’s going to happen. And because, ideally, you haven’t spent too much time on it, the loss aversion that might normally be there isn’t there. The faster you move, the less likely you are to fall in love with something, and the less likely you are to feel horrible if it fails. So do it quickly, get it out there. If it wins, great. Let’s continue to iterate. If it fails, no harm, no foul.
It’s interesting. I’ve heard a lot of people talk about minimum lovable product. Reid Hoffman said, “If you’re not embarrassed by your first version of your product, you waited too long.” I believe that. You should put it out there because you don’t really know how people are going to respond. And the only way you will know if it’s working is to just put it out there, warts and all, and see what happens. Otherwise, we’re all just making assumptions and everybody’s going to make different ones.
Everybody’s going to have different intuition about what’s going to work and what’s not going to work. And at the end of the day, I want to let the customer decide. Get it out there and see what happens.
My first product job was at TouchTunes in New York. I was brought in to build a karaoke application. TouchTunes makes digital jukeboxes, and they were known as a jukebox company. They wanted to increase the revenue per jukebox, so they said, “Once a week, on average, people are running karaoke nights at bars and they’re turning off our jukebox. We’d like to run the karaoke night through our jukebox because that way, we’ll increase coinage per jukebox.”
So we set to work on this and we built an alpha version of the software, as well as the karaoke kit with mics and a PC to display lyrics on a TV screen, and put it in a bar in Midtown Manhattan. As the product manager, I went every Tuesday night to the bar and tested cutting-edge software that had not really even been QA’d.
People are passionate about their karaoke. They’d be hanging out and drinking a little, and I would sit there watching them use the product. They would try to sing songs and something would break, or we would have a feature that was missing or is in the backlog but not yet developed. For example, singers would say, “I’m not ready to go yet. I want you to move my song all the way down to the bottom of the queue.” And I’d say, “I’m sorry, we can’t do that yet. It doesn’t do that.” And they would yell at me.
The next day, I would debrief with our engineering team and say that we have to move this user story to the top of the backlog — people are freaking out because we can’t change the queue.
I would talk to these karaoke jockeys and they’d say, “That’s the biggest thing. People get cold feet, they don’t want to sing.” So we were basically ignoring all of the established behaviors that they had as customers. And was I embarrassed? Absolutely. I was embarrassed to be there and have people yelling at me, and the software would break and couldn’t do everything people wanted it to do. But we learned so fast. I’ve never learned faster in my career than I did during those nights because you’re literally watching someone use your product — often a new build that was deployed that day — in real-time. It was awesome.
I believe strongly in autonomy. It’s the Marty Cagan thing, empowered teams. In the technology group, we let our leaders create and own the OKRs and roadmap that ladder up to the company strategy. As senior leaders, we very rarely put feature requests on the roadmap. We try our very best at the senior leadership level to not drop ideas on them like that. Focus on the problem and on the strategy. At the company level, what are we trying to do? And we let our people figure out the best way to go and do it. But with all of that autonomy comes a lot of accountability and a high need for communication and transparency.
What I have found works for setting teams up for success is being really thoughtful about putting together a product strategy and sharing that strategy with the right leaders at the company. Twice a year at Ibotta, we host product strategy sessions that help set the tone for the next six months. And then we sync up every month in what we call a business impact review to update everyone on the progress we’re making and ensure that everyone has visibility into the roadmap.
We have healthy debates but we also believe in disagreeing and committing if we have to. Some people may not agree with the direction we choose as a group, but we stack hands on it and get moving. And we’re not going to second guess it three days from now. If it doesn’t work, it doesn’t work. But we all stacked hands and there’s a real strength in that.
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?
Scenario analysis is a strategic planning tool that helps you envision a range of possible future states and the forces behind them.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
Learn more →
