Aligning Finance and Product for Success
And the Four Product Manager Archetypes
Plan confidently, close faster, and report with precision using Planful.
Planful’s powerful financial performance management platform elevates teams like yours across every aspect of your business.
What sets Planful apart? Quick implementation and minimal IT involvement—your team can get started in just weeks, ensuring seamless engagement across your organization's key financial processes.
Grow without limits with a platform that scales with you, no matter how fast you expand.
Join over 1,500 global customers who trust Planful for flexible, user-friendly, end-to-end financial performance management. Ready to elevate your financial game?
I’ve worked with all types of product managers throughout my career. Here’s a guide to optimizing the Finance - PM relationship so you can hit your launch dates and revenue forecasts.
Product Managers Need to Understand How the Business Makes Money
Product managers are great at executing on a roadmap, but too many don’t understand how the company makes money. And when that happens, they optimize for engagement, usability, or even customer feedback—without considering whether what they’re building actually improves the company’s financials.
If you’re in finance, part of your job is making sure PMs know:
How we price and package the stuff we sell
What our growth goals actually require (in terms of customers, ARPU, retention, etc.)
Why gross margin matters (and why we can’t just scale costs indefinitely
But before you can influence a PM, you need to know what type of PM you’re dealing with.
The Four PM Archetypes
According to Matt Hudson, CFO of Grammarly and former PM at Google and YouTube (that’s right - I found a unicorn - a former PM turned CFO to give us the inside scoop), PMs tend to fall into four categories, based on what they focus on first:
The Strategist – Wakes up and reads their one-pager on product strategy, market positioning, and competitive dynamics.
The Designer – Lives in the mockups and user flows, focusing on the pixel-perfect experience.
The Taskmaster – Obsessively tracks Jira boards, sprint timelines, and release schedules.
The Data Geek – Immediately checks dashboards, usage telemetry, and performance metrics.
Each of these PMs think differently. If finance wants to be a real partner, you can’t treat them all the same way. Similar to how you have to “meet your customer where they want to transact” (see, I got a bit of PM in me), you need to find common ground with your counterpart.
The Strategist PM needs to see how financial constraints impact the company’s long-term bets. Talk to them about capital allocation and trade-offs.
The Designer PM won’t care about revenue models, but they will care if you show how UX impacts conversion rates.
The Taskmaster PM wants budget clarity—what’s getting funded, what’s not, and why.
The Data Geek PM is your closest ally. They already track metrics—just make sure you’re aligned on which ones actually matter.
When PMs Optimize for the Wrong Things
Understanding who you’re dealing with is step one. Step two is making sure they’re working on the right things. Here are three real life examples of what happens when PMs don’t understand the business model. They come from my own personal experience scaling companies from the finance side.
1. The Dashboard Metric That Didn’t Matter
A PM I worked with was fixated on a specific usage metric. Every morning, they checked it like a stock ticker. They talked about it in meetings. They even suggested tying compensation to it.
The problem? It had zero correlation to revenue, retention, or expansion. It was just a vanity stat. A cumulative metric that could only increase. But because it was easy to track and always trending up, they treated it like a north star.
The Fix: We sat down and mapped out how the business actually made money. What leading indicators mattered? Which ones were just noise? Once they saw the disconnect, and realized we would never talk about this metric in a board meeting, they shifted focus to financially relevant metrics.
2. The Beautiful Project Plan That Would Have Killed Our Margins
Another PM came in with an elaborate project plan. They had a full roadmap, a Miro board that required like 17 monitors to read, and a three-phase rollout strategy. It looked great—until we ran the numbers (no podcast pun intended).
The entire product was built on data we didn’t own. Even if we could acquire it, the cost to structure and maintain it at scale would be massive. Since those costs would sit in cost of goods sold (COGS), they would crush our gross margins.
Even if customers paid for the feature, our unit economics would never work. The best-case scenario was breaking even.
The Fix: We set up a new process—before committing to a major product investment, finance and product had to align on four key questions:
Do we already have the data/infrastructure to make this viable?
Do we own the data?
What’s the actual revenue potential compared to the cost to execute?
How does this fit into our pricing and packaging strategy?
What happens to gross margin if this scales?
That single framework saved us from pouring resources into something that would have looked good in a product demo but resulted in a financial disaster.
3. The Customer Survey That Focused on the Wrong Users
A PM once ran a customer survey to validate a new feature idea. The response was overwhelmingly positive—customers loved it. They said they would absolutely use it.
One issue: the people surveyed weren’t our ideal customers.
They were a small, vocal subset, but they weren’t the ones who actually drove revenue. Not only were they few and far between, they had basically no budget. Most were actually free, not paid, users. If we had built what they wanted, we would have spent months catering to a group that wouldn’t materially impact the business.
The Fix: We changed how product and finance worked together on customer insights. Before running any research, we agreed on who actually matters. In other words - did we even have a sales team staffed to sell into this segment?
As a result we launched surveys focusing on customers who aligned with our revenue strategy—not just the loudest voices.
Making the Finance - Product Partnership Work
PMs don’t need to become finance experts. But they do need to understand:
How the business makes money (pricing, packaging, unit economics)
What’s required to hit our growth goals (customer acquisition, expansion, retention)
Why gross margin matters (if COGS scales faster than revenue, we’re in trouble)
And it’s a two way road. Finance teams need to understand who they’re talking to. A “Data Geek PM” will be receptive to financial metrics, but a “Designer PM” won’t care unless you show them the UX impact. Their “light bulb” moments hit different.
When finance embeds these ideas into product decision-making, everything changes. Roadmaps get sharper. Resources get allocated more effectively. And instead of finance being the team that just says no, we become the team that helps product make smarter bets. Because that’s what we’re doing at the end of the day - working together to make the best bets possible with the resources we have.
Apple | Spotify | YouTube
A big congrats to Matt and the whole Coda team on the Grammarly combo.
On the show, Matt and I discussed:
Insights from his unique career path that spans roles as a product manager at Google, YouTube, and Coda before becoming a CFO.
Frameworks he’s used in his career from the Blue and Black Loop framework for understanding the growth of a shareable product like Coda’s
Eigenquestions for getting to the one question at the center of all questions
The Vacation Rule for determining whether to build or buy software tools.
The evolution of Coda's pricing model
How finance can partner with product managers
Really interesting take. We chat with lots of strat finance/ product finance folks and aligning the relationship is hard.
It seems to me like one of the most difficult parts is often the quality of data at companies. If you have highly variable cogs but don't have the granularity to distinguish between users, it's really hard to be data-driven.