Marta Kossowska
Product Owner, STX Next, Poland

Marta has over 8 years experience in software project and product development. She has acted in the different roles including business analyst, product manager and finally Product Owner. She gained her professional skills working for the biggest e-commerce and e-payments companies in the Central Europe, where she focused on developing the on-line payments system for marketplace. Currently Marta works as a Product Owner in the STX Next – an agile based software house – where she supports teams in delivering great software for their clients. She discovers the ways in which POs can maximize product’s value working in different contexts and organizations. She’s enthusiastic about sharing her knowledge and experience with others: she was a speaker at the Agile Tour London 2015 and at the local agile events and webinars.


Vision, responsibility for product’s ROI, decision making power, knowledge about the market and the end-users, impact on the organizational level… at the same time availability for the team and detailed product knowledge allowing to manage Product Backlog effectively. They’re usually the attributes of the exemplary Product Owner.

In the real live many so-called Product Owners work in the environments where achieving these attributes is very difficult or even not possible. A corporation with no single person responsible for product value and a software house where the product vision is owned by the client are the two examples we’re going to show.

We’ll share two case studies of the PO role in a corporation and in a software house working on financial products. We’ll try to answer the question how to – in such situations – be responsible for the product vision, deal with the stakeholders, work with the development team and maintain the ability to go back and forth between the little details and the big picture.

Based on these cases we’re going to indicate what are the similarities and the differences between these environments. We’ll search for a universal pattern to deal with the “mission impossible” and try to define a set of characteristics needed to create a successful product no matter what the organization you are working for.

Twitter Feed