Framework 5 bước tự build sản phẩm cho Product Manager, Owner

Rất khó để bạn có thể học Product Management chỉ bằng cách đọc sách, học khóa học. Product Management là vị trí “vừa làm vừa học”. Đó là lý do vì sao các công ty luôn đòi hỏi người đã từng có kinh nghiệm làm PM. Vậy làm sao để có skills làm sản phẩm

Rất khó để bạn có thể học Product Management chỉ bằng cách đọc sách, học khóa học.

Product Management là vị trí “vừa làm vừa học”. Đó là lý do vì sao các công ty luôn đòi hỏi người đã từng có kinh nghiệm làm PM.

Vậy làm sao để có skills làm sản phẩm thật sự? Làm sao để có kinh nghiệm khi bạn mới chỉ bắt đầu?

Câu trả lời là bạn cần có Một sản phẩm thật sự.

Một sản phẩm thật, có users sử dụng thật sẽ là vũ khí tốt nhất của bạn. Giá trị hơn tất cả những chứng chỉ, văn bằng cộng lại.

Một sản phẩm sẽ giúp bạn chứng minh được bản thân hiểu vấn đề của users, hiểu cách build software… Chứng minh bạn thật sự có kỹ năng.

Dưới đây là framework Sơn dùng để build những mini-product.

Step 1: Bắt đầu với một vấn đề

Mình từng nghĩ bản thân có những ý tưởng sản phẩm tuyệt vời. Và ý tưởng của mình sẽ định hình cách users sử dụng sản phẩm.

Bullshit. Đừng ngây thơ như mình. Hãy bắt đầu với một vấn đề cụ thể. Càng cụ thể càng tốt.

Vấn đề ở đâu ra?

Hãy bắt đầu với vấn đề của chính bạn. Bạn có vấn đề gì cần một sản phẩm nào đó giải quyết hay không?

Ví dụ như bạn hay xao nhãng khi làm việc quá. Có một cái tool để apply timeboxing khi làm việc thì tốt.

Bắt đầu với vấn đề của bản thân có điểm hay là nó rất dễ kiểm chứng, bạn chính là user rồi. Nhưng nó có giới hạn, là bạn sẽ chỉ có 1, 2 users thôi. Product chỉ có 1, 2 users thì không ấn tượng lắm.

Cách tốt hơn là hãy bắt đầu với một cộng đồng. Chắc chắn bạn có tham gia một vài cộng đồng nào đó. Có thể là cộng đồng học ngoại ngữ, cộng đồng học lập trình… Gì cũng được, nhưng hãy chọn một cộng đồng mà bạn quen thuộc nhất.

Chọn một cộng đồng quen thuộc đem lại 2 điều.

Thứ nhất, bạn là một phần của cộng đồng đó nên khả năng cao vấn đề của bạn cũng sẽ là của cộng đồng.

Thứ hai, bạn sẽ có users từ cộng đồng mà không tốn phí quảng cáo.

Step 2: Tương tác, hiểu vấn đề

Bạn hãy tìm ra một vấn đề cụ thể mà ai đó trong cộng đồng đang gặp phải.

Không khó đâu. Chỉ cần tương tác, quan sát để ý hàng ngày là bạn sẽ nhận ra.

Ví dụ, trước Sơn có tham gia những cộng đồng học tiếng Anh.

Sơn để ý thấy mọi người thường đăng những post tìm người luyện speaking. Những bài post đó nhận được rất nhiều tương tác. Mọi người đua nhau để lại thông tin của bản thân.

Rất dễ để nhận ra vấn đề là mọi người chưa có một kênh hiệu quả để tìm người luyện nói.

Sau khi đã xác định được vấn đề, bạn hãy bắt đầu tương tác qua lại với những “users tương lai”. Mục đích là để hiểu rõ hơn nhu cầu của họ là gì. Quan trọng hơn, họ sẽ là những users cho sản phẩm của bạn.

Nếu được, hãy cố gắng tạo một “mini-community” trong cộng đồng, tức là gom một số người có chung vấn đề lại với nhau. Gom vào group chat hay đâu đó tùy bạn.

Step 3: Design solution – feedback

Hy vọng lúc này bạn đã có một đồng đồng nhỏ gồm vài chục đến vài trăm người có cùng một vấn đề.

Không cần những skills research, phỏng vấn users lằng nhằng cao xa làm gì. Chỉ cần ngày nào bạn cũng có mặt, tương tác với họ là bạn đã thừa sức hiểu vấn đề họ đang gặp phải rồi.

Đã đến lúc build thứ gì đó.

Bạn hãy thông báo với tất cả mọi người là bạn chuẩn bị build một tool/product để giúp mọi người. Và bạn sẽ cần mọi người đánh giá, nhận xét.

Bắt đầu nhẹ nhàng thôi.

Bạn có thể dùng các tool cơ bản như XD, Balsamiq… để làm wireframe. Hoặc làm trên giấy cũng được. Hãy lên những concept cơ bản nhất. Rồi đến những wireframe chi tiết hơn với các flow chính.

Sau khi có flow cơ bản rồi, hãy chọn ra vài người trong cộng đồng nhỏ để nhờ nhận xét đánh giá. Nhớ là phải chọn ra vài người thôi, đừng hỏi tất cả mọi người vì nó sẽ rối tung lên.

Mục đích của việc hỏi users, nhờ nhận xét không phải là đề họ chỉ cho bạn nên làm gì. Mà là để bạn quan sát, tự đánh giá xem giải pháp mình đang design có hợp lý chưa. Có gì cần cải thiện hay không.

Bạn lặp đi lặp lại vài lần cho đến khi có được một bản wireframe/mockup ưng ý. Bạn ưng ý và những người được hỏi cũng ưng ý.

Wireframe/prototype cần chi tiết tới mức nào?

Tùy thuộc vào mục đích của bạn. Ví dụ, bạn đang cần sáng tạo, tìm ra các ideas thì tốt nhất là nguệch ngoạc trên giấy. Nếu bạn muốn dùng nó để trình bày ideas cho designer… thì nên chỉnh chu hơn một chút, nhưng vẫn có thể dùng giấy. Còn nếu bạn dùng để test, nhận feedback từ users/sếp thì nên hoàn chỉnh hơn, bạn có thể vẽ trên những tool như XD, Figma, Balsamiq… để demo flow dễ dàng trên màn hình.

Sau khi đã ưng ý với bản wireframe/mockup. Làm sao để ra được bản design UI chi tiết? Có 2 cách.

Một là bạn lên các trang như Fiverr, Freelancer… để tìm Designer làm cho bạn. Giá rẻ thôi.

Hai là tự design dùng các tool kéo thả như Canva.com.

Mỗi cách có ưu nhược riêng. Cách 1 thể hiện được bạn có khả năng lãnh đạo, biết phân bổ nguồn lực. Cách 2 thể hiện bạn có khả năng tự làm những việc cần thiết. Tùy bạn chọn.

Step 4: Build

Bây giờ bạn đã có Design. Chúng ta cần biến bản design thành sản phẩm thật sự.

Thật ra đến bước này là quá ngon rồi. Bạn đã có cộng đồng những người dùng tiềm năng. Đã tìm ra được vấn đề họ gặp phải. Đã có wireframe. Đã test với users. Đã có bản design chi tiết. Bạn hoàn toàn có thể document lại hết những step đã làm lên Notion. Khi đi phỏng vấn, hãy đem chuyện này ra kể.

Tuy nhiên, builder là phải build. Nếu bạn muốn tiến xa hơn để có những users thật sự thì bạn có 2 hướng.

Cách thứ nhất là bạn sẽ bắt đầu viết Specs cho các function, UI. Sau đó lại lên Fiveer, Freelancer thuê người làm. Cũng không đắt.

Cách hai, mình thích cách này hơn, là sử dụng các tool No-Code để tự build.

No-Code là một trend mới, đại ý là bạn có thể tự build sản phẩm mà không cần code.

Website, Apps, Database, Thanh toán, Automation… tất cả đều có thể dùng No/Low-Code.

Tổng hợp các tool No-Code

Kể cả bạn biết code thì mình cũng khuyến khích sử dụng các tool No-Code. Bởi mục đích là build sản phẩm nhanh nhất có thể, hãy tránh bay vào vũng lầy.

Step 5: thành quả

Launch. Bạn đã launch sản phẩm đầu tiên.

Chắc chắn bạn sẽ có những users đầu tiên là những anh chị em trong cộng đồng.

Hãy nhờ họ cho feedback. Chụp lại những lời khen. Chụp lại số người sử dụng. Chụp lại thời khắc bạn Launch.

Document lại hết những steps mà bạn đã trải qua. Bạn sẽ cần nó khi đi phỏng vấn.

Bây giờ bạn chính thức có kinh nghiệm làm Product Management. Không nhiều người làm Product Management thật sự build được một sản phẩm có users thật sử dụng (ngoại trừ sản phẩm của công ty họ làm).

Kết
Mình biết là có rất nhiều bước cần trải qua. Có thể bạn sẽ cảm thấy mông lung, khó khăn.

Nhưng tin mình. Khó khăn nhất là bước bắt đầu. Khi bạn đã bắt đầu. Khi bạn đã có những người users tiềm năng chờ đợi bạn giúp họ giải quyết vấn đề. Bạn sẽ tìm thấy đường đi.

Product Management là build sản phẩm. Builder thì phải build. Hãy bắt đầu build ngay hôm nay.

Nếu có khó khăn gì hãy liên hệ Sơn nhé.

Chúc bạn thành công!

Đọc thêm nhiều bài viết tại: https://simpleproductmind.com

Nguồn: viblo.asia

Bài viết liên quan

Thay đổi Package Name của Android Studio dể dàng với plugin APR

Nếu bạn đang gặp khó khăn hoặc bế tắc trong việc thay đổi package name trong And

Lỗi không Update Meta_Value Khi thay thế hình ảnh cũ bằng hình ảnh mới trong WordPress

Mã dưới đây hoạt động tốt có 1 lỗi không update được postmeta ” meta_key=

Bài 1 – React Native DevOps các khái niệm và các cài đặt căn bản

Hướng dẫn setup jenkins agent để bắt đầu build mobile bằng jenkins cho devloper an t

Chuyển đổi từ monolith sang microservices qua ví dụ

1. Why microservices? Microservices là kiến trúc hệ thống phần mềm hướng dịch vụ,