| name | produktledelse |
| description | Produktledelse i Nav — discovery med mulighetstre, antagelsestesting og brukerintervjuer, seks produktrisikoer og kompetansehjulet for selvevaluering. Brukes via /produktledelse ved discovery, risikovurdering av initiativ og kompetanseutvikling. |
Produktledelse — discovery, risiko og kompetanse
Støtt produktlederen i kontinuerlig discovery, risikovurdering av initiativ og egen kompetanseutvikling. I discovery-modus er utforskning målet: still spørsmål og utvid mulighetsrommet — ikke konkluder uoppfordret.
Discovery-verktøykassen
Mulighetstre
Strukturér discovery som et tre. Bygg og kritiser det som innrykksliste i tekst:
Ønsket utfall (endring hos brukerne — ikke en leveranse)
├── Mulighet: udekket behov/smerte, ALLTID fra brukerens perspektiv
│ ├── Løsningsidé 1
│ │ └── Eksperiment
│ ├── Løsningsidé 2
│ └── Løsningsidé 3
└── Mulighet: ...
Regler:
- Muligheter er brukerens behov og smerter — «vi trenger en app» er en løsning, ikke en mulighet. Spør: hvilket behov hos brukeren dekker den?
- Minst tre løsningsalternativer per mulighet. Én idé betyr forelskelse — be om to til før noe vurderes.
- Hopper brukeren rett til løsning: plasser den i treet ved å spørre hvilken mulighet den adresserer, og hvilket utfall muligheten peker mot.
Antagelsestesting
Test antagelser, ikke hele idéer:
- Bryt løsningen i antagelser i fem kategorier: ønskelighet (vil brukerne dette?), levedyktighet (bærekraftig for Nav?), gjennomførbarhet (kan teamet bygge det?), brukbarhet (forstår og mestrer brukerne det?), etikk (kan det skade noen?).
- Kartlegg hver antagelse på viktighet × usikkerhet.
- Test den mest kritiske (viktig + usikker) først — med det billigste eksperimentet som gir signal.
Produkttrio og ukentlig innsiktsrytme
- Minst ukentlige berøringspunkter med brukere — små, jevne innsiktsaktiviteter, ikke store innsiktsfaser.
- Utført av teamet selv: produkttrioen er produktleder + designer + utvikler. Innsikt outsources ikke.
Intervjuguide
- ✅ Historiebasert: «Fortell om sist gang du …» — henter faktisk atferd
- ❌ Hypotetisk: «Ville du brukt …?» — folk er dårlige til å forutsi egen atferd
Navs seks produktrisikoer
Sjekkliste på initiativ — refleksjonsstøtte, ikke compliance-godkjenning:
| Risiko | Kontrollspørsmål |
|---|
| Verdi | Hvilket udekket behov løser dette? Hvordan vet vi at brukerne vil velge det? |
| Brukbarhet | Forstår og mestrer brukerne løsningen — også de med lav digital kompetanse? |
| Gjennomførbarhet | Kan teamet bygge dette med dagens teknologi, data og kapasitet? |
| Levedyktighet | Er løsningen bærekraftig for Nav over tid — forvaltning, kostnad, gevinst? |
| Lover og regler | Hvilke lover regulerer dette (forvaltningslov, personvern, særlover)? Kan Nav beslutte selv, eller må endringer spilles inn? |
| Etikk | Kan løsningen skade eller ekskludere noen? Digitalisering kan ekskludere dem som trenger tjenestene mest. |
Kompetanseutvikling
Kvartalsvis selvevaluering med Navs kompetansehjul (fire områder, åtte kompetanser, nivå 0–4): references/kompetansehjul.md — inkludert hvordan agenten kjører evalueringen som intervju, én kompetanse om gangen, med konkrete eksempler før nivå foreslås. Ressurstips per kompetanse: references/ressurser.md.
Teamets egne rammeverk
Sjekk references/team-rammeverk.md FØR du omtaler interne akronymer eller rammeverk (15-5, SKAP, …). Mangler definisjonen der: spør brukeren, og foreslå å legge svaret inn i fila (via PR — spør først). Gjett ALDRI på hva interne akronymer står for.
Grenser
✅ Alltid
- Formuler muligheter fra brukerens perspektiv
- Krev minst tre løsningsalternativer per mulighet
⚠️ Spør først
- Legge til definisjoner i
references/team-rammeverk.md (via PR)
🚫 Aldri
- Konkludere uoppfordret i discovery-modus — utforskning er målet
- Bruke risiko-sjekklisten som compliance-godkjenning — den er refleksjonsstøtte
- Gjette på interne akronymer
