People who fulfil this broad and deep profile of requirements are rarely found in one person in industrial practice. For this reason, we have developed the Product Owner Team (POT) from the individual Product Owner. The POT consists of: Product Manager (Market), System Engineer (Technology) and Project Manager (Project).

The idea of the product-owner team has enabled us to achieve a significant relaxation in the companies: None of the three roles has to fear under- or over-employment, the search for the one “extreme qualification” is eliminated. Moreover, no new function needs to be created.

1. The project manager is not alone, project management takes place in a team. The three relevant lines of vision – market, technology and time/cost – are staffed by professionals from each field. No one sets the goal unilaterally or independently of the others. Three sparring partners work together every fortnight on the best sprint goal for a team. The quality of the target definition increases.

2. The market is integrated. In most companies, the active role of the market, i.e. product management, is essentially reduced to the creation of specifications and the market launch. At AGILE, the market is confronted with the capacitive possibilities of the technology every fortnight. This puts an end to the long list of wishes without a regulator. Strategy is the art of doing without, and this becomes very concrete at AGILE: product management is involved when priorities are set in the backlog before each sprint.

3.In many companies, the systems engineer is a key figure who combines interdisciplinary knowledge (e.g. hardware, software, mechanics). Often the career path for this is missing. Experts are promoted to group leader, even if the group strength is still too small and the expert’s leadership ability is neither pronounced nor desired by themselves.

Exactly for this there is now a solution: systems competence, which is crucial for many companies, is now getting more visibility. A systems engineer is becoming an attractive target for young, up-and-coming developers who are looking for an alternative to a line career. The competitive know-how of system and product architecture becomes a personal responsibility.

In agile frameworks, it becomes possible to use the systems engineer as a multiplier for several project teams in parallel. This gives more teams better goals. This in turn strengthens personal responsibility in the team. In this way, he can grow out of the operational role bit by bit. A self-reinforcing effect!

Before diving into the mechanics of writing a story, the team must understand that goals are much more than mere work instructions. Good goals give the team and each individual a deeper sense of meaning and help to fully realize existing potential. They serve to provide real benefit to the Product Owner, team members, and customers. A well-formulated goal also promotes efficient processes, creates necessary creative freedom, and ultimately shapes a strong team spirit. For a goal to be understood, it must be clear from the start for whom something is being done, what purpose it serves, and what the concrete result should look like.

Proven frameworks are used to measure the quality of a story. The classic INVEST model by Bill Wake ensures that stories are Independent and their scope remains Negotiable, focusing on intention rather than technical implementation. A story must be Valuable, Estimatable, and kept Small enough to fit into a sprint (ideally < 20% of team capacity). Additionally, the “PFUNDIG” model by Stefan Berger truly completes a story. A “pfundig” story is planbar (estimatable) and umsetzbar (feasible) because it is tailored to the current project status and the team’s capabilities. It is fördernd (challenging) by pushing the team out of its comfort zone and remains nützlich (useful) and direkt (direct) in its objective. By being individuell (tailored) to the situation and providing a genaue (precise) definition of boundary conditions and acceptance criteria, it ensures that no misunderstandings arise.

In practice, the goal is to keep stories as short as possible without losing essential information. A “pfundig” story precisely describes the expected result and explains the “purpose” (who uses the result and for what). Acceptance criteria (Definition of Done) are indispensable, as they define when a story is considered complete in terms of time, quality, or quantity.