Tim Hall is former CPO at Redis, an in-memory database company. He began his career at Andersen Consulting, where he did information systems consulting for financial services and consumer packaged goods. Tim transitioned to product management while working at HP and later joined Oracle, where he led product teams and contributed to major acquisitions and integrations. Before his most recent role at Redis, he served in various leadership positions at Hortonworks and InfluxData.
In our conversation, Tim talks about the importance of storytelling in product management — specifically, the ability to articulate why something is being built, the value it holds, and why people should be excited about it. He also discusses the critical role of transparency and demonstrating leadership in times of change.
My career has been a bit circuitous. I started my career in systems integration consulting at Anderson Consulting before it became Accenture. I spent four and a half years there working with various customers.
Working in systems integration taught me the basics of product management — you’re building a specific system or an integration between systems for a customer, and you spend a lot of time talking about the business requirements. What are you trying to achieve? How will that happen? You’re looking at manual processes and automating them, looking at what happens next, and asking, “What’s upstream from this? What’s downstream from this?”
These skills are perfectly transferable to the world of product management. I ended up doing almost a decade in professional services and transitioned into the “dark side” of products, as I like to say, after that.
Building something that people love and want to adopt and use. The challenge of pattern recognition and identification excites me. When you’re building something for a specific customer, you don’t have to generalize. You consider the requirements and build on them specifically; it’s a one-off, bespoke solution, and they have to run and operate it that way. But when you make the shift from that world into the world of products, there’s some intuition that you have to apply.
This goes back to a video of Jensen Huang, the CEO of NVIDIA, I saw recently on LinkedIn where he says, “You need to ignore your customers.” And some people were piling in saying, “OK, let’s ignore our customers.”
In my opinion, people are taking the wrong thing away from the video. Product management is a lot about customer validation — spending time with the customers and ensuring you build something they want to use and pay for. In many respects, at least on the enterprise side, B2C is different, but I’m an enterprise software and services person. I want to build a cloud service that people want to use. I have to give them something of value, so I’m always thinking, “How am I going to separate people from their money?”
This goes back to why Jensen said that. There’s this old story that goes, “If Henry Ford went out and asked all his customers what they wanted, they would’ve said a faster horse. And that’s what Jensen’s trying to get at, but he’s doing it in a sound bite. I don’t want people to walk away from that video thinking that ignoring your customers is the way to success. Product management intuition is about understanding the problem domain and making sure you understand it in depth.
It’s about balance and making sure that you stay curious. In every situation, you’re dealing with these incredibly intelligent, talented people who are walking, or in some cases, running the marathon, through a specific problem. They will have opinions, but if you want to build a product that has broad applicability, you have to make sure you understand what was specific about that domain and that environment and what was common. Is there a repeating pattern you can extract to build that product upon? Thinking like that may bring innovation.
I talked to them about the introduction of AI into society and the impact it’s going to have. Most people are holding onto the fearful end of the spectrum and thinking, “Are we doing an Oppenheimer moment where we are not really sure what we’re unleashing on the world?” There’s some validity to that, but I also look at the other side of AI — it provides the opportunity for tremendous automation and eliminating mundane tasks.
As a product manager, you get asked all kinds of questions from customers, such as, “How many security fixes have been released since this version of your product?” I can’t tell you how boring it is to scrape your release notes for all security fixes. For a summarization task like that, ChatGPT and other tools are tremendously powerful in doing that relatively quickly. And, of course, I don’t blindly send the results to the person who asked, but at least I’m not starting with a blank sheet.
When I spoke to the students at Claremont McKenna, I emphasized the importance of learning about AI tools coming out of college because if they don’t, they will be behind those who have invested time in learning how to leverage them in a work environment, whether product management or otherwise.
There’s also another thing that struck me when I was giving that talk. I was sitting in front of students who were top students in their high school classes and scored very well on the SAT to get into a great university. Likely, they haven’t dealt with much rejection or failure yet. In the world of business, and certainly in the world of product management, you will fail. And so, being resilient, they expect to give it their all. But sometimes, it’s not going to be enough.
How do you power through that to the next thing? And what do you learn from that? There’s this phrase, “You learn more from your failures than your successes.”
Product managers, at least in most technology companies, sit at the intersection of everybody — maybe less on the HR and finance teams, depending on what kind of product you’re building, but certainly between sales and marketing, customer success, support teams, and engineering.
You have to be able to articulate to all those audiences why something is being built and the value that it holds — and create some excitement about it. Sometimes, that can be a challenge. At least in the B2B enterprise world, a whole set of enterprise readiness requirements comes up.
For example, say I just went to New York with our sales rep. I say, “I visited the top three banks there, and found a consistency in what they wanted. This is the kind of revenue we will unlock for the company if we build this feature.” And people then will go, “Oh, I get it. That’s a lot of money. We should definitely do that.” Even when it may be some very low-level technical challenge you’re trying to solve, it will motivate those who have to work on the project.
One of the other challenges is spending time with customers, doing the validation, vetting the story, and communicating that to the engineering team. Product managers often go very deep with engineering — building multiple sprints until they come out the other end. Then, they have to go back to the beginning to communicate the value of what they are building to the product marketing team, sales enablement teams, and sellers. Sometimes, all of that can get messy.
There’s value — people will extract a basic understanding out of it. I mentioned you might interact less often with the HR and finance teams, but you want them to be able to tell stories to new recruits. If HR says, “We build a thing and some people use it,” and a potential employee asks, “What have you been working on recently?” how can they get excited if the HR person can’t answer the question?
I would love for everybody to be able to articulate something about the product, even when sitting around a holiday table with their relatives who ask what they do in their jobs. Most of the time, the easy answer is, say, “Well, I work for a tech company.” But likely, the relative will then ask, “Well, but what does it do?” Being able to articulate something of value, like, “We’re protecting the banking infrastructure because we’re helping them modernize the way in which your information is secured,” is essential.
Often, product managers get locked into explaining something technically in depth to their engineering teams, so they can’t roll out of that to give an elevator pitch. You need to be an excellent storyteller and think in terms of explaining it to your grandmother or a friend who’s not in tech. I encourage product managers to build that muscle. It’s important.
Change is hard. People aren’t cogs in the wheel. Employment is definitely a two-way street; part of that is you want to be inspired by the leaders you work with. I encourage working with people who you think you can learn from, but if you ever reach a point where you think there’s nothing more to learn, it’s time to go elsewhere and make that change. And how do you demonstrate leadership in times of change? It’s important to have that story about the rationale for why the change is being made, what you think the benefits are, and what you think the risks are.
Some leaders feel that doing this invites people to question their decision-making. Transparency and showing leadership in times of change are critical because you want to continue to have people follow you and believe you’re making the right decision.
Your productivity will suffer if you’re sitting there worrying, “If that guy’s no longer here, what might happen to me? And are those two things correlated?” Or, “Help put this into context about this decisions of change and why and inspire me to stay.” Every time there’s a change, you open the door for people to question whether they want to be there or not. And as a leader, you should be thinking about what you will do to inspire them to stay.
It’s the transparency. For example, product managers will be asked about the end of their product’s life more than once in their careers. If you’re in that position, you’ll need to decide whether a product you’re working on is viable, useful, necessary, or in line with the business objectives. Do you continue to throw good money after a bad product, or do you say, “It’s time to stop”?
Part of this process is thinking of the others involved. What are you going to do with those working on it? How deeply invested are they in it? How open are they to new opportunities within the company? Are you going to exit them along with the product? All these questions come into play.
Storytelling and communication skills ensure you empathize with each stakeholder group about the impact of the change you’re making. It’s not just the decision of, “The product isn’t making the revenue.” You can’t just say, “Let’s just end-of-life it, and that’s it.” Aside from communicating to internal stakeholders, there’s also customer communication. Part of this skill is knowing how to handle them, how long you will commit to continuing to support those customers, and whether you will grandfather them into certain pricing levels.
How do you work through that? How do you do it with the internal teams? How do you do it with sellers who may have deals in flight? A lot of times, there’s a desire to rip the band-aid off and not worry too much about the implications. But an ounce of care goes a long way.
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 →
