👋 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:

• Austin. June 26th. Thanks to @Andy Keil - Austin!

• Barcelona. June 17th. Thanks to @Marc Bisbal!

• Berlin. June 26th. Thanks to @Daniele!

• Chicago. June 26th. Thanks to @Shivam Malhotra!

• Denver. June 25th. Thanks to @Prachi Jhala!

• Houston. June 24th. Thanks to @Joseph Mapula!

• Kuala Lumpur. June 25th. Thanks to @Wen!

• Lisbon. June 17th. Thanks to @Gabriela Naumnik!

• Melbourne. June 27th. Thanks to @Emily Gu!

• Munich. June 17th. Thanks to @Lukas Gerhardt!

• Philadelphia. June 24th. Thanks to @Keriann Sabatini & @Kamilla Yunusova!

• Portland. June 17th. Thanks to @Julian Dunn!

• San Mateo Morning Meetup. June 17th. Thanks to @Eric Wang!

• San Francisco. June 18th. Thanks to @nikitha!

• Santa Barbara. June 24th. Thanks to @Joni Hoadley, @Cody Landstrom, & @Oliver Barton!

• Santa Cruz. June 18th. Thanks to @Patrick Mottram!

• Seattle. June 18th. Thanks to @Carl Vellotti & Monali Agarwal!

• Shanghai. June 25th. Thanks to @Brendan McBride!

• Sydney. June 19th. Thanks to @Rob Chan!

• Toronto. June 24th. Thanks to @Raf V.!

• Vancouver. June 25th. Thanks to @anant!

• Warsaw. June 25th. Thanks to @Tom Bradshaw!

• Wellington. June 24th. Thanks to @suhel!

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 week

35 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 week

1. What is a “product”?

Q: TLDR: This message is meant to kick off a conversation regarding your perspective on what is considered a product, from a definition standpoint but also a product hierarchy perspective.

In my new role (senior PM, essentially right-hand man to the director of Product), I’m having a debate (very friendly) with my boss about some fundamental questions regarding product management, and this community has always been very enlightening!

For context, my company monitors gas emissions (data collection) through cameras and sensors installed on satellites and airplanes, which in turn customers consume (and pay for), through various means like API, dashboard, etc. There are 2 topics that I wanted to address:

• What is a product?

  • Now, my take here is “a solution that delivers value to a specific user or customer, in exchange for some form of measurable return (e.g. revenue, engagement, efficiency).”

  • The reason why it’s a debate is because my boss is attaching the concept of “selling it” to a client, meaning that a thing such as a customer dashboard (for analytics) is not a product. On its own (without the data to populate it) the dashboard is useless, hence not a product.

  • Furthermore, the fact that we would be meeting the needs of different clients (depending on vertical or needs) would also mean that each one of those would be a product. For example, the type of data we collect for Vertical A is a different “type” of data that we do for Vertical B, but in the end they are all gas emissions data.

  • Thoughts? I strongly feel that the “paid” aspect, not the vertical, should be defining if something is a product.

• Combining the JTBD framework with a product hierarchy

  • I am trying to establish a product hierarchy, i.e. product -> customer needs (JTBD) -> solution(s) -> epics or tasks. Now considering the previous confusion on what a product is, what would you believe is the product here?

  • Like I mentioned, all we do is monitor gas emissions, currently using 2 different methods (satellites and aircraft) because both are meeting different customer needs.

  • The debate here is, the hierarchy should be either:

    • Product: Gas emission monitoring

      • JTBD (e.g. I want to monitor gas emissions on a global scale)

        • Use satellites to track it

      • JTBD (e.g. I want to monitor gas emissions on a more precise scale)

        • Use aircrafts to track it

      • JTBD (e.g. I want to visualize my data easily)

        • Create a customer dashboard

      OR

    • Product: Satellites

      • JTBD (e.g. I want to monitor gas emissions on a global scale more frequently)

        • Send more satellites into orbit

      • etc...

What would you feel makes the most sense based on your experience?

Thanks for coming to my TED talk (and apologies for the lengthy message)! ↗️

—Kevin Sauvageau

Miroslav Pavelek: I would start with another set of questions:

1. Why do you care about the definition of product and product hierarchy?

2. What problems are you trying to solve?

And my take:

• I guess the purpose of your company is to build something which makes money.

• It makes money by fulfilling real customer needs.

• As long as you’re meeting those needs efficiently and selling it well (solid GTM strategy), revenue follows.

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:

• What hierarchy of teams can help you work more efficiently?

  • Is it better to put it around customer needs or part of platforms?

  • Where are the teams located (due to Conway’s law)?

  • …

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

• JTBD 1: “I need comprehensive emission monitoring for regulatory compliance”

  • Solution: Satellite monitoring (global coverage)

  • Solution: Aircraft monitoring (precision verification)

  • Solution: Dashboard (compliance reporting)

• JTBD 2: “I need to optimize operations based on emission patterns”

  • Solution: Predictive analytics

  • Solution: Trend dashboards

  • Solution: Alert systems

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:

• Why ask those questions, and why am I aiming to deliver?

  • It’s a mix of genuine curiosity of how my peers perceive this, but also because we are at this starting point of building the product environment and organization, so I would prefer to start on the right foundation rather than having to change the mentality months or years down the road.

• Regarding product hierarchy, I do have a bias on being “platform-centric” (from past experience and content I have read). I used to work on a structure of product-component-subcomponent. So I wanted to remain open-minded and hear other people’s thoughts on this topic. This thread has been very helpful in doing so; thanks for that!

• I do feel the JTBD format with a product set as the top artifact seems like a good “balance” of focusing on problems and outcome, while making it clear what we consider our products.

Max Karreth: Lots of really great comments! Love this. Two quick angles I’d throw in:

• What user problem are you actually solving? Especially with regard to the point on verticals, I’d anchor on user problems. If the core user problems are the same, does it matter whether the data comes from satellites or aircrafts?

• To your point on JTBD, that makes me wonder on the overall value delivery chain. This goes a bit back to the “People don’t buy products, they hire them” framing of JTBD. I wonder here if it is more about how the product is being delivered, not what the product actually is. Perhaps a question/discussion with your boss on where the lines for product marketing, platform strategy and GTM are?

2. Mismatches between finance and product dashboards

Q: We’ve occasionally noticed small differences between what the Finance team reports (e.g. revenue, subscription counts) vs. what our internal product dashboards show.

We’ve chalked it up to differences in source of truth (billing system vs. event-based tracking), timing, and some customer behavior that results in weird subscription behavior—but I’m curious:

• How much of a difference is acceptable between Finance and internal dashboards?

• What level of discrepancy sets off alarm bells at your org?

• Do you reconcile these differences regularly—or just accept some level of divergence?

Would love to hear how other PMs handle this, especially in fast-growing teams or data-mature orgs. ↗️

—Dheeraj Putlur

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:

• Event-based systems are great for understanding how users are using the product—your inputs

• Finance-based systems are great for measuring the company’s north-star metrics—the outputs

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:

• We have a single source of truth for data—our Product Database

• On top of that, there are two “dashboards”—one for Product and the second one for Finance

• There is a continuous stream of work making sure Finance has correct data and can use them on their dashboards

• Most of the discrepancies are

  • Due to bugs on the Dashboard side (there are still some calculations) or on the Product side. We fix these ASAP.

  • Due to some lagging metrics/different view on data—as we know about these, we are fine with them.

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?

Q: I am working in a SaaS company that has an ARR of $50M and is largely focused on enterprise deals now. I have noticed the PM team, including me, are not building business cases for product decisions/tradeoffs.

To elaborate, we do not look at cost drivers or do not anticipate delta positive revenue for an initiative. It probably is the case that we are in the acquisition mode so we are not keeping a close eye on profitability, but I want to develop that bone; I want to know how folks involve financial metrics in product decisions.

It is also quite difficult for some squads (particularly the service squads) to attribute revenue uptick due to their work, and I am looking for ways to quantify that). Example: Think of a squad responsible for dashboards across the product (this is not a core feature but essential for customers to have).

Can you share your views and experiences, please? ↗️

—Faheem

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

Q: I posted here a little while ago and wanted to follow up with a part 2. Some quick context from the last post: I joined a new org about a month ago as a PM. So far I’ve been helping out with QA, some design work, and general support tasks—but not much core product work yet. It’s left me feeling some impostor syndrome and like I haven’t really had the chance to contribute in a way that reflects why I was hired.

What’s been especially tough is getting the full context of what’s happening across the company. I’ve been trying to piece things together from 1:1s and async convos but haven’t had much access to internal meetings or customer calls—so identifying problems to solve has felt more like guesswork than insight. I’ve asked a few times to be included in more of those convos but haven’t had much traction yet.

I also recently heard (unofficially) that the CEO isn’t quite sure about my fit here, since he hasn’t seen tangible results yet. I had a productive call with the CTO today where we aligned on a few areas I could work on to show more value and lasting impact, which was helpful and appreciated.

So my question is: when you’re early in a company, not plugged into key meetings, and lacking context—how do you find the right problems to solve? How do you create clarity and momentum in the absence of structure?

Any thoughts or advice would mean a lot—really want to turn the corner here and show up strong. ↗️

—Jeff Chow

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:

1. Find things your management sees as valuable and do them. Or ask yourself—why were you hired?

2. Try to include some PM “best practices” you see fit into the game, e.g. engineers are usually not fans of doing (outcome-based) roadmaps, but if you see the point of having better roadmaps there, you can push it as your agenda.

3. I know nothing about you or the company, so please take this with a grain of a salt—there is really the possibility you are not the right fit in the position. The first PM has a tough position, as they have to set up the expectations for everyone, set up the processes and have the trust of the management. I do not want to discourage you from trying to do it right, just do not forget about what is best for you and your career.

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

1. The hidden time bomb in the tax code that’s fueling mass tech layoffs via Dimitris K

2. Creating Intelligent Products via Kevin Holland

3. The state of B2B monetization in 2025 via Anuj Adhiya

4. The last six months in LLMs, illustrated by pelicans on bicycles via Rishi

5. Taste via Nidhi Wadmark

😂 Meme of the week

Have a fulfilling and productive week 🙏

If anyone in your life would benefit from this newsletter or community, consider giving them a​ ​g​i​f​t subscription 💞 There are group discounts, gift options, and referral bonuses available.

Give a gift subscription

Sincerely,

Kiyani 👋