What would you produce in each role?
Atlassian distinguishes the product manager's choices about the product from the systems, data and processes maintained by product operations. Teams can divide that work differently. Neither title means an intern independently controls the roadmap.
| Role | Question | Possible output |
|---|---|---|
| Product operations | Can the team reliably find and compare the evidence? | A traceable feedback view with clear definitions and a review process |
| Product management | Which problem is worth investigating or solving? | A problem definition, alternatives and a recommendation |
A useful question for the manager is: ‘Would I mainly investigate a customer problem and recommend a change, or improve a process used across several product decisions?’ Ask for a past or proposed intern assignment.
Eighty messages are not eighty customer votes
Imagine 80 fictional feedback messages from 12 customer organizations. One organization sent 40 of them. Counting messages as independent customer votes would give that one organization half the apparent demand.
Group by organization when comparing how many customers are affected, but preserve the messages: repeated reports can still reveal persistent friction. Also separate a requested feature from the underlying task. An export request might be about an audit trail, a missing report or moving data elsewhere. Those problems may need different solutions.
Example: investigate the blocked workflow before counting feature requests
Suppose the 12 organizations divide into the groups below. Exports affect the most organizations, but most have a workable alternative. Three organizations requesting permissions cannot complete a required task.
| Request group | Organizations | What is known |
|---|---|---|
| Exports | 6 | 5 already have an acceptable workaround |
| Permissions | 4 | 3 cannot complete a required workflow |
| Mobile access | 2 | A convenience improvement, not a blocked task |
Investigating those three blocked organizations is a reasonable next step. It is not yet a decision to build a permissions feature: the common cause, implementation cost and importance to other customers remain unknown.
The product-operations deliverable is the evidence table and a reliable way to maintain it. The product-management deliverable is the proposed investigation and what would change the recommendation.
A process should resolve an actual failure point
For a permissions release, a useful launch check might confirm that existing users retain the access they need, support can explain the new behavior and an authorized owner can stop a faulty rollout. ‘Support informed’ is not enough without the information support needs.
Keep the work proportional. A wording correction does not need the same review as a permissions migration. In a product-operations sample, explain which step you removed or clarified and which failure the remaining checks prevent. Do not claim a percentage time saving unless you measured it.
Prepare two outputs and see which work suits you
Create a small synthetic feedback file with organization IDs, messages, problems, workarounds and evidence dates. Produce the traceable product-operations view, then write a short product-management recommendation based on it.
In an interview, explain why you did not treat one organization's 40 messages as 40 customers, and what the repeated messages still tell you. Ask who would use your internship output and review it. Describe the work as analysis or a recommendation unless you actually implemented a change.