Product Management Predictions

Product Management Predictions: With January already over, it’s a bit late for annual forecasts. But then again, looking into the future is a secret superpower every Product Manager should look to develop. Therefore, it’s never too late to have an understanding of what comes up next. Mason Adair of Digital Product People did so for the profession itself.

Product Management Predictions for 2020

Ten Wild Predictions, One True Story and some Solid Career Advice

From the article

Just like the industry is changing. And the article makes an effort to put into relation the different aspects Product Management has. Mason starts his thoughts by looking into public available metrics that indicate the importance and projected relevance related to management of products. In this analysis, related topics range from Agile, Minimum Viable Product, Design Thinking, Lean Startup, Product Market Fit, Rice Prioritisation and Net Promoter Score all the way to Jira, Trello and Asana. With an analysis of how relevance for these topics changed over time, the article goes into setting the scenes for professional trends that influenced the past years. These include economic environment, the introduction of new technology, a demographic shift, increasing societal fragmentation and climatic change.

Product Management Predictions shape the conclusion in his article: 10 wild predictions I believe are not that wild. The top most prediction, Product arriving at the C-Level, is almost no prediction anymore. Digital companies already have recognised the importance to actively influence direction towards customers.

Read more: The Future of Product Management in the 2020s – Mason Adair – Medium

The possibility to understand: SaaS Product Metrics

Colorful Rulers to Measure
Do you measure up?

Part of the compelling nature of SaaS Products is the possibility to understand the user and improve on the go. Any Product Manager will literally have to understand what are the use-cases for customers and how to focus on the important areas. Just recently our team led the debate which metrics would be the right ones to focus on.

Nancy Wang, Head of Product Management at Amazon Web Services, highlights six product metrics enterprise SaaS companies should track.

In this Article, Nancy Wang, head of Product Management at the most successful cloud service providers, shares her insights on important metrics to keep an eye on. The possibility to understand often goes overboard and requires focus.

The case under discussion in the article revolves around paid products. Derived metrics are a foundation that serves as a blueprint to other products in the SaaS space. Goals differ, but ultimately, to make a product successful, it requires an understanding of how successful customers were, using the product. Following the established funnel pattern, users are being segmented into funnel. Along that funnel, the metrics acquired need to reflect the stage of the journey the user is on.

At the top of the funnel, most often the interaction is anonymous and requires profiling to understand the audience coming in. Further down in the funnel, metrics capture engagement and transaction. Towards the end of the funnel, the metric needs to relate to retention.

Source: Do You Measure Up? Metrics for Enterprise SaaS Product Managers

Do away with the Product Owner Role

Mike Cohn of Mountain Goat Software has an opinion on Scrum’s Product Owner Role. It’s controversial, and Product people will disagree.

Why Would You NEVER Apply Agile Software Development Processes?

A central statement in the Agile Manifesto is to put Individuals and interactions over processes and tools. Many development teams, in particular those with less experience, lack the self sufficiency to deal with this freedom. It’s probably not the exact answer to the question, but it makes Agile a lot more difficult.

Here is the original blog: Herding Cats: Why Would You NEVER Apply Agile Software Development Processes?

Culture and Organizational Change

Just a small observation I made during AWS Transformation Day. While the entire theme for the event was on transforming business, the schedule had one track for “Culture and Organizational Change” alone. While Culture and Organizational Change is a broad and huge topic, but it is necessary and makes the difference for agility in rapidly changing and competitive markets. Amazon has been talking about this for years and they share their knowledge with their partners.

On an attempt to find out how organizations actually master this, the perspective most consultants and companies I talked to during the event shared with me was rather sobering. Anyone exhibiting at that event merely offered to run any software project under an agile management. No support, consultancy or even efforts to drive actual change, whatsoever, at least nothing that would exceed a traditional software project scope.

Cultural and Organizational Change is something requiring executive buy in and is killed quickly by means of exhaustive efforts to plan ahead. Culture needs to embrace the possibility to change quickly, throughout the process. And the wish for management is human, to have transparency and perspective early in the process, it is just as natural in the process for developers to stay vague for items that are not yet clear.

Any cultural change needs to embrace bi-directual communication and the ability to break down complex. On first thought this sounds easy, but requires plenty of cooperation and trust in a clearly defined team. Culture is rooted in clear understanding of roles, responsibilities and not to mention last, trust of all members.

Product Management vs Product Ownership

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 story of love, hate, oppression and triumph

Source: The Collision of Product Management and Product Ownership

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.

Change.

Yesterday, a software engineer, also new to the organization, roughly told me the following. The way the organisation plans projects is so different to what he is used to as a software engineer. Planning projects with a horizon of 12 or even 24 months is something he says he just cannot wrap his head around.

While this is very common and necessary in the hardware industry, it is indeed something terribly alienating software people. Software is typically treated as a living product, that takes tiny changes at a time, it is more governed towards a direction to take than having the one exact goal it has to hit by a specific date.

These very fundamental goals both mindsets follow make it difficult for change to happen. While the software engineer above obviously has a point to make, he cannot reach the people he needs to reach, because both sides are just too far apart.

At the same time, I don’t yet have an answer to the problem, but the problem itself became so obvious when this colleague told me he just doesn’t know what to say. The digital world does not yet have a common language, not to mention a common way to think about approaching problems, and unless this hurdle is taken, change will only happen slowly.