Tag product development

Reforge Artifacts

thanhhien 2 phản hồi

Đôi nét về Reforge

Reforge từ lâu đã là một địa chỉ học tập đáng tin cậy cho các bạn đang làm Growth và User Acquisition nói riêng và Product nói chung. Vì Reforge nhắm đến phân khúc khách hàng là lãnh đạo và quản lý sản phẩm cấp cao, nên chi phí học đắt đỏ, vì thế ở Việt Nam tôi ít thấy có nhiều người học hoặc chí ít cũng chưa nghe nhắc nhiều ở các cộng đồng sản phẩm. Nếu bạn quan tâm có thể tìm hiểu tại Reforge Plan hoặc email tôi về địa chỉ hoangtung240195@gmail.com, tôi sẽ gửi bạn tham khảo một vài tài liệu từ khoá học mà tôi may mắn có được.

Dù chi phí khoá học cao, rất may là vẫn có thể tìm thấy nhiều tài liệu miễn phí chất lượng từ blog của Brian Balfour, sáng lập của Reforge, về chủ đề Growth, Strategy & User Acquisition cũng như Reforge Blog và Reforge Artifacts mà tôi sẽ giới thiệu trong bài này.

Các bài đăng trên blog của Brian Balfour. Ảnh: Hoàng Tùng

Về Reforge Artifacts

Trước hết, phải xin thẳng thắn rằng có rất nhiều người giỏi nhưng vì giới hạn thời gian và nhiều rào cản mà không phải ai cũng có thể chia sẻ những kinh nghiệm, kiến thức và kể cả sai lầm của mình một cách rộng rãi. Riêng tôi thì blog này cũng là một nổ lực lớn, tôi không nghĩ mình giỏi hay viết hay, chỉ mong viết ra những gì mình biết để mong có ích cho 1-2 người là đã thấy vui. Vì vấn đề này, cho nên ngoài các cuốn sách, khoá học nhỏ, một số chia sẻ trên Youtube thì đa phần vẫn học qua thực tiễn công việc và đồng nghiệp. Kiến thức, tài liệu chưa được lan truyền mạnh mẽ.

Quay trở lại Reforge, là nơi có lợi thế là có đội ngũ giảng viên từ các công ty công nghệ lớn trên thế giới như Hubspot, Dropbox, Lift, Uber, Netflix, v.v.. và các thành viên cũng chất lượng đến từ các công ty công nghệ, khởi nghiệp toàn thế giới. Tận dụng lợi thế này, gần đây Reforge cho ra đời chuyên trang gọi là Artifacts, tại đây các đội ngũ giảng viên, học viên của họ chia sẻ các tài liệu thực tế trong quá trình làm việc của mình như Product Roadmap, Go-to-market Strategy, Strategy, Pitch Deck, v.v..

Một số giảng viên các chương trình của Reforge. Ảnh: Hoàng Tùng
Tài liệu trên trang Reforge Artifact. Ảnh: Hoàng Tùng
Chi tiết một tài liệu chia sẻ về Product Market Fit Score Driven Product Strategy và lý do tại sao có tài liệu này từ tác giả Nik Simak khi làm việc ở SideKick Browser, đi kèm các chú giải của tác giả. Ảnh: Hoàng Tùng

Bạn sẽ thấy rằng các tài liệu này rất đa dạng về phương pháp, đa dạng về cách trình bày và đa dạng về đối tượng sử dụng. Không như các template chung, các tài liệu này thể hiện rõ công ty và vai trò của người viết cộng thêm các chú giải trên các ví dụ khá sát thực tế sẽ giúp chúng ta dễ dàng hình dung bức tranh toàn cảnh. Từ đó khi áp dụng cho trường hợp của mình sẽ không bị miễn cưỡng và gò bó.

Cũng xin nói rằng, những tài liệu trên vẫn là đang áp dụng cho các công ty ở phương Tây. Mặc dù Việt Nam đi sau và rất nhanh chóng học tập cái mới nhưng còn nhiều điều kiện về thị trường, con người khác xa với thị trường quốc tế. Vì vậy, tôi nghĩ rằng khi dùng những tài liệu mẫu này để áp dụng ở nước ta, luôn phải cẩn thận. Có khi là những thử nghiệm và điều chỉnh phù hợp với đặc thù của riêng mình.

Nhân đây, tôi cũng mong tương lai cộng đồng chúng ta sẽ có những nơi như vậy để anh em cùng chia sẻ tài liệu để học hỏi lẫn nhau và nâng cao năng lực không thua kém ngoài kia.

Input metrics & Output metrics

thanhhien Để lại bình luận

Khi phát triển một sản phẩm, xây dựng một tính năng hay đánh giá bất kỳ giả thuyết nào. Ngoài việc xác định mục tiêu, đối tượng mục tiêu, vấn đề/nhu cầu người dùng cần giải quyết, việc xác định chỉ số đo lường mức độ thành công (key measurement metrics) là cực kỳ quan trọng.

Đối với key measurement metrics, sẽ cần nhìn theo hai cấp độ: Input Metrics và Output metrics.

  • Output metrics là kết quả sau cùng mà chúng ta mong muốn đạt được, không thể cải thiện các chỉ số này một cách trực tiếp.
  • Input metrics là các chỉ số mà chúng ta có thể dễ dàng tác động trực tiếp, thông qua các input metrics để tác động lên output metrics.

Một metric vẫn có thể là input metrics của một metric, nhưng cũng có thể là output metrics của một metric khác.

Một output metrics có thể có nhiều input metrics và mỗi input metrics có mức độ tương quan (correlate) với output metric khác nhau.

Ví dụ

  • Goal: Archive Product-Solution Fit
    • Output metrics: Week 1 Retention (W1)
    • Input metrics: % New users open app, % Conversion at Onboarding, R1 Retention, …
  • Goal: Increase customer satisfaction
    • Output metrics: Customer Satisfaction Score (C-SAT)
    • Input metrics: System Usability Scale (SUS), R1 Retention, % App session crash

Sử dụng input metrics và output metrics

Hai loại metrics này có một số đặc điểm khác nhau như giải thích ở trên. Cho nên khi đo lường các chỉ số phát triển sản phẩm, chúng ta cần xác định rõ hai nhóm metrics để sử dụng cho phù hợp:

Với Output metrics

  • Output metrics thường được sử dụng như chỉ số chiến lược ở mức độ high-level. Thông thường Output metrics sẽ được đặt làm Key Result của sản phẩm trong Quý/Năm.
  • Output metrics được dùng để trao đổi, báo cáo với các cấp quản lý, trao đổi với các external Stakeholders và internal team. Giúp tất cả nắm được sức khỏe chung của sản phẩm.
  • Các Output metrics thường được đưa lên các BI Dashboard, Product Dashboard và được báo cáo mỗi Bi-Weekly, Monthly.
  • Nếu chỉ tập trung vào output metrics mà không nhìn vào input metrics:
    • Sẽ rất khó để cho chúng ta đánh giá ưu tiên và có những hành động cụ thể để trực tiếp tăng output metrics.
    • Tăng được output metrics nhưng không có learnings vì có quá nhiều metrics khác ảnh hưởng đến output metrics
    • Có thể đạt được kết quả mong đợi nhưng phải hy sinh các chỉ số khác và có thể gây tác động tiêu cực trong dài hạn. Ví dụ: Để tăng Revenue, team quyết định tăng tần suất hiển thị quảng cáo. Trong thời gian đầu, lợi nhuận tăng nhưng có thể khách hàng rời bỏ sản phẩm sớm hơn vì trải nghiệm không tốt khi xem quá nhiều quảng cáo. Nên nếu tính trọn vòng đợi khách hàng có thể giá trị khách hàng mang lại giảm đi.

Với Input metrics

  • Input metrics là chỉ số dễ dàng đo lường và thấy được thay đổi trong một khoảng thời gian ngắn (Hourly, Daily, Weekly). Giúp team có thể nhanh chóng đánh giá các hypothesis để đưa ra quyết định tiếp theo nhanh chóng.
  • Input metrics giúp chúng ta đánh giá sâu sát liệu các kế hoạch, chiến lược có đi đúng hướng hay không.
  • Dùng input metrics để phân bổ trách nhiệm xuống các nhóm chuyên môn/cá nhân. Ví dụ:
    • User Acquisition: IPM (Installs per Mille), CPI (Cost per Install), eCPI (Effective Cost per Install), ROAS, etc…
    • Tech: Sprint Velocity, Crash Rate, System Active
    • AI/ML: Model Accuracy, Recall Score, Precision Score, F1 score
    • Product: Retention Rate, Set up metrics, Aha metrics, Habit metrics, Engagement metrics, etc…
    • Monetization: LTV (User Lifetime Value), Subscription Rate, Refresh rate
  • Các input metrics thường là các chỉ số dùng để ra quyết định priorities của các actions để đặt được output metrics.

Bài học kinh nghiệm là bất kì một kế hoạch, hành động gì sau khi đặt mục tiêu cũng nên có những chỉ số để đo lường mức độ thành công của mục tiêu. Với các chỉ số này, rất dễ để thiết đặt mong đợi và giao tiếp giữa nội bộ team phát triển và với các stakeholders. Ngoài ra chú ý đến việc xác định các output metrics và input metrics để có cái nhìn bao quát trong việc đánh giá kết quả tổng thể và có sự chủ động trong hành động.

INSPIRED – Marty Cagan

thanhhien Để lại bình luận

Nếu có ai nhờ tôi giới thiệu một cuốn sách về Product Management, tôi sẽ đề xuất ngay cuốn “INSPIRED” của Marty Cagan.

Image: Amazon

INSPIRED mang đến các bài học rất thực tế từ các Product Manager trong ngành phát triển phầm mềm và giúp chúng ta có một bức tranh tương đối hoàn chỉnh về cả phương pháp phát triển, từng vai trò của từng thành viên trong nhóm phát triển và giới thiệu cả các công cụ mà có thể nhiều người đã khá quen thuộc một ít trong số đó.

Cuốn sách được chia làm các phần chính:

  • Part I: Lessons from top tech companies
  • Part II: The Right People
  • Part III: The Right Product
  • Part IV: The Right Process
  • Part V: Culture

Mặc dù được chia nhỏ nhiều phần nhưng mỗi ý trong bài đều được giới thiệu ngắn gọn dễ hiểu. Bám sát theo bộ ba People – Product – Process mà tác giả giới thiệu khá kĩ nên rất dễ nắm bắt.

Đây là một cuốn sách đối với tôi là cuốn sách gối đầu giường đích thực. Mỗi khi gặp khó khăn trong công việc mà bản thân chưa có lời giải, tôi thường dùng cuốn sách như một cuốn từ điển để tra cứu và giúp gợi mở nhiều hướng giải quyết mới.

Có một kỉ niệm vui về cuốn sách là khi tôi lead một team Product, các bạn trong team đều là những người trẻ, chưa có nhiều kinh nghiệm kể cả tôi. Quá trình làm việc gặp phải rất nhiều vấn đề về quy trình, tổ chức và phương pháp mà không ai biết nên làm gì và hỏi ai. May mắn là chúng tôi bén duyên với INSPIRED, mỗi thứ 6 cả nhóm lại với nhau ở phòng họp nhỏ cạnh công ty để cùng đọc và chia sẻ góc nhìn về những chủ đề mà mọi người quan tâm trong sách.

Team Product Cloudjet Solution – Tháng 11/2018

Product Manager Technical Interview (P1)

thanhhien Để lại bình luận

Quy trình tuyển dụng ví trí Product Manager sẽ được chia làm nhiều giai đoạn. Ở các công ty tôi làm việc, quy trình tuyển vị trí này chia làm 6 vòng chính:

  • Vòng 1: Chuẩn bị Resumé và nộp hồ sơ
  • Vòng 2: Phone Screen
  • Vòng 3: Case Study
  • Vòng 4: Technical Interview
  • Vòng 5: General Interview
  • Vòng 6: Get An Offer

Trong bài này, tôi xin nói đến vòng Technical Interview. Đây là vòng cần nhiều thời gian để chuẩn bị và mang tính quyết định, các câu hỏi đi sâu vào chuyên môn công việc của Product Manager.

Các câu hỏi trong vòng Technical Interview sẽ phân bổ theo các nhóm sau:

  • Company Question
  • Personal Question
  • Estimation Question
  • Strategy Question
  • Execution Question
  • Product Question
  • Technical Question
  • Behavioral Question

Company Question

Hiểu rõ một công ty trước khi nộp hồ sơ là rất quan trọng. Không chỉ tốt trong quá trình phỏng vấn giúp gây ấn tượng với nhà tuyển dụng.

Để chuẩn bị cho các cầu hỏi này, có thể tìm hiểu công ty theo guideline sau:

  • Product
    • Products: Các sản phẩm nào công ty đã, đang và sẽ phát triển. Các tính năng, giá trị mà sản phẩm này mang lại.
    • Market: Thị trường mục tiêu mà công ty/các sản phẩm công ty đang hướng tới.
    • Customers: Chân dung các khách hàng mà các sản phẩm công ty đang hướng tới. (B2B or B2C, Demographics, Behavioral, Needs)
    • Competitors: Các đối thủ cạnh tranh trên thị trường. Sản phẩm công ty có điểm gì khác biệt so với các đối thủ.
    • Business Model: Cách mà công ty đang kiếm tiền.
    • Customer Feedbacks: Phản hồi tích cực, tiêu cực của khách hàng (Reviews, Feedbacks).
    • Product Metrics: Chỉ số nào dùng để đo lường mức độ thành công của sản phẩm (Vd: Revenue, Retention, ROAS).
  • Strategy
    • Vision: Tầm nhìn dài hạn của công ty và ban giám đốc
    • Mission: Sứ mệnh mà công ty hướng đến
    • Strength: Điểm mạnh của sản phẩm/công ty
    • Weakness: Điểm yếu của sản phẩm/công ty
    • Opportunities: Các cơ hội tiềm năng dựa trên thế mạnh, thị trường mà công ty đang hướng đến
    • Threats: Với sản phẩm, thị trường đang có các mối đe dọa nào ảnh hưởng sự thành công của công ty trong tương lai (Lĩnh vực, Đối thủ, Luật, Người dùng)
  • Culture
    • Culture: Văn hóa công ty
    • Core Value: Các giá trị cốt lõi công ty muốn xây dựng
    • Company History: Lịch sử hình thành công ty
    • Company Structure: Cấu trúc tổ chức
    • Founding team/Key members: Các thành viên sáng lập và điều hành tổ chức
    • Line Manager & Team: Người quản lý trực tiếp và đặc điểm đội nhóm trong tương lai sẽ cùng làm việc.

Personal Question

Đây là phần giúp nhà tuyển dụng hiểu rõ về ứng viên và cách họnghĩ. Một số câu hỏi sau có thể được hỏi:

  • Tell Me About Yourself
    • Đây là câu hỏi mở, khi bắt đầu phỏng vấn tôi cũng thường sẽ hỏi ứng viên. Ứng viên cần mô tả một cách ngắn gọn và nổi bật những ý chính về bản thân trong vòng 2-3 phút. Không nên nói quá chung chung nhưng cũng đừng đi vào quá chi tiết, nếu nhà tuyển dụng thấy điểm nào thú vị họ sẽ hỏi thêm.
    • Công việc và sản phẩm hiện tại hoặc gần nhất đang đảm nhận và các công việc trước đó
    • Thành tựu nổi bật đã đạt được ở các công việc trước.
    • Cơ duyên nào đưa bạn đến công việc này. Tạo sao bạn lại muốn trở thành Product Manager?
    • Các sở thích ngoài công việc hỗ trợ cho công việc của một người Product Manager (Ví dụ: Viết blog; Đọc sách về phát triển sản phẩm; Làm advisor/mentor cho các dự án; Tham gia các Workshop chuyên đề).
  • Why do you want to work here?
    • Từ bước nghiên cứu về công ty và các sản phẩm ở trên. Hãy cho nhà tuyển dụng thấy điểm đặc biệt ở công ty khiến bạn mong muốn ứng tuyển vào.
  • Why should we hire you?
    • Chúng ta là người hiểu rõ bản thân nhất, cho nên trước khi nhà tuyển dụng nhận ra những tốt chất, tiềm năng và điểm mạnh của bạn. Hãy cho họ thấy điểm sáng nơi bạn mà không phải ai cũng có. Những giá trị gì bạn sẽ mang lại cho công ty về văn hóa, kinh nghiệm, kiến thức.
  • Why are you leaving your current job?
    • Có nhiều lý do để một người rời bỏ công việc và tìm kiếm cơ hội mới. Tựu chung lại hãy tập trung vào những điểm tích cực mà bạn đang tìm kiếm như về cơ hội thăng tiến, sản phẩm mang lại được nhiều giá trị, tìm kiếm một nơi có văn hóa và phúc lợi tốt hơn, chưa phát huy được thế mạnh ở công việc hiện tại. Dù sao đi nữa cũng hạn chế việc nói ra những điều tiêu cực về công ty cũ.
  • What do you like to do in your spare time?
    • Nếu là một người luôn mang trong mình năng lượng tích cực và tinh thần ham học hỏi, hãy cho nhà tuyển dụng thấy. Hãy hạn chế nói ra những hoạt động chung chung như: đi cafe, nói chuyện với bạn bè, shopping, etc. bởi vì không tạo ra sự khác biệt nơi bạn và không giúp nhà tuyển dụng thấy ấn tượng hơn. Hãy tập trung làm nổi bật các hoạt động mang lại sự khác biệt và cụ thể ví dụ như: Dành mỗi ngày 1 tiếng để viết blog về chuyên môn và cuộc sống; Học ngôn ngữ lập trình Python và tự code các ứng dụng nho nhỏ.
  • Where do you see yourself in five years?
    • Tôi vẫn thích hỏi câu này để xem liệu rằng ứng viên có tinh thần học hỏi, cầu tiến và đặt ra những mục tiêu cho bản thân hay không. Ngoài ra, dựa trên đó nhà tuyển dụng cũng sẽ có thể thấy được Career Path hay cơ hội thăng tiên mà công ty có thể mang lại như bạn mong muốn hay không. Có thể xảy ra trường hợp bạn muốn phát triển lên các vị trí cao hơn nhưng có thể trong vòng 1-2 năm tới công ty chưa đáp ứng được vì quy mô công ty.
  • What are your strengths and weaknesses?
    • Theo thói quen, câu hỏi này tôi thường hỏi ứng viên ở cuối buổi phòng vấn. Không có ai là hoàn hảo, cho nên một ứng viên tiềm năng là người có thể thấy được hoặc lắng nghe góp ý của mọi người về điểm mạnh và điểm yếu của mình để tự đó có kể hoạch phát triển cho bản thân. Khi nói về điểm mạnh hãy tự tin nhưng khiêm tốn, đừng nói những ý như “Tôi có product sense tốt/ Tôi rất hiểu người dùng” mà thay vào đó hãy nói “Tôi có phương pháp để luôn luôn đặt người dùng làm trọng tâm trong mọi quyết định và quá trình nghiên cứu tìm giải pháp, tôi giành rất nhiều thời gian lắng nghe phản hồi từ họ, để thực sự hiểu họ”. Với điểm yếu cũng đừng ngần ngại chia sẻ với nhà tuyển dụng, quan trọng hơn hết là cho nhà tuyển dụng thấy bạn thực sự ý thức được những hạn chế của bản thân và có kế hoạch để cải thiện.

Ở bảng dưới là ví dụ một số điểm mạnh của một Product Manager, hãy tìm cách highlight những điểm mạnh của bạn trong quá trình phòng vấn.

Còn tiếp…

Product Manager

thanhhien Để lại bình luận

Trong bài viết trước, tôi có chia sẻ về công việc của Product Owner. Để tiếp nối, hôm nay tôi xin chia sẻ về công việc của Product Manager.

Product Owner và Product Manager là hai vai trò không dễ để tách bạch rõ ràng công việc. Cả hai đều có nhiệm vụ kết nối, định hướng team phát triển sản phẩm để tạo ra sản phẩm thành công. Và rất nhiều trường hợp ở các công ty hay team có scale bé, hai vai trò này có thể được đảm nhận bởi cùng một người.

Định nghĩa một chút để làm rõ hai vai trò này:

  • Product Owner là người quản lý Product Backlog, tạo ra các User Stories mô tả tính năng của sản phẩm cần phát triển. Là người đảm bảo tận dụng tối đa nguồn lực của team (bao gồm Developer, Designer, Tester) thông qua Estimation & Prioritization để tạo ra sản phẩm hiệu quả nhất giải quyết các nhu cầu của người dùng (end-users hoặc clients).
  • Product Manager là người nghiên cứu tiềm năng thị trường, đối thủ cạnh tranh, khám phá nhu cầu người dùng để từ đó vạch ra lộ trình phát triển và phát hành sản phẩm. Giúp team cùng đạt được mục tiêu chung.

Công việc của Product Manager

  • Nghiên cứu thị trường hoặc kết hợp với các bạn Market Researcher, UX Researcher để tìm hiểu và nghiên cứu thị trường. Bao gồm: Ước tính dung lượng thị trường (Market Size), nghiên cứu đối thủ cạnh tranh (Competitor Analysis), tìm hiểu người dùng (User demographics, User behavior, User needs, User pains).
  • Thông qua dữ liệu nghiên cứu thị trường, cùng với Board of Director/C-Suit đặt ra các Vision, Mission trung và dài hạn cho sản phẩm.
  • Đưa ra các giả thiết về nhu cầu người dùng, giả thiết về giải pháp. Từ đó định nghĩa được Minimum Viable Product (MVP) và Key metrics để kiểm chứng giả thiết.
  • Vạch ra lộ trình phát triển sản phẩm (Product Roadmap/GIST Planning) và mục tiêu theo tháng/quý/năm (OKRs).
  • Giúp team, stakeholders làm việc trên cùng mục tiêu chung và hiểu rõ lộ trình phát triển sản phẩm.
  • Xây dựng nguồn lực từ bên trong và tìm kiếm các nguồn lực từ bên ngoài hỗ trợ tối đa cho quá trình phát triển (Advisor, Business, Sale, Marketing,…)

Những điều cần có để đảm nhận vai trò Product Manager

  • Chịu được áp lực và có phương pháp quản lý áp lực như: áp lực về kết quả từ BoD/C-Suit/Invester; áp lực từ vấn đề về giao tiếp, quy trình, chất lượng công việc trong team; áp lực từ phản hồi của khách hàng; etc.
  • Có kĩ năng giải quyết vấn đề (Problem Solving) và có thể giải quyết vấn đề với tần suất liên tục
  • Có khả năng giao tiếp tốt: Truyền đạt thông tin rõ ràng, nhanh gọn; giao tiếp được với nhiều nhóm đối tượng khác nhau kể cả End Users, Developer, Stakeholders, etc.
  • Có kiến thức tốt và sâu về lĩnh vực đang tham gia (know-how).
  • Có tư duy định hướng chiến lược và tầm nhìn dài hạn cho sản phẩm.

Product Owner

thanhhien Để lại bình luận

Bài này tôi có vài đúc kết về công việc hàng ngày của Product Owner kinh nghiệm của tôi và các bạn bè trong ngành. Mục đích là nhằm cung cấp thêm góc nhìn cho các bạn quan tâm và cần tìm hiểu thêm về công việc này.

Cá nhân tôi tự thấy may mắn khi từng trải qua các công ty có tính chất và lĩnh vực khá đa dạng như Software Outsourcing (Gia công phần mềm), Nông nghiệp (Agritech), Quản lý nhân lực (HRM), Du lịch (TravelTech), Thương mại điện tử (E-Commerce), Giáo dục (EdTech), Game. Mặc dù chức danh có thể thay đổi nhưng vai trò và nhiệm vụ của một Product Owner (PO) vẫn chiếm khá nhiều thời gian trong những gì tôi làm.

Tôi sẽ chia các công việc theo tần suất: Hàng ngày (Daily), Hàng tuần (Weekly)/Mỗi hai tuần (Bi-Weekly), Hàng quý (Quarterly) để mọi người dễ hình dung.

Daily

Các đầu việc diễn ra hàng ngày của PO không khác nhiều so với các thành viên khác của Development team (nhóm phát triển).

  • Cập nhật tiến độ công việc hàng ngày với đồng đội: thường diễn ra vào buổi Daily Stand-up (buổi họp nhanh kéo dài tối đa 15 phút đầu ngày để mỗi người cập nhật: Hôm qua làm gì? Hôm nay làm gì? Vấn đề phát sinh cần được hỗ trợ)
  • Tham gia các cuộc họp đã lên lịch định kỳ hoặc không định kỳ với Development team, Stakeholders (Các bên liên quan có ảnh hưởng đến dự án), Users (Người dùng sản phẩm) hoặc Clients (Khách hàng).
  • Tham gia thảo luận các vấn đề liên quan đến công việc trên các ứng dụng chat nhóm như Slack/Discord/Skype.
  • Giải quyết các Ad-hoc Tasks (Các công việc đặc biệt, phát sinh không có kế hoạch nhưng quan trọng). Có thể là bổ sung trường hợp thiếu sót trong Product Requirement Document (Bản mô tả sản phẩm) để bạn Developer tiếp tục coding hay là cùng team điều tra nguyên nhân của một Bug (lỗi phần mềm ảnh hưởng đến việc sử dụng của người dùng) quan trọng.

Weekly/Bi-Weekly (theo Sprint)

Các team làm sản phẩm (không làm việc theo dự án kiểu Waterfall) thường áp dụng mô hình Scrum để chia công việc theo từng Sprint, mỗi Sprint sẽ kéo dài theo chu kỳ 1 hoặc 2 tuần và cứ thế lặp lại. Ưu điểm của mô hình này là có thể nhanh chóng phát hành sản phẩm đến tay người dùng (hoặc khách hàng) để nhanh chóng lấy đánh giá cho lần cải tiến tiếp theo.

Trong mỗi Sprint, PO sẽ thực hiện các công việc:

  • Lên mục tiêu và kế hoạch cho Sprint tiếp theo: Thường dưới dạng Sprint Objectives, Product Roadmap, Epic.
  • Chuẩn bị Product Backlog cho Sprint tiếp theo. Bao gồm: Đánh giá mức độ ưu tiên; tính khả thi của các Backlog Items (Vấn đề, Ý tưởng, Giải pháp, Yêu cầu).
  • Hoàn thiện các mô tả yêu cầu tính năng (Product Requirement Documents (PRDs) hoặc User Stories) đã lên kế hoạch. Ở bước này PO sẽ làm việc với User Experience Researcher (UXR) để lấy thêm insights từ người dùng (Pains, Gains, Needs,…), xác nhận các giả thiết (Hypothesis), hoặc tìm cách đánh giá các bản Prototype (bản thử nghiệm); làm việc với User Experience Designer (UXD) để thiết kế tính năng có trải nghiệm tốt nhất dưới dạng User Flow/Wireframe; nếu PO làm cả phần việc của UXD thì PO cũng sẽ làm việc với UI Designer để biến các bản Wireframe thành các thiết kế có bố cục, phân cấp, màu sắc,… có thể handoff cho Developer tiến hành coding giao diện. Và nhiều vị trí chuyên môn khác để đảm bảo tính năng được hoàn thiện yêu cầu trước khi chuyển sang Developer để tiến hành hiện thực hoá.
  • Ở bước trên, nếu chỉ gửi cho Developer file UI Design (ví dụ: Figma file, Sketch file) thôi thì chưa đủ. Có nhiều tính năng có User Flow và yêu cầu phức tạp, PO sẽ có buổi Backlog Grooming để giải thích về PRDs/User Stories cho Developers. Đảm bảo rằng các Developers hiểu rõ tại sao cần làm tính năng này, luồng đi của người dùng, các trường hợp xảy ra và cách xử lý mỗi trường hợp, các điều kiện,… giúp Developers đánh giá Feasibility, Constraint và Effort.
  • Theo dõi các chỉ số về sản phẩm: Thông qua các công cụ tracking (vd: Firebase Analysis, Appflyer, Amplitude,…) để đánh giá mức độ hiệu quả của các tính năng sau khi triển khai, phẩn hồi và xử lý các vấn đề quan trọng kịp thời.
  • Liên lục lấy phản hồi từ người dùng: Thông qua các buổi phỏng vấn, khảo sát hoặc phản hồi qua các kênh liên lạc (Contact Form, Email, Live chat, Bug Report, Social Media, Store Review,…) để có thêm thông tin cho việc đánh giá và cải tiến sản phẩm, giải quyết các vấn đề tiềm năng, nâng cao trải nghiệm người dùng.

Quarterly

  • Cùng với các cấp cao hơn (ví dụ: Product Manager, Business Owner, CEO) đánh giá lại các kết quả đạt được trong quý, về Objectives và Key Results đã đề ra, các Milestones đã hoàn thành. Đánh giá các điểm đã làm tốt, các điểm làm chưa tốt, những khó khăn để rút ra các bài học cho giai đoạn tiếp theo.
  • Làm việc với Product Manager/Business Owner, CEO, Stakeholders và Development team để đánh giá lại mục tiêu dài hạn, xác định mục tiêu ngắn hạn, nguồn lực, sản phẩm và nhiều thông tin khác để lên kế hoạch phát triển cho giai đoạn tiếp theo dưới dạng Objectives – Key Results – Action Plans hoặc Product Roadmaps.

Và rất nhiều công việc “không tên”

Trong nhóm phát triển sản phẩm, PO như một chất keo kết dính mọi người, tháo gỡ các khó khăn và đảm bảo rằng cả nhóm sẽ cùng đi đến được các mục tiêu đề ra (điều này không đồng nghĩa với việc PO là người quản lý nhóm phát triển). Chính vì vậy, sẽ có nhiều lúc PO đảm nhận nhiều công việc “không tên” hay kiệm nhiệm nhiều vai trò đồng thời.

Việc này có cái hại và cái lợi, đôi khi gây ra rất nhiều áp lực nhưng chính là cơ hội để PO xây dựng nền tảng theo T-Shape Skillset và phát triển lên các vị trí cao hơn như Product Manager.

Nhìn chung, công việc của PO ở các công ty khác nhau rất nhiều do phụ thuộc vào tính chất công ty, thị trường, tính chất sản phẩm, các đồng nghiệp và rất nhiều yếu tố khác. Khi ứng tuyển công việc có chức danh (Job title) là “Product Owner” hay các công việc có tính chất tương tự, điều cần làm là giành thời gian tìm hiểu thêm về công ty và quy trình làm việc ở đó; sản phẩm đang giải quyết vấn đề gì, cho ai và ở giai đoạn nào; các đồng đội tương lai họ là ai và có ưu nhược điểm gì; các đầu mục công việc cần làm; các bài toán cần giải quyết để có sự hình dung và chuẩn bị tốt nhất trước khi tham gia.

Silicon Valley

thanhhien Để lại bình luận

Khi nhắc đến Silicon Valley, có lẽ dân IT ở khắp nơi trên thế giới đều xem đây là thánh địa. Đây là điểm bắt đầu của các công ty công nghệ hàng đầu như Intel, Apple, Google, Facebook,… những cái tên đã nằm trong ngôi đền huyền thoại. Đây là nơi truyền cảm hứng cho không biết bao nhiêu con người, bao nhiêu thế hệ khởi nghiệp trong lĩnh vực phần mềm. Đây là nơi mà các con chiên công nghệ ai cũng ao ước ít nhất có một lần “hành hương” trở về.

Hôm nay, chúng ta cùng đi ngược dòng quá khứ để xem những điều gì đã giúp hình thành nên một Thung lũng Silicon truyền cảm hứng đến như vậy.

Thung lũng Silicon ra đời vào năm 1909 khi David Starr Jordan, Hiệu trưởng trường đại học Stanford, đầu tư tiền vào sáng chế ống chân không của Lee de Forest. Kể từ đó, Đại học Stanford tiếp tục khuyến khích các doanh nhân khởi nghiệp, sản sinh ra những của nhân như Bill Hewlett và David Packard, hai nhà đồng sáng lập của Hewlett-Parkard (HP) và Russell Varian, người đã phát triển công nghệ nền tảng cho radar kiêm sáng lập viên của Varian Associates. Sau Thế chiến thứ II, các cựu chiến binh từng phục vụ tại căn cứ quân sự địa phương đã quyết định gắn bó với khu vực này.

Khuôn viên đại học Standford. Ảnh từ Standford.edu

Nhiều người trong số họ đã đăng ký học tại Stanford khiến số lượng sinh viên tăng lên đáng kể, tạo áp lực lên tình hình tài chính của trường. Để gia tăng lợi nhuận biên tế (hay còn gọi là lãi gộp), nhà trường đã ra quyết định thành lập Khu công nghiệp Stanford, mảnh đất màu mỡ cho các công ty công nghệ non trẻ và ngày nay còn cung cấp không gian văn phòng cho các công ty khởi nghiệp và các công ty đang tăng trưởng thuộc Thung lũng này.

Nền tảng từ một nhóm các kỹ sư

Vào giữa những năm 1950, William Shockley, người phát minh ra bóng bán dẫn, đã chuyển đến khu vực này. Một số kỹ sư từng làm việc cho Shockey đã thành lập công ty Fairchild Semiconductor. Sau đó, hai trong số họ là Robert Noyce và Gordon Moore lập nên Intel. vào năm 1957, sau khi tàu vũ trụ Sputnik của Nga ra mắt, chính phủ Mỹ đã đổ rất nhiều tiền vào Fairchild để phát triển công nghệ mà sau này được sử dụng trong các chương trình vệ tinh và không gian của Mỹ.

Đội ngũ Fairchild Semiconductor thuở đầu. Ảnh từ American Scientist

ngành công nghiệp bán dẫn, Máy tính cá nhân và các công nghệ mới ra đời

Tiếng tăm ngày càng lan trộng của công cuộc đổi mới này đã thu hút các tài năng từ khắp nơi trên thế giới quy tụ về đây. Khi ngành công nghiệp bán dẫn đã tạo ra năng lượng điện toán với giá đủ thấp để cho phép những tay thợ hàn công nghệ thử nghiệm những công nghệ mới, thì ngành công nghiệp máy tính cá nhân ra đời.

Steve Jobs và Steve Wozniak bên máy tính Apple I năm 1976. Ảnh bởi Kimberly White / REUTERS

Apple và nhiều công ty máy tính khác được thành lập, kéo theo sự ra đời của nhiều công ty cung cấp các sản phẩm phần cứng phụ trợ và công nghệ hỗ trợ năng lực sản xuất. Với nguồn tài trợ của NASA thuộc Không quân Mỹ và ARPA, Viện Nghiên cứu Stanford đã phát minh ra chuột máy tính và công nghệ có tên là ARPANET – tiền thân của Internet. Xerox PARC đã tuyển dụng nhiều nhà nghiên cứu tiên phong về chuột máy tính và Internet. Sau này, họ còn phát triển cả lập trình định hướng đối tượng, giao diện đồ họa người dùng, mạng Ethernet, ngôn ngữ máy Postscript và máy in laze.

Những công ty này cùng các phát minh của họ đã góp phần lập nên 3Com và Adobe. Một vài công nghệ trong số này đã tạo điều kiện để những công ty như Cisco, Apple và Microsoft phát triển mạnh. Năm 1995, sau khi mạng Internet được mở rộng sang các hoạt động kinh doanh thương mại, rất nhiều công ty khởi nghiệp đã được thành lập, bao gồm cả eBay và Amazon. Dù Chính phủ Mỹ đã có công trong việc hình thành nên Thung lũng Silicon, nhưng trong kỷ nguyên Internet hiện nay, vai trò của họ đang ngày càng hạn chế.

nguồn vốn đầu tư mạo hiểm mới

Vốn đầu tư mạo hiểm là tác nhân thúc đẩy sự phát triển của Thung lũng Silicon ngay từ những ngày đầu hình thành. Cuối những năm 1970, thay đổi về quy định đầu tư hưu trí đã cho phép các nhà đầu tư mạo hiểm huy động nguồn vốn lớn hơn trước. Trước đây, phần lớn vốn đều được huy động từ những các nhân giàu có.

Đến cuối những năm 1990, các công ty Internet và công ty phần mềm phát triển như vũ bão – cho đến khi bong bóng dot-com vỡ tan và làm thay đổi cục diện vào hồi đầu năm 2000. Tiếp đến là làn sóng các công ty mới nổi chủ yếu trong lĩnh vực điện thoại di động, trò chơi điện tử, mạng xã hội và phần mềm dạng dịch vụ (Saas), bao gồm Zynga, Facebook, LinkedIn, Twitter và Salesforce.com. Gần đây là sự trỗi dậy của các công ty thành công trong nền kinh tế chia sẻ và lĩnh vực phân tích dữ liệu như AirBnB, Uber và Palanir Technologies.

Các công ty khởi nghiệp cung cấp thiết bị y tế và công nghệ sinh học cũng tăng trưởng mạnh mẽ tại Thung lũng Silicon. Genentech, công ty tiên phong trong ngành công nghiệp ADN tái tổ hợp do một nhà đầu tư mạo hiểm ở Thung lũng Silicon, đồng thời là nhà nghiên cứu của Đại học California tại San Francisco (UCSF) thành lập. Công nghệ của Genetech đã được phát triển ở Đại học Stanford và UCSF.

mở rộng và phát triển. trở thành cái nôi sáng tạo của thế giới

Ngày nay, Thung lũng Silicon đã mở rộng phạm vi địa lý, trải rộng khắp San Francisco, kéo tới hơn 64km về phía bắc và còn xa hơn nữa. Công nghệ ở đây cũng đa dạng hơn trước, từ phần cứng và phần mềm truyền thống đến công nghệ sạch, thiết bị y tết, công nghệ sinh học và các sản phẩm nông nghiệp. Nơi này vẫn không ngừng thúc đẩy tinh thần kinh doanh, sáng tạo khi liên tục tự đổi mới bản thân.

Ảnh screenshot Figma các văn phòng công ty tại Silicon Valley. Ảnh bởi Brianne Kimmel/Figma

nguồn gốc tên gọi “Thung lũng Silicon”

Vào năm 1972, Don Hoefler, một nhà báo chuyên mảng điện tử, đã nghĩ ra cụm từ này vì tất cả các công ty khởi nghiệp thời điểm đó đều tập trung vào thiết bị bán dẫn và sử dụng các bảng mạch silicon. Tên gọi đó vẫn được giữ nguyên cho tới tận ngày nay.