The Product Owner role in Scrum is vital, but lacks comprehensive guidance. This talk presents the SMIQ Method (Single Most Important Question), derived from the "48 hour book method," empowering Product Owners and Managers to translate customer needs into software requirements. It simplifies complex techniques into user-friendly steps for effective requirements engineering. The speaker's success in using this method for writing books, organizing conferences, and developing software highlights its simplicity and effectiveness.

Target Audience: Product Owners, Product Managers, Requirements Engineers, UX, Project Managers
Prerequisites: Scrum, Product Owner role in Scrum, beginner level knowledge of User-centered design
Level: Basic

Extended Abstract:
Product Owner is one of the most critical roles in the Scrum Framework. However, beyond “the backlog” and “prioritization”, there’s very little guidance as to what that role entails. This talk presents a method (The SMIQ or Single Most Important Question Method, discussed in the “48 hour book method”) that guides Product Owners, and Product Managers in their discovery work, and helps them translate customer needs into Software requirements. It’s a simple method, but it offers the opportunity for in-depth understanding and effective requirements management. The method achieves it’s simple format by codifying some complex techniques into a simple set of steps that anyone can use, and this speaker has used to write books, create conferences, and develop software.
Key Learnings

1. The challenge of understanding the customer, and what is required to succeed
2. How to translate real life into software requirements, reliably, and quickly
3. Concrete practices and techniques to implement the method suggested
4. Practical application of the SMIQ method in the conference room, with the participants
5. How to bring the SMIQ method to our work as Product Owners and Product Managers

Stoic practitioners know they cannot control circumstances, other people or rather... they know they cannot control anything outside of the realm of their own choices. So as a Stoic Product Leader you should stop focussing on outcome (!). Outcome is always outside of your control. However the CHOICES you need to make the product vision and goals ARE within your power, within your control. So the best thing you can do as a (product) leader is improving the quality of your decisions and teach your teams how to do that too.

Target Audience: Project/Portfolio Leaders, Product Owners, Product Managers, Leadership, Decision Makers
Prerequisites: None
Level: Basic

Extended Abstract:
Stoic practitioners know they cannot control circumstances, other people, behaviour of other people in their teams, or simply: they know they cannot control anything outside of their own mind, the realm of their own choices.
So as a Stoic Product Leader you should stop focussing on outcome. Outcome is outside of your control as a leader. Your own choices are within your control. The choices you need to make in the long run (product vision) and the ones you need to make that are right in front of you (iteration goal).
So the best thing you can do as a (product) leader is improving the quality of your decisions and teach your teams how to improve their ability to make better choices.
(Sustainable) product leadership is far more like poker (with uncontrollable circumstances and emerging events that influence possible outcomes) than like chess (if you think long and hard you could predict what is the next best move).
* Learning goals

1. know how to move from outcome focus to focus on improving decision quality
2. know how to implement habits that will improve your decision making as a product leader

This session will help you make better, more sustainable product choices

Many of us have worked on death-march projects or rewrote code "just because CTO said so".
How many have seen such endeavours succeed - without burning people, motivation, reputation & lots of money?
The quest for Sustainable Pace is as old as XP. Maybe even older.
It's neither an individual task nor is it only a team’s responsibility. It’s an interaction of both - and beyond: it all is about (organisational) systems!
If we cannot architect livable organisational systems, how are we supposed to architect decent socio-technical systems?

Target Audience: Developers, Architects, System Engineers, Managers of all flavours, Curious human beings
Prerequisites: Curiosity and some work/project experience is beneficial
Level: Advanced

Extended Abstract:
In this session you will get some of my answers on these questions.
Also you will:

1. learn what sustainable pace is about (and what it's NOT)
2. connect to all-too-common pitfalls that can “unbalance” a system (i.e. team, a whole organisation, and also yourself)
3. get simple yet powerful self-care practises for yourself and for your team(s)
4. learn necessary psychological background (e.g. stress & coping)

Bring genuine curiosity with you - the number one “tool” to expand horizons!

In 2011, realizing it desperately needed to offer a competitive product to Airbus’ A320neo, Boeing embarked on a project to upgrade its legendary 737 aircraft to match the A320neo’s efficiency. Limited by the constraints of the 737’s original design and their desire to minimize training needed by pilots to fly the new aircraft, Boeing made multiple critical compromises in the aircraft’s design. 346 deaths and $87 billion later, we have all been reminded of the importance of rigorous design processes and the need to engineer systems for the realities of the end users and their environment. This talk dives into the motivations for the design compromises, the human factors considerations that were disregarded, and how a Fortune 100 company’s prioritization of profit over good design practice led to its stunning fall from grace.