Jarrad Lokes is Director of Digital Product Management at Trupanion, a pet insurance company. He started his career at Alpine Sports before moving to The Pro’s Closet as an operations manager. From there, Jarrad transitioned to digital media within the company, eventually becoming an ecommerce and digital marketing manager. He joined digital marketing, and, later, product at Vail Resorts before moving to Basis Technologies and his current role at Trupanion.
In our conversation, Jarrad talks about building trust in teams, as well as how trust is an artifact of the transparency and the value that you provide. He emphasizes the importance of basing his manager-employee relationships on a human connection. Jarrad also walks through his process for effective user testing.
I lean into the transformational leadership style — with motivation, inspiration, purpose, context, and empowerment. I strive to hire people that scare me. I want to think, “Wow, they could take my job one day.” By building a team of leaders, I can focus on enabling skilled product managers to lean into their expertise.. This leadership style helps them lead their cross-functional teams in a way that they find most beneficial to achieve their goals and objectives.
That said, I’ve managed plenty of individual contributors earlier in their career and flexed into other leadership styles when it’s necessary to have a more hands-on approach. When I lean on a coaching mentality, I specifically like to focus on identifying the skills necessary for the success in the role, their current state with these competencies, and create each person’s unique development plan. My goal is to understand where they’re at with their career journey, strengthen the areas of weakness, and encourage the areas of strength.
I find it critical to form a team with a basic understanding of who they are and who I am, as regular people. For example, what do they do outside of the office, what is their preferred communication style, how do they want to be praised or criticized, when do they want to be online or offline, do they prefer meetings with cameras on or cameras off, etc. I want to base our professional relationship on a human connection first.
As more teams function in a remote or a hybrid environment, having that core human understanding of each other is critical. That’s where I like to start all of my relationships. Then tactically, I make sure to build out gap analyses with them. This helps me understand where I can lean on them and where I need to help them develop.
When I’m interviewing somebody, I like to have an understanding of the holistic experience through their career journey. Where did they start? No one starts in product right out of the gate, so how did they get here? What are their successes? I want to know which successes they list first and last. Are they most proud of business results, team conflict resolution, or something else? What have they achieved both from a team perspective and something that you see on a company’s P&L? What accomplishments and challenges have they encountered in leading a cross-functional team?
I like to understand the challenges they faced in working with other teams, especially stakeholders and engineering. I ask questions about how they resolved those challenges and try to key in on the things that would make them a really strong product leader in the future.
I find that trust and transparency are joined at the hip. I believe trust is an artifact of the transparency and the value that you provide. I’ve spent most of my career in B2C businesses, and a lot of these companies rely on technology as a core business enabler, but haven’t built the technology org with the same emphasis — and they are thoughtfully building out their product and engineering teams relatively late. They did not start as a technology-forward company, but have found themselves relying on it more than they anticipated. Many of them have gone through transformations — and now they are figuring out how to position technology as a component of their business strategy.
Through those growing pains, I’ve encountered many stakeholders who say, “I want this thing, just go and do it. Tell me when you can deliver it.” It’s a very inhuman experience. I find it critical to build trust through a demonstration of value delivered and transparency of the process, successes, and failures. This transparency opens the door to a conversation to let your stakeholders know what your teams actually do today, the value that you’ve provided in the past, and how, with alignment to a vision, you can provide greater value in the future in areas that the stakeholders haven’t yet thought of.
Once you can provide that transparency, you can illustrate the value and gain trust. Once you gain trust, you have your foot in the door for the bigger and more important conversations.
There was a time in my career when I came into a less-than-ideal situation as a product manager. The team I was put on was in charge of looking at an intake form and pulling things into a project plan, one by one. Stakeholder A wants project X delivered. OK, we’ll pull it in, we’ll talk about it as a team, we’ll build a plan, we’ll tell them when it’ll be delivered, and we’ll ship and repeat. This team had incredibly low morale because their thoughts and ideas were brushed off. They were put in a corner and weren’t necessarily trusted to have a business mindset.
When I came in, I said, “OK, let’s create a process that encourages conversation. Let’s implement a framework that we’re all relatively familiar with — scrum.” I brought scrum in, and told the team, “We’re not going to change anything aside from how we operate.” Not the what, not the why — just the how. Through that, we started leaning on sprint planning to start the conversation. The objective was to get everyone who submitted projects through an intake form together every two weeks and review what they requested and what we’re going to deliver next. The goal was to force those stakeholders to have conversations.
Suddenly, stakeholders would ask, “Why are you doing that first? I think my request is more important.” Or, “Oh, you’re doing that? I also want to do this related thing.” All of a sudden, these people start openly communicating about their technology needs. That openness allowed us to step in and say, “Based on what we know, this is how we would propose going about achieving objective X, Y, or Z.” That one tactic completely shifted the positioning of the product team in the minds of the stakeholder group.
As time went on, we thought, “OK, this has been working. We are having great, tough conversations, but now, let’s have these conversations before the request is submitted.” Through this shift, we could better understand the outcomes the various teams were actually trying to achieve. We’d help the stakeholder shape the request and really push them out of the solution space. We’d go back to the problem space, identify the problem that they’re trying to solve, the goal they’re trying to achieve, the strategic context, and bring it forward in a way that addresses their issue with a technology solution.
We implemented user testing and customer research into the process and were able to play back the specific ways in which their customer wanted to engage with the technology. The team’s objectives were achieved at a rate much greater than before this mini-transformation.
That was a specific example, but the tactics of making a space for that conversation to happen led to some tremendous progressions into the company’s mindset about technology as a revenue generator, not just a means to their end.
I think stakeholder conflict is an incredibly common issue, especially when stakeholders have diverse goals. It’s really important to have those points of tension when thinking about features or roadmaps. I don’t know if I’ve been in a place where emotion hasn’t gotten involved when talking about roadmaps. This is because everyone wants to achieve their goals — they each have their metrics to hit.
For me, I try to oversimplify my roadmap. I try to bring everything back to the lowest common denominator — or an enterprise North Star metric — what the company is trying to achieve during a period of time. I use that as our sounding board. If conflicts arise when we’re building out a quarterly or annual roadmap, I ask myself, “How does stakeholder A’s feature request support a team strategy aligning to that North Star metric? How does that compare to stakeholder B?” It may be a totally different team metric, but if it doesn’t scale up, then we need to challenge each other’s approach to building company success.
On LinkedIn, everyone’s chatting about the right product framework, but it’s funny because it really doesn’t matter. Product frameworks are going to be defined based on what the company needs to achieve. I worked somewhere that used the Spotify model, and it was cool and fun. We felt empowered, we felt like we were doing product the “right way,” and we delivered features that we were all very proud of. I’ve worked elsewhere where the same Spotify model did not work at all, and that was because the underlying technology was diverse and complicated, and business needs were not served by smaller teams working in more autonomous roles.
There isn’t one size fits all. Once you’re in a framework, it’s likely going to change as the business and macroeconomic climate changes. Or, even as the people doing the work change, there might be a need to shift your framework. It’s important not to get married to the how and lose focus of the why. Be flexible, stay open to new ideas, and always be learning. That’s been the biggest lesson that I’ve taken from my product journey over the past few years.
I love user feedback and user testing. Throughout my career, I’ve worked in tandem with an agency for user testing, and with in-house product researchers, and I’ve done it on my own. It’s been the most enjoyable part of product management for me because I get to talk to the people that are actually going to be engaging with the technology that we want to build. I’ve never gone through a user testing round and not been surprised by something, and I love that aspect of it.
User testing is necessary for nearly every new feature or enhancement we’re going to deliver. Strategy is built through our objectives, what we know to be true, and assumptions about what we think can be achievable. Validation of these assumptions before development is crucial to success. Strategy should evolve over time as we understand more about user engagement or the user perception of what we’re creating.
I led a team in charge of transforming the digital ski rental experience. The team was tremendous and they went on to achieve national recognition for their innovation.
If you’ve ever looked at a ski rental website or gone into a ski resort village, you’ll know that every ski rental shop offers three packages of gear, which are tiered. It’s similar to when you look at a product pricing page and you have bronze, silver, and gold packages. When you look across an industry, it’s easy for those tiered products to become commoditized, especially when they all look and sound the same.
Through my user research, I discovered that the purchasing decision had little to do with the specific product we were selling, it wasn’t the skis — it was the location and its value-adding attributes. How close is the rental shop to the chairlift? How far do they have to walk in those uncomfortable ski boots? Do they valet their skis overnight? This intangible value wasn’t recognized through the commoditized model.
So, when we built out the digital experience, we flipped the script. Every other company said, “Come to our website, pick your gear, pick your location, and buy.” We said, “Come to the website, pick your location and its intrinsic value, and then pick your gear with greater confidence and make your purchase.” We only discovered this through talking to actual skiers, and we saw a tremendous conversion rate improvement once this new website went live. It was awesome.
Since that day, I’ve been a huge believer in talking to customers as much as possible. We assume too much. We’re too close to our product and to our business. We need to challenge ourselves and challenge our assumptions frequently.
I like to prototype anything that involves a UI element. Ideally, I have a designer work very closely with my product people early on in the discovery process to think through the user experience. We build out from there. I’ve gone into user testing with really low-fidelity and really high-fidelity prototypes. I used to lean on low-fi prototypes to get quick feedback and high-fi prototypes for the higher consequence tests because creating a full-color, clickable prototype was labor-intensive. But the progression of prototyping apps over the past few years has enabled more user tests with a better tool yielding greater insights.
When I go into user interviews, particularly with a prototype, I want to break down the interviewer-interviewee construct as quickly as possible. I want to be able to chat with them like I’m chatting with my neighbor. I want to know the name of their dog, and I’ll tell them about my pug. That helps us get to the point where we can be honest with each other. It’s really easy for test subjects to tell me what I want to hear, but I never want that to be the case in these sessions.
If I break down that construct and get into a conversation with them, that allows me to lean into my standardized questions in an organic manner. Maintaining a standard script with a cohort eliminates bias that may occur by changing the questions across tests. However, I like to make space. The questions in my script are the guardrails, but between the questions, I poke, ask follow-up questions, and dig into unique comments or actions.
The more I can allow the conversation to find its own path between my questions, the more I can allow that person to think past their first answer and give me what they’re actually thinking about.
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?
Learn how to use Fibonacci story points for Agile estimation, avoid pitfalls, and explore alternatives like T-shirt sizing and #NoEstimates.
Randolph D’Souza talks about how he works to align different teams together, such as product, OEM engineering, and sales.
Understanding the root causes of project bloat is essential for aiming to improve productivity and streamline workflows.
Mahesh Guruswamy shares experiences learning from and coaching others on how to have tough conversations and how this inspired his book.
Learn more →
