About Me

Hi! My name is Areti Panou. I am a product owner at SAP SE in Walldorf, Germany working in the internal development platform.

My view point is that we should try to build systems where quality, compliance, and improvement happen naturally, not because someone enforces them, but because the environment makes them the easiest thing to do.

I started this blog in 2018 while on parental leave because I had the time to reflect on my experiences in software development since I started in 2010. The more I thought about all the challenges teams have to face to deliver products in good quality, the more questions started popping up in my head. My hope is that if I manage to formulate the questions right, I might be able to figure out the answers. Or even better, somebody else can help me get to them along the way.

How I Build: With Teams, for Teams

As synthesized by ChatGPT based on my thinking as reflected in my talks, writings, and public presentations. I stand behind this description.

1. Product = System + People + Context

Finding the big picture and bringing the right people together to improve it.

Internal platform product management isn’t just backlog grooming. It’s understanding how systems, tools, and people interact.
Every product exists inside a living ecosystem containing policies, legacy systems, compliance, teams, habits.
The internal platform’s product owner’s job is to map those connections and make them visible so that improvement becomes systemic, not local.

Practice:

Draw the flow of how people interact with the tool or process.
Identify friction points and ownership gaps.
Facilitate cross-team conversations instead of just managing tickets.

2. Quality Is a Team Sport

The role of a tester is not only to catch bugs; it’s also to coach quality.

Quality is not a separate phase or a separate person’s job.
The product owner must help create conditions where everyone owns quality from developers to designers to ops.
Coaching and empowering are more beneficial in the long run than enforcing.

Practice:

Turn “quality” into a shared goal for the team.
Make testing, feedback, and documentation visible and shared.
Ask: “Who else needs to understand this risk or decision?”

3. Compliance Should Be Meaningful

Compliance should be embedded, not bolted on.

Internal compliance systems often feel bureaucratic. We should aim to design compliance as a user experience problem; something developers naturally flow through rather than fight against.
The goal: make compliance invisible where possible, educational where necessary.

Practice:

Use automation for the repetitive parts (e.g., license checks, security scanning).
Keep manual compliance steps lightweight and contextual.
Always ask: “Does this policy still serve a purpose?”

4. Build Tools That Reduce Cognitive Load

Tools should support, not obstruct.

Internal platforms should make developers’ lives simpler, not just add abstraction.
The success of a tool is measured by how confidently and quickly teams can use it, not how many features it has.

Practice:

Observe teams using the tool; don’t rely only on feedback forms.
Measure time-to-completion for common tasks.
Focus on clarity and discoverability in UX copy, dashboards, and error messages.

5. Move from Product Owners to Problem Communicators

Quality is not a product with no bugs; It’s a product that people use and like.

The product role needs to communicate feedback from the users, and encourage iterations not just be a gatekeeper of requirements.

Practice:

Frame user stories around learning outcomes. What will we know after shipping this?
Celebrate experiments and postmortems, not just releases.
Encourage knowledge sharing (brown-bag sessions, internal blog posts, etc.).

6. Optimise for Outcomes, Not Outputs

Delivering features is not the same as delivering value.

A release is not success; adoption and usefulness are.
Embrace outcome-based thinking: focus on measurable improvement in workflow, satisfaction, or reliability.

Practice:

Define success metrics as changes in user behavior, not just delivery.
Track adoption, usage frequency, and user sentiment for internal tools.
Remove unused features to reduce maintenance load.

7. Create Feedback Loops Everywhere

Listen to what the system tells you.

Feedback isn’t just surveys; it’s observing patterns: skipped steps, workarounds, recurring questions.
Treat every complaint or confusion as a design signal.

Practice:

Instrument tools to capture usage data.
Hold “office hours” for developers to share friction points.
Treat internal docs as living design artifacts.

8. Foster Psychological Safety for Change

Change is easier when people feel heard.

Teams resist change not because they hate improvement, but because they fear losing competence or stability.
Empathy for the win. Help people feel part of the evolution, not victims of it.

Practice:

Communicate why a change is happening early.
Invite dissent and questions; document decisions transparently.
Celebrate learning from mistakes, not just success.

9. Simplify Language & Communication

Working in Babel taught me clarity.

Working in multilingual, multicultural environments is rewarding but also challenging (“Working in Babel”).
Stick with clear, simple language; shared terminology; less jargon.

Practice:

Maintain a glossary of key terms for cross-team clarity.
Review documentation with non-native speakers for accessibility.
Prefer short, active sentences in tooltips, messages, and docs.

10. Advocate for Invisible Work

If your product is doing its job well, no one should notice it.

Internal tools and quality work are often invisible when successful, yet they’re essential.
Part of the internal platform product owner’s job is to advocate for invisible value: reliability, speed, developer happiness.

Practice:

Track invisible wins (uptime, fewer errors, reduced onboarding time).
Communicate improvements in business terms (“saved X hours per week”).
Educate leadership about the compounding effect of good internal tools.