Brian Tajo is Vice President, Group Product Manager at Elavon, Inc. Before joining Elavon, he was Senior Director of Product Management at Linear Financial Technologies and held various product leadership roles at well-known companies such as Salesforce and Johnson & Johnson.
In our conversation, Brian discusses the soft skills that help product managers succeed in their roles — in particular, proactive listening and intently digesting and synthesizing information. He also talks about what it was like to teach a new class of product managers after a company restructure and how he created an academia-like experience to get his new team up to speed.
I think more of an extreme factor is where you are in terms of seniority. As I’ve moved from company to company, I’ve been able to learn various technical skills and, in a way, individual execution skills. My main evolution has been going from a person doing day-to-day execution to leading by example. Even if I’m still doing execution, I’m showing others how to do it.
Especially in the more senior roles, the proportionate day is not doing any type of execution. You really have to lead through vision, through guidance, and through coaching. It’s much more strategic; you have more horizontal responsibilities. It’s really about being able to lean on others to help with the strategy and execution.
No matter what, the most critical skill is communication. As a product manager, there are different forms of communication and I believe you have to have a high level of competency in all of them to really be successful. But most product managers understand that.
One area of soft skills that’s often overlooked is listening skills and your ability to intently digest and synthesize information. In this area, there can be pressure to constantly be right. Naturally, you take in things quickly and want to respond right away. But it takes a certain level of practice to be more of a proactive listener — not trying to think about your response, but making sure you actually digest what’s being said.
If you think about it, understanding customers, empathizing with stakeholders, listening to your teams, and getting down to the problem involves a whole lot of listening skills and empathy to make sure you know what to address. So, I think that’s an area that’s potentially not talked about enough in this profession.
Empathy requires creating an environment where you alleviate the fear of speaking out. You’re able to be authentic and speak your mind.
Naturally, as a product leader, you want to create that culture so your team feels like they’re in a safe space. My technique is finding common denominators across your teams — learning about each other deeper than the professional relationship.
On my team, we have “Fun Fridays” where the team will talk about topics unrelated to work like hobbies, personal interests, and vacations. We use such conversations to build rapport with one another. Finding common denominators and going beyond the professional relationship, helps to foster that culture of safe space.
User research is always critical, and I learned this while building product experiences for small business owners. One of the things that we were missing was an onboarding guide. When we rolled out our product, we released a number of advanced features, and there were a lot of bells and whistles. We thought that it was all easy to digest, but we didn’t provide enough overviews and onboarding success for those small businesses to really understand how to use it and take advantage of our product in regards to their sales.
The product that we were rolling out was a new financing alternative payment. We needed to provide them with speaking points for their customers to show why this alternative financing option could be better. We needed a way to tell those merchants how to use invoicing and a way to offer them financing. It was a little bit overwhelming to digest. Most small business owners are thinking about how to run their business, its operations, and educating their customers on financial terms — alternative payments was not something there.
There was a time when the software company I was at provided workflows regarding payments and billing for the small business population (SMP). As a company and as a product team, we always had a principle of digitization and automation. I think we didn’t really understand their day-to-day and their livelihoods. They still operate with a heavy load of paper processes. If we’re going to design for those things, we have to take that into account.
We had made some assumptions, but it wasn’t until we actually followed them day to day that we fully understood our customers’ needs. They said, “Maybe your software solves some things here, but it actually creates more problems for me. You’re actually not solving the things that I need with regards to actually paying for it.” That’s something that we failed to listen to in terms of what we were trying to solve.
Critical thinking skills are instrumental. There’s a component of analyzing and also being able to formulate your options and make a decision. In a software startup I worked at, when we were still early in trying to determine product-market fit, we didn’t have an idea of who our customer acquisition was.
We started with large enterprise customers. Our first set of clients were large organizations like American Express and J.P. Morgan, and we signed them to build our product. As I looked at the product landscape and the features that we were building, I noticed that the lead time to build and install for our customers was too long. The number of things were, in a way, too customized.
We were only an eight-person product team with 30 or so engineers. I didn’t think that we could scale the business with our resourcing. We had a certain amount of funding that would quantify to three years. And it took us 14–16 months to build these things for American Express and J.P. Morgan. If we stayed in that area of the market, we’d only be able to sign four or five more clientele, whereas if we focused on second-tier banks, there was more of an overlap with regards to the features that we built and that we can replicate, a true software as a service.
It was my decision to say, “This is our customer segmentation. Here’s the total addressable market, here’s what the pricing would be. If we attack this market, I think that our time to implementation would be a lot smaller and we would have a lot more repeatable uses.” That’s what caused us to actually 16x our annual recurring revenue.
I was at an organization during the pandemic and one of the big changes during that time was cost-cutting. We had to lay off a good percentage of our staff and some of our more expensive talent.
Within my organization, my staff was cut down. I was left with certain individuals who had less seniority or less experience as a product manager, so I evolved my model from traditional vertical ownership, where one leader is in charge of a specific vertical of your software, to be a little bit more flat where I’d own the whole platform.
In terms of strategy, we were exploring various things for small business financial products, such as the SBA uncollateralized loans. We focused on not being so financially structured. It was the pandemic, so we didn’t know which financial products would do well. We were actually financially agnostic and decided to focus on the software — being able to accommodate any type of financial product like deposits, credit cards, mortgage-backed assets, etc.
By doing that — being more abstract and focusing on the digitization of what is involved in opening a financial product instead of specific small business products — it actually created more of an opportunity to survive the pandemic and exponentially grow our clientele and revenue.
After the layoffs happened, we had to figure out restructuring and where to put individuals who were left. We didn’t have as many product managers, so I took a handful of individuals who were not actually of product or software backgrounds. They were high-performing individuals who knew operations and I felt like they could transition well.
The mindset of the transition was on extreme ends. For those individuals that were going to product, they were excited. But more senior levels of employees had some anxiety about the probability of success.
For the first two months, we dedicated a day a week to focus on building product competencies.
I created a learning agenda, a curriculum — here’s what you need to know for product 101. Every Friday was a different set of skill sets. The first two months were about the classroom learning objectives. The next two months were about various activities and trying to let them practice.
We treated those first four months like academia — you learn and then you practice. By the third cycle, it was about executing and monitoring their competencies and ability to perform.
I am an extreme product enthusiast — I naturally try to attend a product conference every year. One for my product management profession and one for my industry (financial services). That’s one big area that I wholeheartedly believe in: you should attend those things. Nowadays, there’s an endless number of blogs and newsletters to choose from. You just have to be able to find what you like to read and get emails for.
Another big thing is belonging to product groups — or, in my case, subject matter experts, like roundtables. There are different organizations that do roundtables, so you wouldn’t be involved with that to share your expertise and what you’re doing, but to listen to other subject matter experts.
I think every product manager would describe that as the objective and OKR process. I think it comes down to being able to cascade organizational goals down to your teams.
The way we have it structured is to have the five or six company goals for the year, and then take that down to a level with business unit leaders like myself. I try to have every product manager own a specific OKR that lines up to the levels that I’m responsible for, and that ultimately lines up to the responsibility of the organization.
By doing this, you have a clear relationship and hierarchical recognition of where your impact is. It’s also an empowerment mechanism: even though you may not be very senior, you’re empowered to make decisions and identify where you’re going to make an impact.
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?
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.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
