I was on a panel with Marc Manara, who is responsible for OpenAI’s (ChatGPT) startups. As an entrepreneur in Thailand, one important lesson stood out.

The next generation of startups will use fewer employees but grow revenue faster — powered by AI.

That sounds exciting, but it raises an important question for all of us:

How can we adapt our product development to this new reality?

As a product leader, I’m interested in the process and speed of Age of AI because everything seems to happen so FAST!!!.

AI Changes the Speed and Shape of Product Development

Marc shared that OpenAI doesn’t just build tools — they co-create with startups. Their product philosophy is built around the speed of learning, not just the speed of building.

The faster you can get feedback from real users, the faster you can make things better. This is especially important for AI-powered products.

Their cycle looks like this:

1. Adopt quickly—bring new capabilities into the product early.
2. Stress-test with real users—don’t wait for “”perfect” get it into the hands of testers right away.
3. Feedback, feedback, feedback (repeat) — prioritize user input above our assumptions.

This creates a continuous loop of improvement, rather than long, slow release cycles.

The OpenAI Product Development Framework

Marc showed us a simple but powerful way to think about making things, whether they’re tech or not:

Research

• Train and test your core idea.
• Introduce new capabilities when possible.
• Gather early feedback from a small, trusted group.

Apply

• Build a usable version.
• Test & iterate based on real-world use.
• Collect structured feedback to shape the next version.

Deploy

• Run alpha tests and “dogfooding” (using the product internally).
• Provide hands-on guidance for users.
• Share feedback back to the product team.

And then—repeat.

So what about us?

This cycle is very similar to what we already do, but OpenAI are shorter, faster loops. But most companies can’t do…

Instead of waiting months for a polished release, the goal is to test small, learn fast, and improve continuously.

In the AI era, the winners will be the ones who:

• Embrace imperfection in early versions.
• Collect and act on feedback daily.
• Keep testing assumptions—even after launch.

Key Takeaways for Our Team

• Don’t overbuild before testing—get it in front of users early.
• Feedback is currency—treat it like the most valuable resource.
• AI can multiply our speed—but only if we keep the loop short.
• Our size can be an advantage—fewer people means less bureaucracy and faster decision-making.

If we do this, we’ll not only keep up with the AI shift, but we’ll also be ready to lead it.

The message from OpenAI is clear:

“ Move fast, learn faster, and let feedback guide the way.”

คุณเคยเจอเหตุการณ์เหล่านี้ไหม ??

“ แม้จะเห็นว่าสปรินต์ที่แล้วทำอะไรเสร็จบ้าง… แต่ก็ยังรู้สึกเหมือนกำลังหลงทาง เหมือนพัฒนาไปก็ไม่ตอบโจทย์อยู่ดี… ”

นี้คือจุดของ User Story Mapping เริ่มมีบทบาทมากขึ้น

User Story Mapping — สิ่งนี้ไม่ใช่ Tool ที่ไว้จัดการทีมงาน แต่คือ การสร้างพื้นที่ทำให้ทีมงานเข้าใจภาพเดียวกัน เพื่อสร้างสิ่งที่มีคุณค่าต่อการใช้งาน

บทความนี้ผมได้รับแรงบันดาลใจาก “User Story Mapping by Jeff Patton” ครับ

หวังการเริ่มที่ User จะช่วยพี่ ๆ เพื่อน ๆ ทำงานได้สนุกมากขึ้นครับ :)

Why Agile Teams Lose the Big Picture

ยิ่งงานไวยิ่งหลงทาง ?

การทำงานสาย Product เรามักคุ้นเคยกับคำว่า “Agile” ซึ่งหลักการทำงานนั้น คือ

การหั่นภาพฝันใหญ่ ๆ ออกเป็นชิ้นเล็ก ๆ แล้วค่อย ๆ ปล่อยออกมาให้คนใช้ เหมือนการวาดภาพทีละเส้น เพื่อให้เราได้เห็น และแก้ไข ก่อนที่ทุกอย่างจะสายเกินไป”

ก่อนอื่น ๆ มาทวนข้อดีของ Agile กันก่อนครับ

1. Faster Feedback : ได้วิธีการปรับอย่างรวดเร็ว,
2. More User Involvement : คนใช้งานจริง ได้ลองจริง ได้เรียนรู้ตรงมากขึ้น
3. Visible Progress : ได้เห็นความคืบหน้า การค่อยๆวาดทีละเส้น ทำให้แก้ไขได้ก่อนที่ภาพจะเสีย

แต่มันก็มีข้อเสียร้ายแรง — เรามักละเลย คือ ทีมอาจหลงลืมภาพรวมของ Product ได้

เนื่องจากการแบ่งงานออกเป็นเรื่องย่อย ๆ อาจทำให้งานออกไปได้ไว แต่ก็แลกมาด้วยการไม่เห็นการเชื่อมโยง ซึ่งอาจทำให้ทีมมองไม่เห็น Impact ที่เกิดขึ้นต่อผู้ใช้

…จนสุดท้ายการแยกส่วนทำให้ Product ไม่ตอบโจทย์คนใช้งาน

ซึ่งในหนังสือ พี่ Jeff ได้เตือนไว้ว่า

“Story mapping is a technique that provides the big picture that a pile of stories so often misses.”

“Story Mapping คือเทคนิคที่ช่วยให้เราเห็น ‘ภาพใหญ่’ ซึ่งมักหายไปเมื่องานถูกแยกเป็นชิ้นเล็ก ๆ โดยไม่มีบริบทเชื่อมโยง”

ซึ่งมันตรงกับปัญหาที่ผมคิดว่า ทีม Aglie มักเจอคือเมื่อเราขาดความเข้าใจในภาพรวม — มันง่ายมากที่เราจะมุ่งแก้ปัญหาที่เล็กน้อยเกินไป

และพลาดสิ่งที่เป็น value แต่ผู้ใช้งานจริง ๆ

What is User Story Mapping?

ใจความสำคัญของ User Story Mapping — To visualize the user’s journey step-by-step กล่าวคือ วิธีการทำให้ทีมเห็นภาพการใช้งานตั้งแต่เริ่มไปจนจบ ผ่าน

1. Who : User ของเราคือใคร
2. What : พวกเขากำลังพยายามจะทำอะไร
3. Why : แล้วเพราะอะไรถึงต้องทำสิ่งนั้น

ลองนึกภาพตัวอย่างข้างล่าง

เราเริ่มจากจัดวาง Story หรือสิ่งที่ User พยายามจะทำจากซ้ายไปขวา และเติม Working iteam หรือ รายละเอียดเพื่อช่วยให้ User ทำสิ่งนั้นจากบนลงล่าง

โดย Map นี้จะช่วยให้เราเข้าใจมากกว่า “หนึ่ง Feature” แต่ “เข้าใจถึง Impact” ของการสร้างสิ่งนั้นจริง ๆ ว่าจะเข้าไป User ในจังหวะไหน นอกจากนี้ยังช่วยให้

• เข้าใจและเรียงลำดับสิ่งสำคัญต่อ User ได้ง่ายขึ้น
• ช่วยให้เกิดการพูดคุย Interaction มากกว่าแค่รายละเอียดใน Ticket (ออกจาก Jira บ้าง)

How Story Mapping Builds an Agile Mindset

แล้วช่วยให้เราทำงานดีขึ้นยังไง ?

1. Sharing Vision Together: ในการทำงาน Product เราต้องทำงานแบบ cross functiomal team ที่มีหลากหลาย Stakeholder ทั้ง Business, Tech หรือ Designer — ความยากคือทำให้ทุกคนเข้าใจ Vision ว่าเราทำสิ่งไปทำไม
2. Value First: การที่เราสร้าง Map จะช่วยให้ทุกคนเข้าใจว่า “สิ่งที่ User ต้องทำคืออะไร” และช่วยให้ทีมค้นหา Value ผ่านการกระทำเหล่านั้น — มันย่อมง่ายขึ้นที่เราจะเลือกว่าอะไรสำคัญต่อ User
3. Boost Ownership: การสร้าง Map ช่วยให้ทีมเห็นว่า “สิ่งที่พัฒนาไปจะช่วย User ยังไง” — สิ่งนี้ช่วยสร้าง Ownership ให้ทุกคนกล้าร่วมตัดสินใจ เพราะทุกคนเข้าใจว่า ทำไมเราต้องพัฒนาสิ่งนั้น
4. + Agile = 🔥 :ความเข้าใจในทั้งมุม User และ Product เป็นฐานที่สำคัญที่ทำให้ Agile ใช้ได้จริง เพราะเมื่อเราเลือกสิ่งที่สำคัญเป็น และ Release สิ่งนั้นได้เท่ากับ Learning ที่มีประโยชน์ต่อการพัฒนา และ นำไปสู่การ Iteration จน WORK!!!

Building shared understanding leads to better products.

The Map Is Only the Beginning

จริง ๆ มันแค่เริ่มต้น…

User Story Mapping ไม่ใช่ AI ที่แค่ prompt ให้ทีมพัฒนา Product ได้ตรงใจ User ได้ทันที่ — แต่มันคือ “เครื่องมือที่มีชีวิต” ที่เราต้องอาศัยการกระทำ + ความพยายามในใช้ ในทุก ๆ การพูดคุย การทำ Discovery หรือในทุก ๆ รอบ Release

อย่างที่พี่ Jeff กล่าวไว้ว่า

“ Building a map helps you see the big picture, to see the forest for the trees. But if you’re responsible for building the forest, you’ll need to do it one tree at a time ”

“ การสร้างแผนที่ช่วยให้เราเห็นภาพรวม — เห็นทั้งผืนป่าแทนที่จะมองแค่ต้นไม้ทีละต้นแต่ถ้าคุณคือคนที่ต้องลงมือสร้างป่าจริง ๆ คุณก็ต้องปลูกมันทีละต้นอยู่ดี ”

.

.

สุดท้าย
ความสำคัญของ Agile ไม่ใช่แค่ความเร็ว

แต่คือ Learning….

และยิ่งไปกว่านั้นคือใช้ Learning เหล่านั้น สร้าง Product ที่เปลี่ยนแปลงชีวิต User ได้จริงครับ :)

Ref
Do, V. (2024, November 8). What is user story mapping? how it works in jira. ProductGo — Agile User Story Map for Jira. https://userstorymap.io/what-is-user-story-map/

Patton, J., Hildebrandt, P., & Economy, P. (2015). User story mapping. O’Reilly Verlag.

ขอบคุณเพื่อน ๆ พี่ ๆ ทุกท่านที่อ่านมาถึงตรงนี้
ถ้าชอบก็กด Like กดติดตามกันได้ ใน Medium นี้ครับ ขอบคุณมากครับ😄

ยังไงฝากกด like กด share กดติดตามพวกเรา Humanalytics — UX x DATA เพื่อที่จะไม่พลาดคอนเทนต์เกี่ยวกับ ux , การใช้งาน data ดี ๆ ที่จะช่วยให้คุณทำ product ให้ดีและสนุกมากขึ้นกว่าเดิมแน่นอน~

https://www.facebook.com/humanalytics.th

User Story Mapping x Agile: สร้างของที่คนอยากได้จริง was originally published in Humanalytics-UX x Data on Medium, where people are continuing the conversation by highlighting and responding to this story.

จริง ๆ มันก็ไม่ได้วุ่นวายขนาดนั้นหรอก—ในฐานะคนทำ Product บางครั้งคุณก็นั่งล้อมวงคุยเรื่อง strategy ว่า product vision ควรเป็นแบบไหน ต่อมาคุณก็เปิดข้อความอ่านเกี่ยวกับเหตุผลที่เราต้องเปลี่ยน Design และจบวันด้วยการดูว่า bug ที่ user report มาต้องแก้ยังไง…

ตำแหน่ง Product manager คือคนกลางที่เชื่อมโยงระหว่าง Business และ Tech—เป็นคนตัดสินใจใน direction ต่าง ๆ และเป็นคนที่คอยช่วยให้ทีมผ่านปัญหาทั้ง user feedback (บ่นนั้นแหละ), bug การใช้งาน และ roadmap ที่เปลี่ยนไปเปลี่ยนมา

แต่ด้วยความเป็นคนกลาง…ย่อมทำให้เกิดปัญหาทั้งฝั่ง business และ tech แล้วต้องทำให้ยังไงให้ผ่านปัญหานั้นไปได้

คุณเคยเจอเหตุการณ์เหล่านี้ไหม?

• Dev ไม่เข้าใจเหตุผลที่มาที่ไปของ Feature
• Design งงว่า ต้องพัฒนา UX ยังไง

ดังนั้นทักษะอะไรที่สำคัญที่ช่วยให้เราผ่านความวุ่นวายไปได้?
หรือจริง ๆ แล้ว things just got out of hand.

บทความนี้ผมได้ไอเดียจาก Coursera: Product Management Fundamentals by Xbox ในบทความ “Essential skills for successful product managers” และประสบการณ์ที่เกิดแต่ความวุ่นวายตลอดชีวิตการทำงานครับ 🤣

Why Always Messy?

กล่าวจากใจจริง—งาน Product management คือการ Alignment ความแตกต่างของทีมทำงาน เพื่อสร้างสิ่งที่ User ต้องการใช้งาน… ด้วยเหตุนี้มันเลยมีความเอ๊ะ! นิดๆ เพราะ

• คุณจะไม่ได้เป็นคนทำงานจริง ๆ แต่คุณต้องรับผิดชอบต่อผลลัพธ์ที่เกิดขึ้น
• คุณเป็น “คนกลาง” ของ User, Developer , Designer, Marketer และ Stakeholder อีกมากมาย
• ทุกคนถูก…อ่านไม่ผิดหรอกครับ เมื่อทุกคนมีความคิดเห็น ความเห็นทุกคนถูกต้องเสมอ—ในมุมมองของตัวเขาเอง

Everyone still loves Framework, right?

ก่อนเราจะลงลึกไปที่การทำงานร่วมกันในทีม Product เพื่อให้เราผ่านความวุ่นวายไปได้ ผมอยากพาทุกคนมาเข้าใจ Framework ที่ PM (Project manager นะ) ใช้กันในการทำงาน

The Project Management Triangle

Scope. Time. Budget. สิ่งที่เราไม่สามารถทำได้หมดทั้ง 3 อย่าง เราเลยต้องเลือกและสื่อสารออกมาให้ชัดเจน.

มันไม่ใช่เรื่องของการควบคุม แต่เป็นเรื่องของการจัดการความคาดหวัง และทำให้การตัดสินใจต่าง ๆ สอดคล้องกับผลลัพธ์ที่ต้องการ

ยกตัวอย่างเช่น feature ใหม่ที่เราใส่เข้าไปใน scope มันอาจจะกระทบ timeline หรือ budget ที่ต้องใช้มากขึ้น… มันเลยค่อนข้างเป็นศิลปะที่คุณต้องเลือกและสื่อสารสิ่งนั้นออกมา (แต่ก็สามารถใช้ทักษะ Analytical data ประกอบการตัดสินใจได้)

เพราะฉะนั้นในการทำงาน Product การเข้าใจถึง Project Management Triangle จะช่วยให้เราสร้าง impact ในการพัฒนา product ได้อย่างมีประสิทธิภาพ

The Human Side of Product Management

ตำแหน่ง PM (หรือแม้แต่ role อื่น ๆ ) ต้องใช้ทักษะทั้ง Hard skill & Soft skill ในฝั่งของ Hard skill

Hard Skill

ให้ลองสมมติว่า

• Stakeholder อยากได้ feature เพิ่ม
• Dev team บอกกลับมาว่า sprint เต็ม
• แต่ Timeline ยังเหมือนเดิม

คุณจะทำอะไร??

ทักษะ Hard Skill จะช่วยให้เรามี step ที่ช่วยแก้ปัญหาอย่างมีประสิทธิภาพ

โดยเริ่มตั้งแต่การทำ Market research & User interview เพื่อเข้าใจ pain point และการวิเคราะห์ data เพื่อเข้าใจ pattern การใช้งานและดูจุดที่ user drop off เพื่อนำไปสู่การพัฒนา—นี้จะช่วยให้สร้าง product strategy และ prioritize ได้ตรงกับ user expectation และ business goal

ในระหว่างการพัฒนา หน้าที่ของเราจะเป็นแนว Project มากขึ้น กล่าวคือเราต้อง working แบบ cross-functional team สร้าง environment ที่เสียงของทุกคนได้รับการได้ยิน empower team ให้เกิดการพูดคุยและแชร์ไอเดียกัน เพื่อให้มั่นใจว่าทุกคนเข้าใจ Product Vision และช่วยให้ทีมตัดสินใจได้อย่างมั่นใจ

และเมื่อ Product ได้ Launch ออกไป คุณจะเป็นหนึ่งคนที่ monitor การใช้งานของ user ไม่ว่าจะเป็นการ Adoption หรือ Activation—วิเคราะห์สิ่งเหล่านั้นและนำไป discuss รวมระหว่าง stakeholder เพื่อช่วยให้ทีมงานและผู้ใช้งานเกิดความพึงพอใจ… โดยคำนึงถึงการส่งมอบ value ที่นำไปสู่การสร้างธุรกิจอย่างยั่งยืน

You continue to represent the voice of the customer.

หนึ่งสิ่งที่ PM ต้องจำได้เสมอคือ “เราคือตัวแทนของ User” เราต้องเริ่มทำ Usability testing & Gather feedback เพื่อนำไปสู่การพัฒนาที่อ้างอิงจาก User insight นี้จะเป็นจุดที่เริ่มใช้ทักษะ Soft skill…

Soft Skill

ตรงนี้แหละที่บางคนรอด บางคนก็ร่วง ว่าแต่มีสกิลอะไรที่เราต้องฝึกเพื่ออยู่ในความวุ่นวายนี้ได้

Communication : Product manager มีส่วนร่วมในหลาย Stakeholder ทั้ง Dev หรือ business — ความสามารถที่สื่อสารได้ชัดเจน จะช่วยให้ทีมเข้าใจสิ่ง Goal และทำงานในร่วมกัน

Leadership: การทำงานในสิ่งที่ไม่แน่นอน บางคนก็ต้องการคนที่ยึดเหนี่ยวทีมไว้ หรือสร้าง motivation ให้ทีมทำงานต่อไปได้ ทักษะความเป็นผู้นำจะช่วย PM empower ทีม, สร้างความเชื่อมั่นใน vision ของ product และทำให้ทีมผ่านสิ่งที่วุ่นวายเหล่านั้นไปได้—"Guiding without authority. Inspiring without control”

Empathy: ความสามารถในการเข้าใจคนอื่น เป็นสิ่งที่หาได้ยากในยุคปัจจุบัน แต่ในงาน PM คุณต้องเข้าใจผู้อื่นให้ได้ตลอดเวลา ทั้งทีมงานและ user ผู้ใช้งาน—สิ่งเหล่านี้เป็นสกิลที่สามารถฝึกฝนได้ ผ่าน active listening, user research และสำคัญที่สุดคือความตั้งใจจริงที่อยากเข้าใจมุมมองเขา เพื่อช่วยเหลือเขาจริง ๆ

Truly getting user pain. Building for them, not you.

Problem-solving: “งานของเราคือ การแก้ปัญหา ไม่ใช่เพิ่มปัญหา” ประโยคนี้คงไม่เกินจริง ในงาน PM เมื่อถึงจุดที่เกิดความท้าทาย ไม่ว่าจะเป็นปัญหาภายในทีม ข้อจำกัดของการพัฒนาในมุม technical หรือความเปลี่ยนแปลงของ market & user need—หน้าที่ของคุณคือ identify ปัญหา วิเคราะห์ และหาวิธีแก้ไขที่มีประสิทธิภาพ “Creativity within constraints. Clear thinking under pressure.”

Data-driven decision-making: สิ่งที่เราต้องทำคือการวิเคราะห์ข้อมูลต่าง ๆ แล้ว translate สิ่งเหล่านั้นไปเป็น actionable insight หรือ feature ที่สร้าง impact ได้จริง เพราะงั้นเมื่อรู้สึกอยากใช้ gut feeling แต่อย่าลืมเทียบกับ metric ด้วยนะ

It’s Okay If It Feels Messy

มันคงไม่ใช่แค่ PM หรอกที่เกิดปัญหาเหล่านี้ ทุกคน ๆ ย่อมเคยเจอทั้ง Dev , Designer, Business หรือไม่ว่าคุณจะนิยามตัวเองว่าอะไร

การเริ่มทำงาน Product ในฐานะ PM หลายคนมักรู้สึกว่ามันยุ่งยาก เหมือนการทำงานในพายุที่ทุกอย่างดูวุ่นวายจนไม่เข้าใจว่าเกิดอะไรขึ้น

แต่เมื่อคุณเข้าใจว่าความวุ่นวายเหล่านั้นเกิดจากอะไร—และได้เรียนรู้ทักษะที่จะแก้ไขมัน You will not only survie, You will LEAD

Because when the product journey gets overwhelming, these skills are your compass.

And that’s when true product leadership begins.

ของฝากนัก DEV

ผมว่าคงมีเพื่อน ๆ พี่ ๆ หลายคนที่ไม่ได้เป็น เข้ามาอ่านและรู้สึกว่าทำไม PM ที่ทำงานมันอยู่ใน meeting ทั้งวันเลยวะ—จริง ๆ มันก็อะไรมากกว่านั้น

สิ่งที่ผมอยากให้เราช่วยกันทำให้การทำงาน productive มากขึ้นเมื่อเข้าใจว่าเราต้องการอะไรจากอีกฝ่าย

สิ่งที่ Great PM จะทำให้พี่ Designer คือ การไม่ Micromanage Figma ของคุณ แต่จะช่วยสนับสนุนไอเดียของคุณและทำให้ทีมเห็นคุณค่าของสิ่งที่คุณคิดมากขึ้น—ผ่านการสร้างความเข้าใจใน Product goal & user pain และให้พื้นที่ให้คุณ design ได้อย่างมั่นใจ ไม่ใช่การคาดเดา

สำหรับพี่ ๆ Dev Great PM จะไม่ใช่คนที่เดินมาบอกคุณว่า “ ขออีกหนึ่ง feature” แต่จะช่วยให้ทีม dev อยู่ใน direction ที่ชัดเจน และช่วย break down สิ่งที่ใหญ่ออกมาเป็นของที่จับต้องได้ ให้ทีมรู้สึก achievable มากกว่านั้นคือ การเป็นเหมือน Shield ที่ trade-off สิ่งต่าง ๆ ด้วย empathy ไม่ใช่ pressure เพื่อสร้าง timeline ที่ realistic และมี room สำหรับทีมให้เก็บกวาด tech debt ที่เกิดขึ้น

We’re not just delivering features

We’re delivering sustainability.

Ref
Product management fundamentals. Coursera. (n.d.). https://www.coursera.org/learn/xbox-product-management-fundamentals/

Rick. (2023, April 11). The power of the Project Management Triangle. qosmic technology consulting. https://qosmic.tech/rocketsurgery/project-management-triangle

ขอบคุณเพื่อน ๆ พี่ ๆ ทุกท่านที่อ่านมาถึงตรงนี้
ถ้าชอบก็กด Like กดติดตามกันได้ ใน Medium นี้ครับ ขอบคุณมากครับ😄

ยังไงฝากกด like กด share กดติดตามพวกเรา Humanalytics — UX x DATA เพื่อที่จะไม่พลาดคอนเทนต์เกี่ยวกับ ux , การใช้งาน data ดี ๆ ที่จะช่วยให้คุณทำ product ให้ดีและสนุกมากขึ้นกว่าเดิมแน่นอน~

https://www.facebook.com/humanalytics.th

When everything feels messy - อ่อ… PM ที่ดีเป็นแบบนี้ was originally published in Humanalytics-UX x Data on Medium, where people are continuing the conversation by highlighting and responding to this story.

ความสุข และ กับดัก…

ในฐานะคนทำอาชีพ Product เราอยากทำให้ product ของเราเข้าไปอยู่ในใจผู้ใช้งาน กลับมาใช้ Product เราบ่อย ๆ ซึ่งมันดีที่ App หากเราทำได้ แต่มันดีต่อคนใช้งานจริงหรือป่าว ?

บทความนี้ผมเรียบเรียงจากหนังสือ “Behave: The Biology of Humans at Our Best and Worst by Robert Sapolsky” และประสบการณ์การพัฒนา application ไม่ว่าในฐานะ UX หรือ Product manager + คนที่เรียนจบคณะจิตวิทยามาอีกนิด ๆ

Are you the same ?

ไม่รู้ว่าทุกคนเป็นไหม ช่วงเวลาว่าง ๆ มักหยิบไอจีมาส่องสตอรี่ ไม่ก็ไถหน้า feed ไปเรื่อย ๆ หวังว่าจะเจอ content อะไรสนุก ๆ บางครั้งรู้สึกตัวอีกทีผ่านมาเกือบชั่วโมงแล้ว — -

บางทีมันไม่ใช่ habit หรอก มันคือการ Design
ซึ่ง Application ต่างถูกสร้างมาด้วยรูปแบบนี้ “Dopamine Design”

What is Dopamine?

ก่อนจะไปลงลึก เราต้องกลับมาเข้าใจ Dopamine ก่อนว่าคืออะไร… ซึ่งผมคงไม่ได้มาเล่าว่ามันคือสารเคมี x y z ในสมอง

สิ่งที่เราควรเข้าใจคือ Reward, Pleasure หรือ Happiness สิ่งเหล่านี้ถูกเล่าผ่านมุมมองของสารที่ชื่อว่า Dopamine

เรามักเข้าใจว่า เมื่อเรามีความสุข = dopamine หลั่ง ซึ่งเบื้องหลังของมันคือ Dopamine ไม่ใช่สารแห่งความสุขโดยตรง แต่มันคือสารที่เกี่ยวกับความคาดหวัง (expectation) หรือ แรงจูงใจ (Motivation)

Dopamine isn’t about pleasure — it’s about anticipation.

ในหนังสือ In Behave, Robert Sapolsky เล่าว่า “ Dopamin is not about the happiness of reward. It’s about the happiness of pursuit of reward tha has a decebt chance of occurring ”

ยุคก่อน Dopamine ช่วยให้เราออกล่าอาหาร และในระหว่างเรายังล่าไม่ได้ เรายังคงสามารถล่าต่อไปได้ ด้วย “ความหวัง” เพื่อช่วยให้เราอยู่รอด แต่ตอนนี้มันกลับช่วยให้เราไถ scrolling ไปเรื่อย ๆ เพื่อตามหา “ความหวัง” ใน app ไม่ว่าจะเป็นการกดไลค์ คำชื่นชม จากคนรอบข้าง หรือ ข่าวสารชีวิตชาวบ้าน

กลับกลายเป็นว่า Dopamine สามารถ hook ให้อยู่ในสิ่งที่ไม่ใช่ Reward แต่เป็นความหวัง ที่หวังว่าจะได้ Reward จากรูปที่แปะข้างบนจะเห็นว่า Dopamine จะเริ่มเมื่อเรา Work หรือ การที่เราเข้า APP ต่าง ๆ และสูงขึ้นเรื่อยๆ จนเราได้ reward

แต่น่าแปลกใจมันหายไปเมื่อเราได้ reward…

“ ไม่ใช่จังหวะที่เราได้รับ reward หรือเจอ post ที่ถูกใจ แต่มันคือจังหวะก่อนที่จะได้รับตั้งหากที่ทำให้เรารู้สึกมีความสุข ”

สิ่งเหล่านี้ถูกนำไปใช้ในการ Design behaviour ไม่ว่าใน Application หรือทาง Psychology นึกภาพง่าย ๆ ก็คือการพนัน ที่เรามักสนุกการลุ้นมากกว่าตอนได้

ถึงพอได้จะมีความสุข… แต่ผมหวังว่าคนอ่านน่าจะไม่ได้คิดสร้างคาสิโนอยู่หรอกนะครับ 😄

In modern life
กลับมาในยุคมือถือลองคิดถึง Feature เช่น
Pull to refresh , Random Notification หรือ Daily Login สิ่งเหล่านี้กำลังเล่นกับความสุขของเรา

เราต่างเคยคิดหรือเคยทำ feature เหล่านี้ — มันอาจไม่ได้สร้าง value โดยตรงแต่มันช่วยให้สร้างความคาดหวัง ถ้าทุกคนลองสังเกตุมันคือ The delay before feedback กล่าวคือ การ Loading หรือแค่คำว่า Just a second ก็สร้าง Dopamine loop ที่ทำให้เราเสพติดเช่นกัน

The delay before feedback also create a dopamine loop

As a product guy ผมไม่เห็นว่าสิ่งนี้จะผิดอะไร ถ้าเรามุ่งเน้นไปที่ผลประโยชน์ของผู้ใช้ นอกจาก App social ที่ทำให้เราติด ผมก็เคยเห็นเพื่อนผมติด App สอนภาษา หรือ App นับสารอาหาร

การเสพติดมันไม่ได้แย่ ถ้าเราพัฒนาไปในทิศทางที่ถูกตรง คำถามคือ “ Are we building for value… or for adduction?”

นี้คือหนึ่งเหตุผลหลักที่ผมอยากเขียนบทความนี้ เพราะถ้าเราใช้มันอย่างมีหลักการ เราสามารถสร้างชีวิตที่ดีแก่ user ของเราได้มากมาย อย่างที่ Sapolsky บอก “Dopamine is about the pursuit.” สิ่งที่ Product design ต้องตระหนักคือ เรากำลังสร้าง Product ที่ให้ user เข้ามาทำอะไร และเพื่ออะไร

The real power of product design lies in understanding what we’re making people chase — and why.

Ref

Sapolsky, R. M. (2018). Behave: The biology of humans at our best and worst. Penguin Books, an imprint of Penguin Random House LLC.

ขอบคุณเพื่อน ๆ พี่ ๆ ทุกท่านที่อ่านมาถึงตรงนี้
ถ้าชอบก็กด Like กดติดตามกันได้ ใน Medium นี้ครับ ขอบคุณมากครับ😄

ยังไงฝากกด like กด share กดติดตามพวกเรา Humanalytics — UX x DATA เพื่อที่จะไม่พลาดคอนเทนต์เกี่ยวกับ ux , การใช้งาน data ดี ๆ ที่จะช่วยให้คุณทำ product ให้ดีและสนุกมากขึ้นกว่าเดิมแน่นอน~

https://www.facebook.com/humanalytics.th

1. ชีวิตเราเป็นของชั่วคราว.
   ในวัยใกล้ 25… เป็นครั้งแรกในชีวิตที่ต้องตกงานแบบกระทันหัน แต่มันทำให้กลับมามองชีวิตมากขึ้นว่า ของหลาย ๆ อย่างกลับเป็นของชั่วคราว ทั้งความรู้สึก ความสัมพันธ์ ล้วนแต่เปลี่ยนแปลงตลอดเวลา ชีวิตเราต่างต้องรับมือกับความเปลี่ยนแปลงนั้น อย่าไปยึดติดกับของเหล่านั้นมากเกินไปจนใช้ชีวิตต่อไม่ได้
2. Build a meaningful life by build relationship.
   ในช่วงเริ่มต้นของชีวิต เราต่างมุ่งไปที่ความสำเร็จ ทรัพย์สินเงินทอง การยอมรับจากสังคม แต่ไม่รู้ว่าทำไม..มันไม่ยั่งยืนสักอย่าง พอมองกลับมาความสัมพันธ์ยั่งยืนมันกลับทำให้เรารู้สึกมีคุณค่าในชีวิต…
3. Purpose never done.
   บางครั้งชีวิตเหมือนก้าวต่อไปเรื่อย ๆ ไม่มีจุดสิ้นสุด พอทำอย่างหนึ่งเสร็จ ก็มีอีกอย่างเกิดขึ้นมา ไม่ต่างอะไรกับการแก้ปัญหา ที่พอแก้ได้หนึ่งอย่าง ไม่นานก็มีปัญหาใหม่ขึ้นมาให้แก้อีก เพราะงันสนุกที่ได้ค่อย ๆ ก้าวต่อไป…
4. ช้าๆ ดีกว่าเร็วแบบเร่งรีบ.
   เมื่อเราเร่งเกินไป นอกจากใจเราจะไม่นิ่งเหมือนตอนช้าแล้ว บางครั้งเราก็เสี่ยงเกินไป ข้อคิดนี้เริ่มจากการเล่น future ในการ trade crypto เมื่อไหร่ที่อยากรวยเร็ว มักรวยช้าเสมอ…
5. Saving money is fundamental for gaining wealth.
   จำไม่ได้ว่าเอา mindset ประมาณนี้มาจากไหน แต่น่าจะรวมๆหลายทีที่บอกว่า การลงทุนค่อนข้างเป็นปลายทางของการสร้าง wealth สิ่งแรกที่เราควรทำให้เป็นนิสัยคือการจัดสรรเงินได้ให้เหมาะสมกับชีวิต การ saving จึงเป็นการพื้นฐานที่สร้างความมั่นคงให้ชีวิต…
6. Never add losing money to losing position.
   ข้อคิดการลงทุนที่ต้องเลิกเป็น ยอม cut loss ดีกว่าทนอยู่กับสิ่งที่ไม่ได้เป็นไปตาม logic ของเรา บางครั้งชีวิตก็เหมือนกัน พอเจอจุดเปลี่ยน เราต้องยอมละทิ้งสิ่งเดิม เพื่อเป็นสิ่งที่อยากเป็นมากกว่า..
7. Sleep is the multiplier of life.
   พื้นฐานการนอนเป็นอีกสิ่งที่เรียนศึกษาจริงจัง จากสุขภาพที่ป่วยง่ายและบ่อย จึงค้นพบว่า สุขภาพกายและใจขึ้นอยู่กับการนอน วันไหนนอนดี อารมณ์ดีง่ายกว่าวันที่นอนไม่ดีมาก
8. Workout can improve the energy of life.
   แค่ออกกำลังกายก็สามารถต่อยอดอะไรได้เยอะมาก ๆ และมันช่วยให้เรามี discipline ในการใช้ชีวิตมากขึ้นกว่า มันช่วยให้เรารู้สึกถึงความสำเร็จได้ง่าย ๆ เพียงออกไปออกกำลังกาย
9. At least 1% every day.
   ผมค่อนข้างเชื่อในการพัฒนาตัวเองแบบเรื่อย ๆ ทำเรื่อย ๆ เพราะงันแนวคิดที่ว่า ขอแค่วันละ % เป็นสิ่งที่จริง ถ้าไม่หยุดเราก็ค่อยๆพัฒนาขึ้นเรื่อย ๆ
10. Try to keep memory and experience about it, time is shall too fast.
    ชีวิตผ่านไปเร็วมาก แปปเดียวผมก็ 25 แล้ว ความทรงจำที่ผ่านมาจึงเป็นสิ่งที่สำคัญมาก บ่อยครั้งที่เราต้องฝึกสร้างปัจจุบันให้เป็นที่น่าจดจำ เพราะเราไม่ได้มีโอกาสกลับมาเจอปัจจุบันได้เป็นครั้งที่สอง
11. Control what you can.
    พื้นฐานการปล่อยวางคือ การแยกให้ออกว่าอะไรที่เราควบคุมได้ อะไรที่เราควบคุมไม่ได้
12. Meditation helps me to increase self-awareness.
    ชีวิตมีอะไรเข้ามาตลอดเวลา แต่สิ่งหนึ่งที่เปลี่ยนไปหลังนั่งสมาธิทุกวันคือ เราเท่าทันความเปลี่ยนแปลงนั้น ไม่ไหลไปตามกระแสอารมณ์ มันทำให้เราใช้ชีวิตได้ง่ายขึ้น
13. If it does not take more than 3 minutes, do it now.
    ถ้าไม่ได้ใช้เวลาเกิน 3 นาทีในการทำอะไรให้เสร็จ ก็ทำเลย จะได้ไม่ลืม
14. Vacation is a must, Life is not a robot. trying to slow productive.
    ชีวิตเหมือนการวิ่งมาราธอน มันอาจมีจุดที่เร่งบ้าง ช้าบ้าง ไม่ต้อง productive ตลอดเวลาหรอก การพักผ่อนจึงเป็นเหมือนการเตรียมตัวสำหรับ sprint ต่อไป
15. Sometimes rejection doesn't mean that we don't have value.
    การไม่ได้ถูกเลือกไม่ได้แปลว่าเราด้อย แต่มันคือจังหวะและโอกาสที่เหมาะสมตั้งหาก อย่าแบกความผิดหวังที่มากเกินความเป็นจริง
16. Quality over Quantity.
    เน้นที่คุณภาพยั่งยืนกว่า บางทีทำอะไรหลากหลายเป็นสิ่งที่ดี แต่ต้องมีบางอย่างที่เราทำได้ดีกว่าคนอื่น พยายามสร้าง value จากคุณภาพที่เรามี
17. Productivity does not mean multi-task is about the outcome.
    Productivity ไม่ได้แปลว่าทำเยอะ แต่แปลว่าทำแล้วได้ผลลัพธ์ที่มีประสิทธิภาพในระยะเวลาที่เท่ากัน
18. You are what you think.
    ในช่วง 25 นี้ได้เริ่มทำ vision board ทำให้เราได้เห็นภาพสิ่งที่เราอยากเป็นชัดมากขึ้นเลยกลายเป็น principle ของชีวิตว่า เราเป็นในสิ่งที่เราคิด เมื่อภาพเราชัด เราจะพยายามหาวิธีเพื่อไปให้ถึงภาพนั้นเอง
19. Happiness is simple but humans made it hard.
    เคยมีช่วงเวลาที่ไปเที่ยวกับพี่ที่ทำงาน แล้วมีคำถามว่าความสุขคืออะไร มันกลับ reflect ชีวิตที่ผ่านมา ชีวิตเราที่ได้ตื่นมาแล้วมีเวลา ออกกำลังกาย กินกาแฟ แล้วนั่งกับปัจจุบัน เรากลับรู้สึกถึงความสุขแล้ว บางทีความสุขมันง่ายแต่เรากลับทำให้ยากเอง
20. Not any past that bad, everything depend on how you learn from it.
    คำถามที่คุยกันบ่อยๆเวลาเจอเพื่อน “ ถ้าย้อนเวลากลับไปได้ อยากจะย้อนกลับไปแก้ไขชีวิตตอนไหน ? ” คำตอบที่เรา คือ ไม่ได้อยากย้อนกลับไปเพื่อแก้ไข เพราะหากไม่มีความผิดพลาดตอนนั้น เราคงไม่ได้เรียนรู้การใช้ชีวิตในปัจจุบัน บางครั้งต้องดื่มด่ำกับล้มเหลวเพื่อให้ชีวิตก้าวต่อไป
21. Your future = Your responsibility.
    อนาคตของชีวิต คือ ความรับผิดชอบของเราในปัจจุบัน การทำอะไรในปัจจุบันส่งผลต่ออนาคตเสมอ
22. Sometimes life is about risk-reward ratio.
    การเลือกทำอะไรสักอย่าง บ่อยครั้งที่เรากลัว แต่จริง ๆ พอคิดไปคิดมา ชีวิตมันก็มีความเสี่ยงทั้งนั้นแหละ แต่ต้องลองคิดดูว่าเสี่ยงสุดคืออะไร แล้วสิ่งที่ได้คืออะไร หลาย ๆ ครั้งมันคือก็แค่กลัวเสียหน้า แต่สิ่งที่ได้คือประสบการณ์ที่หาไม่ได้อีก
23. Writing skill can clear you mind.
    ถ้ากลัวลืมก็แค่จดออกมา ถ้ากังวลก็เขียนความรู้สึกออกมา การเขียนสำหรับผมเหมือนการวางภาระต่าง ๆ ในจิตใจ
24. focus skills is essential in this world.
    การจดจ่อกับอะไรตรงหน้าเป็นสิ่งที่สำคัญมากที่ทำให้เราใช้ชีวิตได้อย่างรู้คุณค่า
25. Present = Present ; keep smiling :)
    สุดท้ายชีวิตก็คือมีทั้งขาขึ้นและขาลง แต่การยิ้มให้ทุกความดีและร้ายที่เข้ามา ทำให้เรายินดีกับปัจจุบันได้ง่ายขึ้น ถ้าเจออะไรก็แค่ยิ้มให้กับมันแล้วมันจะผ่านไป…

เคยไหม เวลาทำ Product หรือ Marketing เราต้องหา idea แต่ส่วนใหญ่ที่หลายองค์กรทำคือ ลากเข้าประชุมแล้วให้ brainstorm ออกมา

แต่จริงๆ แล้ว idea มันสามารถเกิดขึ้นได้ทุกจังหวะตั้งแต่ตื่นถึงเข้านอน ด้วยเหตุนี้การใช้เวลาแต่ละวันของคุณให้คุ้มค่ามันส่งผลต่อ creative มหาศาล

Idea ที่ดีคือ Idea ที่เยอะ ?

ความเชื่อผิด ๆ ในการเข้า brainstorm คือพยายามหา idea ที่ดีที่สุดในตอนที่กำลังคิดถึงความเป็นไปได้ต่าง ๆ หากนั้นเป็นคุณ ถึงเวลาที่ต้องลองคิดถึง creative ในมุมมองอื่นบ้าง

Creative is a process, not a product

Innovators เก่งๆ ไม่ได้แค่ออกไปหาไอเดีย 1 ชั่วโมง แล้วกลับมาพร้อมเวทมนต์ในสร้างสรรค์สิ่งใหม่ แต่พวกเขาเหล่านั้นใช้กระบวนการ และความมุ่งมั่นในการหาไอเดียอยู่ตลอดเวลา

“ It’s time to change your mindset from one of problem and project to one of process and practice ”

THE IDEA QUOTA

การที่เปลี่ยนแปลง mindset ตัวเองจาก quality เป็น quantity ในตอนที่ต้องการไอเดีย เริ่มจากทำตาม “Idea Quota” ที่จะค่อยๆสร้างวินัยในการสร้างสรรค์ในไอเดียในแต่ละวัน

เริ่มจากทุกเช้า คุณต้อง “เขียน” ไอเดีย 10 อย่าง (เรื่องว่าต้องเป็นไอเดียอะไร จะเขียนตามไปครับ) โดยไม่ต้องคำนึงถึง point แม้ตอนนั้นคุณจะเริ่มตัดสินใจไอเดียของคุณแล้ว แต่ขอให้จำว่า “Idea validation หรือ การตรวจสอบความ work ของมัน ไม่ได้อยู่ในกระบวนการนี้

THREE-S process

Idea quota เริ่มทำได้ง่าย ๆ แค่ 3 ขั้นตอน

1. Seed. เลือกปัญหาที่สนใจ
2. Sleep. ปล่อยให่จิตใต้สำนึกทำงานในปัญหานั้น ๆ
3. Solve. Flood the problem with ideas ; ถล่มปัญหานั้นด้วยไอเดียที่มาก (ไม่รู้จะแปลยังไงดี ถถถ)

Seed

คุณไม่สามารถสร้างไอเดียจากความว่างเปล่า หรือพูดง่าย ๆ จะสร้างไอเดียอะไรถ้ายังไม่รู้ปัญหาที่จะแก้

ในความเป็นจริงสมองเราทำงานตลอดเวลาเกี่ยวกับปัญหาอะไรสักอย่าง ตั้งแต่เรื่องงาน ว่าต้องออก feature อะไรดี, marketing campaign หน้าเป็นอะไรดีนะ หรือ สุดสัปดาห์นี้จะไปเที่ยวไหน

สิ่งที่คุณต้องทำคือ “เลือกปัญหา” ที่สำคัญต่อคุณมากสุดในตอนนี้

แล้วไปนอน…

ปล. อย่าไปกังวลเรื่องการระบุปัญหา อย่าใช้เวลามากเกิน 2–3 นาที แล้วถ้าหากมีมากกว่าหนึ่งปัญหา ให้คุณ list queue ให้มันด้วย

“ As you unwind for sleep, select a problem from your problem queue and let your mind play with it in a relaxed and un focused way. ”

Sleep

แม้คุณจะหลับไหล แต่สมองยังคงเดินต่อ

จากงานวิจัยพบว่า การนอน คือ สิ่งที่สำคัญต่อ Congitive performance และ การซ่อมแซมสมอง และสำคัญที่สุด idea มักจะมาในตอนเราพักผ่อนได้อย่างเต็มที่

— คือตอนผมอ่านหนังสือมาถึงตอนนี้ ตอนแรกคิดว่า idea จะมาเข้าฝัน แต่ปรากฎว่า หนังสือแนะนำให้เราปฎิบัติต่อการนอนให้เหมือน หนึ่งใน process การสร้าง ideas —

หากคุณมีปัญหาต่อการนอน แนะนำให้ลองค้นหาวิธีการนอนอย่าง effective มันเป็นสิ่งที่มองข้ามไม่ได้ หากคุณอยากสร้าง idea ให้เยอะ

Solve

ก่อนที่คุณจะเริ่มงาน หาเวลาในช่วงเข้าสัก 5 นาที ในการเขียนไอเดียให้ได้อย่างน้อย 10 ไอเดีย

สิ่งที่ยากที่สุดไม่ใช่การไม่มีไอเดีย แต่มันเป็นการที่คุณตัดสินไอเดียเร็วเกินไป แต่หากถามว่าทำไมถึงเป็นแบบนั้น ในช่วงชีวิตตั้งแต่เรียนจนถึงวัยทำงาน เราถูกสอนให้ใช้กล้ามเนื้อแห่งการตัดสินตลอดเวลา เราต้องหาคำตอบที่ถูกที่สุดเสมอ

ทั้งที่ความจริงมันอาจจะถูกทั้งคู่แค่คนละมุมมอง

It’s all about discipline

It you don’t capture it, it didn’t happen

สิ่งที่พยายามให้ทุกคนได้ฝึกกันไม่ใช่แค่ step สนุกๆ ไว้ทำก่อนนอนหรือตอนตื่น แต่มันคือการสร้างวินัย ที่ standford เรียกสิ่งนี้ว่า “ the discipline of documentation ” มันคือสิ่งแรกที่พวกเขาสอนให้กับนักเรียนที่นั้น

ในเมื่อคุณสามารถสร้างวินัยในการสร้างสรรค์ idea ได้แล้ว คุณจะเริ่มมั่นใจกับความ creative ในที่ทำงานและยิ่งไปกว่านั้น ยังสนับสนุนให้คนรอบข้างกล้าที่จะ creative อีกด้วย

Be patient with yourself ให้เวลากับตัวเองให้การลองสร้าง habit เหล่านี้ ก่อนที่คุณจะไปแนะนำวิธีนี้ให้ใคร อยากให้คุณลอง capture ไอเดียของตัวเองก่อน เพื่อนๆคุณอยากรู้สึกไม่มั่นใจหากยังไม่เห็นคุณเขียนไอเดียด้วยตัวเอง

Show don’t tell

Ref

Divergent vs convergent. (2023, February 16). https://www.stephanhitchins.com.au/divergent-convergent/

Utley, J., & Klebahn, P. (2022). Ideaflow: The only business metric that matters. Portfolio / Penguin, an imprint of Penguin Random House LLC.

Product ที่ดีเริ่มจากทีมที่แข็งแกร่ง ?

ถ้าถามว่าทีมแบบไหนที่ สายงาน product ต้องการ ผมว่าเราต้องเริ่มกลับมาเข้าใจภาพรวมกับ “Product team” ก่อนว่าประกอบด้วยอะไรบ้าง

ก่อนจะลงลึกไปแต่ละตำแหน่ง อยากให้เข้าใจก่อนว่าทีมที่ดีควรมีลักษณะแบบไหน

Principles of Strong Product Teams

นิยามของทีม Product คือกลุ่มคนที่มีความหลากหลายในสายงานที่ตนเองถนัด มีความรับผิดชอบ และต้องการเป็น “เจ้าของ” product ที่ตนเองรับผิดชอบ แต่กว่าจะไปถึงขั้นนั้น เราลองไปดูคุณลักษณะของทีมก่อนว่ามีอะไรบ้าง

Missionaries -> เราไม่อยากทีมที่ทำงานเป็นเครื่องจักรสร้างของ แต่อยากได้ทีมที่สนใจในการแก้ปัญหาของ customer จริงๆ

Empowerment -> ได้รับการสนับสนุนในการคิดวิธีการแก้ปัญหาที่ตนเองคิดว่าเหมาะสมที่สุด และมี accountability ใน ผลลัพธ์ของวิธีการนั้น

Autonomy — ถ้าอยากให้ทีมมีทั้ง Missionaryและ Empowerment เราต้องให้ Autonomy อย่างเต็มที่เพื่อให้ทีมคิดหาว่า วิธีการไหนที่เหมาะสมที่สุด

Collaboration — การแลกเปลี่ยนความรู้ feedback ต่าง ๆ ช่วยทำให้ทีมสามารถแก้ไขปัญหาได้ดีขึ้น

Why it Works???

3 เหตุผลว่าทำไม model นี้ใช้ได้จริง

1. การ Collaboration นำไปสู่การสร้าง relationships ที่ดี และทีมที่ trust กันจะสามารถสร้างก้าวข้ามปัญหาที่ยากได้ดีกว่าทีมที่ไม่ trust กัน
2. Innovation จะเกิดเมื่อเราเอาความถนัดของแต่ละคนมาแชร์กันและนำยังช่วยให้ทีม gain knowldge ได้ดีเมื่อทีมมีทั้ง autonomy และ empowerment จาก leader
3. ทีมจะไม่ใช่แค่สร้างของออกไป แต่ทีมจะสนใจถึง value ของสิ่งที่สร้าง ยิ่งไปกว่านั้นเพื่อสร้างของที่ value ทีมต้องเข้าใจถึง user’s need, business context และสำคัญที่สุดคือ feel ownership และ accountability ใน ผลลัพธ์ที่จะตามมา

Each role in Product team

Product Manager

สิ่งที่เราต้องเข้าใจเมื่อเป็น Product Manager คือ

The product manage need to be among the strongest talent in the company.

ถ้า product manager ไม่มีความเข้าใจใน technology ไม่เข้าใจเรื่อง business ไม่ได้มีความน่าเชื่อถือที่จะโน้วน้าวใครได้ ไม่ได้เข้าใจปัญหาของ customer ไม่ได้ passion ใน product , รับรองได้เลยว่า fail แน่นอน

Deep Knowledge of the Customer — หา insight เป็นทั้ง Qualitative (why our user behave the way they do?) และ Quantitative (What they are doing ?)

Deep Knowledge of the DATA — ภาพใหญ่ที่ต้องหาเป็น ส่วนใหญ่ PM จะใช้เวลา 30 นาทีในช่วงแรกของวันดูว่า เกิดอะไรขึ้นกับ product ใน 24 ซม ที่ผ่านมา

Deep Knowledge of the Business — Sccessful product ไม่ใช่แค่ user ชอบ แต่ต้อง work for your business ด้วย

Deep Knowledge of the Market and industry — ต้องหาจุดที่ fit ของ product เป็นว่าเราจะเข้าไปอยู่ใน ecosystem ของตลาดได้ยังไง

ลักษณะของ Product Manage ที่ดีคือ “Smar,Creative and Persistent”

By smart, ไม่ใช่เรื่อง IQ แน่นอน แต่เป็น ความ cusious ในสิ่งที่ทำและเรียนรู้ได้ไวเพื่อแก้ปัญหาให้กับ customer

By creative, คิดนอกกรอบ หรือ แค่พยายามพัฒนาสิ่งที่มีอยู่ให้ดีมากขึ้นอีก

By persistent, “Pshing companies way beyond their comfort zone, Compleing evidence, constant communication” ความเพียรมันไม่ได้สร้างกันได้ มันรวมถึง passion ที่เรามีในการแก้ไขปัญหาให้ customer

To be VERY Honest

ในหนังสือได้เล่าถึงความจริง ที่จริ๊งจริงของ Product manager คือ มันไม่ใช่งาน 9–5 แน่นอน และก็ไม่ใช่งาน 15 ชั่วโมงใน office… แต่มันคืองานที่หนักที่จะตามคุณไปในทุกคืน ไม่มีความ balance อะไรเลย เพราะมันคือ ownerships ที่เรารู้สึกต่อ product มันอาจจะมีทุกครั้งที่แว๊บไปคิดเรื่อง product ปัญหาของ user ที่เจอ

Step to become a successful product manger

• Start with user — become an expert in your users, พยายามเข้าใจทุกอย่างที่เกี่ยวกับ user ทั้ง quantitative และ qualitative
• Strong relationship — with your stakeholder, ผ่านสองมุมมอง คือ 1. constraints ที่พวกเขามี และ 2.เราจะช่วยแก้ไขปัญหาที่เราเชื่อว่าจะแก้ได้ดีที่สุดผ่าน constraints เหล่านั้น
• Search for an expert in your product and industry — พยายาม learning อยู่เสมอในงานตัวเอง และความเข้าใจต่อตลาด Share your knowledge openly and generously

References

Cagan, M. (2018). Inspired: How to Create Tech Products Customers Love. Wiley.

ขอบคุณเพื่อน ๆ พี่ ๆ ทุกท่านที่อ่านมาถึงตรงนี้ ถ้าชอบก็กด Like กดติดตามกันได้ ใน Medium นี้ครับ ขอบคุณมากครับ

ยังไงฝากกด like กด share กดติดตามพวกเรา Humanalytics — UX x DATA เพื่อที่จะไม่พลาดคอนเทนต์เกี่ยวกับ ux , การใช้งาน data ดี ๆ ที่จะช่วยให้คุณทำ product ให้ดีและสนุกมากขึ้นกว่าเดิมแน่นอน~

https://www.facebook.com/humanalytics.th

ทำงานสาย. Product?

ในหนึ่งสายอาชีพที่ดู “งง” ที่สุด ผมว่าคงหนีไม่พ้น Product เพราะหากเข้าไปดู Job description คนทำงานสาย product ทั้ง Product manager, UX/UI designer หรือ Dev ต้องมีความเข้าใจที่ครอบคลุมทั้งสายงานตนเอง และ สายงานรอบข้าง เช่น Business , Marketing หรือ Human management

เพราะการสร้าง Product ให้คนต้องการ ไม่ได้มีเพียงการสร้าง Features

บทเรียนจากช่วงแรกของการทำงาน

จากประสบการณ์ส่วนตัวผมจบจาก Psychology แล้วเริ่มงานใน ฐานะ UX research แล้วค่อย ๆ เก็บประสบการณ์จนเป็น Product Owner ที่ Application ไทยแห่งหนึ่ง

แต่เอาเข้าจริง ผมยังรู้สึกว่าตัวเองไม่ได้เข้าใจการทำงาน product ได้ดีขนาดนั้น จนเริ่มหาหนังสือมาอ่าน แล้วพบกับหนังสือ “Inspired” ซึ่งได้สรุปเนื้อหาได้ดีมาก เหมาะกับทุกคนที่เริ่มทำงานสาย product ไม่ว่าะเป็น PM/PO, UX/UI designer หรือ Dev ก็เหมาะกับการอ่านเล่มนี้

ผมเลยขออนุญาตสรุป #ไว้(write)กันลืม :)

ในบทความนี้ผมพยายามเอาประสบการณ์ตนเองที่เกี่ยวข้องกับเนื้อหาในหนังสือมาสรุปให้ทุกท่านได้อ่านกันนะครับ หากมีจุดที่บิดเบือนไปก็ขออภัยมา ณ ที่นี้ด้วยครับ

PART1 Lessons from Top Tech companies

Product fail เพราะอะไร ?… คำถามนี้อาจมีหลายสาเหตุ แต่สาเหตุใหญ่สุดคือ
“ไม่มีคนใช้ ” พอคนใช้น้อยก็ไม่มีเงินพอมาใช้จ่าย สุดท้ายก็ปิดตัวหรือเปลี่ยนคนทำ

ฟังดูใจร้ายแต่ในฐานะคนทำงานที่พยายามอย่างหนักในการวางแพลนพัฒนา feature อดหลับอดนอนเป็นเวลาหลายวัน หรือบางท่านอาจเป็นหลายเดือน เพื่อ launch product ออกมา… หลังจากนั้นก็พบกับความจริงว่า

Product เราไม่มีใครใช้

แต่ในทุกปัญหาย่อมมีโอกาสให้เราได้ทบทวนตัวเองว่า ทำไม product ของเรา fail วะ ?? (ใส่อารมณ์นิดนึงงงง)

1. ถ้ามัน fail แล้วใครเป็นคนตัดสินใจในการสร้างสิ่งนั้น (ฟังดูโทษกันแต่ผมว่าควรทบทวนดู)
2. แล้วตอนนั้นเพราะอะไร เราถึงตัดสินใจแบบนั้น ?
3. ในอนาคตเราจะแก้ไขให้ เราสร้างแต่สิ่งที่ user ต้องการได้อย่างไร?

ผมเคยทำ startup แล้วก็ fail ทั้งทีตอนนั้นผมมีทีมที่รู้สึกว่า ทั้งประสบการณ์หรือ passion ทีมเรามีครบ แต่ทำไมเราล้มเหลว… สุดท้ายคำตอบคือ

“ มันไม่สำคัญหรอกว่าทีมคุณจะเก่งแค่ไหน ถ้าคุณไม่ได้สร้าง product ที่มัน Worthwhile หรือคุ้มค่าที่จะลงแรง ”

หลักการทำงานของ Product

ถ้าให้ผมพูดว่า product ทำงานยังไง ผมอยากจะขอหยิบรูปนี้มาใช้พูดถึงภาพรวมของ product ที่แบ่งได้เป็น สองอย่างที่ parallel กันคือ

1. Discovery phase 2. Delivery phase

1. Discovery phase คือ การค้นหา ว่า“เราจะทำสร้างอะไรดี ?” มันเริ่มทั้ง qualitative คือ การหา insight ผ่านการสัมภาษณ์ user การทำ UX research และ quantitative เช่น การวิเคราะห์ข้อมูล funnel analytics
2. Delivery phase คือ การสร้างของ หลังจากรู้แหละว่าจะสร้างอะไรก็มาถึงขั้นตอนการสร้างที่อาจกินเวลา 1 วัน ถึง 1–2 ปี แล้วแต่บริษัท

ซึ่งหลายบริษัท ***ย้ำว่าหลายบริษัทจริง ๆ ผมไม่ได้โม้*** ตายตั้งแต่การ discovery ว่าจะสร้างอะไร แล้วยิ่งมาตายต่อในจังหวะจะสร้าง บางทีใช้วลา 1 ปี ในการสร้าง product ที่ไม่มีคนใช้ และกลับแปลกใจอีกว่าทำไมคนไม่ใช้

บางครั้งก็เอามาจากสิ่งที่ consultant บอก หรือ copy paste คู่แข่ง…

นี้เลยเป็นสาเหตุหลัก ๆ ที่ทำให้ผมพยายามจะเข้าใจว่า “ ถ้าอยากสร้าง Product ที่ดี ที่ user ต้องการ” ต้องเริ่มยังไง…

Life is too short to build things that no one wants.

บทความนี้…

ผมพยายามที่เขียนสรุปหนังสือ “Inspired: how to create tech products customers love” ให้ได้ทั้งเล่ม เลยขออนุญาตแบ่งเนื้อหาออกเป็นตอน ๆ ทั้งนี้เพื่อความง่ายในการเขียนและการนำไปใช้งานต่อของ พี่ ๆ ทุกท่านด้วยนะครับ :)

References

Acharya, D. P. (2022, July 29). An introduction to dual track agile for product managers. Geekflare. https://geekflare.com/dual-track-agile-guide/

Cagan, M. (2018). Inspired: How to create Tech Products Customers Love. Wiley.

Harriet Adams Aug 3, Team, R. B., Adams, H., & Wynne, D. (2020, May 25). Learning to fail to deliver digital product success. Our Thinking. https://content.red-badger.com/resources/learning-to-fail-to-deliver-digital-product-success

Miklashonok, O. (2021, November 16). Why do most startups fail? top reasons for startup failure: LITSLINK Blog. Litslink. https://litslink.com/blog/why-do-most-startups-fail

ขอบคุณเพื่อน ๆ พี่ ๆ ทุกท่านที่อ่านมาถึงตรงนี้ ถ้าชอบก็กด Like กดติดตามกันได้ ใน Medium นี้ครับ ขอบคุณมากครับ

ยังไงฝากกด like กด share กดติดตามพวกเรา Humanalytics — UX x DATA เพื่อที่จะไม่พลาดคอนเทนต์เกี่ยวกับ ux , การใช้งาน data ดี ๆ ที่จะช่วยให้คุณทำ product ให้ดีและสนุกมากขึ้นกว่าเดิมแน่นอน~

https://www.facebook.com/humanalytics.th

วันนี้ผมอยากสรุปหนังสือ “User Friendly: How the Hidden Rules of Design Are Changing the Way We Live, Work, and Play.” ของ คุณ Cliff Kuang (Author) และ Robert Fabricant (Author) ไว้กันลืมครับ #writeกันลืม :)

แต่ด้วยความที่หนังสือเล่มนี้ค่อนข้างเปิดมุมมองได้เยอะเลยจะแบ่ง part เป็นหลายๆ part โดยวันนี้จะเริ่มที่…

บทที่หนึ่ง User Friendly = Easy to use

Confusion

หากให้ลองคิดถึงว่า อะไรคือ ความง่ายในการใช้ง่าย (Easy to use) ใน product ต่าง ๆ หลาย ๆ คนอาจตอบว่า มันคือการออกแบบที่เน้นความสวยงามและเข้าใจง่าย เช่น มีปุ่มให้กดไปต่อได้ และ สามารถหาปุ่มนั้นได้ง่าย เป็นต้น

แต่หากเรามองกลับกัน ถึง product ที่เข้าใจยาก เช่น ระบบปฎิบัติการนิวเคลียร์ เราจะยังคิดว่าไหมว่า มันจำเป็นต้องมีการออกแบบที่สวยงามและเข้าใจง่าย

ว่าแต่เราขาดอะไรไปเมื่อนึกถึงการออกแบบที่ช่วยให้คนใช้ง่าย ?

หนึ่งในคำตอบเหล่านั้นสามารถอธิบายได้ในรูปแบบของ “Feedback”

Three Mile Island

หากให้ทุกคนช่วยออกแบบให้หน้าตาของระบบจัดการในเครื่องปฏิกรณ์นิวเคลียร์ ทุกคนคิดว่า

หนึ่ง มันต้องสวยไหม ?

สอง มันต้อง minimal ไหม มีปุ่มน้อย ๆ ?

สาม ต้องมี Ads ไหม จะได้หาเงิน ( อันนี้ไม่เกี่ยว 555 ใส่ไว้ขำ ๆ)

ทุกความคิดไม่มีผิดไม่มีถูกมันคงขึ้นอยู่กับทีมหรือบริษัทของคุณ แต่แก่นคิดในการออกแบบต้องมีอะไรบ้าง ถึงเรียกได้ว่ามันคือ User Friendly ผมอยากพาทุกคนย้อนไปใน เหตุการณ์อุบัติเหตุนิวเคลียร์เกาะทรีไมล์ เพื่อช่วยให้ตระหนักถึงความสำคัญของ Feedback

อุบัติเหตุนิวเคลียร์เกาะทรีไมล์ เป็นหนึ่งในเหตุการณที่เกิดขึ้นจากความผิดพลาดในออกแบบที่ลืมคำนึงถึง Feedback ระหว่างระบบและคนใช้ ซึ่งในเหตุการณ์นี้เกิดจากเกิดจาก วาล์วที่ติดขัด จนทำให้น้ำหล่อเย็นจำนวนมากของเตาปฏิกรณ์นิวเคลียร์รั่วไหลออกมา

นอกจากปัญหาทางด้านเทคนิคแล้ว อีกหนึ่งในสาเหตุหลักของอุบัติเหตุในครั้งนี้ก็คือ “ระบบไม่ได้ออกแบบให้ผู้ใช้งานสามารถจัดการแก้ไขปัญหาได้อย่างถูกต้อง”

เพราะผู้ใช้งานเข้าใจผิดว่ามีน้ำหล่อเย็น มากเกินไป อยู่ในเครื่องปฏิกรณ์และเป็นสาเหตุให้ความดันไอน้ำถูกปล่อยออกมา

ไฟแสดงสถานะของวาล์วถูกออกแบบให้ติดเมื่อมีไฟฟ้าไหลมาที่วาล์ว และจะดับเมื่อไม่มีไฟฟ้า นั่นหมายความว่า สถานะของมันไม่ได้บอกว่าวาล์วเปิดหรือปิด เมื่อวาล์วทำงานผิดพลาด ไฟแสดงสถานะดับทั้งที่วาล์ลยังเปิดอยู่ เลยทำให้ผู้ใช้งานเข้าใจผิด

และไม่ได้เข้าใจถึงสถานะที่แท้จริงของวาล์ว ปล่อยวาล์วให้เปิดไปเรื่อยๆ รวมทั้งไม่ได้มีการตรวจสอบเพิ่มเติม จนเป็นสาเหตุให้ความดันไอน้ำที่ปนเปื้อนถูกปล่อยออกมาจนกลายเป็นอุบัติเหตุนิวเคลียร์ในครั้งนี้

สาเหตุ คือ User Interface ของไฟแสดงสถานะของ วาล์ว ได้ทำให้ผู้ใช้งานสับสน จนนำไปสู่การตัดสินใจที่ผิดพลาด

No abiding logic that a user could understand

Easy to Use?

ถ้าให้ทุกคนคิดถึง Product ที่เรารู้สึกว่าใช้งานง่ายตั้งแต่ครั้งแรกที่ลอง มันประกอบด้วยอะไรบ้าง ?

คำตอบที่หนังสือได้บอกประกอบด้วย

Navigability : สามารถนำทาง “การใช้งาน” ได้

Consistency : มีรูปแบบ การจัดวางที่สม่ำเสมอ

และหากทั้ง Navigability และ Consistency สามารถทำได้อย่างมีประสิทธิภาพ จะทำให้ user สามารถ “Predict” หรือ ทำนายสิ่งกำลังจะเกิดขึ้นได้

ก่อเป็น Mental Model : การมีรูปแบบวิธีคิดต่อสิ่งนั้น ๆ

มาถึงตรงนี้ผมอยากให้ทุกคนเข้าใจ concept ของ Mental Model ว่า “ หากสิ่งที่เราออกแบบขาดรูปแบบจัดวางที่มีความหมาย ,วางปุ่มต่างไว้อย่างรกๆ แบบไร้เหตุผล หรือขาดความสม่ำเสมอในรูปแบบการใช้งาน”

สิ่งเหล่านี้จะไม่สามารถช่วยให้ user เกิด mental model ต่อการใช้งาน product ของเราได้ ซึ่งหลักการ Mental Model ถูกนำไปใช้ได้ตั้งแต่ ของเล่น จนถึง ระบบโรงไฟฟ้านิวเคลียร์

But How?

Mental Models are nothing more and nothing less than the intuitions we have about how something works

Mental model เป็นสัญชาตญาณที่เรามีต่อวิธีใช้งานของสิ่งของ แต่ถ้าเราไม่มีเคยรู้จักสิ่งของนั้นมาก่อน เราจะมีสัญชาตญาณได้ยังไง ?

คำตอบคือ เราจะใช้ “Feedback” ในรูปแบบของการลองผิดลองถูก (trial and error) เพื่อสร้าง mental model ขึ้นมาก

เอาละครับ ถึงเวลาของการเชื่อมโยง หาก Feedback ก่อให้เกิด Mental Model แล้วมันต้องมีลักษณะยังไง ?

Feedback ?

คำตอบคือ feedback ต้องประกอบด้วย Navigability และ Consistency กล่าวคือ หาก user เริ่มใช้ไม่ถูกต้อง

1. เราต้องมีการให้ feedback ที่สามารถนำทางเขาไปสู่การใช้งานที่ถูกต้องได้ เช่น มีคำแนะนำ คำบอกใบ้ว่า user ทำอะไรผิด
2. เราต้องให้ feedback ที่สม่ำเสมอ จน user สามารถนำ information เปลี่ยนเป็น action ที่เหมาะสมได้

It’s science!

สิ่งที่หนังสือได้อธิบาย หากสรุปมันคือ “กระบวนของวิทยาศาสตร์ในการหาคำตอบอะไรสักอย่างผ่านการทดลอง”

แต่สิ่งที่เรามองข้ามไปคือ เราไม่ได้ออกแบบให้ user ได้ทดลองและหาคำตอบได้อย่างเหมาะสม จนทำให้ user เลิกใช้ product เราไปในที่สุด หรือไม่ก็หงุดหงิดสะก่อน

เพราะงันสิ่งเราต้องนึกถึงเสมอเวลาออกแบบอะไรสักอย่าง คือ user ต้องสามารถหาทางออกได้เองว่า ต้องทำอะไร หรือ บอกได้ว่าจะเกิดอะไรขึ้น หากเลือกการกระทำนั้น ๆ ….

ขอบคุณเพื่อน ๆ พี่ ๆ ทุกท่านที่อ่านมาถึงตรงนี้ นี้เป็นเพียงจุดเริ่มต้นของ user friendly ที่ผมวางไว้จะเขียนสรุปของหนังสือเล่มนี้ทั้งเล่ม

ในบทต่อเราจะดูกันว่า product ที่สร้างควรเป็นแบบไหน แล้วควรเริ่มคิดยังไงครับ :)

ถ้าชอบก็กด Like กดติดตามกันได้ ใน Medium นี้ครับ ขอบคุณมากครับ

ฝากเพจด้วยครับ :)

นี้เป็นเพียงจุดเริ่มต้นของ user friendly ยังไฝากกด like กด share กดติดตามพวกเรา Humanalytics — UX x DATA เพื่อที่จะไม่พลาดคอนเทนต์เกี่ยวกับ ux , การใช้งาน data ดี ๆ ที่จะช่วยให้คุณทำ product ให้ดีและสนุกมากขึ้นกว่าเดิมแน่นอน~

https://www.facebook.com/humanalytics.th

— References

Kuang, C., & Fabricant, R. (2020). User friendly: How the hidden rules of design are changing the way we live, work, and play. WH Allen.

From my own experience, it’s easier said than done.

Since starting at a startup and tech firm, I’ve heard terms like design thinking, customer-centricity, and lean start-up. They all begin with the goal in mind, the User. But, in practice, it is easier said than done.

As a startup in large tech, or venture builder, I generally operated many projects as a startup. I have to discuss this with many top leaders who don’t understand the benefit of starting from the user’s point of view.

For example,

when we begin to design a feature, it comes from the highest level and is unconcerned about what users think of it.

We make decisions based on profit rather than user experience to improve customer retention in the long term.

Finally, we did not plan on discussing customer perspectives in each meeting, and most of the meetings remain mute because no one is brave enough to speak with hippo.

I think that nothing is absolutely right or wrong; it all depends on context, but as a way of working, I try to keep my team or culture more customer obsessed. I also want to prevent unnecessary struggle with other leaders with different points of view by applying specific working tools…

How do I start?

I’d like to start changing something in my team because I believe that the way we work in tech firms or produce products should be more customer-centric.

It all starts with a meeting….

the reason I stated that it is that in Thailand, we have to accept that we are meeting rather than developing things. As a result, I think we should enhance our meeting by “working backward.”

The Working back process requires the individual to present ideas in a narrative form and to accept the critique of anyone in the room

“ Ban PowerPoint -> start using PR/FAQ ”

Why might PR or press releases help? -> As you begin with press releases, it will frame you, to begin with, the user’s perspective and continue to seek further input, both internal and external. The meeting’s major goal is to argue for the truth about the suggested proposal or topic. and here are my template

For PR

Tell us what you’re trying to do

from your customer’s perspective.

What is the problem you’re trying to solve?

What is the solution that you propose?

What would customers say about that particular solution?

Would that be something that they would like or not like

As we’ve seen, this model challenges the team to question whether the current PR has it right or if there are additional fundament truths to uncover.

And here are some of the ideas that Amazon has employed to keep the firm focused on the consumer and investing in innovation, such as AWS or Amazon Prime.