Aufbau eines Food Office

Das Lebensmittelbüro ist sinnvoll, wenn es Teams hilft, schneller bessere Entscheidungen zu treffen, anstatt eine weitere Genehmigungsebene hinzuzufügen. Definieren Sie vor dem Start das Mandat, die Kunden im Unternehmen und Probleme, die nicht lokal gelöst werden können: gemeinsame Daten, Portfoliokonflikte, Einstellung, Praxisentwicklung oder Teamabhängigkeiten.

Voraussetzungen

In großen Unternehmen können Produkte oft “von selbst” wachsen, aus den direkten Anforderungen der Stakeholder, dem operativen Umfeld des Unternehmens oder der Wiederholung von Wettbewerbern. Das Geschäft diktiert, was zu tun ist, und erwartet spezifische Fristen für bestimmte Aufgaben. In solchen Fällen ist es üblich zu sagen, dass sich das Produkt nach dem Projektansatz entwickelt.

Wenn Sie erwachsen werden, wächst die Anzahl der Stakeholder und Abhängigkeiten, und um mit Entropie fertig zu werden, kann sich der Ansatz für das Design und Produkt ändern - Iterationen, Streams, Produkte werden Diskaver machen, Dokumente auf Vorlagen schreiben und sogar einige Metriken zählen.

Dies ist ein normaler evolutionärer Weg, insbesondere für Inhouse-Lösungen, die auf spezifische Bedürfnisse bestimmter Menschen abzielen. Aber früher oder später wird die Unsicherheit so stark wachsen, dass das Team beginnt, existenzielle Fragen zu stellen - wer wir sind, wo und warum.

An dieser Stelle können wir über die Notwendigkeit einer **Produkttransformation ** sprechen, eine Möglichkeit der Umsetzung, die darin besteht, ein **Produktbüro ** aufzubauen.

Produkttransformation erfordert kein Produktbüro, aber da wir über ein ausgereiftes Projekt mit einem großen Team sprechen, ist es angemessen, über die Notwendigkeit einer Formalisierung zu sprechen.

Siehe den Unterschied zwischen dem Designansatz und dem Produktansatz

Produktbüro

Das Lebensmittelbüro ist eine Funktion, die den Produktansatz in einem Unternehmen skaliert.

Wir werden nicht über die Produkttransformation und ihre Ziele sprechen, sondern über den Aufbau eines Lebensmittelbüros, das zu einem Bezugspunkt für den Übergang zu einem Produktansatz werden kann.

Der Produktansatz beinhaltet die Arbeit in 3 Richtungen:

• Praxis - Entwicklung von Standards, Prozessen, Tools
  • Methodik und Artefakte
  • Prozesse
  • Rollenmodell und Karriererahmen
• Kultur - Arbeiten mit Menschen und Rollenentwicklung
  • Unterricht
  • Gemeinschaft
  • Tätigkeiten
• System - Unterstützung und Umsetzung von Änderungen
  • Rhythmus
  • Metriken

Praktizierende

Praktiken sind der Rahmen des Produktansatzes. Es ist normalerweise das erste, was in einem Lebensmittelgeschäft auftaucht, auch wenn es nicht so genannt wird. Praktiker bestimmen, wer was tun wird und wie sie Produktziele erreichen.

Ein häufiger Fehler von Produktteams ist Praxis für Praxis, oft am Rande eines Frachtkultes. Die Schaffung von Praktiken kann kein Selbstzweck sein.

Artefakte müssen nicht existieren, weil sie müssen, sie müssen Teams helfen, in einer gemeinsamen Sprache zu kommunizieren. Prozesse sind nicht darauf ausgelegt, Industriestandards zu erfüllen, sie sollten Unternehmen helfen, ihre Ziele systematisch zu erreichen. Das Vorbild wird nicht für Röcke in Slack benötigt, es muss die Verantwortlichen bestimmen.

Es sind Praktiken erforderlich, um den „Heldentum in ein reproduzierbares System zu verwandeln, dessen Existenz das Leben von Teams erheblich vereinfachen, viele ungefragte Fragen beantworten und einen Qualitätsstandard festlegen kann, der sich direkt auf die Ergebnisse des Unternehmens auswirkt.

Praktiken bestimmen, wie der Discovery-Prozess des Teams aussehen wird.

Methodik und Artefakte

Die Produktmethodik ist ein großartiger Diskussionsbereich.

Lean Startup, Agile, Design Thinking, Kundenentwicklung, Backwards, Continuous Discovery, Shape Up, OKR, etc. Ist das alles eine Methodik? Es gibt auch Methoden und Frameworks - JTBD, North Star, Shape Up. Und etwas kann sowohl eine Methodik als auch eine Methode sein, abhängig vom Kontext. Und einige Techniken, die in einem Bereich angewendet werden könnten, könnten in einen anderen migriert sein, wie HADI von Growth gerne in Agile Discovery erscheint. Kundenentwicklung kann vereinfacht werden, um Kundeninterview. Ist das alles, oder ist es nur eine Meinung?

Siehe Erstellen eines Produkt-Frameworks in 2 Minuten

Unsere Aufgabe ist es nicht, die Methodik zu definieren, in der wir arbeiten, sondern unseren Ansatz für die Arbeit für das Team explizit zu formalisieren.

Der Markt ist groß, jeder hat unterschiedliche Erfahrungen, einige Methoden, obwohl sie eine gut etablierte und gemeinsame Definition haben, aber unser Ziel ist es, einen gemeinsamen Ansatz zu gewährleisten.

Damit eine Methodik nicht in Abstraktion lebt, braucht sie Artefakte – kleine, praktische Vorlagen, die dem Team helfen, die Ergebnisse zu reproduzieren, zu den richtigen Fragen zu führen und sich gegenseitig den Gedanken zu erklären, den wir ausdrücken wollen.

Artefakte sollten Zeit sparen, nicht wegnehmen.

Artefakte, sowie Methoden, sind voll, wählen Sie sie für Ihre Aufgabe, aber es gibt diejenigen, ohne die Sie sich kein einziges Produktteam vorstellen können:

• Produktstrategie
• Fahrplan
• BRD/URD/PRD
• One Pager
• Release Notes

Jedes Artefakt muss eine spezifische Struktur in sich haben, die durch den Prozess und den Kontext des Produkts bestimmt wird.

Beispiele für Fragen, die wir mit Methodik und Artefakten beantworten müssen:

• Wer ist der Verbraucher dieses Dokuments?
• Welche Artefakte sollten vereint werden?
• In welchem Format beschreiben wir BRD?
• Was ist das Release Note Format?
• Wie bewerten wir den Markt?
• Wie beschreiben wir Hypothesen?

Prozesse

Der Prozess ist eine Folge der Formalisierung ungeplanter sich wiederholender Aktivitäten in geplant.

Ein Algorithmus, der formalisiert wurde, um das Leben von Teams zu vereinfachen, damit sie nicht “wieder nachdenken”.

Prozesse können sowohl intern als auch extern sein - der Prozess der Produktforschung, der Prozess der Kommunikation zwischen den Teams, der Rekrutierungsprozess, der Prozess der Kontaktaufnahme mit Gegenparteien, der Prozess der Erstellung einer Zielseite, der Prozess der Anforderung von Analysen usw.

Wie jedes Artefakt sollte der Prozess Zeit sparen, aber auch den Walker vor Fehlern schützen. In der regel ist ein formalisierter prozess eine hart umkämpfte allgemeine regel, deren verstoß für beide parteien schmerzen verursacht, oder der täter selbst riskiert, sich in den fuß zu schießen.

Prozesse sollten formalisiert und transparent sein. Je transparenter der Prozess ist, desto mehr Menschen werden ihn nutzen. Wenn es gut genug funktioniert, wird es schließlich eine Kultur werden. Aber Kultur kann keine Entschuldigung dafür sein, den Prozess nicht zu formalisieren.

Der Erfolg der Umsetzung der erstellten Prozesse hängt weitgehend von ihrer Regelmäßigkeit und Wiederholbarkeit ab. Wenn diese Parameter auf einem niedrigen Niveau sind - höchstwahrscheinlich ist der Prozess hier nicht notwendig.

Es ist auch wichtig, dass der Prozess kein Hindernis für andere Teams sein sollte. Die Situation “Prozess, Sie müssen 50 Formularfelder ausfüllen” ist ein Zeichen für ein schlechtes Prozessdesign.

Ein Prozess ist auch eine Art Produkt, das Benutzer und Leistungsmetriken hat. Sowohl die Bank als auch das Finanzamt haben einen Interaktionsprozess mit dem Kunden, beide benötigen plus oder minus die gleichen Daten, aber die ersteren werden gebeten, nur die Telefonnummer zu diktieren, und die letzteren geben ein 100-Inflationsformular an, um den Antrag auszufüllen. Wo ist der bessere Prozess?

Rollenmodell und Karriererahmen

Ein Rollenmodell ist eine formalisierte Beschreibung von Rollen, Verantwortlichkeiten und Entscheidungsbefugnissen.

Am häufigsten wird das Rollenmodell in Form von RACI / DRI präsentiert, und die Beschreibung der einzelnen Rollen wird in ** Stellenbeschreibungen ** gemacht.

Ein Vorbild ist erforderlich, um:

• Erwartungen formalisieren,
• klar definierte Zuständigkeitsbereiche,
• Beschleunigung der Entscheidungsfindung.

Häufige Situation - Rollenmodell oder Stellenbeschreibungen werden nur auf Papier präsentiert und in der Praxis nicht verwendet. Dies kann darauf hindeuten, dass die Dokumente schlecht zusammengestellt sind - oberflächlich, nicht verständlich oder irgendwo weit weg für Zecken versteckt.

Es ist eine gute Praxis, Stellenbeschreibungen so zu erstellen, dass sie bereits in der Einstellungsphase als Anforderungen für den Kandidaten verwendet werden und tatsächlich ein Leitfaden für die Arbeit sind und Leistungskriterien enthalten. Auf diese Weise können Sie sofort die richtigen Leute einstellen und die Erwartungen aneinander ausrichten.

Siehe Beispiel der Stellenbeschreibung

Bei der Erstellung eines Rollenmodells ist es wichtig, die aktuelle Zusammensetzung des Teams, die Verfügbarkeit von Ressourcen und die Last zu berücksichtigen – wenn Sie keine Business Analysten haben und die Produkte auf dem kanonischen Rollenmodell die Anforderungen nicht beschreiben, wer wird sie dann schreiben? Wenn die Anforderungen die Produkte beschreiben, wer wird Marktforschung und Hypothesen durchführen?

Die Einführung eines neuen Rollenmodells ist der Übergang von AS IS zu TO BE. Und dieser Übergang ist vielleicht nicht immer einfach, besonders wenn jemand daran gewöhnt ist, innerhalb bestimmter Grenzen zu arbeiten. Finden Sie einen Weg, um diesen Übergang mit minimalem Widerstand zu machen.

Ein weiteres wichtiges Element ist das Karriere-Framework.

Ein Karriererahmen ist eine Beschreibung der Rollen und Ebenen im Unternehmen, Erwartungen und Kompetenzen für jede Ebene, nach der Mitarbeiter bewertet und für Wachstum geplant werden.

Ihre Mitarbeiter müssen verstehen, wie sie bewertet werden und was sie tun können, um das Unternehmen zu fördern. Es ist ein wichtiger Teil der Motivation.

Sie sollten ein transparentes Notensystem und Übergangskriterien haben. Dies bedeutet, dass Sie eine Kompetenzmatrix für alle vorhandenen Rollen in Ihrem Produktbüro haben müssen.

[Siehe Beispiel der Kompetenzmatrix (#)]

Anhand der Kompetenzmatrix können Sie sich der Objektivität der Bewertung Ihrer Mitarbeiter nähern und auf Basis der erzielten Ergebnisse einen Individual Development Plan (IDP)** erstellen, der transparente Kriterien für die Förderung eines Mitarbeiters annimmt.

Siehe Beispiel für IPR

Kultur

Die Formalisierung von Methodik, Prozessen und Rollen ist einfach. Es ist schwer umzusetzen.

Sie müssen die Art und Weise ändern, wie Menschen denken, die es gewohnt sind, auf eine bestimmte Weise zu arbeiten, während sie positive Ergebnisse erzielen.

Sie werden auf eine unglaubliche Menge verbalen Widerstands stoßen, und alle Versuche, Änderungen umzusetzen, werden dazu führen, dass die Dinge wieder in Gang kommen. Dies wiederum wird die Meinung des Teams über die Bedeutungslosigkeit der aufgezwungenen Ideen weiter stärken.

Der Schlüssel zur Lösung dieser Situation ist Regelmäßigkeit und Geduld.

Ausbildung

Alle Innovationen müssen gelehrt werden, auch wenn sie klar und offensichtlich sind.

Die Arbeit in einem Produktteam beinhaltet die Arbeit mit organisierten, intelligenten und produktiven Menschen. Auf der einen Seite ist es gut, auf der anderen Seite werden sie es nicht nehmen.

Wenn sie sehen, dass die neue Art, wie Sie eine Aufgabe verkaufen, dasselbe tut, aber sie müssen mehr mentale Ressourcen ausgeben, werden sie es nicht akzeptieren, weil es kontraproduktiv ist.

Ihre Aufgabe ist es, ernsthaft zu erklären, warum wir all dies tun und nicht nur das Erlernen neuer Praktiken der Realität näher bringen, sondern buchstäblich beginnen, diese Realität mit ihrer Hilfe zu gestalten. Idealerweise sollten Sie ein Beispiel für das Team geben und zeigen, wie es sein sollte.

Das erste Mal wird nicht funktionieren, oder Sie werden von einigen gefolgt. Einige Leute werden Monate brauchen, um zu den neuen Tracks zu wechseln, und einige werden sich weigern, die Änderung zu akzeptieren. Es ist ein normaler Lernprozess.

Gemeinschaft

Der beste Weg, Änderungen umzusetzen, besteht darin, das Team dazu zu bringen, mit der Implementierung und Entwicklung des Themas zu beginnen.

Erstellen sie einen gruppenchat, halten sie q & a-meetings ab, lassen sie andere vorschläge machen, fragen stellen und streiten und diskutieren sie Änderungen untereinander.

Organisationsverhalten funktioniert so, dass es einfacher ist, Veränderungen in einer Gruppe zu akzeptieren als individuell. Je besser Sie das Team mit Ideen entzünden können, desto leichter wird die Zeit der Anpassung vergehen.

Aktivitäten

Ein wichtiges Element der Kultivierung einer Esskultur ist die Organisation von Veranstaltungen für das Team. Dies können sowohl formelle als auch informelle Veranstaltungen sein - Berichte, Buchclub, Demos, Konferenzen, Berichtssitzungen des Leiters, Mitapas.

Wenn Sie bereits eine Community organisiert haben, hilft Ihnen die Organisation von Veranstaltungen, diese zu entwickeln. Aerobatics - um die Community dazu zu bringen, Veranstaltungen ohne Ihre Teilnahme zu organisieren.

Systemsystem

Ein System aufzubauen bedeutet, alle Änderungen, die zur Erreichung des Ziels vorgenommen wurden, in Betrieb zu nehmen.

In gewissem Maße wird der Erfolg des Aufbaus eines Systems das Ergebnis des Erfolgs oder Misserfolgs des Aufbaus eines Produktbüros widerspiegeln.

In dieser Phase müssen wir sicherstellen, dass alle unsere Ergebnisse:

• berechenbar
• messbar
• zugänglich

Rhythmen

Rhythmen bieten Vorhersagbarkeit und Konsistenz. Dies sind alles regelmäßige Treffen, die das Produktionsregime bilden. Rhythmen können verwendet werden, um Veränderungen zu fördern und Kultur aufzubauen, das gesamte Team der Einheiten- und C-Levels einzubeziehen, Metriken regelmäßig zu überprüfen, Pläne auszurichten usw.

Rhythmen sind am einfachsten zu setzen, basierend auf Frequenz, Beispiele für Rhythmen:

• Wöchentlich
  • Status Sync - Status der aktuellen Hypothesen/Forschung, Risiken, Metriken
• Zweiwöchentlich
  • Sprintplanung - Priorisieren für 2 Wochen
  • Produktbewertung / Demo – was geliefert, was sich in Metriken / Verhalten, Feedback geändert hat
  • Wie man Prozess, Qualität, Interaktion, Zyklusgeschwindigkeit verbessert
• Monatlich
  • Roadmap Sync - Synchronisation mit Roadmap, Anpassung der Pläne
  • Tech / Product Health Review - Tech Schulden / Qualität / Leistung.
• Vierteljährlich
  • OKR Review - Bewertung der Quartalsergebnisse, Aktualisierung der Ziele und wichtigsten Ergebnisse.
  • QBR - eine Teamveranstaltung mit Berichten über die Arbeitsergebnisse
• Vierteljährliche Teamplanung – Abhängigkeitssynchronisation mit anderen Teams/Plattformen, Planungen

Wie bei jeder anderen Entität sollten Rhythmen einem bestimmten Zweck dienen und das Team nicht überlasten. Das Schlimmste, was passieren kann, ist, dass Teams an diesen Meetings nicht aus Gründen der Bedeutung teilnehmen, sondern weil sie es sollten.

Metriken.

Der Produktansatz impliziert, dass alle Änderungen messbar sein sollten und Metriken, Produkttransformation und Produktbüro-Konstruktion betreffen, sind an sich ebenfalls keine Ausnahmen.

Es sollten Metriken erscheinen, die die Auswirkungen von Änderungen widerspiegeln, sei es Prozess- oder Finanzmetriken.

Wie viele Hypothesen haben wir vorher getestet? Wie war die Kapazität der Teams? Wie viel sparen wir bei einem Job, den wir nicht mehr machen? Und andere:

• Annahme, der Anteil der Befehle mit Vorlagen / Rhythmen
• Zykluszeit/Vorlaufzeit
• Discovery-Qualität – der Anteil von Initiativen mit einer expliziten Hypothese + Metrik

Neben der Bewertung implementierter Änderungen können Metriken bei der Verwaltung des Lebensmittelgeschäfts helfen - wenn das metrische System für alle Streams einheitlich ist, ist es ein großartiges Werkzeug, um die Leistung einzelner Produkte zu korrelieren.