Product owner sollicitatie en management skills presenteren

[Furion2000]

Software engineer en wannabe ondernemer die tot de tijd aanbreekt dat er echt iets van de grond komt freelance/vaste dienst werk blijft doen. Laatste 2 jaar eigenlijk als PO/Engineer/Architect/Alles 2 projecten gedaan voor MKB en 1x officieus bij een overheidsinstelling. Goed onderlegd in SAFe(Agile)/Scrum/DevOps.

Op gesprek komen met minder ervaring lukt op dit moment wel - dus ik twijfel niet aan mijn verhaal op papier. Ik merk tijdens de gesprekken ook zeker dat ik op persoonlijk vlak de gunfactor heb en dat ze aan mijn technische skills niet twijfelen. Ik merk alleen van mijzelf dat ik relevante PO voorbeelden in mijn werk te praktisch omschrijf. Als in "als ik iets nodig heb en niet weet ga ik op zoek naar de persoon die het wel weet" en "data gedreven keuzes maak ik meestal op basis van metrics vanuit het team en bij stakeholders praat ik gewoon met ze en vraag ik door over onderduidelijkheden" - erg "dat doet ik gewoon vibes en dan ook nog af en toe met een Brabants accent". Daarnaast natuurlijk wat teveel woorden omdat ik mij probeer te bewijzen met relatief weinig ervaring.

Hebben mensen adviezen hierin? Ik heb het idee dat er wel tips en tricks zijn om hetzelfde te zeggen maar dan meer die strategische woordkeuze (ik noem maar iets). Ik wil daarnaast ook gewoon mezelf blijven en ben ook die no-nonsense gast die zegt wat er gezegd moet worden, maar weet ook dat dat in sollicitatie gesprekken net even wat 'minder' moet.

[Emgeebee]

Ik zou je rol als PO wat breder inzetten dan enkel stakeholder management en weten wie je moet hebben.

Dingen als:
- Focus is heel belangrijk voor een ontwikkelteam, agile betekent niet dat je bij elke verandering meteen van koers wijzigt. Ik wil als PO graag epics afmaken en opleveren
- Business cases vanuit de stakeholders en metrics vanuit het team maken het mij als PO mogelijk om weloverwogen beslissingen te nemen
- Het is heel belangrijk dat de MVP / Definition of Done bekend is bij alle stakeholders om verwachtingen, rework en deadlines te managen

Als je nadenkt over je rol als PO en vooral wat de organisatie kan verwachten van jou als PO, dan laat dat zien dat je in control bent. Daar zijn de meeste managers naar op zoek.

[epicfailguy23]

Ik zou als ik jou was 'gewoon' mezelf blijven. Als je met een solicitatie moeit hebt met de managers bullshitbingo jargon, dan is dit straks ook als je aan de functie begonnen bent, echter moet je dan constant een toneelstukje spelen om je werk te doen, wat erg vermoeiend is..

Dus je kunt beter een bedrijf/functie zoeken die nu bij je past zonder constant op te moeten letten op je woorden/'Brabantse vibes'.. Daarmee krijg je vanzelf ervaring om het goed te leren en de ervaring opbouwen.

Daarnaast kun je inderdaad beter aangeven hoe jij het bedrijf gaat versterken. dan te vertellend dat je werk bij andere neerlegt. "iets met PM's die wij hier als dozenschuivers zien en alleen er maar voor zijn om die meeting in te plannen dat ook een email had kunnen zijn".

Als je gaat overcompenseren omdat je vind dat je de ervaring niet hebt, daar prikt een bedrijf meteen doorheen. dus hou het lekker simpel. Als je veel woorden wilt gebruiken en niets wilt zeggen moet je naar Den Haag gaan

[Furion2000]

@Emgeebee @epicfailguy23

Eigenlijk dus een concrete visie hebben is wat jullie zeggen (waar ik vooral van mening ben kijken wat het team nodig heeft en incrementeel verbeteren maar dat is niet veelzeggend realiseer ik mij nu). Relevant punt denk ik en zie dat wel beter overtuigen ja

[Emgeebee]

Furion2000 schreef op donderdag 26 februari 2026 @ 10:24:
@Emgeebee @epicfailguy23

Eigenlijk dus een concrete visie hebben is wat jullie zeggen (waar ik vooral van mening ben kijken wat het team nodig heeft en incrementeel verbeteren maar dat is niet veelzeggend realiseer ik mij nu). Relevant punt denk ik en zie dat wel beter overtuigen ja

Dat is meer de rol van een scrum master die je nu beschrijft. Verdiep je nog even goed in de rollen zou ik zeggen.

[epicfailguy23]

Furion2000 schreef op donderdag 26 februari 2026 @ 10:24:
@Emgeebee @epicfailguy23

Eigenlijk dus een concrete visie hebben is wat jullie zeggen (waar ik vooral van mening ben kijken wat het team nodig heeft en incrementeel verbeteren maar dat is niet veelzeggend realiseer ik mij nu). Relevant punt denk ik en zie dat wel beter overtuigen ja

Het is inderdaad niet veel zeggend, ik heb weer 2 stempels op de bingo kaart
Je kan zoiets zeggen, maarrrr... vul dan ook meteen aan HOE je dit wilt gaan doen. Dit kan zijn: uit wekelijkse meetings pijnpunten halen en uitzoeken waar deze vandaan komen (wil niet zeggen dat je ze kunt oplossen) maar wellicht kun je dit meer stroomlijnen of een workaround vinden: --> vul dit aan met een voorbeeld van wat het probleem uitdaging was en hoe je dit hebt aangepakt. reflecteer ook wat de aanpassingen waren en hoe dit uitpakte (hoeft niet altijd goed te gaan, maar dat je weet dat iets niet werkt is ook een goede indicatie (dan doe je het in de toekomst hopelijk niet meer ))

Dus zeggen is een ding, maar onderbouw het ook met je eigen ervaring en voorbeelden. blijf weg van de 'hoog over bullshit tenzij je solliciteer op een RvC functie

maar dat is mijn 2cents.

[Skamba]

Als je goed onderlegd bent in SAFe, laat dat dan ook uit je antwoorden blijken. Op basis van je antwoorden klinkt het alsof je heel erg ad-hoc reageert, in plaats van dat je structuur aanbrengt in hoe je je stakeholders en het team managet.

[naitsoezn]

Furion2000 schreef op donderdag 26 februari 2026 @ 09:56:
Ik merk alleen van mijzelf dat ik relevante PO voorbeelden in mijn werk te praktisch omschrijf. Als in "als ik iets nodig heb en niet weet ga ik op zoek naar de persoon die het wel weet" en "data gedreven keuzes maak ik meestal op basis van metrics vanuit het team en bij stakeholders praat ik gewoon met ze en vraag ik door over onderduidelijkheden" - erg "dat doet ik gewoon vibes en dan ook nog af en toe met een Brabants accent". Daarnaast natuurlijk wat teveel woorden omdat ik mij probeer te bewijzen met relatief weinig ervaring.

Om uit de "dat doe ik gewoon"-vibe te komen werkt het altijd heel goed om een concreet voorbeeld te benoemen uit de praktijk. Hoe ben jij de laatste keer op zoek gegaan naar de persoon die het wel weet. En welke metric vanuit het team hebben jou geholpen om wat voor data-gedreven beslissing te nemen? Of welke onduidelijkheden heb je boven tafel gehaald in je gesprekken met stakeholders en hoe wist je dat je die details nodig had?

Wees vooral niet te bang om details te geven over de voorbeelden, maar let natuurlijk wel op de vertrouwelijkheid van je opdrachten (niet alle technische details geven, maar je kunt vaak echt wel wat details geven in de manier van aanpak).

[Furion2000]

Skamba schreef op donderdag 26 februari 2026 @ 10:43:
Als je goed onderlegd bent in SAFe, laat dat dan ook uit je antwoorden blijken. Op basis van je antwoorden klinkt het alsof je heel erg ad-hoc reageert, in plaats van dat je structuur aanbrengt in hoe je je stakeholders en het team managet.

Ad-hoc klopt enigszins wel en ook in positieve zin heeft mij dat nou juist geholpen. Goed om te horen dat dat nu ook zo overkomt, dat bevestigd ook mijn vermoeden

@rest lees dat 'hoe' erg veel terugkomen. Ik besef dat ik mijn voorbeelden wat verder mag verduidelijken en koppelen aan de juiste terminologie in Agile/Scrum. Ik weet het allemaal wel, maar in een gesprek lijk ik redelijk terug te vallen op TE technische termen of 'gewoon' (overdreven natuurlijk) omdat het al zo standaard aanvoelt

[Skamba]

Furion2000 schreef op donderdag 26 februari 2026 @ 11:22:
[...]


Ad-hoc klopt enigszins wel en ook in positieve zin heeft mij dat nou juist geholpen. Goed om te horen dat dat nu ook zo overkomt, dat bevestigd ook mijn vermoeden

Ad-hoc zou altijd je fallback moeten zijn; en dat zou ook uit je gesprek moeten blijken.

Een voorbeeld van hoe ik zou verwachten dat je typische PO vragen beantwoordt, als voorbeeld:

V: "Hoe ga je om met stakeholders die met spoed-verzoeken komen tijdens een sprint?"
A: "Normaal gesproken probeer ik dat te te ondervangen door in de refinement voor te lopen op de input van de stakeholders, om deze te vertalen naar onze user stories. Daarvoor heb ik de nodige kennis en ervaring. Naar mate je je stakeholders beter kent, kun je beter inschatten wat er speelt en weet je een werkwijze te vinden die voor iedereen goed werkt.

Als de nood aan de man is, probeer ik natuurlijk een zo pragmatisch mogelijke oplossing te vinden voor problemen."

Als je meteen springt naar hoe je de uitzonderingen managet, geef je het beeld dat je niet goed bent in structuur aanbrengen.

[De Cheetah]

Even heel bot gezegd maar daar prik je als mede Brabander zo doorheen: als je praat zoals je schrijft snap ik je probleem wel. Ik lees heel veel enthousiasme, maar ook een wirwar aan braindump meets ‘terwijl ik begin te praten/schrijven verlies ik de rode draad uit het oog’.

Een boodschap overtuigend brengen is pretty much het tegenovergestelde. Probeer daar wat skills te ontwikkelen. 1 tool/ principe dat ik daarin ken is ‘the pyramid principle’, ik zou zeggen google daar eens op en doe er je voordeel mee.