Cách xác định Metrics từ Product Goal
- 1 trong những challenges của Product Managers là chọn được Metrics
- Nếu chọn đúng, nó sẽ mang lại rất nhiều giá trị cho users và doanh nghiệp. Nếu chọn sai, doanh nghiệp sẽ dễ build ra những ứng dụng/ tính năng vô nghĩa
1. Metrics quan trọng như thế nào
1.1. La bàn chỉ hướng
Các metrics giúp chúng ta làm đúng những việc cần lại, có ý nghĩa bằng cách cho chúng ta cái nhìn, thông số về cách sản phẩm được thực hiện, nó đang như thế nào, và cần làm gì ở những lần release tiếp
1.2. Giúp ra quyết định
Mỗi quyết định sẽ ít nhiều bị ảnh hưởng bởi cảm xúc, định kiến của một người hay một nhóm người. Do đó, với metrics trong tay, các quyết định của chúng ta sẽ mang yếu tố khách quan hơn, giải quyết đúng bản chất vấn đề hơn.
1.3. Giám sát liên tục
Các metrics giúp chúng ta biết được điều gì đang diễn ra trên production. Có bất kì điều gì bất thường xảy ra không hay có bất kì tín hiệu khả quan nào xuất hiện không
1.4. Hiểu được sản phẩm
Metrics giúp chúng ta hiểu được cốt lõi của sản phẩm. Những lý do tại sao sản phẩm của chúng ta tồn tại được, nó làm được gì cho users và nó mang lại giá trị gì cho doanh nghiệp
2. Framework
Đây là framework được sử dụng để xác định những metrics dựa trên các yếu tố
Lấy người dùng làm trọng tâm - User-Centric
Có thể đo lường được - Measurable
Có thể thực hiện được - Actionable
2.1. Hiểu được Product Goal
Cơ bản giai đoạn này, ta cần trả lời cho câu hỏi: Giải quyết vấn đề gì cho Users và mang lại giá trị gì cho Doanh nghiệp. Tại giai đoạn này, khoan nghĩ sâu sa đến việc KPIs hay hướng đi nào, công nghệ gì. Chỉ đơn giản là điền vào chỗ trống câu sau
Tạo ra <Cái gì> để cho <Ai> có thể <Làm gì>. Điều này sẽ giúp <Được gì>
- Tạo ra e-Commerce để cho mọi người có thể shopping online. Giúp cho việc shopping tiện lợi hơn
- Tạo ra Social Network để cho mọi người có thể tương tác với bạn bè và gia đình. Giúp cho việc tương tác dễ hơn
- Tạo ra một nền tảng để cho mọi người đặt vé trong kỳ nghỉ dễ dàng hơn. Giúp cho việc du lịch đơn giản hơn
- Tạo ra một nền tảng log và share workout để cho người tập fitness share với bạn bè. Giúp họ có động lực hơn.
2.2. Xác định một North Star duy nhất
Chọn 1 metrics north star duy nhất để đo lường - make sure rằng mình đi đúng hướng. North Star này phải thoả mãn được hai yếu tố
Sát với Product Goal và Có thể đo lường
Hãy cùng Duy phân tích bốn ví dụ trên
2.2.1. E-Commerce
Tạo ra e-Commerce để cho mọi người có thể shopping online. Giúp cho việc shopping tiện lợi hơn.
=> Product Goal là: Shopping tiện hơn. Vậy, north star cần xác định ở đây là gì. Duy sẽ list ra tất cả các metrics Duy có thể nghĩ trong đầu và sẽ phân tích từng cái một
1. User active/ User sign-up/ User retention ❌Không ổn, vì số lượng users đăng ký, active hay retention không phản ánh đúng Product Goal của mình. Vì cái mình muốn là shopping tiện hơn, người dùng play app mình nhưng chưa chắc đã shopping.
2. Revenue ❌ Ban đầu, thì cái này khá hợp lý nhưng khi nghĩ kĩ thì không ổn.Giả sử, số lượng users là 100. Nhưng chỉ có 1 giao dịch nhưng giao dịch này là một 1 triệu thì là do mặt hàng đó đắt tiền, chứ thị trường hoàn toàn yên ắng
3. Number of sellers/ Number of buyers ❌Tương tự như vậy, số lượng người mua người bán có chênh lệch hay không cũng sẽ phục vụ cho mục đích khác, metrics khác, chứ không phục vụ cho Product Goal của mình
4. Number of transactions ✅Đây là metrics thể hiện rõ được các yếu tố mà mình mong đợi, phản ánh phần lớn các yếu tố phía trên (mặc dù vẫn cần sự hỗ trợ của 3 metrics trên). Nhưng đây là yếu tố sẽ thể hiện rõ được hướng đi từ Product Goal của mình.
2.2.2. Social Network - AirBnB - Fitness App
Cùng phân tích như vậy, ta sẽ có các Product Goal các ví dụ 2,3,4 sẽ là:
- Social Network: Số lượng Interaction trong một ngày <-> Product Goal: Interact Easier
- AirBnb: Số lượng lượng phòng được book <-> Product Goal: Booking Easier
- Fitness App: Số lượng workout được chia sẻ <-> Product Goal: More Motivation
Kết luận phần north star
Vậy đấy, North Star thường được dùng để, đo lường, xác định sản phẩm của chúng ta có đi đúng hướng hay không. Tuy nhiên, vẫn chưa đủ thành phần để ta xác định rõ. Với north star, ta có thể xác định, đo lường một product goal, nhưng vấn đề là ta chỉ có thể đo lường tăng giảm như thế nào mà không hiểu lý do đằng sau - tại sao tăng, tại sao giảm.
Giả dụ, hướng mong đợi của bạn là hướng thẳng, nhưng bạn bị nghiêng (đi sai) thì nghiêng (sai) như thế nào thì bạn không rõ. Nghiêng 90 độ rất khác với nghiêng 30 độ. Visibility của north star không đủ rõ ràng. Do đó, nó cần được hỗ trợ bởi những yếu tố khác.
2.3. Map với User flow
Định nghĩa user flow có nghĩa là tìm được một flow phù hợp để
Người dùng hoàn thành mục tiêu của họ bằng cách sử dụng sản phẩm của mình
Làm thế nào để chúng ta đạt được north star của mình.
Tại giai đoạn này, user flow chỉ cần được định nghĩa một cách chung chung nhất là đủ, không cần thiết phải quá chi tiết. Chỉ cần định nghĩa các bước chung nhất mà người dùng cần thực hiện để có thể hoàn thành mục tiêu của họ, vì vậy, yêu cầu duy nhất tại thời điểm này là nó nắm bắt tất cả các bước thiết yếu và chỉ những bước thiết yếu là đủ.
Các bước thiết yếu đó phải dựa trên các tiêu chí về mặt cảm xúc như những phần hạnh phúc cũng như không hạnh phúc vì vậy nó xem xét các việc phù hợp với sản phẩm hoặc người dùng theo mục tiêu của họ, nó cũng xem xét những gì có thể xảy ra sai.
Mình nhấn mạnh, nó nên đào sâu vừa đủ để có những thông tin chi tiết có ý nghĩa nhưng nó không quá chi tiết đến mức làm mất tập trung ý tưởng cốt lõi là có thể chỉ xem người dùng làm gì
Ví dụ, khi phân tích User Flow tại thời điểm này, chúng tôi có thể sẽ không thực hiện phân tích từng trang nhỏ nếu bạn đang xây dựng một ứng dụng hoặc một trang web. Phần này mình sẽ làm nhưng là làm sau.
Ngoài ra, nó không hạn chế framework gì cả, nó không phải nhất thiết phải theo thứ tự chuẩn nào cả. Ví dụ bạn có thể bắt đầu bằng phần đăng nhập, đăng kí, hoặc đi vào từ phần Home dưới dạng guest hoặc thậm chí bắt đầu bằng phần thích hoặc bình luận cũng được, miễn là nó phải hình thành 1 flow của user thoả mãn hai điều kiện ở trên là được. Dưới đây là một vài ví dụ về e-Commerce và Sport
2.4. Translate to Support Metrics
Đây là phần quan trọng nhất trong quá trình chuyển đổi, phần này sẽ bao gồm hai giai đoạn chính
Customer Journey Map to Product Action
Product Action To Support Metrics
2.4.1. Customer Journey Map to Product Action
Giai đoạn này, ta sẽ xem thử từng bước của users trong Customer Journey Map, sau đó ta sẽ chuyển thành 1 product action tương ứng. Những product action này phải có sự ảnh hưởng nào đó đến journey step tương ứng.
Lưu ý chỗ này, 1 journey step sẽ có nhiều product action khác nhau chứ không hẳn là 1-1. Và những product action này có thể là song song hoặc có thể là liên tiếp nhau đều được.
Riêng ở phần cuối, mình muốn giải thích thêm một chút vì phần này khá là hay. Khi user makes thêm another purchase, chúng ta sẽ tăng thêm engagement bằng nhiều cách như referral, discounts hoặc gợi ý thêm những items tương tự hoặc add thêm complimentary, đánh giá v...v. Nói chung, làm gì thì làm, miễn tăng được engagement là được.
2.4.2 Product Action To Support Metrics
Sau khi đã định hình xong bước này, ta sẽ tiếp tục chuyển sang một bước nữa, đó là chuyển từ product action thành các metrics dùng để đo lường các product action đó.
Để mình cùng với các bạn phân tích 4 yếu tố cuối - vì 3 yếu tố đầu tiên khá đơn giản và dễ hiểu.
- Đối với yếu tố payments -> product action là làm sao cho việc payment dễ dàng hơn -> bằng chứng là số lượng drop payments phải minimum. Tức là đo lường số user đến step payment nhưng không đi tiếp là bao nhiêu.
- Đối với yếu tố delivery faster thì metric là có bao nhiêu đơn hàng đúng giờ (chỗ này có những bài học khá thực tế từ Now và Grab - đó là đôi khi việc chậm hàng không phải do người giao hàng mà còn nhiều yếu tố khách quan khác ảnh hưởng đến như là kẹt xe, tình hình địa phương bất ổn, dịch bệnh, đơn hàng nhiều, v..v)
- Đối với yếu tố đảm bảo chất lượng, thì số lượng đơn hàng trả về càng ít, chứng tỏ chất lượng đơn hàng đạt mức ổn định - tốt.
- Đối với yếu tố increase engagement, thì ta có nhiều thông số để đo lường, ví dụ như
+ Có bao nhiêu user có nhiều hơn một đơn hàng một ngày
+ Số lượng đơn hàng của 1 user trong 1 tuần
+ Những thông số đo lường tương tự
-> Mục đích chính vẫn là để capture transaction frequency
2.4.3. Kết luận
Sẽ có rất nhiều metrics kiểu này, chúng sẽ mang sắc thái và màu sắc cụ thể cho sản phẩm mà bạn đang xây dựng. Vì vậy, ở giai đoạn này, nếu ta phân tích đúng hướng thì hầu hết những metrics này đều mang tính biểu thị rất cao nhưng chúng cũng sẽ rất dễ dàng tinh chỉnh.
===
3. Track the funnel
13:32
nhưng điều đó là chưa đủ theo nghĩa
uh
hầu hết các nhóm sản phẩm, đặc biệt nếu bạn
làm việc trong một tổ chức lớn có
các khoảng kiểm soát nhỏ hơn nhiều vì vậy bạn
có thể không ảnh hưởng đến
phễu end-to-end của thương mại điện tử uh
Công ty
hoặc bạn có thể không ảnh hưởng được
kênh xã hội end-to-end
uh vậy để kiểm soát uh
loại hỗn loạn này và cũng để cung cấp cho bạn
khả năng hiển thị nhiều hơn về sản phẩm của bạn
đang làm
các chỉ số cuối cùng là một nơi tốt để chỉ
ừm có ở phía sau của bạn
túi và
xem xét các chỉ số kênh chỉ để thực hiện
chắc chắn rằng sản phẩm của bạn hoạt động như
dự kiến trong
thang đo và phễu nhỏ hơn, chi tiết hơn
các chỉ số được lấy thông qua một chi tiết
phân tích hành trình của người dùng cho một
một phần cụ thể của sản phẩm
4. Eliminate zero influnce
we eliminate the
supporting metrics that we feel we have
no influence over
um this is essentially an exercise in
trust um so if you're doing your part
right and someone else is doing their
part right
then you essentially sum up as
everything is working well
um for our specific example for the
loyalty program
um as a product manager i would have no
influence on
what specific product category if any is
selected by the user
i would have little influence on how
much of that translates to card ads or
how much of that
translates to drop offset payments so
these are supporting metrics that i
cannot influence
um and i essentially read them out of my
supporting metric list just so that
the metrics that i do have are clearer
and more visible to me and i can derive
more meaning from them
all of this essentially gave us a fairly
good picture of what primary metrics and
supporting metrics and funnel metrics we
want to track
but this is not always practical so
let's say i was working in customer
service in that
large e-commerce company i would not
necessarily directly influence
transactions per day or i would
influence transactions per day but over
a very long period of time
so if a user today has a customer
service issue and i
decide and i solve it effectively it
doesn't necessarily mean that the next
day the user is going to have another
transaction
it might take a week two weeks even
sometimes six months before the user has
another transaction
so for me working in customer service a
northstar metric that says transactions
per day
doesn't make as much sense because it's
not immediately actionable
so we try to adjust the metrics for
finer measurability and we do that by
proxies
so proxies are needed when the overall
impact of the non-stop metric is either
small
or it's delayed some examples of a proxy
um
on-time delivery can be a primary metric
for logistics rather than
the frequency of transactions or the
number of transactions because
it's not necessarily that a user will
make another order as soon as
their previous order is delivered on
time so if it's a delay of a week or two
weeks i would still go with transactions
but if it's
three months or six months i would
probably prefer to have
on-time delivery as my primary metric um
new user signups as the primary metric
for social onboarding flows because
there's a delay in
representation for how many users this
specific user actually interacts with
and how frequently because they're still
familiarizing themselves with the
product
and then like we discussed tickets
handled as the primary metric for
customer service
2.5. Tiến hành theo dõi số liệu
so a good proxy metric has a strong
correlation with the north star
it meaningfully accomplishes the product
goals that we set out to go
set out to get and ideally a good proxy
metric is also derived from a supporting
metric or
is just a supporting metric in the
product if it's not
that's usually a very special situation
that uh
most product managers would not land
themselves in
so i wouldn't really bother much about
kind of going through a flow of
not having a supporting metric that can
be translated into a proxy
one good note always track the not star
as a supporting metric when using a
proxy metric
and even though there's a delayed result
or a small impact
on the primary metric it's always good
to add it into your tracking funnel just
so that you can see if something is
going terribly wrong
2.6. Điều chỉnh số liệu
so a good proxy metric has a strong
correlation with the north star
it meaningfully accomplishes the product
goals that we set out to go
set out to get and ideally a good proxy
metric is also derived from a supporting
metric or
is just a supporting metric in the
product if it's not
that's usually a very special situation
that uh
most product managers would not land
themselves in
so i wouldn't really bother much about
kind of going through a flow of
not having a supporting metric that can
be translated into a proxy
one good note always track the not star
as a supporting metric when using a
proxy metric
and even though there's a delayed result
or a small impact
on the primary metric it's always good
to add it into your tracking funnel just
so that you can see if something is
going terribly wrong
with the not strong metric or
something's just not right with the
non-stop metric
so our final final list um for the
e-commerce
uh kind of problem area uh if i'm doing
the loyalty program i would choose new
signups per day as my north star metric
or my primary metric
i could choose transactions per day if i
have a transaction frequency that's
viable
if i'm getting one transaction per two
or three weeks it's probably a good
metric but let's say in our case i'm not
uh so i pick new synopsis per day as the
north star that i want to optimize for
my loyalty program for
my supporting metrics remain at new
users per day on-time deliveries number
of returns
transaction frequency and because of
eliminated transactions per day as the
north star i still add it as a
supporting metric
and then my final metrics which again
talk about new exposures per day page
visits per day
check out initiations per day and new
signups per day
so essentially if my product is built
right
the first metric that i should see a
change in is new signups per day
if it changes for the positive that
means everything's going fine
uh usually but if it does change for the
negative i can fall back on my
supporting metrics and see where my
product breaks
um let's let's imagine a situation where
i have
a large number of new signups per day
and that's leading to
a large number of new transactions per
day but it's also leading to a reduction
in on-time deliveries
because there are so many orders that i
now have to handle that i can't fulfill
each of them on time
or if there's a large number of returns
because
essentially i'm causing a buyer's
remorse by getting people to sign up
into the loyalty program getting them
excited about the next purchase
i'm having them purchase something that
they don't fundamentally want and then
therefore they return it
so my supporting metric kind of
triangulates any problems that i might
have with the product that i can
iteratively solve
regardless of whether or not my primary
metric is going in the right direction
finally uh my final metrics helped me
debug problems with my non-star metric
so if i see a decline in the new signups
per day
is it because there's not enough
exposures is it because there's not
enough page visits
is it because there's too few checkout
initiations so users don't find the
loyalty program affordable or don't find
value in it
or is it because there's just not enough
new signups per day to the loyalty
program itself right
sorry that's a bit correlated but
essentially the funnel metric
um derives what problems you might have
in the path to the primary metric and
this set of metrics essentially captures
that quite well
so now you have the list of metrics you
need to validate if this is the right
set of metrics
a few ways to do it run simple a
experiments this validates if your
metric is actually computable if you can
actually see it without errors
if there are any bugs in the metric that
you need to sort um
run a few small a b experiments with
obvious outcomes
um so this kind of validates the power
that your metric might have how much it
moves uh in one direction or the other
is it sensitive enough for the purposes
that you want to use it in
one good tip is to use outages to your
advantage so whenever there's a product
outage in a specific
part it will impact multiple metrics
look at what metrics are impacted by
these outages and failures
for your customers as well as for your
business that's a good proxy for
establishing correlations between
metrics
for establishing just how well your
metric functions and forges to general
visibility into
what specific gaps exist within your
metrics and finally give it time
usually designing metrics for a product
that are functional and sustainable
over a long period of time needs a lot
of tweaking needs a lot of iterations
and
just needs a lot more experience with
the product itself so
give it time before you have a final
final list of metrics keep going through
the steps keep going through the motions
keep asking yourself
is this a good not star is it
representative what's supporting metrics
am i missing and you'll kind of arrive
at
a good set of metrics that you can keep
consistent within your product and you
can keep iterating on and
kind of keep making the product better
for your users
