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.

Linux at 25: Why It Flourished While Others Fizzled

Linux, the open source operating system that virtually powers all of webservers, billions of Android phones as it’s kernel just as well as the majority of home routers and IoT devices, turns 25 years this year. IEEE Spectrum runs an article on the history and why the open kernel became so successful.

Timing, cost, and the right license made all the difference.

Also, Linus Torvalds has an approach that would be called agile these days. Bringing a feature in place is more important than having the 100% solution, and Linus explains this approach in the accompanying Q&A session:

I’d rather make a decision that turns out to be wrong later than waffle about possible alternatives for too long.

via: Linux at 25: Why It Flourished While Others Fizzled – IEEE Spectrum