Tag: management

  • Every concept starts with a con

    Every concept starts with a con

    Solid Product Management Advise

    Unfortunately I lost the source for this quote and it’s sat in my drafts folder for more than a quarter. Still I felt like I need to write down a few thoughts about it and share it here.

    Because it’s actually solid advice to any product manager or designer, in particular those that work on concepts for new ideas.

    This, of course, is very different if you work in a corporate then it is for a start up. Then again, it’s only the type of people that raise a con.

    One very fundamental difference the start-up has to the corporate:

    • In corporate, if one person says no, your concept is out.
    • In a start up, if only one person says yes, you can move on.
  • What People Hate About Being Managed by Algorithms

    Uber ran a study to figure out, how people feel about being managed by ‘the platform’. And to no surprise, Captain Obvious helped with the results. Drivers working for the company, feel like they are managed by a micromanager, watching every small step and worse, criticising every small mistake, leads to worse, sometimes toxic results. There is way to go for algorithms to catch up with social achievements.

    It’s like having a micromanaging boss who’s always watching you.

    Source: What People Hate About Being Managed by Algorithms, According to a Study of Uber Drivers

  • Unlock your product organization’s potential by defining “done”

    Simplifying and aligning conversations with a definition of done

    All too often, the task list for your teams shared project management tool shows items like “Create Workflow” or “Define Process”. Items that do resonate well in the flow of work and in the nexus of individuals. But they do fall short of allowing the rest of the organization to grasp the meaning and even fail to do so for the reporter when some time has passed.

    Some consice expressions on expectations on what this story or ticket is about can do wonder to getting things done. Rather than “defining a a workflow”, for example the product management team would

    • Check for Duplicate Entries
    • Describe the Requirement
    • Outline all depending products
    • Draw a critical path
    • Align all stakeholders on the critical path
    • Communicate to the team

    The core idea is to eliminate any discussion about when an issue, item or story is delivered and is unique across function. Of course, the above serves as an example and will vary by team and work, and needs revision in any particular scenario. Having specific action advise will help reducing debates and focus on an actual deliverable, that is done by all opinion.

    Source: Unlock your product organization’s potential by defining “done”

  • Empowering the Product Team

    Point Towards the Mountain

    Set Rules for the Journey

    Focus on Learning and Teaching

    Empowerment is Worth it

    Source: 4 Keys to Empowering Your Product Team – Mind the Product

  • Product Manual

    Als “Product Hunt Product #4 of December 2017” ist das sicher keiner der heissen Tips. Product Manual ist aber trotzdem für jeden Produkt-Manager eine Erwähnung wert, weil sich zu allen relevanten Themen in der kuratierten Sammlung dort etwas findet. Angefangen von der Definition von Produkt-Management über Benutzer-Interaktion (Umfragen!) und Prototypen bis zur Strategie-Entwicklung.

    Product Manual

    Loaded with articles, videos, podcasts, and more, Product Manual is your essential guide to building remarkable products.

    Source: Product Manual

  • Engineering Marketing

    One important aspect of the implementation of product management roles and organisation, is the engineering partnership. The other day I found Julia Austins article on the topic that also touched the realistic options. To re-cap, these are either market oriented or engineering oriented. Either of these have their Pros and Cons.

    My few thoughts on these two approaches:

    Product Management driven Product development – While this indeed seems to be the more traditional approach, in which a “Product Manager” collects customer requirements. Nevertheless, it’s not necessarily a setup that is favourable for Waterfall development, nor is waterfall something favourable as as such for software development. It allows an organisation to maintain the customer focus through a dedicated person, that is incentivised differently than engineering.

    Engineering driven Product development – This is an approach you can read a lot about from big tech companies recently. It requires a team that is well into the field the product shall serve, which often enough is not the case. In particular large and diversified companies will struggle to give find the right people at the right time, whereas smaller, growing companies can hire for the sharply defined purpose.

    An compromise approach is sure the PM<>Engineering partnership to overcome the shortcoming, and the responsibility to maintain a customer focus is on the PMs shoulders

  • What It Takes to Become a Great Product Manager

    While doing a bit more research on Product Management, I found Julia Austins thoughts on HBR the topic. She reflects on three primary considerations for the role: Core CompetenciesEmotional Intelligence(EQ) and Company Fit

    Her original aritcle is here, the HBR release is here.

  • Produktmanagement

    Die Wikipedia definiert ein Produkt folgendermaßen:

    Unter einem Produkt wird in der Betriebswirtschaftslehre ein materielles Gut oder eine (immaterielle) Dienstleistung verstanden, die das Ergebnis eines Produktionsprozesses ist.

    In der Praxis wird ein Produkt viel zu häufig als ein Ergebnis verstanden, das am Ende des Produktionsprozesses steht. Eins der größten Hindernisse für die Digitalisierung ist dieser Gedankengang, denn damit wird die Möglichkeit einer Dienstleistung häufig ausgeschlossen.

    Gerade im traditionell produzierenden Gewerbe ist die Erwartungshaltung häufig, man müsse Apps herstellen, wie Produkte von einem Band laufen. Der Kunde kauft aber keine Glühbirne, sondern beispielsweise die Möglichkeit einen Mehrwert-Dienst in Anspruch nehmen zu können.

    Je nach Produktgruppe unterscheiden sich die Möglichkeiten für Dienstleistungen natürlich sehr grundlegend. Vom traditionellen Produkt unterscheiden sie sich aber all dadurch, dass sie mit der Auslieferung nicht abgeschlossen sind.

    Digitalisierung ist umgekehrt auch kein Enabler für Dienstleistungen, das gab es auch früher schon. Aber Digitalisierung eröffnet Möglichkeiten Kundenfeedback zu sammeln, zu verarbeiten, in Kontext zu setzen und nutzbar zu machen. Jede folgende Generation eines Produktes kann mittels diesem Feedback besser gestaltet werden und jede Dienstleistung kann zu einer besseren Kundenzufriendenheit führen.

    Wenn der Kunde sich verstanden fühlt.

  • Innovation in Organisation

    Digitalisierung ist als Schlagwort allgegenwärtig. Trotzdem bedeutet es nichts anderes als grundlegende, marktwirtschaftliche Kunden- bzw. Marktorientierung. Lediglich die Geschwindigkeit, die notwendig ist, als Marktteilnehmer mit sich ändernden Marktsituationen auseinanderzusetzen stellt besonders große Organisationen vor eine Herausforderung.

    Organisation wird in der Regel mit dem Ziel gebildet, um ein Produkt oder einen Service einer breiteren Kunden-Gruppe anbieten zu können und damit Skaleneffekte zu erzielen. Ein fertig entwickeltes, bestehendes Angebot wird in der Regel industriell gefertigt, von einer horizontal skalierten und auf das Angebot geschulten Salesforce vertrieben. Alle Abläufe zu Herstellung und Vertrieb genau dieses Produktes können gemessen und hinsichtlich Kosten und Gewinn optimiert werden. Das ist auch, was anerkannte Business Schulen in der Regel lehren.

    Innovation dagegen findet häufig in einem technischen Zusammenhang statt, mit einem herangehen, in dem zwar die Idee und das Ziel feststehen, noch nicht aber alle Schritte feststehen die zu diesem Ziel führen können. In einem kreativen Chaos, das es erlaubt, werden auf dem Weg kurzfristige Richtungsänderungen umgesetzt, das Ziel stets vor Augen.

    Es ist nicht in das Korsett starrer “Business Prozesse” eingebunden. Die bestehenden Prozesse sind in der Regel auch langsam entstanden, führen aber zu  anderen Zielen. Organisation und Innovation finden mit unterschiedlichen Zielen statt.

    Digitalisierung fordert aber beides von Wettbewerbern, die im Markt bestehen wollen und Ihren Kunden passende, innovative Lösungen anbieten möchten. Das fordert ein Umdenken in beiden Bereichen.

  • Culture eats Strategy for Breakfast

    “Culture eats Strategy for Breakfast” is a quote that is often attributed to Peter F. Drucker, but was apparently coined by Ford’s Mark Fields. Whoever said it, both have plenty of business acumen to take some credit for the thought behind it. There statement has lot of truth in it, looking into corporate structures.

    With the arrival of digitalisation it is more true than ever before. All verticals struggle with fundamentally changing markets, forcing them to innovate in technology and services, and strive for new business models. In this environment it is crucial to embrace change, which enterprise culture often outright rejects.

    Change Management has been a topic in management and HR for many years, and never has been so fundamental to organisational success as it is nowadays. Technology is converging at a breathtaking pace. The Internet of Things, as an example, requires electrical & mechanical engineers to cooperate with computer scientists and data analysts to produce a product a usability engineer designed jointly with a designer. Fundamentally different schools of though define the success of a product, and even consumer and enterprise grade of products converge in their appearance.

    At the same time, the technologic ecosystem has outgrown individual organisations capabilities. Partnerships with technology vendors require management while intellectual property needs defence at the same time.

    Organisations develop anti-patterns like “Silo Thinking” or “Not invented here” syndrome. While these cultural behaviours are tolerable in less dynamic situations, their effect can quickly go out of bounds and create a substantial counterforce to any change infused through external factors.

    Embracing an open ecosystem and building on technologies developed outside the own organisation are fundamental to innovation. This open mindset is a prerequisite for any change into agility. Any strategy aiming for change ignoring these behaviours will be eaten by this exact culture. For breakfast.