Building a product strategy is not so difficult in theory. It is mostly about the Why, What, How. In practice there are so many important topics to be included in a strategy, that it is easy to lose track of what is really important.

Building a strategy in a team does not make it much easier as the view points may vary significantly. When there is no good enough notion about the story line, wild discussions start and in every meeting a new topic or idea on what is important pops up. Probably a necessary phase. But it should not last too long, not longer until you have a good gut feeling on how the story has to look like.

Cutting short on the wild, explorative phase is needed when the incremental value of new topics or ideas is too low. Then it helps to have clear story line of maybe 10 to 15 slides with one message per slide. Build it and then the team discussion becomes more focused and effective.

And the slides (PowerPoint rules) have to be easily understood. Which costs time.

I am in a hurry and I need content for the portal. Product owners do not have time either to provide the right input. At least there is a clear, predefined structure for the content.

So I try to speed up with ChatGPT. The content structure helps to shape the prompts. And yes it helps to get the right terms to focus on. I do not like the long sentences ChatGPT provides, so I only take elements, add my own wisdom and have more than a text prototype. It can be reviewed and improved at any time.

My conclusion: ChatGPT delivers very quickly a starting point. Not more, not less.

I have been inspired by Giles Turnbull's "Doing week notes" to produce my own weekly newsletter (e-mail) about the project of developing a portal for digital services.

My intention was two-fold:

• Be conscious as a team to understand what we achieved during the week as it provides a bit of pride and confidence
• Provide transparency and awareness to any stakeholder in our organization for a topic which is not top of mind

One of the aspects was not only to have words in the newsletter but also screenshots, graphics and similar to show what has been achieved - show & tell. Links to standard documents, specifications and presentations are always included. In general I would say that the length of the newsletter including screenshots etc. is about one to two pages

What received most attention were the memes at the top of the newsletter. This is were we got most feedback for.

My observations so far:

• Many recipients are aware of the newsletter, but not all
• Memes are important to make people open the newsletter (e-mail)
• We do not know what people read and if they read
• One manager uses the newsletter content to report back to his managers
• Some people request access to mentioned internal documents, so they must have read it

Bases on the (non) feedback the newsletter evolves. The newest addition:

• TDLR with the most important things in 2 to 3 bullet points - Inspiration via Why You Should Send a Weekly Summary Email
• Soon: short videos on the functionalities of the portal, especially those which need first a login

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.