David Bloom is a product and commercial leader. He completed his MBA at Cornell University and worked in strategic planning and industry development at American Express for seven years. After running his own startup, David led product development and strategy at Dow Jones before joining Wirecutter, a recommendation service acquired by the New York Times. Most recently, he served as Head of Global Product Strategy at Sterling, a global provider of background and identity services.
In our conversation, David talks about how, in the product universe, the concept of being global is often a fallacy, and how organizations falsely assume that just having a worldwide customer base makes them a global company. He discusses his method for drawing a straight line from company objectives to product strategies, including thinking about product strategy as a series of if-then statements. David also shares the importance of storytelling in product, and how talking to people the right way enables them to be effective.
Prioritization is a very personal, company-specific exercise. It isn’t one size fits all. When you’re dealing with a consumer or a B2C company, chances are, you’re collecting a ton of data and using that to optimize and plan your own roadmap. If you’re in a B2B environment, you’re balancing long-term objectives with short-term client or business requirements. I’ve been in both B2B and B2C environments, and I think it’s a more complicated exercise in B2B because you have a lot of constituents to juggle. It’s not just product-driven in that sense.
For me, building a roadmap is a little bit like a Jenga puzzle. You must have strong communication with the CEO because they say what the business is responsible for accomplishing. As the product person, you have to translate that into the roadmap. When people come to you with short-term needs, you have to evaluate them and see which kind of revenue they support and the resources they demand. Then, you have to look at the longer term and ask the same series of questions.
At the end of the day, somebody needs to decide which contract is going to be supported versus which long-term opportunity is going to be pursued. The company needs to agree on who will make that call. That alchemy of multiple interests and constituencies in the short and long term goes into building an effective roadmap.
I was in that position when I ran my startup. It’s really hard. Sure, in a small startup everyone needs to wear multiple hats, but beyond that, those roles should be so big that if the CEO is spending enough time to be an effective CPO, they must be neglecting work only a CEO can do and vice versa. And when the CEO is head of product, they may be inadvertently dampening the constructive friction, which helps ensure a balanced roadmap. The CEO needs to let go.
There is a critical role for the CEO in product, but not as CPO. A good CEO leads product, so to speak, by being very clear about what the company needs to accomplish. The CPO turns those corporate goals into a product roadmap. The CEO needs conviction that the product roadmap will allow the company to hit the CEO-level goals. And of course, when there is conflict that the CPO cannot resolve, the CEO steps in.
I have a great deal of empathy for CEOs who are leading product. They have a vision and feel they are personally responsible. Not to mention the risk of roadmap failure can mean the CEO will miss targets and lose their job. Nevertheless, I really don’t recommend it. Save yourself the headache and let someone else lead product!
It didn’t necessarily give me objectivity. A lot of product people will say that they’re objective and that they let the data guide them, but I always think that’s a fallacy. Data can be as biased as any other source of information. You need to trust your data before you start relying on it to make strong decisions.
Having been the CEO, product guy, and GM in the sales organization, I have a tremendous amount of internal empathy. I can think about what it’s like to be a salesperson who feels like if they can just get this feature built, they can close the big deal. Or the GM who’s worried about their margin target and needs something to support that. Or the product or engineering leader who’s worried about burnout in their team.
The most empathetic product people are the ones who have actually walked a mile in their constituents’ shoes. I don’t think that’s breakthrough thinking, but it can be hard to remember in the heat of the moment when you’re negotiating over a roadmap and everyone has strong opinions. It’s hard to remember that the other person is a human being and they’re not just trying to win. When you remember the humanity of these negotiations and how personal they are, it’s much easier to start shaping that roadmap and do so with kindness, effectiveness, and firmness as appropriate measures.
The advice I typically give young product managers is not to worry about externalities — those erratic or chaotic events that may happen. Because if you are thinking, “What if there’s a pandemic?” or, “What if there’s an earthquake?” you are too focused on risk. Instead, plan for the long term. Build a strategy for what needs to be accomplished as a company and a roadmap that supports that strategy. Flexibility and resiliency come from the culture you have built in your product organization.
A lot of times, when things change — like if a client threatens to leave or a new market opens — product people get frustrated. It’s like, “Wait, I just spent six weeks planning Q4 and now you’re telling me Q4 needs to change?” Hey folks, the job isn’t easy. We earn our money when it’s hard. To know if your team can handle the unexpected, ask yourself if you built the right set of tools to enable that change. Did you hire people with business maturity and resilience? Are you able to maintain calm and contextualize what’s going on for your team?
As a product person, if you have culture, communication, tools, and a little emotional reserve, you can navigate change. But if you don’t have these things, it’s going to feel like a sack of spuds landed on your head.
I love that you’re asking about success. You should instrument up your product world and have metrics that tell you whether the work you’re doing has impact, not just whether the product is working according to requirements.
One of the things that I coach young product people on is to know what matters to their internal clients — such as their boss. Even if you don’t own a profit and loss (P&L), you should know how many customers are using the product, how often they are using it, and how satisfied they are with it. That’s the client-facing stuff. On the inside, you should know how much money the company is making from the product. How easy is it to make that money, and how much margin or contribution are you keeping when you sell the product?
It is not enough for us to deliver features and capabilities and then move on to the next thing. A product person should care if they’re having an impact on their enterprise and their clients. I don’t care about the responsiveness of your website and how quickly your DOM loads — I want to know if people are transacting on that website and if they’re transacting well.
It is so rare that this gets done well. To do this “well” requires that the corporate goals are properly defined. That doesn’t always happen. Sometimes, you get a lot of buzzwords thrown in, and then you need to know what that means and product’s role in making those goals come to life. You need everyone to know their part in making that happen.
I like to think of it as an if-then statement. This is how product people often work. If the CEO wants to achieve 20 percent growth, then we have to launch a new product to open a new category. The next person says, “If we’re going to open a new product to open a new category, then I need to get this work done by the end of Q2, and it needs the following features.”
Everybody should have an if-then statement, and they should all ladder up. If you ever feel as though you’re justifying why your if-thens are what they are, you’re not doing it right. It should be remarkably obvious. And your if-thens need to change, that’s OK. We need to build a culture that enables us to be resilient so that when those externalities happen, we can roll with it.
This is very important. Sometimes, we lump these cultural differences and market expectations into a neat term called localization. That makes it seem so much easier than it is. When you’re doing something global, the first thing you have to do is be rational about whether you actually have something global or not.
We often think that if we have customers around the world, we are global. But do these customers all use the same language? Do they operate with the same regulations? Do they have the same functional requirements? Can we even fulfill their requests in the same way in other markets?
For most of us in the product universe, global is a fallacy. What you then need to do is ruthlessly prioritize. Go back to the CEO and ask, “Which markets are most important to you? I can’t do them all.” Look at each market and figure out what it takes to unlock growth there. It may be a new vendor that serves that market, language support, new vocabulary, etc.
Lay out the opportunities in different markets and what it takes to win. Do the work and the analysis yourself. Do the research so that you can go to the CEO and say, “This is what it’s going to take to win in this market.” You have to be an effective communicator and a good storyteller, while also not making people defensive. We all know that being a good product person involves listening skills. Your job is to make people around you effective, and talking to them in the right way is part of that.
Australia has its own national criminal reporting service, and in my last job at Sterling, I was Head of Global Product Strategy. You can’t succeed in Australia if you don’t have an automatic integration with the Australian criminal system. If you’re doing it all manually, you’ll never be efficient enough to win deals there.
If a client in the United States wants to run a background check, which is what we did at Sterling in Australia, they’re going to have more or less the same expectations for fulfillment around the world. But how we actually had to go about doing our job varied from country to country.
First, you need to be willing to reflect on yourself. Ask, “Am I getting what I want and need?” Do you feel you are being heard and people are responding to you? If the answer is not an unqualified yes — which is what 99.9 percent should say — then your storytelling might need help. You should treat yourself like a product, just like you treat any feature in your tech stack as a product. Analyze the conversations you have and identify what might have gone wrong.
The other thing is to frame your communication around the issues that are important to the person across the table from you. It’s not lying, it’s not bias or trickery, it’s just being effective. For example, at a previous job many years ago, I needed an engineering team to spend a few sprints refactoring. I knew that they had done an amazing job delivering a huge feature in a tight timeframe, but I was nervous that it wouldn’t scale well. I went to the commercial leader and said, “I want the team to focus on making the original code much more efficient.”
She asked me, “Why does this matter to me?” My immediate reaction was that she was pushing back. But really, she needed to know so she could figure out whether to support my plan or not. I explained to her that the reason we could hit her tight deadline was by taking shortcuts. “The risk to you is that every other feature you want from now to the end of the universe is going to take X percent less delivery unless you invest in this now.” She said, “Got it. I approve.”
That is what storytelling is. If my story was that the engineering team wrote janky code, which they hate, she would have weighed her revenue goal against the personal feelings of the engineering team. You have to be empathetic and frame the ask based on what’s important to the other person.
A lot of product leaders have different things that work well for them. Personally, I like working with people who are creative problem solvers. Just doing the analysis and telling me what’s wrong isn’t good enough. I want to be able to work with people who are willing to dig into those details and try and figure it out.
Second, you have to be ambitious. I look for people who want to write stories that turn into capabilities that move the needle on a business and create real value. Be ambitious, do good work, be excited, and want to have an impact.
The third piece that I’m always looking for is accountability. It is really easy in the world of product, especially in B2B products where you’re running up against regulations and client requirements, to get stopped or diverted because there are “no’s.” I want people who are accountable for delivery, and that means they’re going to have to find a way to get to “yes.”
They also better be nice because I don’t like working with jerks. Life is short, I want to work with people I like.
One, you have to set the right tone. As a leader, you have to create an environment in which those characteristics can flourish. That means celebrating success and not making people feel bad about failure — unless they failed because they didn’t live those values. That is a wonderful thing to talk about in the abstract, but it is really hard to do in the moment when you miss a deadline or a client is not satisfied. You have to give your team air cover if necessary and live those values yourself.
The second thing is you have to link and label. By that, I mean you have to be very explicit. “When you did X, I was happy because you were demonstrating the value of accountability, driving results, creative problem solving, or just being nice.” People are emotional creatures, and when you make them feel successful, they will want more of it. Make sure that you are explicitly showing them when they are succeeding and when they’re not succeeding so that they know what to do and they feel confident doing it.
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?
Hypergrowth happens when a company experiences an exceptionally rapid rate of expansion, typically more than 40 percent annual growth.
Detractors have long-term effects like negative brand perception, reduced customer loyalty, and a decrease in sales.
To proactively address liability concerns, you can create an internal product recall team for dealing with risks and ensuring quality.
Our Galileo AI Fall ’24 release makes Highlights available to all Pro and Enterprise customers. We’re also debuting Ask Galileo, which enables you to directly ask questions about what you see in session replays.
Learn more →
