I cringe every time I see product teams use a spreadsheet to rank the ideas in their backlog based on some made-up math formula usually consisting of things like business value, user value, and technical difficulty. While this exercise is pervasive, it misses the point entirely. Our job is not to prioritize solutions. A product […]
Point Towards the Mountain
Set Rules for the Journey
Focus on Learning and Teaching
Empowerment is Worth it
The organisation that I am part of introduced an overlaying Product Management department only fairly recently, less than a year ago. Early in the time it was exciting to see this role dedicated to market and customer perspective, but it raised questions over how this was different from Product Ownership from day one.
Over the course of the past year many discussions have been led and lot’s of articles have been led. This week Anthony Murphy shared his perspective and experiences on the Product Coalition. While my own experiences with this separated role have been predominantly positive, I tend to see the necessity to split responsibilities for larger organisations. The article is reflecting on why the Agile movement created the Product Owner in the way it did and how it was meant to abolish the Product Manager to start with.
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.
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.
A useful and visual mental model that represent the product management role in relation to its environment.
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.
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.
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.