Produktmanager! Sag das nicht!

Eine Sammlung dessen, was Produktmanager ihrem Team nicht sagen sollten und wie man besser kommuniziert.

Sei dir deiner Worte bewusst und baue eine gesunde Beziehung zu deinem Team auf.

#bugs-or-issues

Don't say

"Wir müssen uns auf neue Funktionen konzentrieren; die Bugs können warten."

The same goes for:

  • Lassen wir uns nicht von den Bugs ablenken; wir haben Funktionen zu starten.

  • Die Funktionen sind wichtiger als die Behebung dieser Bugs im Moment.

  • Die Kunden warten auf Funktionen, nicht auf Bugfixes.

Sich ausschließlich auf neue Funktionen zu konzentrieren, während man Bugs ignoriert, kann die Benutzererfahrung und Kundenzufriedenheit erheblich beeinträchtigen. Dieser Ansatz deutet auf eine Fehlausrichtung im Verständnis der kritischen Balance zwischen Innovation und Produktstabilität hin. Bugs, egal wie geringfügig, können das Vertrauen der Benutzer im Laufe der Zeit untergraben und zu Unzufriedenheit und potenziellem Verlust von Kunden führen. Es ist wesentlich zu bedenken, dass sowohl Funktionen als auch Bugfixes zum Gesamtwert des Produkts beitragen.

Anstatt Funktionen und Bugfixes als konkurrierende Prioritäten zu betrachten, ist es vorteilhaft, sie in eine ganzheitliche Produktentwicklungsstrategie zu integrieren. Dies beinhaltet die Bewertung der Auswirkungen von Bugs auf die Benutzererfahrung und den Wert, den neue Funktionen bringen. Indem man eine Umgebung fördert, in der die Kommunikation zwischen Produktmanagern und Entwicklern die Bedeutung von beidem hervorhebt, kann man sicherstellen, dass sich das Produkt auf eine Weise entwickelt, die Benutzerbedürfnisse erfüllt und dabei hohe Qualitätsstandards aufrechterhält.

Say this

"Wie können wir unseren Fokus zwischen der Einführung neuer Funktionen und der Behebung von Bugs ausbalancieren, um eine optimale Benutzerzufriedenheit zu gewährleisten?"

The same goes for:

  • Lassen Sie uns die Auswirkungen aktueller Bugs im Vergleich zum Wert der bevorstehenden Funktionen bewerten. Was ist das beste Gleichgewicht?

  • Könnten wir unseren Backlog überprüfen, um Bugs, die das Benutzererlebnis signifikant beeinflussen könnten, neben unserer Funktions-Roadmap zu priorisieren?

  • Ich glaube, sowohl Funktionen als auch Bugfixes sind wesentlich für unsere Benutzer. Wie können wir unsere Ressourcen effektiv verwalten, um beides anzugehen?

Die Balance zwischen Innovation mit neuen Funktionen und der Aufrechterhaltung einer stabilen, bugfreien Benutzererfahrung ist der Schlüssel zum nachhaltigen Produktwachstum. Dieser Ansatz spiegelt das Verständnis der Wechselbeziehung zwischen Funktionen und Bugfixes bei der Lieferung von Wert an den Benutzer wider. Durch eine Dialogführung, die Kollaboration und Prioritätenbewertung betont, können Produktmanager und Entwickler die wirkungsvollsten Arbeitsbereiche identifizieren.

Das Gespräch sollte sich auf das Verständnis der Schwere der Bugs und der strategischen Bedeutung neuer Funktionen konzentrieren. Diese ausgewogene Ansicht fördert einen datengesteuerten Ansatz zur Entscheidungsfindung, bei dem Benutzerfeedback und Analysen eine zentrale Rolle spielen. Die Priorisierung von Arbeiten, die die Benutzerzufriedenheit und Produktqualität maximieren, stellt sicher, dass die Bemühungen des Teams mit den übergeordneten Geschäftszielen und Benutzerbedürfnissen übereinstimmen.

#deadline

Don't say

"Das muss bis nächsten Monat fertig sein. Können wir das schaffen?"

The same goes for:

  • Die Frist ist nicht verhandelbar. Wie wirst du sicherstellen, dass wir sie einhalten?

  • Dieses Projekt ist bereits im Verzug. Wir müssen die Dinge beschleunigen.

  • Kannst du nicht einfach Überstunden machen, um das rechtzeitig fertigzustellen?

Ein Projekt mit einem unrealistischen Fristen zu fordern, ohne die Ingenieure zu konsultieren, kann zu Stress, Burnout und beeinträchtigter Arbeitsqualität führen. Es missachtet die Komplexität der Aufgaben und die Kapazität des Teams, was Vertrauen und Moral schädigen kann. Effektive Kommunikation über Fristen sollte Zusammenarbeit und Respekt für die Einsichten und Vorschläge des Ingenieurteams beinhalten. Das Setzen von Fristen sollte eine gegenseitige Vereinbarung sein, die alle Aspekte des Projekts berücksichtigt, um eine Balance zwischen pünktlicher Lieferung und der Aufrechterhaltung hoher Qualitätsstandards zu gewährleisten.

Say this

"Angesichts unseres aktuellen Umfangs und der verfügbaren Ressourcen, welchen Zeitrahmen hältst du für realistisch für dieses Projekt? Ich würde gerne deine Meinung hören, damit wir die Erwartungen abstimmen und eventuelle Einschränkungen frühzeitig an die Stakeholder kommunizieren können."

The same goes for:

  • Mit Blick auf die Komplexität und unsere Kapazitäten, wie siehst du die vorgeschlagenen Fristen? Lass uns gemeinsam potenzielle Risiken und notwendige Anpassungen identifizieren.

  • Lasst uns den Projektumfang und unsere Teamkapazität überprüfen, um unser Zeitfenster besser zu verstehen. Es ist wichtig, dass wir erreichbare Fristen setzen, die Qualität oder Wohlbefinden nicht beeinträchtigen.

  • Könntest du mir die Schlüsselmeilensteine und den benötigten Zeitraum für jeden erläutern? Das hilft uns, einen realistischen Zeitplan zu erstellen, der uns Spielraum für unvorhergesehene Probleme lässt.

Die Diskussion von Fristen mit Ingenieuren sollte eine gemeinsame Anstrengung sein, wobei der Fokus auf der Erstellung eines realistischen und erreichbaren Zeitplans liegt. Dieser Ansatz respektiert die Expertise des Ingenieurs und fördert ein gesundes Arbeitsumfeld. Es ist wichtig, transparent über die Bedürfnisse des Projekts zu sein und flexibel in der Anpassung der Erwartungen basierend auf ihrem Feedback. Dieser Dialog hilft nicht nur dabei, praktische Fristen zu setzen, sondern baut auch Vertrauen auf und stellt sicher, dass alle hinsichtlich der Projektzeiten und -lieferungen auf dem gleichen Stand sind.

#delay

Don't say

"Warum dauert das so lange? Du sagtest, es wäre bis jetzt fertig."

The same goes for:

  • Das ist hinter dem Zeitplan, was ist das Problem?

  • Wir sind schon wieder verzögert? Das scheint ein Muster zu sein.

  • Kannst du nicht einfach schneller arbeiten? Wir hinken bereits hinterher.

Über Verzögerungen in einer Weise zu sprechen, die Geschwindigkeit oder Engagement des Teams in Frage stellt, kann anklagend wirken und die Moral senken. Schuldzuweisungen und Ungeduld in deinem Ton erkennen die Komplexität der Entwicklungsarbeit nicht an und können das Vertrauen zwischen Produktmanagern und Ingenieuren untergraben.

Um dies zu vermeiden, solltest du nie implizieren, dass die Verzögerung auf mangelnde Anstrengung oder Fähigkeit zurückzuführen ist. Konzentriere dich stattdessen darauf, die Ursache zu verstehen und gemeinsam an einer Lösung zu arbeiten. Würdige die bereits geleistete Arbeit und zeige deinen Einsatz, um bei der Überwindung von Hindernissen zu helfen.

Say this

"Ich sehe, wir liegen hinter unserem Zeitplan. Können wir darüber sprechen, was die Verzögerung verursacht und wie ich helfen kann, uns wieder auf Kurs zu bringen?"

The same goes for:

  • Angesichts der Verzögerung sollten wir die Herausforderungen, mit denen du konfrontiert bist, überprüfen und besprechen, welche Anpassungen wir eventuell vornehmen müssen.

  • Ich verstehe, dass wir auf einige Hindernisse gestoßen sind. Welche Ressourcen oder Unterstützung benötigst du von mir, um diese Probleme zu bewältigen?

  • Lass uns ein Meeting einberufen, um unseren Zeitplan neu zu bewerten und Aufgaben zu priorisieren, um die Verzögerung zu mildern.

Verzögerungen mit einer Haltung der Zusammenarbeit und Unterstützung anstatt der Schuldzuweisung zu begegnen, hält die Kommunikationswege offen und produktiv. Es zeigt, dass du den Einsatz und das Fachwissen des Engineering-Teams wertschätzt und bereit bist, zuzuhören und Pläne bei Bedarf anzupassen. Dieser Ansatz fördert eine problemlösungsorientierte Einstellung, stärkt das Vertrauen und motiviert das Team, gemeinsam auf das Ziel der Projektvollendung hinzuarbeiten.

#estimation

Don't say

"Das dürfte nicht lange dauern, oder? Es scheint eine einfache Aufgabe zu sein."

The same goes for:

  • Wie viele Tage wird das dauern? Zwei, vielleicht drei?

  • Kannst du das nicht einfach von irgendwoher kopieren und einfügen?

  • Es geht nur darum, einen Button hinzuzufügen, warum brauchen wir dafür zwei Wochen?

Engineering-Schätzungen mit vorgefassten Meinungen über die Einfachheit zu diskutieren, untergräbt nicht nur die Komplexität der involvierten Arbeit, sondern zeigt auch einen Mangel an Respekt für den Engineering-Prozess. Zu behaupten, dass eine Aufgabe einfach ist, ohne die technischen Details oder Implikationen zu verstehen, kann dein Team demotivieren und Reibungen erzeugen. Ingenieure benötigen Zeit, um den besten Ansatz zu überlegen, potenzielle Hindernisse zu berücksichtigen und Qualität zu gewährleisten. Ihre Arbeit auf wahrgenommene Einfachheit zu reduzieren, ignoriert diese beruflichen Überlegungen.

Frag stattdessen offene Fragen, um den Umfang, Herausforderungen und Aufwand zu verstehen, der involviert ist. Dies fördert eine Kultur des Respekts und der Zusammenarbeit und stellt sicher, dass Schätzungen in der Realität und technischem Fachwissen verankert sind.

Say this

"Könntest du mir helfen zu verstehen, was bei der Implementierung dieses Features involviert ist und welche potenziellen Herausforderungen du siehst?"

The same goes for:

  • Basierend auf deiner Erfahrung, mit welchem Zeitrahmen sollten wir für diese Aufgabe rechnen?

  • Ich würde gerne deine Einsicht darüber bekommen, wie komplex diese Aufgabe ist und welche Schritte involviert sind.

  • Können wir die technischen Anforderungen und potenziellen Hindernisse für dieses Feature besprechen?

Engineering-Schätzungen mit Offenheit und dem echten Wunsch zu verstehen, was Aufgaben komplex macht, zu nähern, zeigt Respekt für die Engineering-Expertise und den Prozess. Diese Methode fördert transparente Kommunikation und ermöglicht es Ingenieuren, ihre Einsichten über den technischen Umfang, mögliche Herausforderungen und eine realistische Zeitschätzung zu teilen. Es erkennt an, dass qualitativ hochwertige Arbeit Zeit benötigt und dass unvorhergesehene Komplikationen Zeitpläne beeinflussen können. Durch das Engagement in einem kollaborativen Dialog werden Erwartungen abgeglichen und eine produktive Umgebung gefördert, in der technische Bewertungen die Projektzeitpläne leiten.

#feature-request

Don't say

"Diese Funktion ist kritisch und muss bis zur nächsten Veröffentlichung fertig sein. Das kann doch nicht so schwer sein, oder?"

The same goes for:

  • Wie lange würde es dauern, diese Funktion hinzuzufügen? Wir brauchen sie wirklich.

  • Diese Funktion sollte nicht viel Aufwand erfordern, können wir sie im nächsten Sprint bekommen?

  • Ich verstehe nicht, warum das schwierig zu implementieren sein sollte.

Das Diskutieren einer neuen Funktionsanfrage, indem man ihre Komplexität unterschätzt oder enge Fristen ohne Absprache vorgibt, kann Ingenieure vor den Kopf stoßen und ihre Expertise untergraben. Es deutet auf ein mangelndes Verständnis und Respekt für den Ingenieursprozess hin. Dieser Ansatz kann zu Frustration, überstürzter Arbeit oder einem Rückgang der Teammoral führen.

Stattdessen sollte man Ingenieure früh in die Diskussion einbeziehen, ihre Meinung zu Machbarkeit und Zeitplänen einholen und einen flexiblen Ansatz bei der Priorisierung der Arbeit bewahren. Denken Sie daran, Zusammenarbeit und gegenseitiger Respekt sind der Schlüssel zum erfolgreichen Navigieren von Funktionsanfragen.

Say this

"Wir ziehen diese neue Funktion für die nächste Veröffentlichung in Betracht. Können wir ihre Machbarkeit und wie sie in die aktuelle Roadmap passt, besprechen?"

The same goes for:

  • Basierend auf Ihrer Erfahrung, wie komplex wäre es, diese Funktion zu implementieren, und welcher Zeitrahmen erscheint realistisch?

  • Bevor wir Entscheidungen treffen, möchte ich die technischen Implikationen und den erforderlichen Aufwand für diese neue Funktion verstehen.

  • Können wir erkunden, wie diese Funktion mit unseren technischen Möglichkeiten und Produktzielen übereinstimmt?

Das Ansprechen von Funktionsanfragen, indem man den Ingenieuren Fragen zur Machbarkeit, Komplexität und Zeitplänen stellt, fördert eine Kultur des Respekts und der Zusammenarbeit. Es erkennt die Expertise des Ingenieurteams an und integriert ihre Perspektive in den Entscheidungsprozess. Diese Methode stellt nicht nur sicher, dass technische Herausforderungen frühzeitig angesprochen werden, sondern richtet auch die Produktentwicklung nach realistischen Erwartungen und Ressourcen aus.

Ingenieure früh einzubeziehen und ihre Einsichten zu respektieren führt zu fundierteren Entscheidungen, besserer Planung und einer stärkeren, k

#implementation-disagreement

Don't say

"Es ist mir egal, wie du es machst; sorge einfach dafür, dass es funktioniert."

The same goes for:

  • Das ist nicht mein Problem. Repariere es einfach.

  • Ich verstehe nicht, warum das so schwierig für dich ist.

  • Mach, was immer nötig ist, gib mir einfach das Ergebnis.

Zu einem Ingenieur zu sagen "Es ist mir egal, wie du es machst; sorge einfach dafür, dass es funktioniert." während einer Meinungsverschiedenheit über die Implementierung ist ein großer Kommunikationsfehler. Es missachtet die Expertise des Ingenieurs, verkleinert die Komplexität ihrer Arbeit und setzt einen Ton der Gleichgültigkeit gegenüber den Herausforderungen, denen sie gegenüberstehen. Dieser Ansatz untergräbt nicht nur das Vertrauen, sondern entmutigt auch die Zusammenarbeit, da er einen Mangel an Respekt für die Perspektive und die Beiträge des Ingenieurs vermittelt. Solche Aussagen können zu Demotivation, Groll und einem toxischen Arbeitsumfeld führen, was sowohl für den Erfolg des Projekts als auch für die Teammoral schädlich ist.

Say this

"Kannst du mir deine Bedenken bezüglich dieses Ansatzes erläutern?"

The same goes for:

  • Ich verstehe, dass dies herausfordernd ist. Wie können wir das gemeinsam angehen?

  • Was denkst du, wäre der beste Weg, um dieses Feature zu implementieren?

  • Können wir einige Alternativen erkunden, die unsere beider Ziele erfüllen könnten?

Einen Ingenieur zu bitten, "Kannst du mir deine Bedenken bezüglich dieses Ansatzes erläutern?" während einer Meinungsverschiedenheit über die Implementierung fördert eine Kultur der offenen Kommunikation und des gegenseitigen Respekts. Es signalisiert dem Ingenieur, dass seine Meinung geschätzt und seine Bedenken ernst genommen werden. Diese Frage öffnet nicht nur die Tür für einen konstruktiven Dialog, sondern ermutigt auch zum Problemlösen und zur Zusammenarbeit, was eine Umgebung schafft, in der sich jeder ermächtigt fühlt, seine Ideen und Lösungen zu teilen. Indem Produktmanager aktiv zuhören und sich mit der Perspektive des Ingenieurs auseinandersetzen, können sie ein stärkeres, kohäsiveres Team aufbauen, das gemeinsam Herausforderungen überwinden kann. Dieser Ansatz hebt die Bedeutung von Empathie, Respekt und Partnerschaft bei der Bewältigung von Meinungsverschiedenheiten hervor.

#scalability

Don't say

"Wir können einfach die Server hochskalieren, wenn wir Leistungsprobleme bekommen, richtig?"

The same goes for:

  • Wenn es jetzt funktioniert, kümmern wir uns um Skalierbarkeit, wenn sie zum Problem wird.

  • Lasst uns nicht zu früh auf Optimierung fokussieren.

  • Hochskalieren ist einfach; wir erhöhen einfach bei Bedarf die Ressourcen.

Die Annahme, man könne "einfach die Server hochskalieren" als pauschale Lösung für Leistungsprobleme, übersieht die Komplexitäten der Skalierbarkeit und kann zu erheblichem technischen Schulden führen. Dieser Ansatz vereinfacht eine hochtechnische Entscheidung zu der Annahme, dass das Skalieren von Ressourcen eine Lösung für alles ist, was selten der Fall ist. Ingenieure schätzen Weitsicht in der Planung und wissen es zu schätzen, wenn Skalierbarkeit als Teil des ursprünglichen Designs betrachtet wird, und nicht als nachträglicher Gedanke. Es ist entscheidend zu verstehen, dass einige architektonische Entscheidungen die Skalierbarkeit des Systems grundlegend einschränken können, was es viel schwieriger und teurer macht, später anzugehen.

Statt einen sofortigen Anstieg der Ressourcen vorzuschlagen, fördere Diskussionen über skalierbare Architektur von Anfang an. Dies beinhaltet die Berücksichtigung von zustandslosem Design, Lastverteilung, Caching-Strategien und Datenbankoptimierung. Indem du dies tust, bereitest du nicht nur das Produkt auf zukünftiges Wachstum vor, sondern respektierst auch die Expertise des Ingenieurteams und die Komplexitäten beim Aufbau eines skalierbaren Systems.

Say this

"Wie können wir unser System von Anfang an skalierbar gestalten?"

The same goes for:

  • Welche Architekturmuster können wir jetzt annehmen, um zukünftiges Skalieren zu erleichtern?

  • Können wir unsere Strategie für den Umgang mit erhöhter Last diskutieren, während wir wachsen?

  • Welche potenziellen Skalierbarkeitsherausforderungen sollten wir jetzt schon planen?

Fragen wie "Wie können wir unser System von Anfang an skalierbar gestalten?" zeigen einen proaktiven Ansatz zur Produktskalierbarkeit, betonen die Wichtigkeit der frühzeitigen Überlegung und Planung. Diese Frage zeigt Respekt vor der ingenieurtechnischen Perspektive und anerkennt die Komplexität des Designs eines Systems, das effizient wachsen kann. Sie fördert eine kollaborative Diskussion über skalierbare Architektur und lädt Ingenieure dazu ein, ihre Expertise über bewährte Praktiken wie zustandsloses Design, Lastverteilung, effektives Caching und Datenbankskalierbarkeit zu teilen.

Durch die Rahmengebung der Konversation rund um die Planung für Skalierbarkeit von Anfang an, hebst du ein Engagement für Qualität und Nachhaltigkeit hervor. Dieser Ansatz fördert ein Gefühl der Partnerschaft zwischen Produktmanagement und Ingenieurwesen, da er darauf abzielt, ihre technische Expertise in informierte Entscheidungen einzubringen, die dem Produkt langfristig zugutekommen. Es ist eine Strategie, die nicht nur für aktuelle Leistung optimiert, sondern auch das Produkt darauf vorbereitet, zukünftiges Wachstum nahtlos zu bewältigen.

#scope-change

Don't say

"Wir sollten in der Lage sein, die Projektanforderungen unterwegs anzupassen. Flexibilität ist doch der Schlüssel, oder?"

The same goes for:

  • Ich denke, eine leichte Richtungsänderung wird nicht schaden; es ist alles Teil des Prozesses.

  • Lass uns nicht zu sehr darauf konzentrieren, uns an den ursprünglichen Plan zu halten; wir können uns bei Bedarf anpassen.

  • Es ist normal, dass Projekte sich entwickeln, also lassen wir die Dinge einfach auf uns zukommen.

Diese lässige Herangehensweise an Projektanforderungen und Projektumfang unterschätzt die Komplexität und die Welleneffekte, die selbst kleine Änderungen auf ein Projekt haben können. Es führt oft zu Scope Creep, wo kontinuierliche Änderungen und Ergänzungen den ursprünglichen Plan entgleisen lassen, was zu Verzögerungen, Budgetüberschreitungen und Stress im Team führt.

Flexibilität ist wichtig, sollte aber mit einem klaren Verständnis der Projektgrenzen und -ziele ausgeglichen sein. Ohne einen strukturierten Prozess zur Bewertung und Integration von Änderungen können Projekte leicht unhandlich werden, was Qualität, Fristen und die Moral des Teams beeinträchtigt.

Say this

"Wir sollten in der Lage sein, die Projektanforderungen unterwegs anzupassen. Flexibilität ist doch der Schlüssel, oder?"

The same goes for:

  • Ich denke, eine leichte Richtungsänderung wird nicht schaden; es ist alles Teil des Prozesses.

  • Lass uns nicht zu sehr darauf konzentrieren, uns an den ursprünglichen Plan zu halten; wir können uns bei Bedarf anpassen.

  • Es ist normal, dass Projekte sich entwickeln, also lassen wir die Dinge einfach auf uns zukommen.

Diese lässige Herangehensweise an Projektanforderungen und Projektumfang unterschätzt die Komplexität und die Welleneffekte, die selbst kleine Änderungen auf ein Projekt haben können. Es führt oft zu Scope Creep, wo kontinuierliche Änderungen und Ergänzungen den ursprünglichen Plan entgleisen lassen, was zu Verzögerungen, Budgetüberschreitungen und Stress im Team führt.

Flexibilität ist wichtig, sollte aber mit einem klaren Verständnis der Projektgrenzen und -ziele ausgeglichen sein. Ohne einen strukturierten Prozess zur Bewertung und Integration von Änderungen können Projekte leicht unhandlich werden, was Qualität, Fristen und die Moral des Teams beeinträchtigt.

#technical-limitations

Don't say

"Wir müssen hier innovativ sein, also sind eure technischen Einschränkungen keine Ausrede."

The same goes for:

  • Diese Funktion ist ein Muss, findet heraus, wie ihr es trotz der Einschränkungen schafft.

  • Können wir nicht einfach einen Workaround finden, um diese technischen Probleme zu umgehen?

  • Wir sind hier, um Grenzen zu verschieben, also sollten diese technischen Beschränkungen uns nicht stoppen.

Den Ingenieuren zu sagen, dass ihre technischen Einschränkungen keine Ausrede für das Nichterreichen von Innovation sind, missachtet die sehr realen Herausforderungen der Softwareentwicklung. Es untergräbt nicht nur die Expertise der Ingenieure, sondern fördert auch ein toxisches Arbeitsumfeld, in dem realistische Bedenken einfach weggewischt werden. Dieser Ansatz kann zu Burnout, Produkten minderer Qualität und einer Schuldzuweisungskultur führen, wenn ambitionierte Projekte nicht wie erwartet realisiert werden können.

Statt technische Limitationen zu ignorieren, sollte man sie als Gelegenheiten begreifen, um Funktionen zu priorisieren, innerhalb von Einschränkungen zu innovieren und gemeinsam an machbaren Lösungen zu arbeiten. Das Verständnis und der Respekt vor der Komplexität der Ingenieursarbeit können zu produktiveren Diskussionen und einer gesünderen Teamdynamik führen.

Say this

"Angesichts unserer technischen Einschränkungen, lasst uns Funktionen priorisieren, die mit unseren Innovationszielen übereinstimmen. Was ist machbar?"

The same goes for:

  • Können wir alternative Lösungen innerhalb unserer technischen Beschränkungen erkunden, die uns dennoch ermöglichen zu innovieren?

  • Wie können wir unseren Ansatz anpassen, um unsere Innovationsbestrebungen mit der aktuellen technischen Landschaft in Einklang zu bringen?

  • Lasst uns die technischen Einschränkungen gemeinsam überprüfen und kreative Wege finden, diese Herausforderungen zu meistern.

Einen kollaborativen Ansatz zur Innovation im Kontext technischer Beschränkungen zu fördern, erkennt die Expertise des Ingenieurteams an und validiert ihre Bedenken. Es verändert die Erzählung von Schuld zu Problemlösung und fördert eine Kultur der Innovation, die in der Realität verankert ist. Dieser Ansatz schafft eine Umgebung, in der sich Teammitglieder wertgeschätzt und motiviert fühlen, kreative Lösungen zu finden, die den Wunsch nach Innovation mit den Realitäten technischer Einschränkungen in Einklang bringen. Es führt zu besserer Planung, realistischer Zielsetzung und letztendlich einer kohäsiveren und produktiveren Teamdynamik.

#urgency

Don't say

"Können wir diese Aufgabe aufgrund ihrer Auswirkungen auf unsere Roadmap und aktuellen Kundenverpflichtungen priorisieren?"

The same goes for:

  • Angesichts ihrer Bedeutung für unsere Ziele wäre es großartig, sich jetzt darauf zu konzentrieren.

  • Diese Aufgabe steht in engem Zusammenhang mit unseren unmittelbaren Zielen, was sie zu einer hohen Priorität macht.

  • In Anbetracht ihrer Bedeutung für unseren Projektzeitplan sollten wir hier zuerst Ressourcen zuweisen.

Die Dringlichkeit einer Aufgabe zu verstehen ist entscheidend, sie effektiv zu kommunizieren jedoch umso wichtiger. Zu sagen "Können wir diese Aufgabe priorisieren, weil sie bedeutende Auswirkungen auf unsere Roadmap und aktuellen Kundenverpflichtungen hat?", verlagert den Fokus von einer vagen Dringlichkeit auf die spezifischen Gründe hinter der Notwendigkeit der Priorisierung. Dieser Ansatz bietet nicht nur Klarheit, sondern respektiert auch die Arbeitsbelastung des Ingenieurs, indem er die Relevanz der Aufgabe für die Projektziele und die Verpflichtungen des Teams hervorhebt. Es fördert eine gemeinsame Anstrengung, gemeinsame Ziele zu erreichen, anstatt mit dem breiten Etikett der "Dringlichkeit" Druck auszuüben.

Say this

"Können wir diese Aufgabe aufgrund ihrer Auswirkungen auf unsere Roadmap und aktuellen Kundenverpflichtungen priorisieren?"

The same goes for:

  • Angesichts ihrer Bedeutung für unsere Ziele wäre es großartig, sich jetzt darauf zu konzentrieren.

  • Diese Aufgabe steht in engem Zusammenhang mit unseren unmittelbaren Zielen, was sie zu einer hohen Priorität macht.

  • In Anbetracht ihrer Bedeutung für unseren Projektzeitplan sollten wir hier zuerst Ressourcen zuweisen.

Die Dringlichkeit einer Aufgabe zu verstehen ist entscheidend, sie effektiv zu kommunizieren jedoch umso wichtiger. Zu sagen "Können wir diese Aufgabe priorisieren, weil sie bedeutende Auswirkungen auf unsere Roadmap und aktuellen Kundenverpflichtungen hat?", verlagert den Fokus von einer vagen Dringlichkeit auf die spezifischen Gründe hinter der Notwendigkeit der Priorisierung. Dieser Ansatz bietet nicht nur Klarheit, sondern respektiert auch die Arbeitsbelastung des Ingenieurs, indem er die Relevanz der Aufgabe für die Projektziele und die Verpflichtungen des Teams hervorhebt. Es fördert eine gemeinsame Anstrengung, gemeinsame Ziele zu erreichen, anstatt mit dem breiten Etikett der "Dringlichkeit" Druck auszuüben.

#user-feedback

Don't say

"Dieses Feature erhält viel negative Rückmeldung. Unsere Kunden hassen es. Wir müssen es so schnell wie möglich ändern."

The same goes for:

  • Das Feedback zu diesem Feature ist furchtbar. Wir müssen es jetzt reparieren.

  • Kunden beschweren sich viel darüber. Es ist eine Katastrophe.

  • Jeder hasst dieses Feature. Es ist dringend, dass wir etwas unternehmen.

Kundenfeedback negativ und dringlich zu übermitteln führt oft zu defensiven Reaktionen anstatt zu einem konstruktiven Dialog. Wörter wie "hassen" und "Katastrophe" verstärken die Negativität und Dringlichkeit, ohne handlungsrelevante Einblicke zu bieten. Dieser Ansatz kann Ingenieure demotivieren und fördert keine kollaborative Umgebung. Es ist entscheidend, Feedback so zu teilen, dass es das Team motiviert, das Problem tiefgehend zu verstehen und gemeinsam an einer Lösung zu arbeiten. Vermeiden Sie es, sich ausschließlich auf die negativen Aspekte zu konzentrieren, und verzichten Sie darauf, Dringlichkeit zu vermitteln, ohne Klarheit über die Spezifik des Feedbacks.

Say this

"Wir haben einige Rückmeldungen zu diesem Feature erhalten, die Verbesserungsbereiche hervorheben. Lass uns die Kommentare gemeinsam durchgehen und über mögliche Anpassungen diskutieren."

The same goes for:

  • Ich habe das Kundenfeedback durchgesehen, und es gibt einige wiederkehrende Themen, die wir berücksichtigen sollten. Wie können wir diese gemeinsam angehen?

  • Einige Benutzer finden dieses Feature schwer zu nutzen. Könnten wir Optionen erkunden, um es benutzerfreundlicher zu gestalten?

  • Es gibt wertvolles Feedback darüber, wie dieses Feature die Bedürfnisse unserer Kunden besser erfüllen könnte. Können wir uns etwas Zeit nehmen, um Verbesserungen zu brainstormen?

Kundenfeedback konstruktiv zu teilen bedeutet, es als Möglichkeit zur Verbesserung darzustellen, statt nur Mängel aufzuzeigen. Formulierungen wie "Verbesserungsbereiche" und "wertvolles Feedback" fördern einen positiveren und kollaborativeren Ansatz. Es ist wichtig, das Ingenieurteam in den Feedbackprozess einzubeziehen, damit sie die Perspektive der Nutzer verstehen und zur Lösung beitragen können. Diese Methode fördert eine problemlösende Einstellung, wobei der Fokus darauf liegt, wie das Team gemeinsam daran arbeiten kann, das Produkt auf Basis des Nutzerfeedbacks zu verbessern.

#vision

Don't say

"Wir machen das, weil es das ist, was der Markt will, konzentrieren Sie sich einfach auf das Programmieren."

The same goes for:

  • Die Produktvision ist eher eine strategische Sache; das ist nichts, worum Sie sich kümmern müssen.

  • Implementieren Sie einfach, was ich im Anforderungsdokument umrissen habe.

  • Überlassen Sie die Vision uns; wir werden Ihnen sagen, was zu tun ist.

Dieser Ansatz ist ein bedeutender Fehltritt, weil er die Wichtigkeit einer einheitlichen Vision untergräbt und es versäumt, ein Gefühl von Eigentum und Zweck unter den Teammitgliedern zu fördern. Ingenieure und andere Stakeholder sind motivierter und effektiver, wenn sie verstehen, wie ihre Arbeit zum größeren Ziel beiträgt. Dieses Verständnis führt zu besseren Entscheidungen, Innovation und einer stärkeren Ausrichtung an der strategischen Richtung des Produkts. PMs sollten es vermeiden, die Bedeutung der Produktvision zu minimieren, und stattdessen darauf hinarbeiten, sicherzustellen, dass jeder im Team die Vision versteht und sich ihr verpflichtet fühlt.

Say this

"Lassen Sie uns besprechen, wie dieses Feature mit unseren Marktanforderungen und der Produktvision übereinstimmt. Ihre Einsichten sind wertvoll."

The same goes for:

  • Ich möchte unseren Produktfahrplan teilen und wie Ihre Arbeit zu unserer Vision beiträgt.

  • Lassen Sie uns gemeinsam brainstormen, wie dieses Feature besser die Bedürfnisse unserer Kunden erfüllen kann.

  • Das Verständnis der Reise unserer Kunden kann uns helfen zu innovieren. Hier ist das große Bild.

Die Einbindung von Ingenieuren in die Produktvision ist entscheidend für die Schaffung eines Produkts, das wirklich mit dem Markt resoniert. Wenn Sie sagen, "Lassen Sie uns besprechen, wie dieses Feature mit unseren Marktanforderungen und der Produktvision übereinstimmt. Ihre Einsichten sind wertvoll," teilen Sie nicht nur die Vision, sondern schätzen auch ihre Beiträge über das Programmieren hinaus. Dieser Ansatz fördert offenen Dialog, Zusammenarbeit und Innovation, was Ingenieure sich als integralen Teil des Produkterfolgs fühlen lässt.

Durch die Kommunikation des großen Bildes und wie jedes Teil zusammenpasst, stellen Sie sicher, dass jeder in die gleiche Richtung bewegt mit einem gemeinsamen Verständnis der Produktziele. Diese Ausrichtung fördert ein motivierteres Team, was zu einem erfolgreicheren und innovativeren Produkt führt.

Wer könnte von dieser Sammlung profitieren? Produktmanager und Designer arbeiten eng mit Ingenieuren, Teamleitern, die nach kuratierten Ressourcen suchen, wenn sie ihre Teams coachen, und jedem, der seine Kommunikationsfähigkeiten verbessern möchte, zusammen.

Das Umfeld, in dem PMs arbeiten, ist vielfältig, und die Kommunikationsstile sind in jeder Kultur unterschiedlich. Ich versuche, die generischsten Dialoge auszuwählen, um die Denkweise hinter den Nachrichten zu repräsentieren. Das Wichtigste ist, die Absicht hinter den Worten zu verstehen.

nohello.net hat mich motiviert, dieses Projekt zu starten. 🙏

Diese Sammlung ist inspiriert von wertvollen Threads und Artikeln über den Aufbau einer gesunden Beziehung zwischen Produktmanagern und Ingenieurteams. Vielen Dank an alle Leute, die ihre Erfahrungen und Einblicke geteilt haben.

Sie stammt auch aus den persönlichen Erfahrungen von Personen, die Produkte mit über 150 Millionen Nutzern gebaut haben und mit Ingenieuren aus vielen verschiedenen Kulturen gearbeitet haben. Und Jahre des Mentorings und Wiederholens, "Sag das nicht!"

Dunkelmodus ist verfügbar für das Lesen bei Nacht ~> Klicken Sie hier, um umzuschalten

Diese Sprachen werden unterstützt: English, Tiếng Việt, Deutsch

Zu tun: Unterstützung mehrerer Sprachen; Funktion, um aus Ihrem "Sag das nicht!" zu lernen; Machen Sie es Open Source; Fügen Sie mehr Inhalte hinzu;