Being sort of a product manager for a portal, there are so many questions to answer from a large variety of stakeholders. With time some things become clearer, like the purpose and the type of customers to serve.

One of the tasks is to make progress more visible and tangible for the internal stakeholders to to get noticed and increase trust. Not an easy task on top of the other ones. Communication is important, but when building feels sort always more important and quality communication is never prioritized as most important.

The project started without a product manager. Since the role was filled, I got the feedback that the development is not anymore driven by the feature potential of a certain stack, but driven by a product idea. Feature development has now a purpose and serves use cases and (still imagined) customer needs in a systematic way. This statement indicates progress.

The question now: how do other stakeholders feel progress and how do I get their feedback?

It does not matter how much is reported about readiness of products, portals and the like.

Yes you argued with product management about the product readiness, you cautioned management about what the current status "really" means. Will it be understood? No. Because it is in the abstract, in the Powerpoint, in the report. It is not the real thing.

The "real" understanding starts when you accompany the stakeholders on a customer journey, which is easier with digital products. Then it becomes better understood.

Beware, the product has to have a certain maturity, because extrapolating as a non-product owner is very very hard. And the visual design has to be right as well. Not good enough, means there is no trust in the substance.

Concrete beats abstract. Don't talk about the things, show them or work directly on them.

I conducted my second "real" retrospective. I like it, it is about people.

The retrospective was conducted the second time with the same team on product development. Each time roughly 2 hours. The space between the 2 retros was about 3 months.

There were very distinct differences between the 2 retros. The first time I did not see so much "one team". There was quite some frustration in the room, which needed some space to be expressed. But there was at least one common denominator: everybody agreed to invest time in one specific topic: process descriptions.

Other results from the first retro:

• Confidence that things would get better after the retro was fairly low
• Some participants considered the retro as a good starting point for the team to really come together
• Some participants were unhappy about the lack of "concrete" measures
• There was no conclusion on how to do it. The "how" was then discussed and elaborated afterwards by 2 participants.
• there was no blame game

In the second retro I adapted the methodology to have one section which forced the participants to come up with concrete measures.

Before that I asked if the participants, looking back, if things had gotten better, the answer was quite positive ("yes"). But as a moderator, I could not really explain the root cause of this positive development. It cannot only be a retro.

The participants had to go through an analysis of their current experience with their collaboration and results, the take an outside in view, before developing concrete measures, SMART ones. The challenge here as a moderator was to make sure that:

• the discussions on how to execute the measures, on the dependencies and people to conduct it, were kept to a minimum
• the measures were indeed SMART

At the end the team was satisfied with the result BUT was still skeptical on delivering the product in time. That's a challenge for the next retro.

As a moderator I learned a lot:

• Retros make sense
• Retros have to be prepared well, having an idea on how the team ticks helps a lot to choose the right methodology out of a large catalogue
• The goal of the retros has to be very clear
• Retros are fun

IT systems are neutral and do what they are supposed to do according to what their developers have implemented.

But IT systems are done and managed by humans. The roadmap is done by humans, budget allocation is done by humans, resource governance is done by humans. And when humans act, they have interests.

Some humans believe that they act in the best interest of the company, or shareholders, or innovation, or sustainability, or revenues, or profit, or the targets they have received (which, in larger organization may contradict each other) ... and also personal interests. Hopefully the latter are not too dominant.

In this field of various interests, departments have to think about which systems they need to have a close governance aka. ownership over some IT systems or not. Then the question arises: can I trust the "other" department to do the best to achieve my goals? Will I get my roadmap prioritized in a fair way? Do we have a common agreement on the business model(s)? There is no one size fits all answer to that question.

Launch date is close, everybody concentrates on delivering the first version of a digital portfolio + portal + website.

This focus is full of energy, pushing people's performance and engagement. And decisions are focused in view of the launch.

Questions about long term effects of current decisions and approaches are considered backlog.

But maintenance is hard, often boring and still needs resources. We should be mindful of this.

We are launching a new digital portfolio. We need a "brand" name and an URL for that. We are not brand experts, but we need to have a result.

The process:

• Collect all the ideas
• Check what complies with company regulations and what not
• Discuss in a larger round what is good and not so good
• One or two persons refine the list
• Setup a new meeting to conclude

The base question is: what should the ("brand") name represent? So far the discussion is about about: what is being sold and who is selling it.

I am too lazy to google what "digital services" are.

Everybody has its own (strong) opinion on what a digital service is and especially what it is not. Probably the word "service" makes it difficult, but I don't know.

From my perspective "digital services" can be a lot of things which are exposed via a website or portal:

• APIs to whatever kind of service
• services which are managed via a portal not APIs
• ticketing
• storage for documents like bills, contracts
• documentation
• SaaS like services: CRM, billing, invoicing
• and probably much more

Anyway I do not bother too much with such a definition, as long as the stuff is exposed via a website or portal. And this will be decided case by case. A discussion over it is too much of a semantic discussion for me.