Chad Lane is Head of Product at OffSec (Offensive Security), a software company that provides hands-on cybersecurity training and certification programs. His career began in investment banking before transitioning to YPO, where he started as the director of product management and engineering before leading as the senior director of development. Chad then served as senior director of product management at Apollo Global Management and VP of Product at D2L, overseeing the company’s successful IPO. Following this, he took on the role of CPO at ISSA and led efforts to improve customer satisfaction and product revenue. Before joining OffSec, Chad was the CPO, Managing Partner at Food Intelligence, LLC.
In our conversation, Chad shares how his background in finance shaped his approach to product management and pricing. He also talks about mentoring product managers to work as full-stack PMs and developing a holistic go-to-market strategy with cross-departmental alignment and stakeholder management.
I went to UC Berkeley (go Bears!), and back then, all I thought about was making a lot of money when I graduated. The best-paying job was in investment banking, so I went to Merrill Lynch Corporate Finance right out of college. It was exciting, but I quickly realized it wasn’t ideal for my mindset. I’m more driven to build and innovate than to do pure analysis.
My finance background helped me understand how businesses operate and how users behave. It taught me a lot about optimizing pricing models and making data-driven product decisions using financial insights. While it was a good experience, I found more fulfillment in creating creative pitch decks, interacting with customers and competitors, and taking on those aspects of the role.
This was the experience that really got me excited about product management. One of the associates I worked with back in my banking days invested in a small company called OpenTable, and they were looking for people who could step into a product management role. As a banker in the early 2000s who had seen stories of people making it big by helping companies go public, I was excited about the role. It seemed like a good time for me to take a risk, so I joined as the tenth employee.
At OpenTable, I had the opportunity to digitally transform the reservation process — taking the pen and paper completely out of the process and digitizing it. My role was centered on building key partnerships. We spent a lot of time with our first three restaurants, trying to figure out how they worked and converting the experience into a digital format with touchscreens and internet access. It was challenging, but that was its appeal.
Our focus with OpenTable was not only to grow the number of restaurants but also to expand geographically. During my tenure, we grew to over 40,000 restaurants worldwide. This story is a great example of how you can use technology to change something that has been done a certain way for decades, if not centuries.
Scaling the platform required me to focus on constant iteration, listen to both the restaurant and the reservation sides, and build this tiny startup into something that went public and was later bought and sold by so many people. It was an exciting experience and a great entry point into product management for me.
I look at full-stack product managers like full-stack engineers — they do almost everything. A full-stack PM needs a blend of technical expertise, strong business acumen, and a passion for user experience and design. Traditional product managers may be fluent in understanding the technical implications of product decisions and managing customer needs and business goals, but the role often requires more than that.
As a full-stack PM, you manage the full cycle of a product. You’re not just sitting in stand-ups or working with the dev team. You’re working with all the departments to align around go-to-market strategy, manage success metrics, make constant iterations, help make data-driven decisions, and explain why the product is important. The role comes with challenges because you’re not only thinking about the idea to invest in and the requirements but also working with designers and the dev team before you’re ready to go to market.
I don’t typically hire designers or engineers and convert them to product managers. I’ve had successes and failures with that approach. Instead, I look for a curious mindset and some sense of user flows and design elements. A full-stack PM needs to be able to research competitors and leading companies in adjacent industries, see what functionalities they are using, make suggestions, and create basic wireframe sketches.
I acknowledge that everybody has their own solutions to problems, but I emphasize a customer-centric mindset. I encourage PMs to deeply understand a problem before proposing solutions. My philosophy is to guide them to focus on problem discovery, data analysis, and validating assumptions before executing.
When I mentor PMs, I encourage them to make the decisions. I don’t want them to get used to coming to me and saying, “Here’s the problem. What’s the answer?” I want to empower them to think for themselves, make mistakes, and evolve from those mistakes.
If they face a challenge and ask for my input, my first question will be, “Well, what have you thought of already? What three solutions have you considered to potentially solve this?” Then, they make an effort to start thinking for themselves. By considering what they’ve thought through and the data they provide, it’s easier for me to reach a decision with them. So it becomes a more collaborative mentoring kind of relationship, instead of a top-down one.
Stakeholders often say, “Here’s our problem. Here’s what I want you to do.” I encourage my PMs to actively communicate with our stakeholders to build trust and align with expectations early on. I mentor them in framing the discussions with the stakeholders around business impact. I ask them to use storytelling to make compelling cases for the product vision — this helps surface things that the stakeholders might not have thought through. This way, we have more clarity on the direction they want to go in with their idea or initiative.
I like having my product managers put together a Y-slide or one-pager after they talk to stakeholders to ensure alignment. What are we trying to achieve? Why is it important? What impact do we see this making on the stakeholder, the organization, and the customer? I also ask them to address how it will impact the user and the user experience. Is this focused on revenue? Is it growth? Is it retention? What are the key KPIs? This sets the stage for how they would work on the project and ensures they’re aligned on the next steps to build out that particular product.
Yes, documentation communication is key. If a stakeholder requests a new feature mid-project, I compare it to building a house, which is a side passion of mine. If they ask for an extra bathroom, I’ll explain that it’ll take longer and cost more. They might need to sacrifice something else, like the garage, to make it happen.
PMs must have excellent communication — be transparent, honest, and realistic. And a lot of the time, stakeholder management turns into pushing, pushing, and pushing. But if you say yes to everything, you’re bound to fall behind. Sometimes, you just need to get used to saying no.
The benefit of documentation — one-pagers or Y-statements — is that you can almost turn that into a pre-press release. You can announce what you’re doing even before you build it. Having this document can help a PM prepare as if they’re launching the product the next day. Even though the product isn’t built, writing up a press release helps others envision the plan too.
Let’s say a product or project is close to launch. As a full-stack product manager, it is your responsibility to work on the go-to-market strategy. This ensures alignment between marketing, sales, and, specifically, customer support. They need to be educated on what you did and why it was important. You also have to make them aware of the competitive landscape, the product’s target audience, and potential product positioning.
Creating as much awareness about what you built and why it is important helps all the different parties tailor the correct message when we go to the market. They need to know if the product was designed to be a neutralizer to our competitors or if it’s something that’s completely new in the market. PMs might not be building the marketing campaigns, but I like to see them involved to help ensure everyone’s on the same page.
We have so many different feedback channels, including Discord communities. I also encourage PMs to attend the sales and account management meetings with our bigger customers to hear their challenges. We also have a continuous feedback loop built into our platform.
If you’re not heavily involved with and listening to customers, your product won’t evolve. They’re the ones who are paying for and using the product the most, so their input is second to none. We prioritize them and their feedback and incorporate it into future roadmaps and initiatives.
I’ve had many instances like that. We might come up with some innovative, seamless ways to access something and think that it solves challenges that have surfaced for our customers, only to find that just 60 percent of users liked the new feature. There will always be some people who don’t like change.
One specific example of a post-launch pivot I had to do was when we implemented a continuous flow for user navigation. Before, the process was linear — the user would turn the page to go to the next step. But we heard that they wanted a more continuous flow with fewer clicks. We found out that some like that continuous flow, while others like the satisfaction of clicking and saying, “Oh, I completed that task. I’m moving on.” Of course, every user is different, and with accessibility and general user experience, there’s no one-size-fits-all solution.
So, we gave users the option to either have a continuous flow through the content we surfaced or to set it up to have more of a click-based structure. It took extra effort, but in the end, it created a positive NPS score. We realized that a hybrid solution like this often works when we can’t make everybody happy with what we have.
Revenue and market share are always the most important, but many things we build into the platform don’t directly correlate to revenue. So, user engagement is a big metric for us. We have a full system in place for heat mapping to see where people move around the platform.
In the education and learning management system, specifically, we focus heavily on NPS and other KPIs like retention rates and engagement. We often track these metrics years after the product moves forward. It helps identify any glitches or seasonal patterns. Overall, it helps us evolve the product and make smarter decisions.
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 developer relations specialist — also called DevRel — is a cross-section between a community manager and a product marketing manager.
Gaurav Nukala shares his passion for both the healthcare and public sectors and how he’s working to influence technology and AI them both.
Hina Kharbey talks about how the roles of a mentor versus a coach differ, as well as the situations that work best for having each one.
The core premise of contingency theory is that there’s no universally correct way to lead a team or make decisions. Instead, it advocates for a strategy that’s flexible and adaptable to the situation at hand.
Learn more →
