Lately, I have been using AI a lot more than in the months before. I've had a few conversations with colleagues that have inspired me.

How does this look in concrete terms, what have I done differently in the last few days?

First of all, I used the AI-based chatbot on Coursera to review and better understand my learning material.

I learned from a colleague that you can also have a conversation with AI tools. I did this during a walk to better understand a specific product in terms of technology, user flows, market participants, market size and so on. I had this conversation with Perplexity.

I also prepared customer meetings with AI, mainly because I had little time for this. I will automate this preparation even more with no-code tools so that colleagues can benefit from it. But that will take some time.

My conclusion: the more I think about my personal use cases, the more I realize how AI can help me. Am I always satisfied with the results? No, sometimes the results are too generic and I'm also not sure if everything is “true”. But more and more I see how AI improves my productivity and also my knowledge.

By the way, I didn't have this article written by an AI, but I used AI to translate and improve it.

Our HR process leads to annual formalized feedback meetings with line managers. Now it was time again. It's good that something like this is formalized, even if I sometimes find the framework too rigid. It's about evaluating my performance and commitment, making my tasks and goals transparent, discussing my development and implementing measures. So far so good.

My need is not so much to receive positive feedback, although I really appreciate it and it does me good, but to find ways together to develop myself further. For me, development means getting better, growing, acquiring new skills and abilities, leaving my comfort zone. I'm not interested in changes to the organization chart at the moment, nor am I interested in company cars. A salary increase is of course always welcome :-)

My boss and I talk to each other openly, honestly and as equals, which is how I like it. Nevertheless, I always have the feeling that there should be more, but I can't express it so concretely. I would like to reflect here so that I can formulate requirements for better quality feedback.

Positive feedback, as it is called, must go far beyond compliments. It must make transparent the extent to which it has benefited the team, the company. This is not always easy. One example: good networking. What does it achieve? What value does it have for whom? Does it make the team stronger? How much time should I invest, how can I make it even more effective? That's not so easy to answer.

I have a certain routine for my tasks and goals and a set of methods to implement them. Over the years, I have expanded my repertoire, sometimes systematically, but mostly unsystematically or by learning by doing, which is not always systematic. And I have also learned that not every task, every goal, every project creates value for “eternity”. Nevertheless, I enjoy my work.

In terms of my performance, it is important for me to have the feeling that I am creating value for the team and the company. I really enjoy that. But I can't really articulate what my value is, even though I do see my output as performance. Unfortunately, I didn't ask about the value contribution. That's a shame. However, I have found that both individuals and teams rarely ask or even answer this question. That's a shame too. And not easy.

As far as my development is concerned, measures or suggestions are actually always decided on that I can really agree with. I have to take the initiative for most of them, but that's fine, then I can adapt them better to my needs. Nevertheless, I always have the feeling that my full potential is not being exploited and developed here. Without being able to say exactly what that potential is. It doesn't make it any easier to work in an industry that changes at a rapid pace and can't always be planned.

Why am I so focused on permanent personal development/improvement? I am definitely influenced by the idea or theory of the growth mindset and value it highly. It has allowed me to focus less on complaining or forever looking to the supposedly “golden” past and more on making my own future the best it can be and ultimately becoming happier as a result. Sometimes that works.

So what can you do better? I have already asked myself a few questions. But I think HR can also improve its approach to the annual formalized feedback meeting. And line managers should acquire more feedback skills, for their own benefit, for the benefit of their team and for the benefit of the company.

I have now conducted three retrospectives with the same team on the same topic. I was very touched that the team wanted me back as a moderator after my very first retrospective, even though I am not an expert.

How did I come to moderate retrospectives? Well, I have always been of the opinion that organizations like to repeat mistakes. They don't like to analyze mistakes and turn the conclusions into institutional knowledge. So I took part in a wonderful adult education course, wonderful because Carina Holzmann was able to convey this didactically and experientially in a masterful way. It was the best learning experience per euro I have ever had.

When I think back on the three retrospectives, they were all different. Together with the team leader, I defined the goal of the retrospective each time: to analyze the latest product development and identify measures that contributed to success.

The first retrospective was a challenge. The team was neither familiar with the methodology nor with me and expected clear measures. However, concrete measures only emerged after the retrospective through discussions with two participants. During the retrospective, it was not easy to let the different perspectives have their say without losing sight of the structure and objectives of the retrospective.

Nevertheless, I was invited back a second time. Something must have gone well.

The team knew me and was more open to the methodology. The team itself had grown together better through the time spent together on the project. The measures developed had become much more concrete and feasible, and it was also much easier to get the team on board. Despite the concrete measures, the optimism that the product would be launched on time was restrained.

At the third retrospective, I had less time and was not satisfied with my methodological choice. But the team members were very respectful of each other and the long period of working together was a defining factor here. Everyone involved quickly agreed on the measures, so I was able to cancel part of the process without jeopardizing the result. Although I didn't feel optimally prepared, the team's feedback was positive, both in terms of the methodology and the measures. The optimism about achieving the (new) launch target was much greater.

I am convinced that retrospectives are an effective method for moving teams forward and developing solutions independently. The positive response from the team and the desire for further retrospectives show that it is an effective method.

I was happy just to be thrown into a retrospective. It helped me to quickly gain practical experience despite my self-doubt, which helped me to recognize what works and how after a self-reflection. However, I also realized that a retrospective works best when it is requested by the project management or the team. But here too, the team learned through practical experience with the retrospective.

Now I just need to find a course that answers the question: “How do I convince my own team of the usefulness of retrospectives? This is still a challenge.

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.