The Value Of Your Stakeholder

Almost 30 years ago, I worked as an editor for a German computer magazine called “PC Praxis“. With a monthly circulation of about 200,000 copies, it was the top-selling magazine. In these days, you could be a know-it-all, we were exploring and writing technological history in real-time: I disassembled huge desktop computers and tested graphic cards, hard disk drives and modems; installed, tested and reviewed software (on DOS 3.1) and games, wrote how-to-articles and experimented with the Usenet.

The publishing house belonged to a very famous car sales company in Düsseldorf specialising in exotic cars: Ferraris, Bugattis, many old American brands. In the late 80s, they opened a computer store and published their own computer books. Because there weren’t any.

Working agile in the 90s

I did not understand that both the owners and the editor-in-chief were quite futuristic, even “agile“ thinkers. We had editorial planning sessions as “sprint planning“, in which we pitched our stories to each other and decided in the team which story would have the highest value to our readers. We worked in increments — each article got proof-read and layouted right away. And we had sprint reviews with stakeholders (we had several contests and surveys in the magazine, and had to answer many “letters to the editor“).

We even held sprint retrospectives, in which we debated — often in a blunt German way — on what worked and what didn’t. These meetings often ended in an emotional bloodbath because there was no Scrum Master around trying to keep the crowd civilised.

Beer drinking or customer surveys?

There was one element we all hated: offline customer surveys. Each Friday afternoon, one of us had to visit the computer store to meet potential readers. The editor-in-chief urged us to find out what they were buying, and what made them decide. What else they were thinking to buy and what they did or didn’t like in our magazine. Monday morning we had to present our results. Often this resulted in altered articles.

While some editors went to a nearby café or bar and faked their result, I diligently followed the order. I might have been too shy or couldn’t grasp the value of it, so I decided on slightly bending the rules: Instead of asking the first 50 people to enter the store, I was quite selective.

I only asked nice-looking people and customers carrying fancy stuff to the counter. Not only that, but I ignored the ones with stacks of printing paper in their hands. My questions weren’t always powerful, and every so often I tried to ask questions leading to an answer I needed to pitch an article. “You really would love to read about that new ink jet printer, wouldn’t you?“

Who is afraid of the customers?

Thirty years later, the value of knowing exactly what your customers need or what makes them happy should be clear. But then I often worked with clients who knew little about their customers. They based products and improvements on wild guesses, and it was impossible to create deep personas. Product managers seemingly tried to avoid mingling with pesky customers.

In many companies, internal stakeholders seem to be the most important ones. It is all about power and influence. There is lots of strategizing and talking going on. Many still see customers a herd of necessary milk cows. In the Scrum framework, the team is encouraged to work closely with internal but also with external stakeholders, especially real customers.

The product owner as a value maximiser needs to be on top of the game. Not only schmoozing with the internal stakeholders to get more budget but constantly reevaluating the value to customers. And the product owner needs to know exactly what makes customers tick.

Tear down the silos. Let us talk to stakeholders

In many cases, the development team is shut off from all others in the company. I worked in projects in which I was not allowed to have contact with other competing departments. Nor was I allowed to call an internal expert if I needed further information. I had to ask the marketing manager. She would send a project manager to a different department and there they would flatly decide that such a contact would not be necessary.

We all know that the quality of the product will suffer from such territorial thinking. In Scrum, the self-managing development team may contact relevant stakeholders to clarify tasks. In the sprint review, stakeholders are highly beneficial to give input for further adaptions. We should value their expertise, inspect and adapt.

But which stakeholders are the dearest?

In German, we say “many cooks spoil the porridge“ (… the broth): You might have too many stakeholders in the most direct feedback loop, which might make things even more complicated. So, which stakeholders should you make as your best friends and allies? I found a useful guide in the highly recommendable book “The Zombie Scrum Survival Guide”. How about asking these three questions to identify the people who have an actual stake in your product:

1. Is this person using, or going to use the product regularly?
2. Is this person investing significantly in the development of the product?
3. Is this person deeply invested in solving a challenge that your product addresses?

Based on these questions, what about the marketing department? Of course, they need to know what is happening to prepare campaigns and materials. But I think they should be more in a “developer“ role. Too often a team introduces a product with great UX, but the contents suck or do not exactly address the customers’ situation in the best tonality. Wouldn’t it be better to work on this right in the beginning? May this could be part of the Definition of Done?

Consistent stakeholder involvement and active, transparent communication is key. Moreover, I believe it is significant to engage your stakeholders on all levels. They need to understand that in the end it is all about the value for the customer and quality of the product.

We are not in the game to soothe the ego of a power broker, but to ship valuable products and services people care about. The more value we offer in shorter time, and the faster we learn and adapt, the more successful we will be. I have finally learned the lesson.