Product Owner
27.02.2023
Sarah Berger

Was macht eigentlich ein Freelance Product Owner?

Oftmals werde ich gefragt, welche Aufgaben üblicherweise ein Freelance oder Interim Product im Projektalltag übernimmt. In diesem Blogbeitrag werde ich es dir verraten. Da ich sowohl fest angestellt als Product Owner gearbeitet habe, als auch selbstständiger Freelancer tätig bin, erläutere ich dir die Unterschiede und die Gemeinsamkeiten.

Begriffserklärung

Ein Freelance Product Owner ist nichts anderes als ein Product Owner, der jedoch nicht bei einem Arbeitgeber dauerhaft angestellt ist, sondern selbstständig ist. Entweder als Soloselbstständiger oder im Kontext einer selbst gegründeten Firma, so wie es bei der Biberei der Fall ist.

Ein großer Unterschied ist also, dass der Product Owner nicht fest angestellt ist und nur temporär das Produkt oder Projekt betreut. Üblicherweise haben die Projekte eine Laufzeit von 3 Monaten und können durchaus 1-2 Jahre gehen.

In welchen Situationen engagiert ein Unternehmen ein Freelance Product Owner?

Oftmals werden wir (Die Biberei) engagiert, wenn es personelle Engpässe gibt, beispielsweise wenn ein Mitarbeiter gekündigt hat und es keinen adäquaten Ersatz im Team gibt oder aber auch, wenn das Softwareentwicklungsprojekt neu startet und es keinen Product Owner im Unternehmen oder im Team gibt.

Eine andere Möglichkeit ist aber auch, dass die Produktentwicklung eine kurze Laufzeit hat und es sich nicht lohnt, jemanden fest anzustellen.

Oder aber man möchte sich explizit Hilfe von außen suchen, weil man keine Erfahrungen im Bereich der Individualsoftwareentwicklung hat und das sich das Wissen im Unternehmen mit externer Hilfe aufbauen möchte.

Was macht also ein Freelance Product Owner in der Praxis?

Die grundlegenden Aufgaben eines Freelance Product Owners unterscheiden sich nicht maßgeblich von denen eines angestellten Product Owners. Oftmals ist es auch das exakt gleiche Tätigkeitsfeld, nur eben temporär.

Anforderungsanalyse und Stakeholder Management

Die Anforderungsanalyse ist besonders wichtig, wenn es sich um eine komplette Neuentwicklung handelt. Das heißt, ich definiere die Anforderungen an das zu entwickelnde Produkt. Übliche Fragen, welche ich dabei stelle und auch beantworte, sind beispielsweise die Folgenden:

- Was soll das Produkt tun?

- Welche Ziele sollen mit dem Produkt erreicht werden?

- Welches Problem soll damit gelöst werden?

- Um welches Problem handelt es sich konkret?

- Wer ist der User?

- Welche weiteren Stakeholder gibt es?

- In welcher technischen Umgebung agiert das Produkt?

- Und viele weitere

Diese Fragen stelle ich in verschiedenen Workshops und befrage unterschiedliche Stakeholder und/oder User.

Nicht selten ist schon eine richtige Fragestellung und Diskussion über das Produkt Gold wert. Oftmals denkt man, alle würden wissen, was das Produkt tun soll oder was die Hauptfunktionen sind. Nicht selten haben jedoch die Stakeholder komplett unterschiedliche Meinungen und Erwartungen. Meine Rolle besteht hier bei methodisch die Anforderungen zu erheben, zu dokumentieren und eine Grundlage für die Konzeptionsarbeit zu haben.

Konzeptionsarbeit und Priorisierung

Nachdem die grundlegenden Anforderungen definiert worden sind, beginnt die kreative Phase meiner Arbeit. Konkrete überlege ich, wie die Software aussehen kann. Damit ist nicht unbedingt das Design gemeint, sondern viel mehr, welche Funktionen es benötigt. Diese Funktionen sortiere ich zu den Anforderungen. Es gibt meistens neben den fachlichen auch nicht-funktionale Anforderungen, welche ebenfalls berücksichtigt werden.

Aus den einzelnen Funktionen schreibe ich User Storys, welche die Funktionen in kleinere “Scheiben” schneiden. Ich muss dabei beachten, dass die User Storys verständlich für die Entwickler sind und so klein, dass sie in 1-2 Tagen abzuarbeiten sind. Die genaue Strukturierung der User Storys hängt oft vom Team und Projekt ab.

Neben den User Storys baue ich fast immer Wireframes und Prozessdiagramme. Damit visualisiere ich den Funktionsumfang der Software sowie den logischen Ablaufplan. Je nach Projekt arbeite ich hier auch eng mit dem UX/UI Team zusammen. Es gibt jedoch einige Projekte, bei denen ich die Rolle zusätzlich übernehme.

Oftmals arbeite ich in Projekten, welche mit anderen Systemen interagieren. Das fängt schon damit an, dass wir eine unternehmensweite Authentifizierung nutzen möchten (z. B. Azure AD). Dafür überlege ich mir ebenfalls, wie die Anbindung an dieser Systeme aussehen kann.

Arbeit mit dem Scrum Team

Neben der Konzeptionsarbeit ist die Interaktion mit dem Scrum Team eines der Hauptaufgaben eines Product Owners. Dazu gehört die Planung, welche User Storys in welchem Sprint bearbeitet werden soll und auch die Diskussion der jeweiligen User Storys. Oftmals mache ich mir bereits im Vorfeld Gedanken dazu, wie die technische Implementierung aussehen könnte. Insbesondere, wenn ich das Softwareframework und Programmiersprache sehr gut kenne. Die finale Entscheidung liegt aber immer beim Scrum Team. Abhängig vom Projekt habe ich oftmals keinen Scrum Master, welche für die Einhaltung des Scrum Frameworks sorgt. In den meisten Fällen übernehme ich dann diese Aufgabe.

Abnahme der User Stories und Produktvalidierung

Einer der schönsten Momente ist es immer, wenn ich die von mir erdachten Konzepte tatsächlich testen kann. In der Praxis teste ich jede User Story und mache ich einen Akzeptanztest. Je nach Projekt gibt es noch ein zusätzliches QA-Team. In solchen Situationen stimme ich eng mit dem QA-Team ab und teste mindestens die Funktionalität der umgesetzten Funktionen.

Natürlich muss das Ergebnis nicht nur mir gefallen, sondern vor allem den Usern bzw. Stakeholdern. Daher ist es eine wichtige Aufgabe, die User und Stakeholder die Zwischenergebnisse zu präsentieren und aktiv Feedback einzufordern. Je nach Projekt sorge ich auch dafür, dass das Produkt von anderen Teams getestet wird. Aus der Erfahrung heraus sollte das Feedback und die Produktvalidierung so früh wie möglich passieren. Nichts ist schlimmer als Monate Zeit in die Produktentwicklung zu stecken, nur am Ende zu realisieren, dass das Produkt nicht benötigt wird oder die Probleme damit nicht gelöst werden können.


Das war ein kurzer Ausflug in den Praxisalltag eines Freelance Product Owners. Solltet ihr weitere Fragen haben oder Unterstützung für euer Projekt benötigen, könnt ihr euch sehr gerne melden.

Du hast Fragen zu diesem Thema?

Kontakt aufnehmen
Biberei Icon

Kategorien

Product Owner
Softwareentwicklung
Produktentwicklung
Projektorganisation

Lass uns über dein Projekt reden

Erzähle uns in einem kostenlosen Erstgespräch mehr über dein individuelles Projekt. Wir helfen dir bei den nächsten Schritten und teilen unser Wissen.

Nachricht schreiben