The Desires of a Product Owner: Memories of the Inception Deck from the Perspective of a Salaryman PO

This article is the fifth installment of the Summer Relay Series 2024.

This is Nakamura. I was a Product Owner in in-house development. (I left shortly after writing the last article.)
I will write quite candidly about the troubles and realizations I experienced during that time.

First, I declare as a premise: At the time of my tenure as PO (2021-2023), the project did not run smoothly as Scrum. Therefore, I hesitated to publish knowledge and examples (because I wanted to look good), but I decided to proceed with transparency and commitment to share my experiences. I hope this will be somewhat helpful for teams facing similar challenges, even if it feels like a human experiment.

By the way, here is the situation of the team at the time of the original article (around the second half of 2022).

• Product
  • In-house tools developed internally (ongoing since 2020)
  • Released with minimum basic functionality and gradually expanding while transitioning business operations
  • Infrastructure based on a microservices architecture using EKS
• Team Composition
  • Dev: 2 full-time members + several spot members (also serves as a training dojo for new graduates and mid-career hires)
  • PO (me): From the development department. Certified Scrum Master (CSM). Consolidates requests from various user departments. Also serves as an Agile coach for client projects.
  • SM: Certified Scrum Master (CSM). This was almost the first time for a full-fledged Scrum Master in this project.

Now, the theme for this time is 'Inception Deck'.

I will reiterate that at that time (and still now), I was just a company employee belonging to the consulting department. Therefore, I was in a somewhat unreliable state to fulfill my role as PO.

• Authority and discretion… almost none (regular employee)
• Business knowledge… partially understood through development
• Microservices… grasped the outline through development
• Scrum… obtained the Certified Scrum Master (CSM) qualification. Just imitating what I saw.

To be honest, when the SM proposed holding an Inception Deck with all stakeholders gathered, I could not envision its effectiveness at all. "Well, it’s written in Agile Samurai, so maybe it’s worth trying once as an experience..."

However, to conclude, the Inception Deck became an indispensable event for the PO… and ultimately for the team, as it supplemented the knowledge and discretion that were lacking as a "Scrum team."

• Important requests from stakeholders
• A holistic decision (decision-making) as a consensus of stakeholders
• Business knowledge and enthusiasm behind the requests
• A sense of camaraderie and unity between the Scrum team and stakeholders through discussions

Having worked as a PO for about two years and now over a year since leaving, I looked back at the Inception Deck from that time and jotted down my reflections in bullet points. The descriptions follow the order of execution at that time.

Here, I will not discuss how to conduct the elevator pitch itself. I leave that to the abundant explanations in books like Agile Samurai and on the web.

• As an icebreaker, "It wasn’t bad."
• The rules were at a common-sense level. However, the act of stating them itself might be important.
• Examples:
  • Don’t mute. Background noise is okay.
  • Speak freely.
  • Don’t give up before expressing opinions or requests based on real-life backgrounds.
  • Raising issues without solutions is okay. We can think of solutions together.

• Honestly, I have never encountered a pitch that excited everyone.
• I can imagine that a novel and simple product that breaks through a niche need would be effective, but what about for business applications with diverse users…
  • It tends to "consolidate" into a complex and ambiguous pitch that combines the needs of various departments.
    • However, since needs differ across business units, if we aggregate too much, the number of participants and the volume of voices may dominate.
  • It seems to overlap with the "not-to-do list"…

• Essential of Essentials ①
• I have referred to it many times as a criterion for prioritizing PBIs and controlling scope.
• Gaining management's (not just a one-off) commitment regarding deadlines and budgets (≒ additional personnel) was very reassuring for the team.
• It clarified the differences in quality between business and development.
  • For the business side, "high quality" means that the functionality meets the requirements and does not fail.
  • For the development side, quality refers to maintainability (thus, clean design and code).

• It was very helpful as a stocktaking of the major PBIs to be added in the current quarter and the carry-over PBIs from the previous quarter.
• A place for bargaining between business units and reaching a "consensus" on the compromises.
  • There is only one chair for the elevator pitch, but this has a wide "relative priority," so it has a greater sense of fairness and understanding.
  • Based on the decisions made here, the PO's job is to "fine-tune" the content and order of PBIs within the PO's discretion.
    • In this project, where the PO lacks the discretion and (holistic) decision-making power expected by the Scrum Guide, it became a reassuring compass.

• Essential of Essentials ②
• Essential for gathering requirements and improving communication lines.
• At that time, we did it at the end of the Inception Deck, but I now think it should be done on the first day.
  • It would be disastrous if we discovered important (stakeholders to invite to the Inception Deck) were overlooked at the end.
  • It was merely a stroke of luck that we did not encounter this in the development.
• Instead of drawing a "organizational chart," draw a "relationship map."
  • Write out all the official and unofficial relationships that influence the product (project) centered around the Scrum team.
    • Communication lines
    • Who knows what
    • Where the decision-making authority lies
    • Stakeholders

With the passage of time and the fact that I was incredibly focused back then, there may be some memory errors or embellishments.
On the other hand, having stepped away from the situation, I have also gained insights into things that were not visible at the time.

One conclusion I can draw is, "Let’s definitely do the Inception Deck."
However, since it requires holding busy stakeholders for a long time, effective selection of decks and kitting seems necessary. That’s where the SM can showcase their skills…

It has been over a year since the first installment. I hope to publish the next one within the year.