Aligning Teams through Product Discovery: 5 Leadership Lessons from a VP
Apr 29, 2025
John Fontenot is currently the VP of Product at Terlumina where he leads Product Management and Product Marketing. John is the Co-Founder and CPO of Path2Product which helps aspiring PMs get the hands-on experience they need to land their first PM job. John is also the author of Never Assume: Ten Fatal Assumptions Great PMs Never Make and the Host of the Lessons in Product Management Podcast.
Takeaways from our conversation:
-
Effective cross-functional collaboration requires PM, UX, and PMM to always be involved, with rotating participation from executives and developers who should have at least one customer interaction per month.
-
Balance between short-term customer needs and long-term product vision is crucial for product teams, as many PMs are naturally long-term oriented but must be willing to make trade-offs in both directions.
-
Strategic alignment can be achieved by combining OKRs with Richard Rumelt's "Strategy kernel" framework to identify core challenges, establish guiding policies for decisions, and implement coherent actions.
-
The Opportunity Solution Tree framework helps teams prioritize problems and visualize how solutions build compound value rather than just incremental features that lack strategic coherence.
-
Product decisions should be based on risk assessment—slow down for irreversible "two-way door" decisions that might require costly rework, and move quickly on easily reversible ones.
From Idea to Impact: Mastering Cross-Functional Collaboration in Product Discovery
Irene: John, I’m excited to have you here, both as a product leader and an alumni of the Skiplevel program. To start the interview off, can you share a bit about your background and what led you to start Path2Product?
John: I spent my first 5 years in tech as a contract employee for Intel, where I led software partnerships with Tier 2 ISV partners, and I led a team of international account managers. Product Managers were one of the main roles we interacted with, trying to get Intel Software integrated into some of the top apps in the world. It was in that time that I fell in love with Product Management and what I saw from my time collaborating with so many PMs. After spending two years trying to get my shot at Product, I got lucky to get a UX Researcher role after a winding journey to get that role. Six months later, I was a full-time PM and haven’t looked back since. From that experience, I realized what the myths were about “breaking into product” and what truly mattered: experience. So Path2Product’s mission is to bridge that experience gap for aspiring PMs and eventually facilitate direct employment opportunities.
Irene: How does your role as VP of Product at Terlumina shape your views on product discovery?
John: Product Discovery is absolutely essential for not just product success but organizational success. Discovery covers a lot, including market and customer research, pre-launch product testing, post-launch surveys and usage data, etc. But product discovery isn’t only useful for Product teams.
In my role with Terlumina, I’m not only leading Product Management but Product Marketing. Truly, PM and PMM are two sides of the same coin. Without understanding the value you’re creating and how your product does that and who it does that for, how is Product Marketing ever going to talk about it correctly to the right people? I’ve always known this and appreciated the PMM function, but leading both has only grown my appreciation for the partnership between these two roles. When it comes to discovery, PM and PMM needs to be tightly coordinated to make sure there’s deep, mutual understanding of the market, customer segmentation, value creation, messaging per segment, etc. In short, my role has provided a heightened appreciation for just how important Discovery is for every aspect of the organization and its success.
Irene: What does effective cross-functional collaboration in product discovery look like?
John: PM, UX, and PMM should always be involved in discovery. Optional participants who might rotate in and out are executive leaders and developers. It’s good to have multiple layers of the organization hearing directly from customers. Sales often has strong opinions on what the market needs, but Product people are uniquely trained to get past the surface and into the underlying problems. That’s why I like Executives to either participate or receive the synthesized feedback and the raw data as “backup” info. Without it, you face the challenge of the head of sales trying to dictate what Product builds because excuses like “our sales team isn’t hitting quota because of this missing feature” are inevitable.
On the Product Team side, it’s important to bring engineers in while respecting their time. That’s why I like a rotation where at minimum, every engineer has one customer interaction per month. I’ve used tools like Teresa Torres’s Opportunity Solution Tree as a visual artifact to facilitate conversations within the team. We review business objectives and talk through the top-level problem space. When it comes to the “leaves” of the tree, it gives us a great visual platform to collaborate and ideate on solutions to the prioritized problems.
Irene: What are the biggest challenges PMs face when working with cross-functional teams?
John: The biggest challenge is always alignment. Alignment starts at the top regarding business priorities and objectives. Too often, I’ve seen executive teams misaligned or unclear on their shared understanding of the business’s goals. That makes alignment nearly impossible if your leadership isn’t aligned on what the objectives are. But if that foundational alignment is in place, it’s easier to align your team around the goals of your discovery efforts. You’ll have an objective to anchor your research so that any stakeholder will understand when you share your data.
Even when it comes to generative discovery, the goal should be to uncover and prioritize opportunities or problems that relate to your business goals. Generative discovery is all about uncovering the “unknown unknowns.” Product teams, leaders, and cross-functional partners know of and hear about problems all the time. Those are the problems that drive reactive behaviors and stakeholder-driven roadmaps. Generative discovery, also called “continuous discovery” (popularized by Teresa Torres), is proactive. You’re proactively seeking to learn new information about your customers and their use and perception of your product.
When it comes to generative discovery, you want to use your business objectives as the anchor and frame for your customer interviews. For example, if your business goals are related to retention within a certain customer segment, opportunities related to growth in a different segment should be noted and then ignored for now. You’re looking to gather problems or opportunities related to your objective. That’s the first level of filtering. Then you can prioritize which of the problems or opportunities are going to create the most leverage to help move the needle of your business objectives. If you do this right, you’ll face far fewer challenges from stakeholders on your roadmap prioritization decisions.
Shiny object syndrome can impact priorities at a team level and a company level, and there needs to be a consistent and coherent focus for things to work well. Outside of customer problems and opportunities, there are other considerations such as technical debt, maintainability, performance, etc. In my mind, those things are not in conflict with net new features. They should be prioritized alongside new features in terms of value, effort, impact, and other tradeoff variables that need consideration. This is the last level of prioritization, at the solution level. This isn’t all process for process sake. Getting alignment and buy-in is hard, and this process helps create defensible decisions when collaborating with your team and your stakeholders.
Irene: What role should customer insights and data play in cross-functional collaboration?
John: Quantitative data and qualitative customer insights should play a huge role in cross-functional collaboration. Pre-launch, you need to understand where your product’s gaps are or what problems and opportunities exist that can move the needle. You’ll only build confidence in what those things are with data. Intuition and “gut feelings” are great, but they should be checked against data.
Additionally, even when you build confidence in the problem space, and your prioritization of it, there should be assumption testing and product testing when you get into the solution space. Throughout the entire PDLC (Product Development Lifecycle), you should be identifying and testing critical assumptions. For example, you might think you fully understood a customer’s problem, but did you? Can you put together a user flow diagram and reconnect with them to confirm you understand what’s happening before, during, and after the problem? Usually this follow-up conversation leads to a deeper explanation of the problem from the customer. In either case, the customer will appreciate your desire to confirm their problem, and the conversation will lead to deeper insights or filling gaps in your understanding of the problem.
Post-launch is no different. It’s too common for PMs to say, “we shipped a thing, what’s next?” Frankly, if the thing you shipped was the most important thing, you should make sure it’s successful before immediately moving on to what’s next. More isn’t always better, and the first release of anything is rarely optimal for achieving the business goals it was intended to meet. It takes the full team to be aligned around those goals, the testing that’s involved, and ensuring you have the right instrumentation to measure against success criteria.
Irene: What are common sources of friction between product teams and other departments?
John: There are two common sources of friction. One that I’ve addressed already regarding alignment. It’s always fascinating when executive leadership gets organizational goal setting wrong. When objectives aren’t common across functions and you get competing goals and priorities from the top, it’s hard to find agreement on what’s important further down the org chart.
The second biggest point of friction is balancing the long-term and the short-term. Short-term thinking focuses on the day-to-day issues that arise. Long-term thinking focuses on the product vision and where you want to be 6, 12, or 24 months from now. You can’t exclusively focus on one or the other. It’s a balancing act. This is difficult for PMs to do well, as many of us are long-term-oriented, but we must be willing to make trade-offs in both directions.
There’s always going to be pressure to immediately address every customer complaint, feature request, lost deal, and churned customer. Each of these issues becomes an opportunity for the organization to react and become hyper-focused on the short-term needs of the customer and the business. There are times to be reactive and there are times to be proactive. The goal is to always operate in a proactive state, but we need to balance the reactive nature of “here-and-now” issues with a long-term orientation that keeps our organizations relevant well beyond today.
Irene: How can PMs proactively address misalignment before it becomes a bigger issue?
John: The best time to address misalignment is before it happens. In my experience, there are three areas where a lack of upfront clarity can cause issues:
-
The objectives of an initiative or project
-
The criteria for yes/no decisions (what’s in scope or out of scope)
-
How we’re going to measure success
If you can define, document, and disseminate that information at the beginning of an initiative, getting and keeping alignment through the execution phase of an initiative becomes easier.
Regardless of how proactive we try to be, misalignment does still happen. When issues do arise, it’s best to address them head on. Hiding from misalignment issues will only create more problems downstream. Identify the misaligned individuals and the nature of the misalignment. Then, set up a meeting. Next, bring the documentation you shared before the project kick-off and the data supporting the project. If necessary (and often recommended), bring your product leader who can help when dealing with senior stakeholders. Talk through the misalignment and see how you can help. This isn’t a time to be combative but a time to be a good partner. Listen intently, and seek to find a resolution to the alignment issues so that you can all move forward on the same page.
Irene: Have you seen any effective frameworks or rituals that help teams collaborate better?
John: There are a couple. One is for strategic alignment, and the other is for alignment in execution.
Strategic Alignment: I’ve found combining a couple of known concepts into one framework has been applicable to any level of your organization. Whether you’re an IC looking to develop a strategy for your team and purview or you’re in product leadership responsible for multiple teams, this framework can work for you.
This framework combines OKRs and Richard Rumelt’s “Strategy kernel” from his book, Good Strategy Bad Strategy.
The OKRs act as the two buns on a sandwich. You start with your business objectives at the top, and you finish with Expected Results or success measures at the bottom.
In the middle, you have Rumelt’s strategy kernel.
-
What is the core challenge in the way of our business objective?
-
What will we choose as our guiding policy to overcoming this challenge? Basically, what “yes/no” question will we ask for every problem or opportunity we could pursue?
-
Which coherent actions (aka the “yes” answers from #2) will we take to overcome our core challenge? (#1)
Combining those two frameworks provides a solid guide for strategic thinking and alignment with your team and across functions. If you agree on your business objective, the challenge in your way, and how you’ll make go/no-go decisions, then you solve upstream many of the alignment issues that arise downstream.
Execution Alignment: I mentioned this concept before, but it’s important for this part of the answer to your question. The concept of the Opportunity Solution Tree from Teresa Torres has been incredibly beneficial for me and the teams I’ve worked with when it comes to executing against the strategic framework above. You retain the business objective and the core challenge on the OST document. Then when you see problems or opportunities that you say “yes” to as it relates to your Guiding Policy, they make it on the tree. Once you start prioritizing the opportunity space, the potential solutions get viewed through the lens of “coherent actions.” What that means is that you’re not scatter-shooting at random solutions.
I’ve seen product roadmaps littered with a random list of features that get prioritized through some framework like RICE, where you measure the reach, impact, confidence, and effort of solutions to determine which get prioritized first on the roadmap. This is hardly strategy.
The idea of coherence is that each solution you deliver builds upon the value of what came before. If you’re executing towards a product vision, features shouldn’t be random. There’s coherence, meaning they work together to build compound value, rather than incremental value, over time. The OST helps visualize that concept as you map out what becomes your roadmap. The goal is to solve a problem or capture an opportunity that’s most likely to move the needle for your business and your customers. That requires coherence or a connectedness among each sprint, each feature, and each initiative. The coherence is what creates focus within a team and allows for better collaboration. You see the big picture as you execute rather than continually churning out more random features.
Irene: Can you share an example where strong cross-functional collaboration led to a great product outcome?
John: My first zero-to-one product build didn’t start out as a “build.” My VP of Product and I held a strong assumption that we’d need to buy a solution that we integrated with for a partner portal experience for our channel partners. However, there was a convergence of ideas and data that came from research and the engineering manager I worked closely with.
Our team’s EM (engineering manager) suggested we could just build the portal experience we wanted by leveraging some internal tooling we already had and building a separate experience on top of it. As she shared the technical details behind it, it made a lot of sense. The costs over time would likely be comparable between the build and maintenance of the build and the recurring costs of buying a solution.
Fortunately the channel we were building for had a waitlist of 400+ small channel partners who became a captive audience for customer research. What we learned in our customer interviews helped shape a spec for our MVP, and it quickly became clear that using an off-the-shelf product would have pigeonheld us from being able to differentiate from competitive alternatives in the market.
If our EM hadn’t spoken up, we would have purchased a solution and delivered a sub-optimal experience for the new partner channel, lowering our chances of maximizing on the channel opportunity, and opening risks for partner churn.
Irene: What’s a mistake you’ve seen PMs make in discovery, and how can they avoid it?
John: There are a few common mistakes I’ve seen in different areas of discovery:
-
When talking with customers, there’s a tendency to want to quickly get through a list of questions. PMs need to learn to listen and drill down into the interviewee’s answers with sub-questions, especially when what they say is interesting or unexpected. The real insights are below the surface answer, getting there requires several follow up questions. The art and skill comes in knowing when, where, and how to drill down.
-
The second problem is equally as common where PMs don’t share insights broadly. The larger the organization, the more duplication of effort you’ll see. Many organizations invest in good research repository software that’s broadly accessible throughout the organization, so insights rarely get codified beyond the tribal knowledge of the team that uncovered them.
-
This is related to #2 in the sense that most people in organizations don’t know what insights exist because they don’t know what research is being done. I got in trouble over a misunderstanding between a former SVP of Lender Partnerships and my CPO because the CPO didn’t know what research I was doing and was caught off guard by the EVP’s comments about some internal discovery I was doing with his team. Let people know what you’re doing and what your goals are. It’ll go a long way.
Irene: How should PMs balance speed with thorough collaboration in fast-moving environments?
John: To me, this comes down to risk, the proverbial “1-way vs 2-way” door decisions. The bigger the risk, the higher the coordination needed. Sometimes slowing down helps you make a decision that prevents rework. What I mean by rework is making decisions quickly that forces you to start over later, refactor large amounts of code, or redesign major sections of the product. This are time-consuming, costly decisions, usually made because of untested assumptions you had about the customers, their problems, or how to solve them. Rework is worse than slower, better decisions. However, if the decision is easily reversible, moving forward without incurring high coordination costs is the way to go.
Good product decisions are based in the confidence that comes from testing the most critical or potentially costly assumptions. Pull together a quick mockup or prototype with one of these awesome new AI tools to test desirability, usability, or any other key assumption. It would go a long way in building confidence in your decisions. These data points go a long way in building confidence with your team and cross-functional partners as well.
Irene: What advice would you give PMs who struggle with getting buy-in from stakeholders?
John: Start engaging in continuous discovery to build a wealth of qualitative data and build systems for quantitative measures of key business and product metrics. When it comes to strategy and your roadmap, getting buy-in truly comes down to data. Everyone has opinions and without data the HiPPO (highest paid person’s opinion) wins. Without data, you come across as argumentative and “not a team player” when stakeholders don’t get what they want. Objective data covers a multitude of potential problems.
But don’t treat stakeholders as roadblocks in the way of your progress. Treat them as business partners. You’re supposed to be on the same team, and frankly you need their help if you want your product to be successful.
Stakeholders won’t be bought in until they are brought in to your process. There’s a five-step framework I like to share with cross-functional leadership when trying to get alignment and buy-in. If you can align on these five critical questions, you’ll save yourself a lot of heartache down the road:
-
What is our business objective?
-
What is the biggest challenge in the way of our objective?
-
What will be our policy to guide what we say yes and no to?
-
Based on our guiding policy, which actions will we prioritize to best position us to overcome the challenge in the way of our goal?
-
How will we measure whether we’re being successful? What are the leading and lagging indicators we’ll measure?
Irene: How can early-career PMs build strong relationships with cross-functional peers?
John: First impressions go a long way. Instead of coming into a new company or team and acting like an expert or a know-it-all, start with individual 1:1s with each member of your team. Each engineer, UX design, data scientist, etc. I like to find out what’s going well, what’s not, what their perception of the PM role is, what they liked about what former PMs have done, what they disliked about former PMs, etc. You learn a lot about how your team views your role and which landmines to avoid from those conversations.
As you get going into the swing of execution, it’s helpful to ask good questions early and often. Solicit feedback and opinions regularly. Product Management requires good leadership and good leaders ask good questions and include their teams in the decision-making process. When people feel heard, they’re more likely to buy-in.
Lastly, it’s a good idea to do quarterly or at least semi-annual 360-degree surveys to run continuous discovery on yourself. Make the surveys anonymous so people feel safe to give you candid feedback, and make sure to take action on the feedback you receive. The three go-to questions I like to ask are:
-
What am I doing well that I should keep doing?
-
What am I not doing that I should be doing?
-
What am I doing that I should stop doing?
The answers tell you a lot about yourself and how you can improve to be a more effective teammate and leader. Again, make sure you take action on the feedback you’re given. Someone’s perception of you is their reality, whether you agree with it or not.
Irene: If you could give just one piece of advice for better product discovery collaboration, what would it be?
John: Over-communicate your goals and what you’ve learned. And part of over-communication is understanding that not everyone receives or digests information in the same way. If it’s important enough to discover, it’s important enough to make sure the right people receive and understand the information and its implications.
Become more technical without learning to code with the Skiplevel program.
The Skiplevel program is specially designed for the non-engineering professional to give you the strong technical foundation you need to feel more confident in your technical abilities in your day-to-day role and during interviews.