Ellen Linardi is SVP of Product and Design at Clover, a Fiserv company that builds point-of-sale software for small and midsize businesses. A self-proclaimed “domain jumper,” Ellen previously held product roles at Intuit and Symantec, where, thanks to the COVID pandemic, she had a crash course in aligning remote teams and fostering a sense of cohesion while managing across time zones.
In our chat, Ellen talks about the growing pains Clover encountered when expanding to the UK and how her design-oriented team came to understand the importance of system thinking. She also describes how her team pivoted during the COVID-19 pandemic and how the market has permanently shifted to become more omnichannel-oriented. Finally, Ellen explains the importance of validating hard data insights with firsthand observation and how her team discovers end-user pain points by running up a bar tab.
The interesting thing about Clover is that it was created not by a payment expert, but by people who were laser-focused on solving problems for both merchants and users in a very complex ecosystem. The solution they built worked very well in the US when we first expanded, but mainly because we live here and we sort of understand how to post a payment in the US. About a year after I joined, around 2016, we decided to do our first global expansion to the UK.
It was actually a pretty rough initial launch. There were a lot of use cases that we didn’t understand. There’s a lot of complexity around not just the flow for the end user, but also with regard to bringing the product to market. There are a lot of entrenched relationships, and the mindset of the population with regard to how they use a credit card is hard to change. We were dealing with a large, complex system. We’ve always been a very design-oriented, design-thinking team, but this concept of system thinking wasn’t as prevalent.
It was a very humbling experience, both in our payment launch in the US as well as in the UK, to understand the local dynamic like how hot to-go food is taxed but cold ones are not. It took us a couple of rounds, and it highlighted the investment that’s actually necessary for an expansion. It was so early in that lifecycle that it wasn’t a question of whether we should expand, but whether it was the right time for us. We didn’t understand how much effort and work it would take to do it right.
Our launch in Canada in 2018 was a significantly different launch. We brought a much lighter version of the product and focused on the things we could do right first. This enabled us to enter the market, spend a lot more time understanding the complexity, devise the right go-to-market strategy, and then slowly extend our portfolio as we understood the market better. But it was definitely one of those launch-and-learn scenarios, and we learned a lot.
It depends on why you decide to enter a country, right? We have a bunch of existing distribution partnerships, but we were predominantly interacting with people who are in a sales position and looking at it from a business perspective. The input that they were giving us wasn’t deep enough for us to fully understand the intricacy of how they use the product, and it wasn’t fair for us to assume they would know all the requirements to have a successful product.
I would recommend spending a lot more time on the ground researching and spending time with the end user to understand how people live their lives on an everyday basis, as opposed to leveraging proxy feedback and taking the input at face value.
The number one takeaway is to actually talk to the end user. Number two, if you’re entering a new market, start small. Don’t just say you’re launching to small businesses; what kinds of small businesses, and in what specific regions? Being able to narrow down and blend and expand is important.
At the time, we didn’t have product managers in the various geographies we were launching in. I think that created a big gap in the knowledge. Interestingly, we were able to launch in Canada without having a product manager on the ground, but we took a lot of lessons from our European launch that we were able to apply to our subsequent releases.
Absolutely, yeah. Actually, prior to Clover, I ran the enterprise mobility product at Symantec, and I had two groups of PMs that reported to me. One is what we call the core PM, with an engineering and scrum team that’s responsible for building products. And then we had a group of folks that we call regional PM, who worked much more closely with the sales team, with the go-to-market, because we had a globally distributed product and it was complex.
Time zone differences made it hard to find enough time for folks to interact with each other and build rapport. Another challenge is that it’s very easy for people on the non-core side to feel secondary, like they’re not prioritized as much and their voices aren’t heard as well. During COVID, ensuring that everybody had equal cycle and air time was difficult.
COVID taught us a lot about how to work well across time zones and offices. When we came back to the office, my researcher started a system that enabled us to have much more productive meetings. Basically, regardless of whether you’re in the office, everybody dials in and puts their face on video. The audio might be shared in the room, but everyone is a single individual in a common space with common access. Everyone occupies a similar space and has their face as part of the gallery.
What we found is that, the minute there are people in the room and three people on the phone, the dynamic changes dramatically. When there are only a few people on the call, you notice they tend to stay very quiet. But if everybody’s just a face on the video, it acts as an equalizer. And those dynamics actually impact the engagement and the team’s contribution.
I think it comes down to the question of what the product manager’s job actually is. There’s a lot of debate about that: what’s the difference between project managers, program managers, product owners, and product managers?
I think the product manager‘s distinct role is to manage the product creation process to ensure it sustainably delivers business value. The most important skill I look for in a product manager is the ability to ask the right questions because product managers are responsible for framing the question and problem space that we’re solving as a team. I always look for an ability to understand the questions, bring the team together, reflect on where we’re going and how we get there, internalize the strategy, take input, and move from there. It’s actually quite a tricky skill set to find sometimes.
I’ve tried different tactics. Sometimes, we just conceptually talk about problems. Sometimes, I ask them, “If we were trying to do X, Y, and Z, what are the questions you would ask me?” Allowing them to go into the space where they’re in the role of a product manager and asking those questions helps me to better understand how they think about product.
I usually don’t look for domain expertise — maybe that’s because I’m a domain jumper myself. I moved from healthcare to security to finance. You’re always going to be surrounded by subject-matter experts. The problem isn’t a lack of knowledge, but a lack of framing and a common goal for everyone to rally toward. That’s why I look for people who can think about the area holistically.
Growing up as a product person at Intuit, I learned to focus on four key areas when thinking about how to solve a problem:
Obviously, Clover is a product that is predominantly utilized on-premises in restaurants and retail places. When COVID kicked off, a lot of small businesses shut down, essentially overnight. There’s zero foot traffic, no activity happening.
At the same time, it was a year of big growth on our side. We had a very large roadmap, growth plan, commitment, and everything else. And so, overnight, not only were we all sent home, but our customers pretty much lost their viability as a business. And we can see that in the data where we’re processing, processing, processing, and everything just drops off. So, what can you do? There’s a very natural tendency to stick to the plan, if for no reason other than you spent a lot of time on it already.
Fortunately, we took the time to actually pause and consider our mission, which was to help small businesses ensure viability and compete with all the bigger businesses. We essentially suspended the entire roadmap, pausing and brainstorming about what we could actually do to help merchants make their way through COVID. Whether folks were admitting it or not, it was a really confusing time. We were suddenly stuck at home and didn’t have a lot of contact with folks. So having a shared mission to rally behind went a long way.
For the merchants, a huge priority was getting access to federal funds to sustain themselves. So we created a lot of bridges and pathways for them to be able to easily attain the federal funds. Another thing we did was to automatically offer and create online ordering capability, for free, for all of our small businesses.
When businesses go through tough times, or something odd is happening in the market, it’s a great opportunity to reflect on your mission and purpose. When you’re lost, that’s a good place to start. That’s also why it’s very important to have a strong mission and vision as an organization. It’s like a little anchor you can always go back to, and it can become a very powerful rallying cry for your team to deliver value to your users. Otherwise, you’re doing things and, suddenly, you wonder if it still matters.
Doing things that matter is very important for any team, but especially the product team. The best of the best are always there because they’re committed to a mission and a problem. When you can tap into that, it’s a very powerful thing.
Yeah, definitely. If anything, a lot of those trends have continued. The market will never be exactly as it was before COVID hit. For one thing, we’ve become much more omnichannel-oriented. So there’s definitely been more investment, not less, in those areas since the pandemic petered out.
I am a huge believer in spending time with the actual end user. In my experience, most product managers and teams don’t do it enough. Especially these days when you have so much access to data. The tough thing is that data, for the most part, doesn’t tell you what the people are thinking or feeling. You know what they did, but you don’t really know why.
Observing and inquiring about what users are actually going through on a human level is incredibly important, but users are scary. If you’ve never been in front of a user, the idea is very intimidating. Once you do it, it’s incredibly rewarding, but getting past that first step tends to be difficult. Whether you’re in front of a salesperson, you’re talking to an end user, or you’re doing research, I think it’s incredibly important to observe your end users because they will tell you the “why” and reveal less tangible insights that data would not show.
It’s also important to understand the context around the problem you’re solving for. Back in the day, when we first started as a point-of-sale system, it was a very generic point of sale. At some point, we decided that we needed to solve for bars. But none of my designers or my product manager had actually worked in a restaurant or a bar. So the first couple weeks of discovery was actually them spending time in those kinds of establishments.
We found some friendly locals that allowed us to sit there. Literally, they’ll spend hours just sitting at the bar observing the people bringing up the order, taking the order, etc. That’s the kind of context that is hard to replicate anywhere else other than actually putting yourself in the situation.
For one thing, it helped us understand the ins and outs of how a bar tab works. When do you open it? Where does the credit card go? When you go to a bar and they take your credit card, you’re like, “Wait — is it a pain to take a credit card?” Maybe we can help them just take information from the card and hold it on the site so they can just hand it back after scanning. It also helped us understand that pain point from the perspective of the user.
So it’s not only observing the customer’s job, but when you’re sitting in the context, you’re able to see the pains that the user is actually experiencing. And if you talk to them, you want to figure out what pain points you can eliminate and discover the things they wish they could do. That kind of insight is much more powerful when you can receive it from the customer yourself, as opposed to just trying to imagine or looking at what somebody else has done.
Right, that happens all the time. And even understanding the stress level — when you watch a bartender trying to serve as the line starts piling up, you realize they will not tolerate any inefficiency. If something doesn’t work, it really throws them off their game. So even just to get an appreciation of that, I think, was valuable.
As a matter of fact, each year, my team volunteers with a nonprofit that sells glass pumpkins. We work the register and we sell glass pumpkins. Experiencing how it feels like to be behind the counter ringing things up — having to do a refund as the lines start piling up, for example — there is empathy and appreciation that you cannot communicate unless people are allowed to experience it.
At Clover, it’s fortunate that there’s a lot of opportunity to do that. There are certainly enterprise products, for example, where it’s much, much more difficult to find someone to perform the role of the end user. But if you’re building a consumer product or a small business product, it’s much more viable for you to be able to do that.
Right. And if it’s a labor problem, it’s hard to hire, then the solution they have might be different. Or, maybe you observe that the clerk is not telling people to sign up for the loyalty program, and you realize it’s because they don’t want to talk to people and interrupt their flow. So you need a screen that asks the consumer to enter their phone number without the clerk having to talk to them. There are a lot of little nuances that we’ve picked up over time.
It’s a little tricky. I would say it depends on the context. Generally speaking, I’d love for each of our product managers to own a couple of friendly customers that they speak to regularly, that they’re able to reach out to. If it’s been a month and you haven’t talked to anybody, that’s not great. But the truth is, we do have a lot of product managers that end up not having the time. Maybe they’re working on infrastructure stuff, for example, so they just don’t get to it.
The way to sort of solve it is to go back to the problem statement again. For each product area, what’s the problem you’re solving for? What are the things you’re trying to learn? And how are you going to learn it? In some situations, maybe it means speaking to the end customer. In others, maybe it’s talking to the developer or looking at future trends.
I don’t have a hard rule for how many contacts you should have but I think, in general, understanding the problem space that you’re working for and then being really critical about how you’re getting your information is a great place to start. Simply understanding the data, for the most part, is not sufficient to really paint the full picture.
Consumers, whether they’re using their mobile phones or otherwise doing part of their journey online, when they come into the store, they expect that their order information follows them into the store. It is often difficult for a small business to deliver that if they have to piecemeal it together because it requires so much work. So we try to figure out, what are the jobs that consumers expect but are very difficult for individual business owners to do on their own? And how do we facilitate that?
The other area that continues to be an opportunity — and this ties in with the consumer expectation — is understanding how to engage consumers and bring them back, along with the general angle of marketing, engagement, loyalty, what AI can do, and what data can do. Running a business can be overwhelming in itself, let alone having to constantly stay on top of new technologies. So we want to make it easier and more accessible for small businesses to take advantage of those opportunities. Running a business is an overwhelming task in itself. On top of that, technology’s always changing.
There are different categories of things we want to do for the business. Obviously, revenue, sales, viability of the business, and growth are always important. There tends to be a group of features and capabilities you want to introduce because it delivers the growth that the business is looking for. So that’s category one.
You also tend to have a huge cohort of client requests — things that people have asked for, commitments that have to be made, etc. That’s the second category.
And then the third category is the opportunity for the product team to delight their users and the market. How can you give them something they love but aren’t necessarily expecting? For example, have we observed any pain points that we believe we can solve better?
It’s a balance of those three areas. And as you’re looking at it beyond just balancing pure revenue numbers, growth targets, the general strategy of what’s happening in the market, where we want to go, etc., think about your roadmap and your plans across those three areas. Your feature might be related to enabling the channel. Or, your features might be related to a new trend. But your roadmap should be a balance of those three areas.
There’s a distinction between your buyer and your user, and the sales team tends to only think about the buyer. So when they’re throwing around terms like “client-centricity,” a lot of times, they’re focused on closing a deal. It’s not that they don’t care about the user, but that concern is secondary.
When you’re responsible for the product, your job is to balance the two. Of course, if you can’t get buy-in from the buyer, they’re not going to purchase your product and you won’t close that deal. But the users are the ones who determine whether you have staying power, so it’s really important for anyone in a product role to be aware of the distinction between buyers and users.
Most of the time when I talk to folks in enterprise sales, they speak to the buyer, someone who’s signing the check. I say, “Where’s your user? What are they going through? What’s their input?” But it’s much harder, I think, to find users to talk to. Unless you’re explicitly reminding yourself there’s a distinct buyer end user, it’s easy to lose sight of that.
And then you see companies like Stripe, for example, that are trying to solve for developers and their features, go-to-market, and sales model reflects that. The developer doesn’t buy the stuff — someone else will likely make the purchasing decision — but the developers are going to love it because it’s designed with their experience in mind. It’s critical to understand what’s meant by client-centricity versus user-centricity and ensure that you’re balancing the two. You’ll find that your sales team and your clients are going to appreciate those conversations.
Sometimes people shy away from that approach. I often hear pushback like, “But that’s not what they’re asking for.” Clients hire us because they expect us to solve a problem they have in a better way. And when you ask those questions, you’re actually demonstrating thoughtfulness about how you’re partnering with them to evaluate those problems. It’s not a bad thing.
In my experience, it’s actually worked very, very well to not only focus on the client, but also on the users. And sometimes you say, “I cannot deliver this feature for you because for the user, this is not going to work and this is why we’re prioritizing.” When you’re able to articulate and represent both sides, you can avoid becoming a feature factory where all you do is crank out what somebody asks for.
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 →
