Geben Sie Ihren Kolleg:innen besseres Feedback (mit Ryan Schaefer von Viget)

Lesen Sie das Transkript:

Wir probieren aus, unsere Podcasts per Software transkribieren zu lassen. Bitte entschuldigen Sie etwaige Tippfehler – der Bot ist nicht immer zu 100% korrekt.

Ben Aston:

Willkommen beim DPM-Podcast, bei dem wir über die Theorie hinausgehen und Tipps geben, die tatsächlich dabei helfen, bessere digitale Projekte zu leiten. Danke fürs Einschalten. Ich bin Ben Aston, Gründer des Digital Project Manager.

Wie gehen Sie damit um, Ihrem Team Feedback zu geben? Nutzen Sie jede Gelegenheit, weil Sie wissen, dass Sie recht haben, schließlich sind Sie Projektmanager:in, oder meiden Sie das Thema, weil Sie befürchten, nicht ernst genommen zu werden? Vielleicht erhalten Sie Feedback und haben das Gefühl, niemand hat wirklich verstanden – oder gar gehört –, was Sie sagen wollten. Doch als Projektmanager:in sind wir verantwortlich für die erfolgreiche Umsetzung – und das ist schwer, wenn unser Team oft am Ziel vorbeiarbeitet.

In der heutigen Podcast-Folge erfahren Sie einige einfache Methoden, wie Sie Feedback geben können, das Ihr Team motiviert, bessere Arbeit zu leisten und Ihre Projekte auf Kurs zu halten.

Heute ist Ryan Schaefer zu Gast. Ryan ist von der Gestaltung und Entwicklung von Websites dazu übergegangen, diese nun zu managen – und arbeitet in Washington, D.C. bei einer Agentur namens Viget. Hallo, Ryan.

Ryan Schaefer:

Hallo Ben. Danke, dass ich dabei sein darf.

Ben Aston:

Cool. Ryan, erzähl mal bitte etwas über deine derzeitige Rolle und was mich wirklich interessiert: Wie hast du den Sprung vom Design/Development ins Projektmanagement geschafft? Das werden wir oft gefragt. Was machst du aktuell? Bist du reiner Projektmanager oder bist du auch noch involviert in Details?

Ryan Schaefer:

Ich würde sagen, es geht eher in Richtung reines Projektmanagement, aber eines der Dinge, die mir den Wechsel erleichtert haben, war mein Know-how in Design- und Entwicklungsprozessen. Ich habe also die ganzen Gedanken und Abläufe, die in Design und Entwicklung einfließen, verstanden.

Das ermöglicht mir, mit den talentierten Designer:innen und Entwickler:innen hier auf Augenhöhe zu sprechen. Ich muss nicht nach den Abkürzungen fragen, nicht danach, welche Tools verwendet werden – solche Dinge halt.

In meiner vorherigen PR-Agentur hatte ich eine Doppelrolle in Beratung und Umsetzung, das hat mir geholfen, darüber nachzudenken, wie man Dinge an Kund:innen vermittelt oder mit Teammitgliedern zusammenarbeitet. So war der Wechsel zum vollwertigen Projektmanagement recht natürlich für mich – zum Glück.

Ben Aston:

Wie ist es dazu gekommen? Gab es einen Auslöser, nach dem du gesagt hast: „Das ist es, ich werde Projektmanager“?

Ryan Schaefer:

Es lag ein wenig daran, Dinge aus der Vogelperspektive steuern zu wollen, statt im Silo zu arbeiten. Aber Hauptgrund war, dass ich in einem digital und zukunftsorientierten Team arbeiten wollte, das voller Leidenschaft für digitale Themen ist, weil das ja gesellschaftlich und national viel verändert. Von Leuten umgeben zu sein, die das wertschätzen und in ihrem digitalen Bereich sehr kompetent sind, war etwas, das ich wollte – das hilft einem dann auch, sich fachlich weiterzuentwickeln.

Ben Aston:

Cool. Erzähl uns etwas über deinen derzeitigen Job. Wie sieht deine Aufgabe als PM bei Viget aus?

Ryan Schaefer:

Also, zunächst mal: Es heißt Viget – das fragen viele.

Ben Aston:

Vid-get? Vig-et?

Ryan Schaefer:

Viget, ja.

Ben Aston:

Ich hab sogar auf der Webseite auf eine Katze geklickt, die sagte, dass es Viget heißt.

Ryan Schaefer:

Ja, da gibt’s einen „Say hi“-Button. Das ist Viget.

Ben Aston:

So ist das halt mit komischen Namen. Was bedeutet er überhaupt?

Ryan Schaefer:

„Gemeinsam blühen wir auf“ – lateinisch.

Ben Aston:

Klar.

Ryan Schaefer:

So ungefähr.

Ben Aston:

Meine Mutter wäre beschämt. Entschuldige, Mama – sie ist Lateinlehrerin. Ich sollte sowas wissen.

Ryan Schaefer:

Latein war mein schlechtestes Fach in der Schule. Wir mussten es belegen. Kaum zu glauben.

Ben Aston:

Na, es hat dich ja bestens auf all die Sprachen vorbereitet, die du jetzt sprichst, oder?

Ryan Schaefer:

Genau. Aber zurück zur Rolle als Projektmanager bei Viget: Diese umfasst sehr viele verschiedene Dinge, z. B. die Kernaufgaben eines PM wie Zeitplan, Budget, Terminplanung, Staffing und Ressourcenkoordination. Dazu kommt alles, was das Produktmanagement betrifft. Wir haben keine eigenen Produktmanager:innen, also sind PMs bei uns auch für User Journeys, Feature-Definition, Qualitätssicherung und das betriebswirtschaftliche Verständnis für Kund:innen und Produkte verantwortlich.

Ben Aston:

Also Projekt- und Produktmanagement?

Ryan Schaefer:

Genau, eine Mischung aus beidem.

Ben Aston:

Also beides in einem.

Ryan Schaefer:

Ja, das ergänzen sich gut, aber sie sind auch unterschiedlich genug, dass es erfrischend ist, mal zu switchen und entweder am Produkt zu arbeiten oder das Projekt zu organisieren.

Ben Aston:

Spannend. An welchen Projekten arbeitest du aktuell?

Ryan Schaefer:

Ich bin seit ein paar Wochen Vollzeit auf einem großen Marketing-Projekt, das ist das erste Mal überhaupt. Wir machen den kompletten Webauftritt neu und entwickeln ein Portal für verschiedene Zielgruppen, die sich einloggen und jeweils eigene Daten sehen.

Wir erneuern also das gesamte digitale Ökosystem, gestalten alle sichtbaren Materialien neu und arbeiten an einer Roadmap für zukünftige Produkte, z. B. eine App. Es ist sehr umfangreich und ich freue mich, mich so intensiv in ein Projekt zu vertiefen und viel dazuzulernen.

Ben Aston:

Du hast einen Lightning Talk auf dem DPM Summit, wo du Tipps zum Management von nativen App-Projekten gibst. Kannst du eine Kurzfassung geben? Was hast du über native Apps herausgefunden?

Ryan Schaefer:

Ja, mein Vortrag basiert auf meinen Erfahrungen beim bislang größten Projekt – der Entwicklung einer Android-App. Ich werde berichten, was ich gelernt habe und vor allem die Unterschiede zum klassischen Webprojekt sowie Best Practices erläutern. Außerdem spreche ich über die technischen Anforderungen, die man als PM kennen sollte.

Beispiel: Bei Apps ist der Preis eines Fehlers viel höher – die App kann abstürzen, bei einer Website reicht meist Neuladen. Die Programmiersprachen für native Apps sind auch andere als z. B. JavaScript fürs Web, und man muss deutlich mehr vom Problem selbst lösen, bei Webapps „erledigt“ JavaScript oft einen großen Teil. Dazu kommen Systemkontrollen und spezielle Einschränkungen etwa im Offline-Betrieb: Wie funktioniert die App ohne Verbindung? Wie verhalten sich die Buttons? Solche Dinge.

Ben Aston:

Du kennst Web- und Native-Apps und der Trend neigt ja zu Web-Apps, weil sie schneller gebaut sind. Wie siehst du den Vergleich und die Entwicklung?

Ryan Schaefer:

Ein spannender Aspekt ist der Aufstieg von Diensten wie Squarespace, WordPress-Themes, Weebly u.ä. – das sind sehr nutzungsorientierte Services, mit denen technisch Ungeübte professionelle Websites bauen können – dank niedriger Einstiegshürden. Dadurch sind klassische Marketing-Webprojekte weniger gefragt. Native Apps sind auf diesem Niveau noch weniger verbreitet, weshalb es für uns dort viele Möglichkeiten gibt. Und es ist natürlich einfach cool, eine eigene App zu haben!

Außerdem gibt es noch viele unerschlossene Software- und Produktbereiche; wie in meinem aktuellen Projekt, einem Portal hinter Login mit individuellen Ansichten – das ist mehr als bei Squarespace o.ä. möglich ist.

Man kann viel individuell gestalten, was für Entwickler:innen und Designer:innen attraktiv ist. Wir können hier auch Standards setzen und den Markt mitgestalten.

Ben Aston:

Du machst App- und große Webprojekte. Was gehört zu deinem PM-Toolkit? Mit welchen Werkzeugen startest du ein neues Projekt?

Ryan Schaefer:

Ein gelungener Anfang ist wichtig: Ich mag moderierte Kunden-Kickoffs, Visioning-Calls, in denen das aktuelle Geschäftsmodell, das Produkt und die Ziele besprochen werden. Außerdem: Problem-, Ziel- und Workshoprunden, Stakeholder-Interviews usw.

Das sind Dinge, die man im Sales-Prozess niemals vollständig aufdecken kann. Mit all diesen Gesprächen und Erkenntnissen – was durchaus ein paar Wochen dauern kann – startet man viel strukturierter, baut effizienter und liefert letztlich ein besseres Ergebnis ab.

Zur Organisation nutzen wir viele Tools: Airtable ist super, zudem GitHub Projects, Zen Hub (mit GitHub einsetzbar), Trello – je nach Kundenwunsch oder unserer Empfehlung.

Ben Aston:

Gibt es besondere PM-Werkzeuge, die dir zuletzt das Leben erleichtert haben?

Ryan Schaefer:

Zwei Dinge: Erstens, ich habe mich mit Tastenkombinationen an meinem Rechner beschäftigt – das spart viele Sekunden, und das summiert sich schnell.

Und zweitens…

Ben Aston:

Welches Shortcut hast du zuletzt entdeckt?

Ryan Schaefer:

Cmd-Shift-T – damit öffnet man den zuletzt geschlossenen Tab.

Ben Aston:

Sehr praktisch!

Ryan Schaefer:

Ja, feines Feature.

Ben Aston:

Mein Tipp – bei Windows kann man mit Windows-V die Copy-&-Paste-Historie aufrufen.

Ryan Schaefer:

Wow, das kannte ich noch nicht.

Ben Aston:

Ich finde das super nützlich – als jemand, der häufig Text in Notepad tippt, kopiert, weiterarbeitet und dann vergisst zu kopieren. Also, Windows-V und Cmd-Shift-T – das sind unsere Shortcuts der Woche.

Ryan Schaefer:

Guter Tipp!

Ben Aston:

Sonst noch was?

Ryan Schaefer:

Das neueste Tool, das mir wirklich die Augen geöffnet hat ist Notion. Kennst du das?

Ben Aston:

Klar.

Ryan Schaefer:

Das ist wie ein digitaler Arbeitsplatz – für Notizen, Zusammenarbeit, offline nutzbar, sehr ansprechende Oberfläche. Man kann auch einbetten, Seiten verschachteln, Toogles nutzen. Dazu Web- und Mobile-App. Sehr individuell anpassbar.

Man kann es im Call öffnen, schnell Stichworte festhalten und später nach Belieben aufbereiten.

Ben Aston:

Bei all den Projekten – was findest du in deinem Job tagtäglich am schwierigsten?

Ryan Schaefer:

Vieles. Zu wenig Zeit ist eines. Aber das Schwierigste ist das häufige Kontext-Switchen.

Als Projektmanager:in betreut man meist mehrere Projekte, hat viele Meetings – man springt von einem zum nächsten und versucht, immer alles parat zu haben. Hilf mir dabei: disziplinierte Notizen, Agenda für jedes Meeting, morgens kurz reflektieren, wo jedes Projekt steht. Das will ich stetig weiter verbessern.

Eine weitere Herausforderung: die Zusammenarbeit bzw. Übergabe zwischen Designer:innen und Entwickler:innen optimal zu gestalten. Die Designer:innen erstellen tolle Mockups, aber wie dokumentiert und definiert man alle Features, Admin-Optionen u.s.w. so, dass Entwickler:innen alles klar übernehmen können?

Dafür testen wir Airtable als Datenstruktur-Tool, das alle Komponten referenziert, was wiederum Entwickler:innen hilft zu kalkulieren, was wie lange dauert.

Ein aufwendiger Prozess, aber ich hoffe, langfristig lohnt sich das für alle.

Ben Aston:

Erzähl mehr dazu: Airtable ist ja eine Art Tabellenbank?

Ryan Schaefer:

Genau.

Ben Aston:

Gibt es eine Integration mit InVision, Sketch o.ä. für eure Mockups?

Ryan Schaefer:

Airtable kann integriert werden, aber wir nutzen vorwiegend Figma. Dafür gibt’s keine direkte Integration, glaube ich.

Wir haben schon vieles ausprobiert, z. B. Links in Google Sheets. Aber das flexible Datenbank-Modell in Airtable ist der größte Pluspunkt: Verknüpfungen im System sind einfach und skalierbar, das UI ist übersichtlich.

Ben Aston:

Für User, die Airtable nicht kennen: Wie ist das aufgebaut? Tipps?

Ryan Schaefer:

Klar. Bei UI-Explorationen dokumentieren wir z. B. im Sitemap-Sheet, wohin jede Navigation führt. Dann gibt es weitere „Tabs“ (nennt sich anders), die aussehen wie Tabs. Man kann immer Verweise setzen, neue Bereiche ergänzen, mit Tags/Kategorien oder farbigen Blöcken abgrenzen.

So entsteht ein gut lesbares, zentrales Dokument für das ganze Team – die „Single Source of Truth“.

Ben Aston:

Das ist hilfreich. Oft ist es schwierig, Anforderungen über den ganzen Projektverlaufsweg zu transportieren.

Ryan Schaefer:

Absolut.

Ben Aston:

Wie dokumentiert man das? Lösungen wie Airtable finde ich spannend – gerade, weil viele Elemente so mehrfach gebraucht werden und Änderungen schwer nachzuführen sind, wenn man nur mit Word oder Google Sheets arbeitet. In einer Datenbank wie Airtable kann man Bausteine (z. B. Menüpunkte) einfach referenzieren.

Super. Thema Feedback: Für Leser:innen, die deinen Artikel noch nicht kennen – dort geht es ums richtige Feedback geben, sodass das Produkt am Ende besser wird.

Für Menschen, die den Artikel noch nicht gelesen haben: Was ist dein wichtigster Tipp zum Thema Feedback? Viele haben Angst davor – warum eigentlich, und wovor?

Ryan Schaefer:

Es gibt mehrere Gründe.

Erstens der menschliche: Wir möchten Kolleg:innen nicht verletzen oder ihre Arbeit abwerten. Zweitens fehlt uns manchmal das Selbstvertrauen, dem Fachexperten, also Designer:innen oder Entwickler:innen, Feedback zu geben.

Beide Sorgen sind verständlich. Aber als PM ist man der/die engste Ansprechpartner:in zum Kunden und hat einen frischen Blick auf das Projekt, den Endnutzer. Man sieht es aus Nutzerperspektive – und das ist wertvoll.

Seien Sie sich dieser Perspektive bewusst: Sie sehen Dinge zum ersten Mal – fragt man sich dabei: Vermittelt das klar, was die Organisation macht? Spricht es die Zielgruppe an? Ist z. B. eine Dropdown klar als solches erkennbar? Das Feedback hilft, die Arbeit auf Nutzer- und Geschäftsziele abzustimmen.

Ben Aston:

Also wir können sozusagen als „Wächter für Erfolg und Nutzererlebnis“ auftreten?

Im Artikel gibst du 10 Tipps für gutes Feedback, der erste: Sich eine informierte Perspektive verschaffen. Wie gehst du bei neuen Projekten vor, um wirklich informiert zu sein und nicht nur zu glauben, informiert zu sein?

Ryan Schaefer:

Gute Frage. Ich glaube, ganz durchsichtig ist man nie – und das ist okay.

Ben Aston:

Stimmt.

Ryan Schaefer:

Aber Visioning-Calls helfen, zu verstehen, wie das Unternehmen sich sieht und wohin es will: „Übernehmen wir eine Firma? Fusionieren wir? Gehen wir an die Börse?“

Mit Gesprächen auf Führungsebene erfährt man, wie das Ganze umgesetzt werden soll, das gibt den übergeordneten Rahmen. Leitet man daraus Diskussionen beim Kickoff mit dem aktiven Projektteam ab, erkennt man, wie die Arbeit zu den Unternehmenszielen passt. Das alles sollte sich schließlich im Ergebnis spiegeln.

Man muss genügend konkrete Infos aus diesen Diskussionen bekommen, um gezielt zu helfen – sei es bei der Kommunikation, dem Markenauftritt, bei App-Empfehlungen usw.

Es ist ein fortlaufender Prozess und verlangt viel Invest zu Beginn. Die Discovery-Phasen sind für genau diese Fragen da – das macht das Projekt schlüssiger und das Ergebnis besser.

Ben Aston:

Teil der Information ist auch, den Kundenerfolg zu verstehen: was für ihn Erfolg bedeutet, die Bedürfnisse der Nutzer und die Wege, wie man beides zusammenbringt. Aber du sprachst auch davon, sich in verschiedene Disziplinen einzuarbeiten. Wie machst du das, etwa bei QA oder UX, wenn du da kein Profi bist?

Ryan Schaefer:

Wenn Sie sich genug einarbeiten, können Sie objektives Feedback geben und vermeiden subjektive Urteile.

Dafür sollte man sich mit Teammitgliedern austauschen und zugeben, wo das eigene Wissen Lücken hat. Vom Development kommend, z. B. nicht so fit in UX: Ich schaue dann einfach bei den UX-Kolleg:innen über die Schulter.

Außerdem hilft: machen! Es gibt viele Ressourcen z. B. zum Coden oder Designen. Ich versuche, fünf Stunden pro Woche Design-Ideen zu skizzieren, Code aufzufrischen und Artikel zu lesen. Mit der Zeit übernimmt man ohnehin viel Wissen in Meetings und Praxis.

Ben Aston:

Welche Webseiten nutzt du, um auf dem Laufenden zu bleiben?

Ryan Schaefer:

Thedigitalprojectmanager.com ist klasse. Dann „A Girl’s Guide to Project Management“, Ad Week für Kreativtrends. Bei Entwicklung: W3Schools.com für CSS, JavaScript und Backend – gut zum Reinschnuppern.

Ben Aston:

Du sagst, praktische Nebenprojekte helfen, Wissen zu vertiefen. Stimmt – dann kann man Diskussionen mit Entwickler:innen fundierter führen.

Also ruhig mal selbst etwas bauen, etwa die eigene Portfolio-Seite. Theoretisch lesen ist das eine, selbst machen das andere. Gerade die Erfahrung, wie viel Aufwand etwas wirklich ist, hilft beim Feedback geben.

Hast du Beispiele, wo dir das schon mal „auf die Füße gefallen“ ist? Viele Fachleute hören nur ungern Feedback von PMs…

Wie gehst du damit um, wenn deine Meinung nicht zählt?

Ryan Schaefer:

Zum Glück habe ich das noch nicht negativ erlebt. Ich glaube, das liegt auch am guten Arbeitsklima, aber auch daran, dass ich das Feedback immer aus Kundensicht argumentiere. Wie passt die fachliche Logik zum Ziel? Das akzeptiert das Team eher.

Es geht nicht um „Mir gefällt die Farbe nicht“, sondern: „Laut Guideline ist das eine Nebenfarbe – ist sie hier zu präsent?“ Die Designer:innen haben sich meist schon etwas dabei gedacht und dafür eine Begründung. Wenn das Sinn ergibt, übernehmen wir es so.

Ben Aston:

Du betonst im Artikel, dass Teamfeedback nicht allein deine Aufgabe ist. Bei schwierigen Themen holt man am besten die Fachverantwortlichen mit ins Boot.

Und du sprichst darüber, dass verschiedene Menschen unterschiedlich auf Feedback reagieren. Eine Balance aus Wertschätzung, klarer Ansage und konstruktivem Lob zu finden ist nicht einfach. Wie schaffst du das?

Ryan Schaefer:

Es ist keine exakte Wissenschaft. Als PM sollte man ein gewisses Maß an emotionaler Intelligenz haben und beim Feedback reagieren können.

Am hilfreichsten ist, immer spezifisch zu sein und nicht subjektiv, sondern objektiv, und Bezug auf die Projektziele zu nehmen.

Außerdem sollte man stets vermitteln, dass man dem Team vertraut. Das motiviert, egal ob jemand Feedback persönlich nimmt oder nicht. Ich höre jedenfalls gern Gutes über mich, solange es nicht herablassend ist – spezifisches Feedback ist selten so.

Ben Aston:

Abschließend: Was würdest du jemandem raten, der denkt, das eigene Feedback zählt sowieso nicht?

Ryan Schaefer:

Ich würde raten: Beim ersten Eindruck muss man nicht immer sofort reagieren. Lieber nochmal in Ruhe anschauen, eigene Notizen machen, überlegen, wo es wirklich Verbesserungsbedarf gibt und konkrete Vorschläge erarbeiten.

So kann man sich sorgfältig auf das Gespräch vorbereiten, und das Feedback wird wahrgenommen und respektiert – je gründlicher, desto mehr.

Ben Aston:

Super. Ich denke, Menschen reagieren empfindlich, wenn wir nur meinen: „Das gefällt mir nicht.“ Besser ist, sich Zeit zu nehmen und herauszufinden, warum man denkt, dass etwas nicht passt. Dann sachlich den Grund benennen – z. B. Anforderungen des Kunden – und gemeinsam nach Lösungen suchen. Ideen aufmalen, Whiteboard nutzen… Es geht nicht darum, dem Designer die Arbeit wegzunehmen, sondern die eigene Überlegung als Angebot für ein besseres Ergebnis einzubringen.

Ryan, vielen Dank für das Gespräch! Es war großartig, dich dabei zu haben.

Ryan Schaefer:

Vielen Dank auch – ich weiß das sehr zu schätzen.

Ben Aston:

Mich interessiert, wie Sie Feedback gegeben haben – wie wurde es aufgenommen? War das Team sauer, oder wurde etwas wertgeschätzt, das sonst niemand bemerkt hat?

Teilen Sie Ihre Gedanken mit uns und besuchen Sie thedigitalprojectmanager.com, um unserem Slack-Team beizutreten – dort finden spannende Diskussionen rund um Projektmanagement statt.

Wenn Ihnen der Podcast gefallen hat, abonnieren Sie ihn gern und hinterlassen Sie eine ehrliche Bewertung für den DPM Podcast auf Apple Podcasts. Wir schätzen jede Bewertung und Rezension sehr – vielen Dank!

Bis zum nächsten Mal – danke fürs Zuhören!