Reforge의 2020 Top Post를 읽고 (part 1)
2021 #4
The Top Product + Growth Strategy Posts of 2020
Growth를 주제로 career accelerating 프로그램을 제공하는 Reforge에서 2020년 가장 중요했던 14편의 아티클을 리스트업 했는데, 미뤄두고 있다가 이번에 몰아서 읽게 되었다.
1.Why Most Analytics Efforts Fail by Crystal Widjaja(Ex SVP Growth @ Gojek)
Gojek에서 4.5년 동안 Growth + Business Intelligence를 이끌었던 Crystal Widjaja(이하 CW)의 경험이 잘 농축되어있는 글. 거의 아무것도 없었던 시점에서 이야기가 시작하기 때문에 더 흥미진진하게 읽을 수 있었다. Tooling 관점에서는 아래와 같은 여정으로 정리할 수 있겠다.
Data Infra: Nothing ➡ Postgres data warehouse(w/ Pentaho ETL) ➡ GCP(BigQuery, BigTable, Data Flow) + Airflow, etc.,
Viz Tools: Tableau ➡ Metabase ➡ Internal tooling
Experimentation Platform: Manual CSV uploads to BigQuery tables ➡ Internal system
물론 이 글은 tooling보다 더 근본적인 data initiative의 문제를 다루고 있지만, 이렇게 다른 회사의 tooling 역사를 보면 비즈니스가 얼마나 빨리 scale up했을지, 어떤 비용 편익 문제들을 마주했을지 등 많은 것들을 상상해 볼 수 있어서 좋다. 여러 테크 회사들의 이런 tooling 역사를 비교해 보면 아주 흥미로울 듯.
어쨌든 이 글의 문제의식이 출발하는 지점은 “How you think about what to track, how to track it, and manage it over time”인데, 다음과 같은 순서로 글을 전개한다.
Data Symptoms
Root Causes of Data Issues
Step by Step Process: 이 문제들에 대한 글쓴이의 thought/action process(여기서 event tracker 템플릿을 공유해준다)
(1)Data Symptoms
Our data is a mess!
많은 회사 임직원들이 자사 데이터에 대해 위와 같이 묘사할 텐데, 그 대표적인 이유는 아래와 같다.
Lack of Shared Language: 약속된 언어(terminology & definition)의 부재. 개인적으로도 여러 회사에서 가장 흔하게 찾아볼 수 있었던 증상.
Slow Transfer of Knowledge: 빨리 성장하면서 turnover가 높거나 re-org를 자주 하는 회사에서 자주 나타나는 증상. 흔히 온보딩 세션/트레이닝 등으로 커버하려고 하는데 CW는 이게 비효율적이며 근본적인 해결책이기 어렵다고.
Lack of Trust: 데이터에 대한 불신이 누적되는 증상. 내가 다녔던 모 회사에서는 이 불신을 해소하고자 ‘certified’, ‘trusted’ 등으로 시작하는 이름의 테이블까지 등장하게 됨. 그러나 이 역시 신뢰받지 못함.
Inability to Act On Data Quickly: 의사결정을 timely하게 도와주지 못하는 상태.
(2)Root Causes of Data Issues
그 원인에는 다음과 같은 것들이 있는데,
Tracking metrics as the goal vs. Analyzing them: 분석이 아니라 트래킹 그 자체가 목적이 되는 경우.
Developer/Data mindset vs. Business User mindset: 데이터의 end customer(business user) 관점에서 생각하지 않는 경우.
Wrong level of abstraction: 개인적인 경험에서도 가장 어렵게 느껴졌던 부분. 데이터를 언어로 치환할 때 생겨나는 문제인데, 여기서는 ‘signing up’이라는 액션을 예로 들어 설명.
(Bad) ‘Facebook Sign Up’ or ‘Google Sign Up’: User action journey 관점에서는 too broad하고, aggregation을 생각하면 too specific함.
(Ok) ‘Sign Up Clicked’: Event 관점에서는 too specific하고, breakdown을 고려하면 too broad함.
(Great) ‘Sign Up Selected’: 적당한 수준의 abstraction. 일단 event가 무엇인지 명확하고, signup method를 breakdown하는 경우를 포괄할 수 있음.
Written only vs. Visual communication: 전에 다녔던 모 회사에서는 지표들을 설명하는 위키 페이지에 프로덕트 화면을 gif로 만들어서 덧붙였는데, 확실히 그 의미가 더 명확하게 전달되는 것을 느낌. 특히 event trigger가 page level 인지 hit level 인지 헷갈릴 때는 화면으로 보면 바로 이해할 수 있음.
Data as a project vs. Ongoing initiative: 꾸준히 iterate하는 영역으로 간주해야 하는데, 역시 고속성장 모드에서 쉽지 않은 일. 어디든 data analyst는 항상 부족하고, 있는 리소스마저 끝없는 ad hoc 분석에 투입되기 때문에 이런 메타적인 이니셔티브에 투자할 수 있는 여유가 없는 것 같기도 하다. Brian Balfour의 Data Wheel of Death 라는 글이 이 문제를 잘 정리해 놓음.
(3)Step by Step Process
The Tool - Event Tracking Dictionary: CW가 구글 시트로 Event Tracking Template을 공유해놨는데, 이런 게 없는 상태라면 그대로 적용해봐도 좋을 듯. 문제는 회사의 데이터가 점점 다변화, 고도화되는 과정에서 이런 딕셔너리를 rigorous하게 관리하기는 정말 어렵다는 것. 그런 점에서 이런 문제를 해결하는 SaaS가 있으면 바로 써볼 것 같다. 원하는 기능을 내 맘대로 나열하자면 event naming convention 추천 및 교정, 프로덕트 화면을 통한 event 설명, 이 event를 포함하고 있는 지표와 테이블 검색 등등..
Mindset of The Business User: CW가 business user 관점에서 생각하기 위해 거치는 4가지 질문들. 당연한 이야기로 들릴 수도 있겠지만, 본문에서 Honeydu(B2B payment 서비스) 사례를 들어 설명하고 있어서 직관적으로 이해할 수 있다.
What are the business goals and objectives? (OKR, quarterly/yearly plan, board report 등에서 찾아볼 수 있는)
What are the objectives and goals of each team? (Team OKR 등에서 찾아볼 수 있는, 1.에서 더 세부적으로 들어간 내용)
What are the product experiences around these goals and objectives?
What are the questions/hypotheses they(or I) might want to answer around these goals and product experiences?
Journey’s Instead of Metrics: 앞서 설명했던 ‘right level of abstraction’과 연결되는 내용. metric 자체보다 그 journey를 정확하게 알아야 한다는 이야기.
To answer the question of "why?" you first need to understand the journey of intent, success, and failure and then the context for each of those events in the journey
예시로 든 이벤트 journey:
Intent: Add New Payment Method Selected & Add New Payment Details Submitted
Success: Add New Payment Method Successful
Failure: Add New Payment Method Failed
여기서 인상 깊었던 부분은 Gojek에서 시간이 지남에 따라 동일한 event에 대한 intent가 달라지는 것을 감지한 이야기. 날이 갈수록 프로덕트에 더 익숙해지는 고객의 intent 변화를 어떻게 발견하고 반영할 것인가의 문제가 점점 더 중요해지는 듯.
The intent event of these users would be searching for a specific restaurant, finding the menu items they wanted, and finally, setting their delivery details. However, as these users matured, we noticed the most prevalent user intent journeys shift as users began using Gojek more as a means of new restaurant discovery rather than fulfillment of restaurants they already knew. Now, intent events would be things like scrolling through their friends' food feeds, browsing discounted deals, or using the Nearby feature.
Failure는 두 가지 레벨로 나눠서 설명.
Implicit Failure: drop-offs that occur before the successful completion of the goal(분명한 실패라기보다는, journey 중간에 유저가 사라지는 경우)
Explicit Failure: events where the intended experience goes wrong
Properties: event에 속하는 세부 property에 대한 이야기. 가장 쉬운 예시는 다음과 같다.
Good:
(event) Sign Up Selected
(property) Source
(property value) Facebook
Bad: Facebook Sign Up Selected
그리고 CW가 comprehensiveness를 위해 체크한다는 property bucket과 그 예시:
User Profile Properties: City, Age, Company Size, Role, Product Tier
Marketing Properties: Source, Campaign, Entry Page
User Action Properties: First Purchase Date, First Service Type, Total Orders
Type of Action Properties:
Ride Cancelled: User Initiated vs. System Initiated
Payment Selected: Credit Card vs. Wire Transfer
Photo Uploaded: Camera vs. Gallery
Login Successful: Google vs. Facebook vs Email vs Phone
Contextual Properties:
The number of drivers on the screen
The types of merchants displayed
The # of search results
Pressure Test: Event와 Property 세팅 후에 필요한 테스트에 관한 이야기.
Testing for Understanding: 이해도를 위한 테스트로, 아래는 CW가 권장하는 중요한 테스트 오디언스.
Business Users Close To Product Development
Business Users Farther Away From Product Development
New Employees
Testing for Actionability: 팀별로 가설 검증하는데 이 Event와 Property들이 어떻게 쓰일 수 있는지 확인하는 테스트.
Track “Decisions Made Without Data”: 가장 흥미로웠던 프랙티스로 Gojek에서는 분기별로 data없이 진행한 의사결정들을 다시 살펴보는 포럼이 있다고 한다. 이런 회고를 통해 어떤 이벤트를 어떤 이유로 더 트래킹해야 할지 결정할 수 있었다는 이야기.
(Final Thoughts) Ongoing Signals of Success
마지막으로 회사의 data system에 대한 Bad/Good/Great 시그널들을 정리하고 있는데, 실제로 경험했던 것들을 하나씩만 골라봤다.
Bad Signals: Data analysts are needed to do basic analysis around key goals and objectives Event names and property names are duplicated, in multiple casings (e.g. Sign up and Sign Up)?
Good Signals: It's easier for a business team to pull the data from the analytics platform than to write transactional queries to find the answers to their questions
Great Signals: Even when the product has a major redesign, the event tracking is able to leverage the original event names and properties logic
2.The Adjacent User Theory by Bangaly Kaba(Ex VP Growth @ Instacart, Instagram)
지난 뉴스레터에서 언급되었던 Heavy Buyer Fallacy와 유사한 맥락의 글. 2016년 MAU 500m 유저에 도달한 인스타그램의 성장 속도가 떨어지기 시작하는 시점에서 이야기가 시작된다. Bangaly Kaba(이하 BK)가 이후 3년 동안 성장 속도가 왜 떨어졌고, 그래서 어떻게 문제를 진단하고 해결했는지를 설명하는데, 그 중심에 있는 것이 바로 The Adjacent User Theory(번역하자면 ‘인접유저 이론’).
(1)The Importance of The Adjacent User
PMF 도달 후에 나오는 retention이 전부가 아니고, 인접유저-intent는 있지만 모종의 이유로 아직 successful user가 되지 못한- 상태를 발견하고 개선하여 PMF의 full potential을 실현할 수 있다는 이야기.
(2)Going Deeper On The Adjacent User
아래는 인스타그램과 슬랙에서 발견한 인접유저. “이들을 어떻게 찾아서 도울 것인가”가 이 글이 제시하는 과제.
“At Instagram, if a user had more than 10 followers in the first 7 days after signing up there was over a 65% chance that the user would become activated. There was always a group of users on that margin that would struggle to build their audience. But the reasons they struggled varied across different sets of user and changed over time.”
“At Slack, we found that if a user was active 3 days out of the last 7 (3d7), they were right on the edge and had a roughly 50/50 chance of churning or retaining the next week.”
그럼 먼저 조직에서 인접유저에 집중하지 못하는 이유에는 무엇이 있을까?
The Gravity Of The Power User: 일하는 사람들이 다 power user이기 때문에 인접유저 관점에서 생각하지 못함. 아래는 Uber에서의 임직원(power user) 편향에 대한 언급.
(Andrew Chen) At Uber, a lot of employees were power users of the Uber product. This led to a lot of voices thinking they knew what we needed to grow just because they used the product a lot. But these were rarely the things that pushed growth of Uber into new audiences.
Persona Tend To Be The Wrong Tool: 페르소나는 next user가 아닌 current user에 대한 관점으로, 유저의 변화를 반영하지 못하고 그 정보가 actionable하지 않음. 그리고 무엇보다도 product usage에 기반하지 않음(demographic factors, emotional needs 위주)
Trying To Hit A Home Run Every Time: 많은 조직이 그렇듯, bigger swing을 과대평가하는 경향.
Solving for the adjacent user is often seen as “optimization”, which in some organizations is viewed poorly because they represent short-term thinking. Solving for your adjacent user is not short term thinking; it is disciplined sequential execution that will enable your longer-term roadmap and faster growth.
(3)How To Know The Adjacent User Is Here
그럼 인접유저의 존재를 어떻게 알 수 있을까?
(Fareed Mosavat) A common thing I see across freemium SaaS companies I advise, is free to paid conversion decline from cohort to cohort. This is your signal that there are a set of adjacent users on the edge of this state that you need to start solving for.
시간이 지남에 따라 cohort to cohort로 특정 conversion rate(위 사례에서는 free to paid conversion)가 감소하는 것을 볼 수 있는데, 이걸 인접유저가 계속 누적되고 있는 것으로 해석. 내가 다녔던 모 회사에서도 아래와 같은 그래프를 목격할 수 있었음.
(4)Discovering and Defining Your Adjacent Users
어떤 방법으로 인접유저를 찾을 것인가의 문제.
Knowing Who Is Successful Today and Why: 현재의 successful user가 가진 attribute들을 통해 인접유저를 파악하는 방법(보통 1~2개의 attribute만 다른 경우가 많다고). Instacart의 경우 75%가 넘는 core user를 다음과 같은 attribute로 표현할 수 있었다고 함.
Women
Urban
Located In Certain Cities
Head of Household
Had one or more kids
Were more affluent and less price sensitive
Willing to spend an hour filling up their Instacart Order
Who Is The Adjacent User? : 이를 바탕으로 인접유저 세그먼트에 대한 가설을 세워나갈 수 있는데, 다음과 같이 Instacart와 Instagram 사례가 나옴.
(Instacart) Our hypothesis was that current users were very high intent users who were willing to spend an hour filling up their cart versus driving to the store. It led us to start focusing on the discoverability of products within first use to capture users with less intent.
At Instagram, when we first looked at the data, we started to see an enormous amount of organic web traffic showing up, but they weren’t converting to sign-ups and healthy users. We didn’t have any idea why. But through a lot of data exploration, we started to figure out where those users were coming from, why they were coming via web traffic, and other reasons that helped us define the adjacent user.
Why Are They Adjacent User? : 인접유저가 누구인지를 아는 것만으로는 부족하고, empathy-building을 통해 그들이 어떤 지점에서 왜 막혀있는지를 아는 게 더 중요하다는 이야기. 아래는 이를 위한 방법론.
Be The Adjacent User: 직접 인접유저가 되어보는 방법. 기기, 네트워크 속도, 언어 등의 조건별로 프로덕트 경험을 점검해 볼 수 있는 페이스북의 Air Traffic Control이 예시로 나온다(international growth를 위해 만들어짐).
For example, at Instagram as our adjacent users increasingly became more international, we needed to find a way to experience the product across many permutations of devices, network speeds, languages, and much more. Facebook built something called Air Traffic Control, which simulated elements of these permutations like network speed so the team could experience the product through the eyes of the adjacent user.
Watch/Talk The Adjacent User: 직접 인접유저를 리크루트해서 usability test + interview 하는 방법. 방법론 그 자체보다는 아래와 같이 제시된 Instagram로그아웃 사례가 더 흥미로워서 통째로 발췌.
We started to see a large increase in access churn (users logging out, then failing to log back in successfully). Two directions emerged. We could either make it harder for people to log out, or easier to log back in. But to determine which path was best, we needed to understand why people were logging out in increasing volumes.
We decided to talk to a lot of users who were intentionally logging out. What we found were two things:
People had a real use case for logging out. They logged out either because they had a prepaid phone plan and were worried about background data usage, or they were sharing the phone with a family member.
These users also commonly used fake email addresses. Email addresses are more of a western paradigm, and new people to the internet internationally don’t use email, they just text.
Once we understood these two things, it was clear the right strategic direction was to work on making it easier to log back in vs. harder to log out and we were able to come up with some creative solutions for the use cases.
Visit The Adjacent User: 인접유저가 프로덕트를 사용하는 실제 환경에서 관찰하고 이해하는 방법. 유저 스스로가 형성한 자신만의 습관이나 workaround를 목격할 수 있는 유일한 방법.
(5)Sequencing Your Adjacent Users
발견한 인접유저 세그먼트를 어떻게 prioritize할 것인가에 대한 이야기.
Adjacent User Should Only Be Different On One or Two Attributes: 앞에서도 언급했듯, 1~2개의 attribute 차이를 보이는 세그먼트에 먼저 주목해야 함. 그 이상으로 가려면 아예 새로운 value prop이 필요.
(Elena Verna) A segment that is different on multiple attributes typically requires enabling a new value prop to bring them into the product. That’s a very big swing. But it’s not an “if” you should be going after them, it’s a question of “when.” If you can first add smaller features for adjacent users that only differ on one attribute you can maintain momentum and growth velocity while working up to a new value prop for those multi-attribute users.
Not All Adjacent Users Are Opportunities: 발견하고 정의한 인접유저가 strategic direction의 부합하느냐에 대한 문제. 이어지는 Instagram 로그아웃 사례가 또 이 측면을 아주 구체적으로 보여준다.
As we solved access churn (people churning because they had trouble logging back in) we noticed feed posts were going up. At first, we didn’t know why, but we eventually discovered people had 2nd and 3rd accounts that they were logging back into. One account was public-facing, and one was more private for friends. So the question came up, should we be more intentional about making it easier to create and navigate across multiple accounts? Is that meaningful? Does it align with the strategic direction of the product? We didn’t have a clear answer and therefore punted on that adjacent user until we had further validation that the 2nd account was an additive opportunity within our strategic direction.
Solve In-House Problems First: 이미 funnel에 들어와 있고 intent도 있는데 goal completion을 하지 못하고 있는 유저의 문제부터 해결해야 한다는 이야기. Slack에서 international growth 시도할 때 가장 monetization이 안되는 국가는 프랑스와 인도였는데, 이 두 시장을 어떻게 prioritize했는지도 이 파트에 나옴.
(6)The Evolving Adjacent User Landscape
앞서 Cohort decay 그래프에서 볼 수 있듯이, 인접유저도 계속 evolve하는데 이 문제에는 어떻게 접근할 것인가에 대한 글.
When I started at Instagram, the Adjacent User was women 35 – 45 in the US who had a Facebook account but didn’t see the value of Instagram. By the time I left Instagram, the Adjacent User was women in Jakarta, on an older 3G Android phone with a prepaid mobile plan. There were probably 8 different types of Adjacent Users that we solved for in-between those two points.
그래서 주기적으로 인접유저에 대한 이해를 reevalute해야하는데, 여기서 중요한 포인트는 아래와 같다고 한다(당연한 얘기처럼 들릴 수도 있겠지만).
Taking Time To Understand The Why
Constantly Working on the Fundamentals of Registration, Activation, Engagement and Monetization: 여기서는 또 Instacart의 acquisition 랜딩 페이지 사례가 인상적. 서비스가 성장함에 따라 funnel entry point의 근본적인 의미가 달라지는 모습.
(Fareed Mosavat) In the early days of Instacart, the best performing landing page was an all white page, that said “Instacart, Groceries delivered to your door, put your zip code in”. Nothing else performed better. The user at that time was very high intent, tech savvy, urban millennial who knew what Instacart was because they heard about it from a friend through the press.
As Instacart grew over time, you had to explain what Instacart was, why does it matter, who it is for, what stores we have. The same experiment on the white page a year later had dramatically different results because the adjacent user had changed.
Continually Cross The Cognitive Threshold of Your Adjacent User: 인접유저의 눈높이에 맞추어 프로덕트를 바라보는 것이 얼마나 어렵고 중요한지를 강조.
3.The Four Types of Product Work by Fareed Mosavat(Ex Dir Product Growth @ Slack) and Casey Winters(CPO @ Eventbrite, Ex Growth Lead @ Pinterest)
나는 product 업무를 하고 있지 않기 때문에, 어떻게 하면 product 분들과 더 잘 협업할 수 있을까 하는 관점에서 읽은 글. 같은 글쓴이들이 쓴 From Product Manager to Product Leader라는 글을 먼저 읽으면 더 좋을 것 같다.
이 글이 조명하는 영역은 사실상 PMF 달성 이후의 product work로, 아래와 같이 4개 영역으로 분류한다.
이렇게 서로 다른 영역을 구분하지 않는 경우 wrong process, wrong success metric, wrong strategy의 악순환에 빠지게 되는데, 아래와 같은 인용들이 특히 와닿았다.
Misaligned incentive에 대하여:
(Ravi Mehta) Companies tend to reinforce the problem of focusing on feature work at the expense of other important product work. It's exciting to talk about new features, and they shine the limelight on the PMs doing that work. Instead, companies need to recognize the value of the different types of PM work, help PMs map their skills to those roles, and reward PMs for all the work that is critical, not just the outwardly sexy work.
Wrong strategic focus에 대하여:
(Casey Winters) My first year at Pinterest we built a Maps product and a Q&A product, neither of which had any material impact to the business and were later deleted. In year two, we changed the "Pin It" button to say "Save" and got a 15% increase in activation rate just from that.
또한 이렇게 서로 다른 product work 영역에 대해 구분하는 것은 아래와 같은 이유로도 중요(From Product Manager to Product Leader 글에서도 다루는 이야기).
Have a wider vision of product problems
Maximize ROI across different types of product work
Go from an “I” shape to a “T” shape as a professional
그리고 각 product work 영역에 대한 더 구체적인 이야기가 전개된다.
(1)Feature Work
대부분의 사람이 생각하는 product work의 영역. 여기서 간과하기 쉬운 문제에는 cost에 대한 것들.
Maintenance Costs: “There is no such thing as zero maintenance”
User Costs: 새로운 기능이 가져오는 cognitive complexity에 따른 비용.
Killing Costs: 기능을 sunset 시키는 데 드는 비용. “/me” 기능을 없애려고 했던 Slack의 사례가 나온다. 한 번 만든 기능은 쉽게 없애기 어려움.
(Farred Mosavat) At one point we tried killing the "/me" feature in Slack. It ended up creating a ton of backlash among users and we ended up undoing the decision. One thing I learned is that there are no dark corners of your product that are easy to kill.
Feature Work에 대해 글쓴이가 특히 강조하는 부분은 프로덕트의 feature sequence를 cohesive하게 잘 설계하라는 것인데, Apple Pay를 그 사례로 제시한다(한국 유저 입장에서는 크게 와닿지는 않는 예시이긴 할 듯). 유저의 관점에서는 한 번에 큰 behavioral change를 받아들이기 어렵기 때문에, 프로덕트의 기능들이 순차적으로 무리 없이 받아들여지는 과정이 필요하다는 것.
When Apple launched Touch ID, it seemed weird to a lot of people. But they sequenced the features of Wallet, Touch ID, and NFC-enabled phones, which added up to Apple Pay (which is the real story). Done well, your features should sequence into a more cohesive story that ladders up to a bigger picture where 1+1 = 3.
(2)Growth Work
어떻게 유저가 이 기능을 알게 되어 습관적으로 쓰게 되는지에 대한 영역인 Growth Work. 새로운 가치를 더하는 과정인 Feature Work와는 다르게, 프로덕트가 이미 내재하고 있는 가치를 어떻게 고객과 연결할 것인가에 대한 문제이기도 하다.
여기서 흔히 발생하는 문제는 프로덕트는 우리가 만들었으니, 유저와 고객은 마케팅이나 세일즈에서 만들어와야 한다는 silo mentality. Growth는 Acquisition, Retention, Monetization이라는 주요 input으로 작동하는 시스템인데 프로덕트가 그 중심 역할을 해야 한다고(그게 B2C social app이든 SaaS든 간에).
그다음으로 흔한 착각은 growth 문제를 new feature 개발로 해결하려 하는 것이라고. 이때는 growth loop이 무엇인지 규명하고 점검해보는 것을 권장(Growth Loops are the New Funnels라는 글을 같이 읽어보면 좋음).
So, everything drives growth? No. "Everything drives growth" is a statement typically used by team members or organizations as a way to deflect from the realization that they don't know the difference between efforts that directly impact growth and those that indirectly impact it.
When doing product work on growth problems, you need to understand how the system of acquisition, retention, and monetization works by answering the fundamental question: how does your product grow? The answer to that question is your growth model.
(3)Scaling Work
개인적으로 이 글에서 가장 흥미롭게 읽었던 부분. Bottleneck 문제를 해결하는 영역으로 가장 unsexy하지만 정말 중요한 product work. 회사에서 관련한 프로젝트들을 찾아봐야겠다는 생각이 들었다.
아래는 Scaling Work에 대한 recognition을 장려하는 Facebook의 문화를 엿볼 수 있는 사례.
(Ravi Mehta) One small way Facebook rewards scaling work is by featuring a ‘Fix of the Week.’ Every week, Mark invites someone to discuss an important fix at the all-hands meeting which gives the company an opportunity to celebrate the critical, necessary work that often goes under-appreciated.
그리고 Scaling Work를 게을리하지 않았던 Zoom의 사례. 판데믹으로 인한 수요 폭증을 감당할 수 있었던 비결.
Zoom is a good example here. They pride themselves on their ability to scale. In 2018, their CFO was quoted on how they always keep an extra 50% capacity available at all times for scaling work. It's one of the reasons they were able to scale during COVID and capture demand that could have easily gone to Google or others.
Scaling Work에는 3가지 세부 카테고리가 있다고 한다.
Technical Scaling: 기술적으로 더 많은 유저와 사용량을 감당할 수 있게 하는 영역(infra work, eng management, design debt 등이 여기에 포함).
Process Scaling: 조직이 성장하면서 생겨나는 organizational complexity의 문제를 해결하는 영역.
User Scaling: 더 광범위한 유저 그룹으로 확장할 때 발생하는 새로운 문제를 해결하는 영역(fraud detection, spam filtering, security 등이 이에 포함)
Scaling Work에서 가장 까다로운 부분은 (not too late, not too early) timing이라고 하는데, 다음 그래프가 이 컨셉을 잘 설명하고 있다. 항상 부족한 리소스로 feature work와 growth work를 하면서 어느 타이밍에 scaling work를 해결할 것인가의 문제.
(Ravi Mehta) I like to think about process scaling work as a team trading upfront engineering time for long-term operational time. Content moderation systems are one good example — manual moderation is fine (and preferable) in the beginning as the team is learning about the problem at hand, but automated and scalable moderation becomes critical once it becomes cost prohibitive to manually moderate.
(4)PMF(Product-Market Fit) Expansion
모든 프로덕트의 성장세는 언젠가는 둔화하는데, 이를 해결하기 위한 product work의 영역.
To continue to fuel growth of the organization, product-market fit needs to be expanded in a non-incremental way. Product-market fit expansion is not about iteration – it's about creating more value by significantly expanding into adjacent products or markets by taking larger bets.
PMF는 지속해서 유지하고 확장해야 할 개념임을 설명하는 차트.
여기서 흥미로웠던 지적은 initial PMF가 좋을수록 빨리 성장하고, 그만큼 고객의 기대치 수준도 빠르게 올라간다는 것(product management의 난이도도 같은 속도로 올라감). 아래의 Slack 사례가 이를 잘 설명하고 있다.
(Fareed Mosavat) Slack had extremely strong product-market fit from the early days and ended up growing so fast. It was extremely difficult to keep up with the rising expectations of our customers over time, and took us a while to launch things like WYSIWYG editing, better ways to launch apps vs. just text commands, and simplified channel discovery that were important for our newer, less-technical users.
앞서 인용되었듯이 PMF Expansion은 new feature work가 아니라 인접 시장이나 인접 프로덕트로 확장하는 것을 의미하는데, 다음과 같이 예를 들어 설명.
Same Product, Expanding to an Adjacent Market
Slack > Slack Enterprise
Instacart expanding to delivery from pharmacies
Same Market, Expanding to Adjacent Product
Credit Karma expanding to Credit Karma Tax
Lyft expanding to Bikes & Scooters
Diversification(launching a completely new product to a completely new market)
Uber launching Uber Freight or Uber Eats
Amazon launching AWS
PMF Expansion에서 저지르기 쉬운 실수 중 하나는, 바로 이미 존재하는 전략과 유저, 그리고 브랜드의 범위를 벗어난 expansion을 시도하는 것. 자신의 key strategic advantage를 무조건 활용해야 한다는 이야기.
This is not about building the best product possible like PMF, it is about building the best product holding some set of variables the same that make you uniquely positioned. You have to know what those things are.
그리고 Over Resourcing 또한 흔히 나타나는 실수.
Many companies end up over resourcing PMF expansion efforts or shoving new products to their existing distribution, just because they can. Both end up killing PMF expansion efforts in different ways. You may progress through the lifecycle faster, but you can't skip steps.
아무리 리소스를 많이 투여해도, 결국 아래와 같은 PMF 찾는 과정을 건너뛸 수 없기 때문. 오히려 over resourcing 때문에 이 과정이 무거워질 가능성이 높다.
Target market hypothesis
Product hypothesis
Validate #1 and #2
Learn and iterate on #1 and #2
Over Resourcing에 이은 또 다른 실수는 기존 프로덕트의 distribution을 이용한 Over Distributing. 앞서 나온 PMF 찾는 과정은 굉장히 좁은 audience를 바탕으로 작동하는 cycle이기 때문에 한꺼번에 많은 유저에게 ‘밀어낼’ 경우 오히려 noise만 증가하는 상황이 발생. 그 때문에 learn & iterate 하기가 어려워짐.
그 외
The Entertainment Value Curve by Ravi Mehta(Ex CPO @ Tinder, Facebook): (이미 잊혀진 것 같지만) Quibi가 왜 망했는지에 대한 설득력 있는 분석.
The Word of Mouth Coefficient by Yousuf Bhaijee(Ex VP Growth @ Eaze): 개인적으로는 seasonality를 더 세부적으로 이해하는 데 도움이 될 것 같은 지표에 대한 글. Clubhouse 데이터로 이 지표를 계산하면 어떤 그래프가 나올까?
Becoming A Peak Product Manager by Ravi Mehta(Ex CPO @ Tinder, Facebook): The Four Types of Product Work와 함께 읽으면 더 좋을 아티클.
part 2에서 계속