80% product discovery and 20% project management

Share

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

กฎของจั๊วะ

กฎของจั๊วะ

ปีนี้ที่อายุ 44 ผม Reflect ตัวเอง และพบว่าหลักการใช้ชีวิตของผมได้มาจากหนังสือ The Seven Habits of Highly Effective People เยอะมาก ใน Habit ทั้ง 7 นี้จะมีเกร็ดเล็กเกร็ดน้อยที่ผมไปศึกษามา แล้วค่อย ๆ เติมเข้าไปเพื่อทำให้ Habit นั

By Chokchai
ขยายกิจการองค์กร

ขยายกิจการองค์กร

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

By Chokchai
คนไม่ใช่สิ่งทดแทนกันได้ (People are not Fungible)

คนไม่ใช่สิ่งทดแทนกันได้ (People are not Fungible)

ในปี 2546 นักศึกษาคณะวิทยาศาสตร์ที่เรียนอยู่ที่ศูนย์รังสิตมาตลอดแบบผม ได้มีโอกาสเข้าเมืองไปเรียนที่ธรรมศาสตร์ ท่าพระจันทร์ เป็นครั้งแรก นอกจากจะตื่นตาตื่นใจกับของอร่อยมากมายรอบมหาวิทยาลัยแล้ว บรรยากาศที่ศูนย์ท่าพระจันทร์มันมีมนต์ขลังแปลก ๆ ตัวผมได้

By Chokchai
ทำไม System Analyst ถึงไม่เชื่อ Design จากทีม

ทำไม System Analyst ถึงไม่เชื่อ Design จากทีม

บ่อยครั้งที่ผมได้ยินน้อง ๆ ออดส์ทีม (ODT) เล่าว่า งานที่ทำอยู่ไม่ท้าทายเลย เพราะเพียงได้รับ Specification มาจาก System Analyst (SA) หรือ Tech Lead ที่เป็นพนักงาน แล้วน้องก็มีหน้าที่เขียนโค้ดตามนั้นไปอย่างเดียว บ่

By Chokchai