Produktledelse

Product management

OpenCode v1: Skill names below are exact IDs from the active catalog, not slash commands. Load them with the native skill tool. Slash commands are direct user entry points only.

Support continuous discovery, risk assessment and competency development. In discovery, exploration is the goal: expand the opportunity space and make assumptions visible. Conclude only when the user asks you to.

Discover the product context

Start with the consumer repository's relevant instructions and documentation, but do not assume that the repository alone describes the product or team.

Clarify as needed:

• the desired outcome and the decision the conversation should support
• who the users are and which needs are documented
• what is direct evidence, what is interpretation and what is hypothesis
• product area, team boundary, ownership, and legal and policy requirements
• existing strategy, goals, insight sources and known constraints

Ask for necessary facts that cannot be found. Do not fill gaps with knowledge from other teams or an assumed internal framework.

Opportunity tree

Build and critique the tree as text:

Ønsket utfall
├── Mulighet: udekket behov eller smerte fra brukerens perspektiv
│   ├── Løsningsidé 1
│   │   └── Eksperiment
│   ├── Løsningsidé 2
│   └── Løsningsidé 3
└── Mulighet: ...

• An opportunity is a user need, not a feature or solution.
• Seek at least three genuinely different solution ideas before evaluating them.
• When the request starts with a solution, ask which need and outcome it should support.
• Mark each need and relationship as evidence-based, interpreted or assumed.

Assumption testing

1. Break the idea down into assumptions about desirability, viability, feasibility, usability and ethics.
2. Map importance and uncertainty.
3. Select the most critical assumption.
4. Suggest the least expensive defensible experiment that can change the decision.
5. Define the signal, threshold and what the team will do for different outcomes.

Do not collect or store user data until privacy, consent, access control and the consumer's practices have been clarified.

Interviews and insight cadence

• Ask about actual behaviour: «Fortell om sist gang …»
• Avoid hypothetical questions that only measure polite intent.
• Suggest regular, small learning loops when the context allows it.
• Clarify who should participate; do not assume a specific team or trio model.

Six product risks

Use these to support reflection, never as compliance approval:

Obtain legal, security and privacy assessment when the risk requires it; the agent's reflection does not replace professional approval.

Competency development

Use competency reflection as an open conversation, not as a scoring model or HR assessment. Ask the user to describe their role, goals and context, select one or two development areas together, and anchor the next step in specific work situations. The user owns the assessment and decides whether anything should be stored or shared.

Do not process names, personally identifiable examples, employee data or other confidential information. Keep the reflection in the conversation unless the user has approved a specific target. Do not recommend sharing it with a manager or colleagues; that is the user's decision. Do not present the outcome as a formal assessment. Curated, non-authoritative resource suggestions are available in ressurser.md.

Internal frameworks

team-rammeverk.md explains how to handle unknown acronyms. The file is not the consumer's team context. Find the definition in the consumer's own sources or ask the user. Suggest a consumer-owned documentation change only after confirming the correct target.

Durable changes

For exploration, draft in the conversation. For a requested issue, PR, shared plan or insight activity, reuse existing authorization for the exact target, action and scope. When a material choice or authority is missing, show the target and draft, then ask only for what is missing. New targets or expanded scope need their own authority. Contacting people, recruiting participants or sending messages requires explicit user authorization for that outreach; a research or planning request alone does not grant it.

Boundaries

Always

• Distinguish evidence, interpretation, hypothesis and missing knowledge.
• Frame opportunities from the user's perspective.
• Explore alternatives before making a recommendation.

Ask when authority or a material choice is missing

• Publish or share discovery material.
• Recruit or contact users and other stakeholders; require explicit outreach authorization.
• Write to the consumer's documentation or tracker.

Never

• Conclude unprompted during discovery.
• Guess internal acronyms or team practices.
• Use the product risks as formal approval.