I think Business Acumen is the skill that helps Product Managers avoid getting stuck in “building features”
There is a situation I find very common when first learning about Product Management: a group discussing products, engineers talking about API and performance, designers discussing user experience, sales mentioning a customer demanding a feature urgently, while the leaders ask: “How does this feature contribute to the business goals this quarter?” If they only hear the part “what the customer wants” and don’t understand “what the business needs”, a Product Manager can easily become someone who just documents requirements and forwards them to the tech team.
After learning from the sharing of Product Managers and experts in videos, I've realized that business acumen is not about talking finance in a “cool” way. For me, business acumen is the ability to connect three things: customer needs, product capabilities, and business outcomes. A PM with business mindset needs to understand how the company makes money, what really pains the customers, how the market is shifting, and why one task should be prioritized over another.
This is especially important for those exploring AI PM or Product Management in general. Because products, especially technology and AI products, can easily get caught up in flashy demos, new models, or smart features. But eventually, the product must still answer: who uses it, for what purpose, is it worth paying for, and does it help the business stay on track?
1. Understand the business before talking about the roadmap
The first point I deduced is that Product Managers need to understand the business's needs and know which work should be prioritized to serve those needs. It sounds obvious, but in reality, it’s not simple. In a company, each department might speak in a different “language”: leadership talks about strategy, finance about costs and profit, marketing about positioning and segmentation, sales about revenue, while engineering speaks of architecture and stability.
A PM with business acumen doesn’t have to be an expert in all these fields but needs to understand enough not to get lost in meetings. More importantly, PM should know how to translate business language into product decisions. For instance, if the leadership says the company wants to increase enterprise customer retention, a PM shouldn’t just note down “need to increase retention.” The task is to ask questions: at what stage do customers leave, due to lack of features, difficult onboarding, or unclear product value? From there, prioritize actions like improving usage reports, adding automatic alerts, optimizing the onboarding flow, or supporting better integration.
The video mentioned SMART: specific, measurable, achievable, relevant, timely. I find the word “relevant” very noteworthy. A feature may be cool, doable, even liked by users, but if it’s not related to the mission, vision, and current goals of the organization, it might not be worth doing immediately. An imaginary example: if a language learning app is focused on increasing the number of paid learners, adding fun 3D avatars might be interesting but not as “relevant” as improving the initial competency test or personalizing the learning path.
PMs also need to understand the organization's strategic portfolio or the set of key initiatives to be achieved. Without understanding the portfolio, PMs can easily optimize locally for their product and deviate from the bigger picture. Practical advice for newcomers like me is: when reading a roadmap, don’t just ask “what features are coming?”, also ask “what are the business goals behind each feature group?” and “which strategic initiative of the company does it align with?”
2. Customers are not just “users,” but part of a specific business context
One idea I really liked in the sharing was that Product Managers should have experience or at least the mindset to work directly with customers. Not to cater to every request, but to understand the environment in which customers operate. Customer needs do not just exist in an empty ticket; they are influenced by industry, processes, regulations, culture, internal policies, and even geography.
An example in the video is very clear: working with a government agency is drastically different from working with a small business in your city, and also from a financial institution. For government agencies, the procurement process can be lengthy, with strict security and compliance requirements, and need comprehensive documentation. For SMBs, they might need quick deployment, understandable pricing, and less complex configurations. For financial companies, reliability, audit logs, access control, and compliance could be critical factors. The same “export report” feature could mean entirely different business implications for different customer groups.
Here, empathy is a core skill. But empathy is not just “caring for the customer” or “listening politely”. As I understand it, empathy in Product Management is the ability to delve into the customer’s operating logic: why they operate in a certain way, why they are constrained, why they ask for a certain feature, and what the business consequences are without that feature. The question “why” becomes a powerful tool.
An imaginary example: a customer requests a “download all data to Excel” button. If the PM only listens superficially, the team may rush to create an export function. However, asking “why do you need to export to Excel?” might reveal they need to reconcile numbers between two systems at the end of the month. In that case, a better solution could be direct integration, reconciliation dashboards, or data discrepancy alerts, not just an export button.
However, a mild counterpoint to keep in mind: it’s not that whatever customers say should be done. Customers often describe solutions they think of, but the PM needs to find the real problem. Newcomers can practice by, after each case study reading or hypothetical interview, writing down three lines: what the customer said they want, what the root issue might be, and what the business impact would be if resolved.
3. Business acumen demands recognizing market, value, and monetization
A PM needs to understand not just the functional and non-functional requirements of a product. Functional requirements are what the product can do, like login, search, report creation. Non-functional requirements are how well the product performs, like security, performance, scalability, reliability. But stopping there means the PM only understands “what to build” and not necessarily “why this is worth building in the current market.”
Therefore, PMs must recognize competitive context and market trends. If competitors are shifting to a self-service model, if customers increasingly expect AI integration, if the market is more sensitive to data privacy, then the roadmap cannot remain static. Competitive analysis is not about copying competitors, but understanding what choices customers have and where your product differentiates.
There is a concept here called product instinct. I understand it as a relatively sharp sense of what has value to customers, what attracts them, and what they are willing to pay for. But this “instinct” shouldn’t be mythologized. For beginners, product instinct can be honed by observing real products: why I pay for this app but not that one, why a feature keeps me coming back daily, why a pricing package makes sense to me.
A very practical part of business acumen is understanding pricing and licensing. In technology, on-premise and SaaS models have different pricing logic. On-premise often involves setups at the customer's infrastructure, licensing, maintenance, deployment, long-term support. SaaS typically charges by subscription, user count, usage levels, feature packages, or data scale. If a PM doesn’t understand pricing, it’s easy to design a cost-heavy feature with no way to recover its value.
An imagined example: an AI product adds a feature for automatic document analysis. If each analysis run incurs high model cost, PMs need to think about usage limits, premium packages, or ways to optimize processing costs. If not, the more users, the more the company loses. This is where business acumen links with technical acumen: understanding the technology enough to know operating costs, understanding business enough to know how to package value.
Strategic planning is also an important skill. PMs need to know how to create short-term and long-term roadmaps: what issue to solve this quarter, what capability to expand in the next six months, what position the product aims to occupy in the market a year from now. Simple advice for beginners is when looking at a feature, try placing it into three time frames: what is the immediate impact, what does it pave way for next, and if not done, what future risks loom?
4. Data, finance, and stakeholders: the “tricky” part but unavoidable
One point that somewhat surprised me was that business acumen is not just about market intuition or customer talks. PMs need to know how to read data, interpret reports, and understand basic financial metrics. Data can come from user research, including qualitative like interviews, observations, open feedback; or quantitative like conversion rate, retention, churn, usage time, feature activation count. There are also business KPIs, financial reports, and other internal documents.
The key is not to turn PMs into data scientists or accountants. I believe the needed skill is knowing what the data suggests and asking the right questions. For example, if a dashboard shows many signups but low returns after the first week, a PM should ask: do they not see the value, is onboarding too long, is the main feature hard to find, or are marketing expectations misaligned? If financial reports show rising support costs, a PM should ask: is the product too hard to use, is documentation lacking, or do new customer segments need different support?
PMs also need to communicate with senior management, executives, and VPs. This isn’t about “talking fancy”, but the ability to present product decisions in business language. With the tech team, PMs can talk about requirements, trade-offs, backlog. With leaders, PMs need to clearly convey impacts on revenue, growth, customer retention, costs, risks, and strategic priorities. Then, PMs must translate those business expectations back into technical requirements, prioritization criteria, and specific tasks for the product team.
Stakeholders are also a crucial part. A point emphasized in the video is that PMs need to understand which stakeholders will collaborate to turn product ideas into success. Stakeholders could be sales, marketing, customer success, legal, finance, engineering, design, data, support, or leadership. If PMs don’t know who influences, who provides information, who implements, who bears risk, a product can fail not because of a bad idea, but due to poor coordination.
Finance is perhaps the aspect most newcomers, including myself, are most hesitant about. But concepts like internal rate of return, net present value, return on investment, and payback aren’t just for making financial reports look good. They help PMs evaluate whether a product investment is worthwhile, how quickly it recoups costs, and whether future benefits are significant enough compared to current costs. An imagined example: if an automation feature helps reduce 500 support hours monthly, a PM should know how to estimate development costs, operating costs, savings, payback period, and impact on customer experience.
The counter-argument here is: “Does a PM need to be so proficient in finance as to calculate everything?” I think not. A PM doesn’t need to replace the finance team. But a PM should understand enough to participate in discussions, know when to ask experts, and not make product decisions entirely based on intuition. A practical way to learn is to pick a familiar product, try writing a simple hypothesis: where does the company make money from, what are the main costs, which metrics demonstrate the product’s health, and which new features could improve those metrics.
5. For AI PMs, business acumen helps avoid “fascinating technology but forgetting value”
Applying these concepts to AI PM, I find business acumen even more crucial. AI can easily create an impressive vibe: smooth chatbot responses, fast classification models, and smart-sounding suggestions. But a PM with a business mindset will ask further: which business problem does this AI feature solve, do customers trust the results, what are the consequences of mistakes, is the inference cost sustainable, is the data secure enough, and are customers willing to pay for that level of value?
An imagined example: a recruitment platform wants to add AI for scoring CVs. Technically, it can be built. But business acumen forces a PM to look wider: does the recruiter need to save time or improve candidate quality? Are candidates being evaluated unfairly? Is there a competitor doing this better in the market? In which price package should this feature belong? Are KPIs the number of CVs processed, reduced hiring time, or increased correct hire rate? By merely saying “add AI scoring”, the product might shine during a demo but flounder during real deployment.
I believe the maturity of a PM is not in always having immediate answers. It lies in asking the right questions amidst many pressures: customers want it fast, sales want deals closed, engineering wants a clean solution, leadership wants growth, finance wants cost control. Business acumen helps PMs avoid being completely swayed to one side.
If you're also self-learning like me, you can start very small. When reading an article about a product, ask yourself: what segment does this product serve, why do customers pay for its value, how can the company measure success with metrics, who are the replacement competitors, and if I were the PM, what would I prioritize next quarter? Doing this exercise regularly, I believe the ability to “think like a PM” will become much clearer than merely learning framework names.
Conclusion: A good PM doesn’t just ask “what to do”, but “why it’s worth doing”
What I realized after this learning part is that business acumen is not an auxiliary skill but an integral layer of Product Management. It’s the mindset that helps PMs connect disparate elements: company strategy, mission, and vision.
Top comments (0)