Product managers are often told to understand a business quickly. Industry research, competitor analysis and collecting requests are not enough.
The deeper question is:
How can we make reasonably sound product decisions with incomplete information, unfamiliar businesses, limited resources and many requests?
Core skills go beyond prototypes, PRDs and prioritization:
- Understand how a domain operates.
- Identify worthwhile problems.
- Judge whose needs matter most.
- Decide what to do now and what not to do.
- Keep correcting judgement under uncertainty.
Understanding workflows quickly means building a product decision framework.
Understand the business before the features
Starting with “Which features?”, “What should the page look like?” or “What do competitors offer?” easily leads astray.
Start instead with how the business earns money, who creates value for whom, how that value is delivered, which steps determine success and where friction occurs. Look at the value stream before the feature list.
| Question | Purpose |
|---|---|
| Who are the customers? | Identify whom we serve |
| Why do they pay? | Identify core value |
| How is that value delivered? | Understand the main process |
| Which steps affect revenue, costs, efficiency or experience most? | Find key constraints |
| What is the largest uncertainty? | Find a product entry point |
Ultimately, explain in one sentence how the business solves which problem for which people and where its return comes from. Without this, later requirement decisions lack grounding.
Move from what users say to why they say it
An ordinary product manager collects requests; a good one identifies their motivation.
When a user asks for export, ask why, who receives the output, how often it happens, how it works today, what happens without it, whether they need the file or the data, and whether the next action could happen inside the system.
Users commonly express solutions rather than needs. “Export to Excel” could mean reporting to a manager, sending client reports, further processing, keeping a trusted backup, overcoming permissions or connecting another workflow. Each motivation suggests a different solution.
| Level | Example | Product work |
|---|---|---|
| Stated request | Export to Excel | Do not rush to implement |
| Actual task | Send a weekly client report | Understand the situation |
| Underlying motivation | Reduce reporting effort and errors | Assess actual value |
Good product work understands why the request exists instead of fulfilling every statement literally.
Assess real needs through costs, not enthusiasm
Strong verbal interest does not prove a need. A quiet daily workaround may be better evidence.
| Cost | Evidence to examine |
|---|---|
| Time | Substantial recurring effort |
| Money | Payment for an alternative |
| Opportunity | Lost sales, retention or growth |
| Organization | Repeated explanation, rework, disputes or dependence on individuals |
Without a cost, a problem is rarely a strong need. Problems users already solve inefficiently are more real than imagined requests.
Evidence includes manually maintained spreadsheets, recurring copy-and-paste reports, dedicated coordinators, makeshift paid tools, lost customers, financial losses and delayed delivery.
Prioritize more than importance
Many needs look important. Also ask whether now is the right time.
| Type | Characteristics | Approach |
|---|---|---|
| High value, high certainty | Clear pain and benefit | Prioritize |
| High value, low certainty | Potentially large, unvalidated | Run a small experiment |
| Low value, high certainty | Useful but limited return | Schedule later |
| Low value, low certainty | Optional and unclear | Do not do it |
A valuable skill is saying a requirement is worthwhile but should not be done now. Product work means choosing what matters most at the current stage, not completing every reasonable idea.
Judge a product opportunity through three questions
An opportunity depends on whether the problem is real, the market is large enough and the solution is effective—not merely whether it can be built.
| Dimension | Question |
|---|---|
| User | Who clearly needs it? |
| Situation | Where specifically will it be used? |
| Pain | What is lost if it remains unsolved? |
| Frequency | How often does it occur? |
| Value | What benefit does solving it create? |
| Payment | Who pays, and why? |
| Alternative | How is it solved today? |
| Difference | Why can this solution be better? |
| Distribution | How will users be reached? |
| Retention | Why will they keep using it? |
If more than half are unclear, the product is probably still an idea rather than a mature opportunity.
Separate must, should, could and should-not requirements
| Type | Criterion | Examples |
|---|---|---|
| Must | The core process cannot operate without it | Login, payment, orders, delivery |
| Should | Clearly improves a core metric | Conversion, retention, reduced manual effort |
| Could | Improves experience without changing core value | Themes, preferences, shortcuts |
| Should not | Expensive, unclear or off-track | Executive inspiration, competitor noise, showpiece features |
Must-have work usually belongs to the core feedback loop. In recruiting:
Employer posts a role -> candidate sees it -> applies -> screening -> interview -> offer
Early work should make that loop operate before adding communities, points, AI avatars or complex reports.
Product judgement grows from constraints
Good product managers choose within constraints: actual user needs, the current business model, team capabilities, available data, time, competition and the stage's most important metric.
The question is not simply whether a feature has value, but whether it is the best investment under current goals and resources.
The same request can deserve different answers at different stages. Early products validate core value; growing products improve conversion and retention; mature products improve efficiency, reliability and monetization; declining products control costs or seek a new direction.
A useful order of thinking
- Business: how does it create value?
- Users: who faces which problem in which situation?
- Costs: what real losses does the problem cause?
- Goals: what matters most at this stage?
- Solutions: what is the cheapest useful validation?
- Priorities: what happens now, later or never?
- Outcomes: do data and feedback support the judgement after launch?
This is the product feedback loop. It does not guarantee permanently correct decisions; it gives us a way to improve them.
A final thought
What needs practice is a complete judgement process, not merely researching an industry quickly:
Find value streams in the business, real tasks behind requests, costs in those tasks, priorities from those costs and a minimum complete workflow from those priorities; then use outcomes to correct judgement.
That distinguishes product judgement from recording requirements. Ordinary product managers receive requests; good ones assess them.
Thanks for reading.