Laut dem Wrike-Produktteam sprechen wir weiterhin über die Schlüsselqualitäten für einen erfolgreichen Produktmanager. Im sechsten (!) Teil dieser Reihe werden wir mit Anton Stozhko sprechen. Anton arbeitet seit 1,5 Jahren als Associate Product Manager und wechselte vom Customer Support Team.
- Hallo Anton! Ich schlage vor, sofort mit einer Schlüsselfrage zu beginnen: Was sind Ihrer Meinung nach die drei Schlüsselqualitäten eines Produktmanagers, der in seiner Rolle erfolgreich sein möchte?
- Ganz oben steht die Fähigkeit, zu planen und Prioritäten zu setzen. Plan und Priorität sind nicht so sehr Produktmanagement, sondern persönliche Kultur oder sogar Hygiene. Der Plan ist wichtig, weil er hilft, das Unbekannte zu bekämpfen, und nur wenige, die ihn lieben und die meisten versuchen, ihn zu vermeiden. Aber wenn Sie ein Unternehmen entwickeln wollen, müssen Sie sich damit befassen. Und Priorität ist wichtig, da es niemals Ressourcen geben wird, um alles vollständig zu erledigen (gute Nachrichten - dies ist nicht erforderlich). Die Hauptsache ist, das Wichtigste rechtzeitig zu tun.
- Und wie können Sie diese Fähigkeiten entwickeln? Kann man sagen, dass sie aus einem Verantwortungsbewusstsein für das stammen, was in Ihrem Team und in Ihrem Unternehmen geschieht?
"Nun, sicherlich nicht für alles, was passiert, sondern nur für das, was in Ihrem Verantwortungsbereich liegt." Sie können sie wie alles andere entwickeln - durch Wiederholung. Eine kleine Einschränkung: Es ist schwer zu lernen, wie man gut plant, bis Sie selbst ein Produkt werden. Die Notwendigkeit für diese oder jene Aktivität ist nicht besonders sichtbar, der wahre Wert ist nicht klar. Wrike hat mich hier sehr erschüttert: Mir wurde klar, dass es nicht so viel persönliche Zeit gab, wie ich dachte, und die Liste der priorisierten Aufgaben ist unendlich. Ich habe immer noch eine Reihe von Anfragen im Support vor Augen, wo ich angefangen habe.
Um diese Fähigkeiten zu entwickeln, müssen Sie versuchen, diese Prinzipien auf absolut alles anzuwenden, was passiert. Fälle für den Tag, Urlaubspläne, Antworten auf Nachrichten von drei oder vier Kanälen, Teampläne für das Quartal. Als nächstes müssen Sie lernen, wie Sie Fähigkeiten auf die Aktivitäten anderer Personen übertragen können: auf Teams und deren Planung, auf Produktmanager und deren Vision.
Mir ist aufgefallen, dass ein kühler Impuls zur Planung und Priorisierung die Möglichkeit gibt, sich zunächst einen „perfekten Zustand“ vorzustellen. Wenn Dinge erledigt sind, Entscheidungen getroffen werden, Funktionen ausgebügelt werden, Metriken erreicht werden. Sobald sich zu einem bestimmten Zeitpunkt der Idealzustand im Kopf gebildet hat, können Sie beginnen, den Ball abzuwickeln.
- Und wie kann man es abwickeln?
- Natürlich Fragen stellen. Dies ist nur die zweite Schlüsselkompetenz - die Fähigkeit, sich selbst und anderen Fragen zu stellen: „Was brauchen Sie, damit dies geschieht?“, „Was fehlt?“, „Was ist für eine Person ohne Kontext unverständlich?“. Große und unartikulierte Fragen werden zu kleinen und spezifischen Fragen. Beantworten Sie auch hier nicht alle auf einmal. Denken Sie an das erste Prinzip.
Die Wichtigkeit der Fähigkeit, Fragen zu stellen, wird wahrscheinlich in allen Büchern über das Produkt geschrieben, aber es gibt einen großen Fokus auf die Frage "Warum?". Ich werde nicht streiten - Kundenforschung ist ein nützliches Thema, aber andere Fragen sind nicht weniger wichtig. Stakeholder interessieren sich oft für „Was und Wann?“. Das Team interessiert sich für „Warum und in welcher Reihenfolge?“. Jeder interessiert sich für „Was und Warum?“.
Die Besonderheit der Arbeit des Produkts ist, dass in Ihrer Tasche nicht immer mehr Antworten als Fragen sind. Aber der Wunsch, Antworten zu erhalten, ist das Geheimnis des Kampfes gegen die Routine.
- Wie weit gefasst sind die Aufgaben, an denen Sie als Produkt einer Oouner im Rahmen einer Strategie arbeiten müssen? Senden Sie nur eine allgemeine Vision oder spezifischere Dinge? Zum Beispiel ist die Situation typisch, wenn sie sich an Sie wenden: „Wir möchten, dass dieser Teil des Produkts so ist“. Und dann stellst du ein Team zusammen und sagst: "Leute, mach es so."
- Ich habe eine Lieblingsmetapher über den Hammer und den Amboss. Hier lebt das Produkt dort, wo sie sich treffen und Funken fliegen. Der Hammer ist eine Top-Down-Bewegung. Hier und Vision und Strategie auf höchster Ebene und OKRs und manchmal sehr spezifische Aufgaben. Einsichten entstehen in verschiedenen Formen mit unterschiedlichem Grad an Wichtigkeit und Raffinesse. Das sind alles Wünsche. Amboss ist eine Bottom-Up-Bewegung. Dies ist die Codebasis, die Ressourcen, die Stimmung der Mitarbeiter im Team, die aktuellen Prioritäten und die vorhandenen Pläne. Es ist eine Realität. Wo Wünsche auf Realität treffen, muss man beides schaffen.
Also die Antwort auf die Frage: "Wie passiert das?" - "Unterschiedlich"!
Es kommt vor, dass Sie eine Idee von einem Top-Manager abwickeln und verstehen, dass eine Art Fluss möglicherweise einen großen Wert hat. Meine Aufgabe ist es, diesen Wert zu identifizieren, zu verstehen, wie er in den Workflow integriert wird, und zu überprüfen, ob er die vorhandenen Prioritätsaufgaben nicht beeinträchtigt.
Es kommt vor, dass eine ganz bestimmte Aufgabe erledigt wird und erledigt werden muss.
Übrigens unterscheidet sich eine direkt gesetzte Aufgabe aus einer Idee, Einsicht oder Strategie im tiefen Sinne nur durch den Grad der Annäherung und Raffinesse.
- Und sagen Sie mir bitte, was ist der Unterschied zwischen einem Produkt und einem assoziierten Produkt im Kontext von Wrike?
- Zuallererst ist dies die Ebene der Entscheidungen, die Sie treffen. Schauen Sie: Ich bin gekommen und wurde Associate Product Manager, und mein Manager sagt zu mir: „Lassen Sie uns Kalender erstellen, damit sich Marketingagenturen, die Wrike verwenden, wohl fühlen“ (ich meine die Funktion „Kalender“ im Wrike-Produkt). Und ich antworte: „Nun, wenn wir sie gesehen haben, dann sollten sie so sein. Es sollte Filter geben, die Möglichkeit, einen externen Link zum Teilen zu erstellen und vieles mehr. “ Ich beschreibe die Details einer Funktion, die noch nicht existiert, aber die Funktion selbst ist verkauft. Für etwas bekomme ich die Genehmigung und beantworte irgendwo zusätzliche Fragen.
Gleichzeitig, wie die Funktion funktioniert und warum sie benötigt wird - jeder versteht. Daher erhalten Sie zu diesem Zeitpunkt eine Aufgabe in der Form: "Komm schon, mach es." Die operative Leitung des Teams liegt bei Ihnen und füllt den Rückstand. Dies ist nicht der Hauptbestandteil des Produkts, sondern ein hervorragender Ausgangspunkt.
Füllen Sie den Rückstand, den viele wissen. Es ist nicht kompliziert aufzuschreiben, wie eine Funktion funktionieren soll, wenn Sie sie erstellen und dann mit den Entwicklern besprechen. Alles was folgt ist eine Frage der Bewertung und Planung.
Alles was ich beschrieben habe ist das Startlevel. In der nächsten Phase der Entscheidungsfindung haben Sie bereits andere Fragen. Nicht "Welche Funktion wird es sein?", Sondern "Was soll ich tun?" Dies ist die Frage, die ich mir gestellt habe, als ich anfing, an Blaupausen zu arbeiten (Hinweis - eine der neuen Funktionen des Produkts). Niemand sagte mir: "Machen Sie Blaupausen und entscheiden Sie, was sie sein werden." Mir wurde gesagt: „Es gibt ein Problem mit wiederkehrenden Arbeiten. Was machen wir?"
Dann kommt die dritte Ebene der Entscheidungsfindung. Hier bezeichnen sie kein Problem mehr für Sie, sondern sagen: "Wir denken, dass es hier vielleicht irgendwo ein Problem gibt." Und Ihre Aufgabe besteht bereits darin, ein Problem zu finden.
- Das heißt, auf der dritten Ebene heben Sie zunächst das Problem selbst hervor, schlagen dann selbst eine Lösung vor und bringen dann alles zum Ende?
- Ja. Und für mich sieht es schon nach einer Abschlussarbeit aus. Wenn Sie selbst recherchiert haben, haben Sie alles verstanden, mit allen gesprochen, Ihre Vision mit der Realität verschmolzen, allen alles gezeigt, alle von allem überzeugt. Zusammenfassend lässt sich sagen, dass Sie in jeder Phase immer eine Einführung erhalten. Die Frage ist, wie definiert sie sind. Und mit jeder neuen Entscheidungsebene erweitert sich der Horizont des Unermesslichen.
- Verstanden. Sie sagten, dass er auf der Ebene der Blaupausen bereits auf der zweiten Entscheidungsebene und auf der dritten Ebene an der Lösung des Onboarding-Problems gearbeitet habe. Gibt es eine vierte, fünfte Ebene und so weiter? Oder gibt es noch ein Ende?
- Wahrscheinlich ist die vierte, wenn Sie eine Gruppe von Produktmanagern haben. Die Arbeit in einem Scrum-Team ist nicht mehr Ihre Routine, und Sie haben ein neues Team, das aus Produkten besteht. Jeder von ihnen hat eine Art Vision und ein Problem, das sie zu lösen versuchen. Und Ihre Aufgabe wird zu einem effektiven Wunschmanagement mit den Realitäten jedes dieser Produkte.
Das heißt, die Skalierung geht im Wesentlichen weiter: Die Anzahl der Horizonte, die berücksichtigt werden müssen, nimmt zu. Dies ist dank Delegation möglich. Und auf dieser vierten Ebene müssen Sie sicherstellen, dass diejenigen, die jetzt auf der dritten Ebene sind, mit solchen Vorschlägen und Präsentationen zu Ihnen kommen, auf deren Grundlage Sie eine Entscheidung treffen oder Ratschläge geben können, damit sich das Rad dreht.
- Gut. Kehren wir zur ursprünglichen Frage zurück. Sie haben bereits Pläne, Prioritäten und die Möglichkeit, Fragen zu stellen, erwähnt. Und was ist Ihrer Meinung nach die dritte Qualität für einen erfolgreichen Produktmanager?
- Wie mein Mentor gerne sagt: „Die einzige Produktressource sind die Beziehungen zu anderen Menschen“, dh die Kommunikation.
- Und mit welchen Problemen müssen Sie sich im Rahmen der Kommunikationsfähigkeit täglich auseinandersetzen?
- Auf der täglichen Ebene gibt es zwei häufige Probleme: Missverständnisse und Unterkommunikation. Informationen werden entweder nicht in ausreichenden Mengen empfangen oder in bösartige umgewandelt. Infolgedessen werden zusätzliche Bewegungen ausgeführt und einige Prozesse gestoppt. Die Korrektur beider ist mit zusätzlichen Kosten verbunden.
Diese Probleme können auf jeder Ebene relevant sein. Je höher das Level, desto teurer das Update. Ein Beispiel innerhalb eines Scrum-Befehls: Ein Mitarbeiter befand sich nicht im Plan, und es wurden keine Informationen an ihn übermittelt, oder das Produkt wurde schief definiert. Alles kann passieren. Infolgedessen hat der Sprint eine Aufgabe, für die nicht alle Schritte abgeschlossen wurden, damit er in die Entwicklung übernommen werden kann. Angenommen, die Entwicklung ist recht einfach: Sie implementieren sie, und dann stellt sich heraus, dass sie entweder zu früh begonnen wurde oder überhaupt nicht durchgeführt werden musste. Die nächste Stufe des Spaßes ist das Kommunikationsmanagement zwischen Teams oder Abteilungen.
- Ich möchte ein paar Fragen stellen. Sagen Sie mir bitte, ist Ihr Hintergrund zunächst original oder nicht?
- Nein. Ich habe noch nie in meinem Leben eine Codezeile geschrieben. Nun, vielleicht bei BASIC bei einem Informatikunterricht in der 6. Klasse vor 100 Jahren. In meiner Arbeit ist dies kein Schlüsselfaktor.
- Viele Menschen sind sich in dieser Frage nicht einig. Denken Sie, dass ein technischer Hintergrund Ihnen hilft, ein besserer Produktmanager zu werden?
"Es wird Ihnen helfen, Ihre Nase in die Angelegenheiten Ihrer Entwickler zu stecken." Wenn dies ihnen hilft, ist dies ein Plus. Wenn dies sie oder Sie daran hindert, Ihre Arbeit schneller und effizienter zu erledigen, ist dies ein Minus. In jedem Fall ist das Produkt kein einsamer Wolf. Ich liebe das Sprichwort von Game of Thrones: Wenn der Winter kommt, stirbt der einsame Wolf, aber das Rudel überlebt. Hier geht es um den Wert des Spiels in einem Team. Ich muss kein JavaScript kennen, aber sie müssen wissen, wie man einen Einkaufsbrief ausfüllt.
- Wenn Sie ein Thema nicht vollständig verstehen, stellen Sie Ihrem Team Fragen und treffen Entscheidungen basierend auf deren Antworten?
- Genau das passiert. Ich bin überzeugt, dass wir jetzt das Wichtigste tun, und ich weiß, wie viel es kostet. Ich sollte immer daran denken und die Komplexität mit dem Ergebnis korrelieren.
Dies wird für jeden Schritt durch ein spezielles Gleichgewichtssystem festgelegt, bei dem Sie prüfen müssen, ob es zu kostspielig ist, diesen Schritt in Bezug auf den daraus resultierenden Wert auszuführen, und ob Sie keinen Schritt verpasst haben, aus dem Sie viel Wert ziehen und gleichzeitig machen können Es ist billig. Der wichtige Punkt hierbei ist, dass ich die Höhe des erzielten Wertes bestimme - dies ist mein Gleichgewicht. Und wie viel es kostet, wiegen die Entwickler. Wir kommunizieren und bestimmen, welchen Schritt wir tun sollen.
- Das heißt, die folgende Situation ist möglich: Sie forschen und finden einen Punkt, an dem der Wert enorm ist. Dann kommen Sie und geben das beschriebene Problem oder die beschriebene Lösung an, und die Entwickler sagen Ihnen, dass das Gewicht zu groß und nicht vergleichbar ist. Dann können Sie weitere Arbeiten an dieser Entscheidung ablehnen, oder?
- In einer solchen Situation besteht alle Hoffnung für Entwickler, da der Einheitswert nicht geändert werden kann. Aber vielleicht besteht die Möglichkeit, die Stückkosten zu ändern.
Es kommt oft darauf an, wie Sie das Problem formulieren. Sie können sagen: "Wir müssen sicherstellen, dass die sich wiederholende Unteraufgabe in die sich wiederholende Aufgabe kopiert werden kann." Und Sie können ein wenig auf die andere Seite gehen: „Wir versuchen, ein Problem zu lösen, wenn es eine Unteraufgabe gibt, und wir müssen sie so gestalten, dass sie in der übergeordneten Aufgabe regelmäßig erstellt und gespeichert wird.“
Die angegebenen Aufgaben scheinen sehr ähnlich zu sein. Aber im ersten Fall sage ich den Entwicklern, dass sie den vorhandenen Mechanismus sich wiederholender Aufgaben reparieren müssen, und im zweiten Fall mache ich keine solche Einschränkung. Und auch Semantik. Nicht "notwendig", sondern "wir". Es funktioniert gut, ein Problem zu lösen, und wie es gelöst werden kann, liegt im Verantwortungsbereich des Teams. Dies ist ihre kreative Freiheit und ihre Möglichkeit der Selbstverwirklichung.
- Und wenn sie mehrere Lösungen für das Problem vorschlagen, wer schätzt dann die besten? Timlide?
- Ich weiß es zu schätzen. Wenn ich nicht weiß, welche Lösung effektiver ist, bedeutet dies außerdem, dass ich dem Team nicht die erforderlichen Fragen gestellt habe. Dies bringt mich übrigens zu einem sehr wichtigen Thema - über das Team. Es ist wichtig, das Team über das Ziel zu stellen.
In bestimmten Fällen können natürlich Ausnahmen gemacht werden. Wenn zum Beispiel eine sehr harte Frist festgelegt wird, die von außen festgelegt wird: dringende Entwicklung für einen großen Kunden, eine Freigabe für einen strategischen Partner, mit dem Sie die Integrationsausgabe synchronisieren müssen, und so weiter. Dann müssen wir uns nur noch hinsetzen und es tun.
Aber meistens merkt man, dass die Frist etwas kürzer ist als der Zug, der zum Meeting fährt. Dann müssen Sie die Seite des Teams auswählen. In Wrike spüre ich das wirklich, weil es teurer ist, ein Team zu schütteln, als ein Produkt zu wechseln.