no more cubes

Category: Product, Projekt & Agile

Product, Projekt & Agile: Thoughts and articles that touch and cover Product and Project Management, for the majority with Agile Methodologies. These items include Market Observation, Competitive Analysis, Backlog Prioritisation, but also choice of tools and technology.

  • Competitive Analysis and Strategy To Win

    A product’s success is not only defined by its features. Whether it can win in the market to a large extent is owed to the environment it is offered. Customer requirements, competitive offering, market climate, environmental conditions, total cost of ownership (TCO) can have an impact on the products success. A competitive overview is essential for any product manager and a competitive analysis can help sharpen the view.

    Product School just today let Joao Fiadeiro share the experience he gathered during his tenure at Google as a Product Manager for Youtube.

    Competitive Analysis and Strategy To Win by YouTube PM in Product School.

    Competitive Analysis
    Competitive Product Analysis

    Source: Competitive Analysis and Strategy To Win by YouTube PM – Product School

  • Pyramid of product manager needs

    Pyramid of product manager needs

    Benoit des Ligneris describes a model in his article about the environment in which product management has to navigate. This environment has many influences, and a product evolves with influences from many sources. The Maslov inspired pyramid of Product Managers needs starts with real world dependencies. The market is the basis for any product, hence is the most needed input to any product and the product management. Further in the article Benoit describes the individual layers and why they are relevant to the Product Management organisation.

    While objectively everybody will agree a Product Manager will need to mediate between these layers, it may be worthwhile to evaluate the level of influence each individual layer has in a particular organisation. Most often the influence on the product is reversed and higher levels influence outcomes more than they should.

    It’s the product management organisations responsibility to feed the product by its needs and not just represent but balance all layers in the decision management process. A lot like in the Maslov pyramid, a healthy product starts with basic needs.

    Product Management Pyramid
    Product Management Pyramid

    A useful and visual mental model that represent the product management role in relation to its environment.

    Source: The pyramid of the product manager needs (Maslow inspired)

  • IntelliCode for AI-assisted now available

    Microsoft trained an AI with Github projects that have more than 100 stars on them. The AI is supposed to help coding. And it is available now. AI is not yet there to take a programmers job, but Facebook took similar approaches to speed up development. Be afraid, coding people.

    Symbolbild (Techcrunch)

    IntelliCode, Microsoft’s tool for AI-assisted coding, is now generally available. It supports C# and XAML in Visual Studio and Java, JavaScript, TypeScript and Python in Visual Studio Code. By default, it is now also included in Visual Studio 2019, starting with the second preview of version 16.1, which the company also announced that. IntelliCode is […]

    Source: Microsoft’s IntelliCode for AI-assisted coding comes out of preview | TechCrunch

  • Tech for Managers

    First, I was excited to see a “Web Technologies for Managers” course exists.

    Then, I reminded myself how often I rant on the internet that “tech is dead” and all industries get digitized. It’s not too long ago that successful companies required their managers to have an understanding of the business they are in. That is mechanical engineers managing car manufacturers, electrical engineers managing electronics businesses. Only the digital industry seems to have technical managers and business managers.

    I periodically remind people how difficult the question “are you doing business or technology” is any tech driven. Even McDonalds has their managers flip burgers to start their engagement with the company, to give them an understanding of how the business looks like really.

    Next time you hear this question, or worse, ask this question, ask yourself: “Am I in the right business”. Likely, you are better qualified doing something else. The reasoning for this harsh thought is simple. Assuming you see yourself in the high tech business and expect your counterpart to do business with you, you need to radiate confidence about what you are doing. Asking this question high tech managers clearly transports you only know half of the story.

    Being an engineer and a business person, I haven’t taken the course itself, hence I cannot recommend it. But I can recommend any person in the business to flip burgers for a few weeks, or the digital equivalent, follow a few technical tutorials. Preferrably from the company you are working for but also, Google, AWS or Github offer plenty of free courses to get your hands dirty. And all of these are free of charge, there is no excuse not to understand technology to that extent that it adds value.

    Nevertheless, here is the link: “Web Technology for Managers“. Go learn something.

  • DIB_DETECTING_AGILE_BS_2018.10.05.PDF

    Das Pentagon hat sich vom Defense Innovation Boards ein Papier erarbeiten lassen, wie Agile BS zu erkennen ist. Die ein oder andere Frage wird dem geneigten Leser aus der Softwarebranche sicher bekannt vorkommen.

    Das Paper ist hier: DIB_DETECTING_AGILE_BS_2018.10.05.PDF

  • Fixing issues in Software

    So machen Profis das.

  • Agile Werte

    Mein Team führt schon seit geraumer Zeit eine Diskussion darüber, wie man den Prozess verbessern kann. Und das ist auch gut, denn ständige Verbesserung ist ein zentraler Bestandteil jeden agilen Handelns.

    Allerdings liegt die Antwort auf die Frage nie in Werkzeugen und deren Möglichkeiten. Um das Problem zu lösen muss dessen Ursache verstanden werden. Jira bietet sicher viele Möglichkeiten, noch ein Feld einzuführen. Wenn die Diskussion sich darum dreht, welches Feld am besten ergänzt wird und wie ein Zustandsübergang abzubilden ist, ist das agile vollkommen aus den Augen verloren.

    Eine unmittelbare Konsequenz von Werkzeugen ist, dass sie es Teammitgliedern erlaubt, Verantwortung abzugeben. Der Zustand wird möglicherweise richtig abgebildet, das Feld richtig gefüllt. Nun ist es an jemand anderem das technische Problem zu identifizieren, die Person weiss möglicherweise nicht einmal über den Zustand Bescheid.

    Agil soll heissen, das Vertrauen aller Mitglieder im Team soweit herzustellen, dass notwendige Arbeit in Standup Meetings oder spätestens im Review transparent gemacht wird. Dabei kann kein Tool helfen.

  • Sysyphonian, Infinite Ikea Instruction.

    Gregor Weichbrodt built a infinite IKEA instruction manual.

    The website of his BÆBEL Project is here.

  • Complex Requirements

    Complex Requirements

    via Agile Scout.

  • When a Project dies

    When is a project dead?

    One question that somebody asked me a few days back keeps me thinking for a while now. Mostly, because it should not have a clear answer. Have you ever had to ask yourself, what to do when your heart-project is at risk to coHantelnme to an end? A project that just dies, has had some serious problems.  A dead-end, that leaves no next steps, along a final decision. In a way that no project goal materialized and no other milestone is reachable? If that is looming to happen, one should consider to check the project plan and answer a couple of questions about the failure. How did all the tasks and work packages depend on each other, that they made an entire project fail? Were some assumptions to optimistic? Was budget too tight? Was the project to ambitious?

    The show must go on

    KabelDepending on size, no project is barely ever dead. Typically, a project consists of multiple components. Milestones, Tasks, Work-Packages, are just common terms for break downs structures of a project. Such fragments, re-used or re-arranged, can help achieving a modified goal. There are reasons, one or another milestone had difficulties. There are hard facts, like budgets, technical dependencies or necessities, required skills, availability of material or combinations of anything. And there are soft facts, like project team engagement, stakeholder opinion, even hubris may result in milestones not being reached.

    Failure

    A roadblock, identified early enough, allows to realign a project plan, to cope with any trouble, endangering tasks and milestones. In an iterative project approach, the project lead can change a goal, aligning with changing requirements. This way, the project may not reach it’s initially intended goal, but it will not fail in its totality. When a project dies, it will leave bad feelings with the budget owner, with stakeholder and the team. A goal that the team reached, maybe through a more creative approach, will still be a goal reached.