80% product discovery and 20% project management

Project manager does not exist in Scrum context. Project management in Scrum is distributed mainly between PO and team, for release and sprint respectively. This clarifies one of the most common understandings about SM as project manager, but raises another misunderstanding, which regards PO as project manager. To clarify this, I start to describe PO's job as 80% on product discovery and 20% on project management.

80 and 20.jpg


20% on project management

If you have done the exercise of discovering how project management tasks are done in Scrum, it is clear that there are two levels of projects, the sprint as small project is managed by team; and the release as big project is managed by PO. While making tradeoffs among scope, time and cost, for sprint, team works with tasks, days and members; for release, PO works with PBIs, sprints and teams.

So, does PO do project management? Certainly yes, but that's only 20% of his job.

80% on product discovery

The 80% should be focusing on product discovery - find the most valuable work. PO shifts the focus from the output (how many features) to the outcome (how much impact).

How does PO do product discovery?

PO collaborates with users, customers and stakeholders, as well as the team on product discovery. He owns the product vision, and defines release goals based on impact. He uses techniques such as persona, impact mapping and story mapping to understand the customer problems deeply, explore the product solutions broadly, and plan the releases with clear focus.

The product development is inherently uncertain, thus, inspection and adaptation on sprint basis is necessary. PO leads sprint review and uses various types of information to make informed decision about what to do next.

Why do you see the opposite?

Unfortunately, I see that many POs have the disproportionate focus on project management and product discovery. Some might have focused 99% on project management. They missed the opportunity to make a real difference. It is sad, but why does it happen?

One common reason is that PO is from R&D, rather than from business and product. This essentially maintains the traditional contract mode - R&D is responsible for delivery, but not for ROI. The prevalent component team structure makes it more difficult to change. If team is responsible for component, their PO can hardly focus on product discovery.

Read more

เวลาอู้

เวลาอู้

ผมกำลังอ่านหนังสือ Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency ของ Tom DeMarco ซึ่งได้ให้มุมมองใหม่เกี่ยวกับ Slack time หรือเวลาอู้งานกับผม แต่ก่อนจะเล่าว่าผมเห็นอะไร ผมของแบ่งปันมุมมองเวลาผมดูองค์กรก่อนนะ สายการผลิต คนในองค์กรมารวมตั

By Chokchai
สุดยอดทีม (Extraordinary Team)

สุดยอดทีม (Extraordinary Team)

ท้ายหนังสือ Teamwork is an Individual Skill ของ Christopher Avery ได้กล่าวถึงสมการของสุดยอดทีมไว้ดังนี้ครับ Extraordinary Collaboration = Exchange + Expansion + Integrity ผมใช้เวลาอ่านตรงนี้ และอีก 3 บทที่ขยายความเรื่อง Exchange, Expansion และ Integrity อยู่เกือบ 2 สัปดาห์กว่าจะพอเข้าใจมันอย่

By Chokchai
ไล่ตามความฝัน กับ ดูแลตัวเอง

ไล่ตามความฝัน กับ ดูแลตัวเอง

ไล่ตามความฝัน กับ ดูแลตัวเอง ก่อนหน้านี้ผมเคยเล่าถึงขั้วตรงข้าม (Polarity) ระหว่างความคล่องตัวกับความสร้างสรรค์ไปแล้ว ครั้งนี้ผมมองว่า “การไล่ตามความฝัน” และ “การดูแลตัวเอง” (เปรียบเสมือน นักรบ กับ นักรัก) ก็เป็นแสงและเงาของกันและกั

By Chokchai
สกรัมเป็น Empirical process

สกรัมเป็น Empirical process

กระบวนการแก้ปัญหาในโลกแบ่งเป็น 2 แบบ แบบแรกคือ Defined process ซึ่งเป็นกระบวนการที่มีขั้นมีตอนชัดเจน เช่น Waterfall เป็นต้น ส่วนแบบที่สองคือ Empirical process หรือ "กระบวนการเชิงประจักษ์" ซึ่งเป็นการทำไปแล้วก็ปรับไปเรื่อย ๆ สกรัมเป็นแบบหลัง

By Chokchai