🧠 Community Wisdom: Building context as a new PM, whether PMs should do financial modeling, managing mismatches b…
👋 Hello and welcome to this week’s edition of ✨ Community Wisdom ✨ a subscriber-only email, delivered every Saturday, highlighting the most helpful conversations in our members-only Slack community. A big thank-you to this month’s community sponsor, Merge. Merge makes integrating with your customers’ software vendors easy. Add hundreds of integrations to your B2B SaaS products, with unified APIs for file storage, ticketing, CRM, ATS, HRIS, and accounting. AI companies love Merge because it delivers instant, secure access to clean customer data that powers their solutions. Stop wasting countless engineering hours staying ahead of breaking API changes and digging through a backlog of integration support tickets. Merge handles the full integration lifecycle so you can focus on what matters most: building your core product! ✨ Upcoming community meetups ✨Upcoming community-organized meetups—click the city name to RSVP:
Can’t find your city and want to host one? Just DM @Riya in our Slack. It takes 10 minutes (i.e. pick a date and location), and you get to meet awesome people from our community. Learn more here. 🎙️ New podcast episodes this week35 years of product design wisdom from Apple, Disney, Pinterest, and beyond | Bob Baxley: YouTube // Apple // Spotify Gamma’s Head of Design on how his team uses AI to synthesize feedback, generate on-brand imagery, and maintain design quality while serving users in 60+ countries | Zach Leach: YouTube // Spotify // Apple How Mercado Libre built Latin America’s most valuable company: 18K engineers, 30K deploys a day, and their own fleet of planes | Sebastian Barrios: YouTube // Apple // Spotify 💥 Top threads this week1. What is a “product”?
Miroslav Pavelek: I would start with another set of questions:
And my take:
No need to think about what is product or what is product management. And the product hierarchy shouldn’t be based on some theoretical rocket science; it should be based on:
Andrew Bartholet: I think a product exists to move someone from a current state to a desired one, by doing a job they care about. A great product = Right person → Right change → Right way → Right time A great product is a system that repeatedly solves a meaningful problem with minimal friction and maximum clarity. It’s not what you build; it’s what people experience, achieve, and feel because of it. Build with empathy, iterate with feedback, and deliver value early and often. Michael Thomas: On product definition: Focus on value, not sales mechanics. I’d frame it this way: A product is a systematic solution that creates measurable value for users. The “selling it” debate misses the point—that’s about business model, not product definition. Your dashboard absolutely qualifies as a product, because it transforms raw data into actionable insights. Without it, customers would have data but no efficient way to extract value. The dashboard does the jobs of visualization, analysis, and decision-making support. The systematic test I use: Does this solution help users achieve outcomes they care about? If yes, it’s a product. Revenue model comes later. Product hierarchy: Work backwards from customer outcomes. Here’s where systematic thinking really helps. I’d suggest this hierarchy: Product: Gas Emission Intelligence Platform
Rationale: You’re not artificially splitting satellites vs. aircraft into separate products. Instead, you’re building a comprehensive platform that uses different collection methods to serve different customer jobs. Eric Metelka: I agree with others that you need to zoom out and get some perspective on why you’re having this debate. The definition of “what a product is” isn’t very helpful. It sounds more like your boss wants you to consider the GTM motion, and I believe they are correct. A product in isolation, without an understanding of how it will be sold and to whom, is not valuable on its own. The job of a PM is to understand and influence the GTM motion because that is how your product will get adopted and make revenue. An example: Building a new feature in isolation does not get it adopted. You have to put together materials for marketing and sales such that you have a strategy for how users will adopt it. But you will likely be wrong and need to iterate on this based on feedback you hear post-launch. You need to be in sync with the GTM team. You cannot get adoption or make money without them! Marsh Gardiner: While I can see the value in zooming out as others have suggested, I also see value in the question. As you build out a product team, how you define products may determine how you staff PM. For example, an internal platform team might benefit from a dedicated product role, but it isn’t going to generate direct revenue. Does that mean it isn’t a product? Does product thinking not apply in that context? I’ll echo others above, like @Michael Thomas wrote, “Does this solution help users achieve outcomes they care about?” And I’ll add that in addition to creating value, there must be some kind of value exchange. That doesn’t mean it has to be $$$! Back to the internal platform, if it is working well, the platform should be creating value for feature teams, which drives impact. I’ve written previously about How X-as-a-Product Is a Useful Lie, which talks about this in more detail. Your director of product boss will be judged on how well they deliver on realizing revenue! As any PM org scales, though, they’re going to collect a mix of different types of PMs to specialize in different ways on different problems. As to your JTBD question, I’m a fan of focusing on the problem, not the solution. As @Isaac Hepworth put it, “PM should stand for ‘Problem Manager’ not ‘Product Manager,’” as better results come from owning the problem rather than owning the solution.” If you are the PM for a measuring tape, you’re less likely to redefine the category with a laser measurer than if you own the problem of measuring itself. Dale Clay: Love this topic and the questions you’re working through. I lead Product and Engineering, and IMO the answer to the question “What is a product?” is pertinent to how teams are organized and incentivized. For me, it is helpful to distinguish between external GTM propositions and internal products (or product lines). For example, the external product may be as simple as Gas Emission Intelligence. The unique way you choose to deliver that intelligence (API, SaaS, flat files, dashboards, etc.) begins to clarify your strategy and differentiators (First and Only Real-Time Gas Emission Intelligence API). However, turning inward, it might make sense to think about your data collection area “as a product.” Like @Marsh Gardiner points out, there doesn’t need to be an exchange of money in order for it to be beneficial to treat data collection as a product. For example, you might need an entire team focused on expanding and optimizing data collection methods. The artifact they might produce is “Prepared and published data feeds < 2 hrs. old.” You might also have a team focused on data analysis and insights, producing “Actionable insights and user-friendly dashboards/reports.” Neither of those artifacts on their own represent the full value proposition but are helpful to distinguish and potentially helpful to treat as their own product. Lastly, since there is a significant part of your product that is shared or used by all (raw or prepared data), it might be helpful to distinguish by use cases, not verticals. All customers may use the same basic data, but in different ways and for different use cases (compliance, scientific studies, quality control, etc.). In which case your PMs could organize around their own particular use cases, while constrained by and taking advantage of the shared products like a platform. Kevin Sauvageau: First off, thank you to everyone who replied. I’m glad it sparked sort of a conversation! Here are some answers and comments on some of the questions mentioned:
Max Karreth: Lots of really great comments! Love this. Two quick angles I’d throw in:
2. Mismatches between finance and product dashboards
Michael Thomas: Hey Dheeraj! This sounds less like a divergence problem and more like a leading/lagging indicator integration challenge. Product dashboards naturally track value creation activities (leading indicators)—user behavior, engagement, feature adoption. Finance tracks value capture for reporting (lagging indicators)—recognized revenue, billing cycles, SEC filings. Both teams are doing their jobs correctly. The gap is systematic integration between them. Instead of accepting divergence, what if you translated leading indicators to help Finance better anticipate what’s coming? “Here’s what we’re seeing on the value creation side that will show up in your reports in 6-8 weeks.” This shifts from “getting Finance on your side” to “helping Finance do their job better through leading indicator intelligence.” You become the person who helps them anticipate rather than just reconcile. I’ve seen this pattern across different functional handoffs—the breakthrough usually happens when you create systematic translation rather than hoping separate frameworks eventually align. Happy to share some approaches if helpful. Anonymous: Given you are comparing the same time period, let’s say Jan.-April, if your subscription revenue differs between what your product says and money in the bank (Finance)—to me you have a major problem. Finance numbers are more accurate because it’s real money, but maybe things are slipping through and you’re not collecting money like it should be. Lady Luck probably has it as: your product says you’re making more money than finance says. There should be 0% discrepancy. But of course you need to layer in the complexity of how you bill. In advance, in arrears, what happens when I hit my billing date—my credit card is blocked—does your product say it got revenue but the numbers aren’t in the bank (Finance)? Also, what is the delay in a credit card charge versus reflecting in the company bank account? There’s probably a transaction date and a “landed in the bank” date. You’ve both got to use the same date for your numbers to match. Eric Metelka: You’ve identified the correct reason for the discrepancy: different data sources. Event-based systems are not based on the same data as finance systems. It’s fine to use these sources for different jobs:
The divergence is fine, but what you don’t want to do is use the event-based system for the output metrics like revenue. These will be wrong and you do not want to report these numbers to leadership, as it will create confusion. Anonymous: Ahhh yes, that’s true. Then for me, I’d entirely depend on finance for subscriptions and revenue. Make friends with Finance and ask if you can build a cohesive dashboard with their data and your other data one nice “dashboard.” Surely you’d want to know that customers are churning (subscriptions), and at least with your data combined you can dig into why. You could pull your customer support tickets in there too. Also, it’s nice for the entire company to have “one place for numbers we all believe in.” Eric Metelka: Getting to one place for numbers is difficult. BI software requires clean and transformed data and pre-made dashboards. They aren’t flexible enough for product analysis. Product analytics is great for getting to answers quickly but doesn’t have the same rigor as what’s in the warehouse. The reality is we as product managers have to exist in both worlds, as there’s not a solution that covers both use cases. Miroslav Pavelek: Our approach is:
Michelle: It’s not that difficult and entirely possible. Tools like PowerBi and hex.tech are designed to combine data from different sources. I taught myself a long time ago, and I’ve done it for every product I’ve run. But when I’ve been low on time, I’ve asked a data person on my team to do it or at least make a couple of DB views if I absolutely needed it. You can also even share the data model in PowerBi as a dataset, so other people don’t get stuck with your dashboard. It’s so much easier when the data is there, visible, and trusted. I’m just saying these tools are completely designed to do this—it’s not that difficult—but you can ask a data person. 3. Should PMs do financial modeling?
Shane J: Do you mind sharing a rough number of how many companies you have as customers (or ARPA, since we know the $50M)? You mention targeting enterprise, so I assume a smaller number of companies with high ACV. Also, what does your pricing model look like? (Are there tiers, packages, seats, usage-based, etc.?) Faheem: ARPA will be around $300K per client. The shift towards enterprise has begun in the past few years. Joshua Herzig-Marx: I found that lots of folks sitting on the Finance team would be happy to talk about this with you! Dan Gent: If I understand what you are saying correctly, we are in a similar spot. We have a RevOps team that are responsible for building those models (e.g. how much ARR this feature will make and what segment of our customers will buy it). I think it’s a lot to ask of a product team to make this appear on their own, as it’s so tied to wider business goals and strategy. Eric Metelka: There are some cases where building out financial impact is useful, but in most cases I find it to be busywork. The big case when there should be a financial model is new product offering. This involves new investment decisions and therefore should have an understanding of both cost and revenue potential. However, for most new features, I don’t think it’s helpful to go through this exercise. The investment decision has already been made to staff teams on the core product. That investment drives deals won (and winning percentage), NRR, and some TAM expansion. The team building dashboards is focused on driving more adoption and usage of the dashboards, which should roll up to more deals won and NRR. But it’s hard to explicitly link these things to the business metrics. Focusing on that product goal of adoption or usage is totally fine. There should be an understanding of ROI at the project tradeoff level (is this project that takes X number of engineering weeks the best way to drive more usage?) and that should be sufficient. 4. Building context as a new PM
Jose Fort: You are probably properly identifying that you need more context, so speaking with the people who have it and that it is a must that you have contact with clients. Michael Thomas: I found something that helps me flip the dynamic whenever I’m in these foggy situations. Gathering more context is good, but how do you actually act on it? Work backwards from the result you want. You probably have some sense of what the company wants to achieve—if you don’t, that’s step one. Start with the outcome. Then you’ll know who cares about it. Based on who cares, you’ll understand what proof they need to see. That tells you what process creates that proof, which informs your priorities. And those priorities reveal what problems they’re actually trying to solve. Simple heuristic: People → Proof → Process → Priority → Problem. Work backwards from people who care about the outcome, and you’ll get much clearer on the problems worth solving. For your situation specifically—ask your CTO what outcome he needs to see from product this quarter. Then ask who else cares about that outcome. That’ll give you the clarity on what ‘tangible results’ actually means to them. Things will unfold a bit clearer from there. Kerstin: Are you the first/only product hire in the company? Jeff Chow: Thanks for that, @Michael Thomas! Definitely will do that to try to put that into practice! @Kerstin, yes, the engineers right now lead a lot of the product initiatives. Kerstin: Definitely talk your CEO and don’t rely on secondhand information. I assume the company is still small, so you should have a regular meeting every (other) week with your CEO to align, know about their expectations and have the chance to talk about how you see things. You will not be able to be valuable (in their opinion) if it’s not clear what value means for them. Additionally, when the CEO knows what you want to work on, you will be enabled to participate in the relevant meetings. If you see a gap, e.g. no regular alignment on where the product is heading in (roadmap), be proactive and set it up. Worst case is that some people are highly irritated, but you will definitely get a sense of how things work there. In my experience, when you are the first PM and management doesn’t have a product background, they don’t have much of an idea what your job is, could be or should be, and therefore expectations aren’t clear. If that’s the case, you kinda have to sell your role and what value you could bring. So back to talking to the CEO and communicating what you would like to work on and why. Miroslav Pavelek: Comments above are gold. I will just mention three things:
Jeff Chow: This is all extremely valuable feedback, thank you all! Have set those 1:1s to realign, and hopefully this new perspective will help. I appreciate everyone for the tips! 🤓 Top finds
😂 Meme of the weekHave a fulfilling and productive week 🙏 If anyone in your life would benefit from this newsletter or community, consider giving them a gift subscription 💞 There are group discounts, gift options, and referral bonuses available. Sincerely, Kiyani 👋 Invite your friends and earn rewardsIf you enjoy Lenny's Newsletter, share it with your friends and earn rewards when they subscribe. |
Similar newsletters
There are other similar shared emails that you might be interested in:
- 🧠 Community Wisdom: Essential reading for early-stage founders, balancing unlimited SaaS plans with profitability…
- 🧠 Community Wisdom: Finding your voice on established teams, focus tips for ADHD brains, how to best use Granola,…
- 🧠 Community Wisdom: Designing great performance review templates, balancing oversight and autonomy with junior te…