제품 관리의 본질은 스토리텔링입니다
제품 관리는 결국 스토리를 전달하는 일입니다. 제가 어떻게 제품 관리를 생각하는지, 그리고 AI 가 이 분야를 어떻게 변화시켰는지를 하나의 이야기로 풀어보려 합니다.
평생 잊을 수 없는 면접 질문
저는 RealNetworks 에서 엔지니어로 커리어를 시작했고, 몇 년 후에는 RealPlayer 의 제품 및 엔지니어링 팀을 담당하게 되었습니다. 당시 RealPlayer 는 수억 명의 사용자를 보유한 매우 의미 있는 소비자용 제품이었으며, 초기 인터넷에 오디오와 비디오를 도입하는 데 큰 역할을 했습니다. 저는 비즈니스 쪽 동료들과 회의하며 “플레이어가 실행될 때마다 광고를 노출해야 한다” 같은 아이디어를 듣곤 했습니다. 이것이 옳은 방향이 아니라는 걸 알았지만, 그들이 제시한 수익 예측 엑셀 시트를 논리적으로 반박할 방법은 없었습니다. 저는 진정한 제품 관리자가 되고 싶었고, 결국 경영대학원에 가야겠다고 결론 내렸습니다.
버클리 경영대학원에 입학한 직후, 과거 대학 이메일 리스트에서 LinkedIn 이 채용 중이라는 소식을 보았습니다. 지원했고, Reid Hoffman 과 면접을 보게 되었습니다. 그는 자리에 앉아 평생 잊지 못할 질문을 던졌습니다.
“그래서, 제품 관리자가 되고 싶다고요? 제품 관리자가 만들어내는 산출물(artifact) 은 무엇인가요?”
그는 설명을 이어갔습니다. 엔지니어에게는 코드가 산출물이고, 사업 개발에는 계약서가 있습니다. 디자이너는 비주얼과 그래픽을 만들죠. CEO 에게는 조직도, 자금 조달 계획, 그리고 모두를 하나로 묶어주는 비전이 있습니다. 그렇다면 제품 관리자는 어떨까요?
저는 제품 관리자에게 그런 명확한 ‘산출물’ 이 있는지 확신하지 못했지만, 우리가 하는 근본적인 일은 모든 상황을 취합하여 명세서(spec) 로 작성하는 것이라고 답했습니다. 명세서는 청사진(blueprint) 입니다. 여기서 요구사항과 앞으로 할 일을 정의하며, 이는 모든 팀이 이를 바탕으로 구축을 시작할 수 있게 해주는 회사 내에서 가장 중요한 문서 중 하나가 됩니다.
분명히 긴장한 상태였습니다. 그가 알아챈 것 같아 괜찮은 답변이라고 안심시켜 주었죠. 결국 합격했고, 경영대학원을 중퇴하고 LinkedIn 에 합류했으며, 그 이후로 줄곧 그 질문에 대해 고민해 왔습니다.
명세서(Spec) 에서 스토리로의 진화
왜냐하면 제가 틀린 답변 을 했기 때문입니다.
당시는 소프트웨어 개발의 워터폴(Waterfall) 시대였습니다. LinkedIn 에서 우리는 소셜 플랫폼 내에 새로운 형태의 잡(Job) 플랫폼을 재구상하고 있었습니다. 채용 담당자가 상호 연결된 인맥 맥락에서 입사 지원서를 볼 수 있고, 후보자는 네트워크를 통해 직접 채용 담당자와 연결될 수 있도록 하는 것이 목표였죠. 이 탐색 과정에서 저는 전체 경험과 요구사항을 정의한 120 페이지 분량의 명세서를 작성했습니다.
수년이 지난 지금도 그때를 많이 회상합니다. 왜냐하면 그 명세서가 분명히 가장 중요한 산출물이 아니었기 때문입니다. 진짜 중요한 것은 스토리 였습니다.
명세서는 시스템이 무엇을 해야 하는지, 완료 전에 어떤 체크박스를 채워야 하는지 기술합니다. 하지만 그것이 제품 관리의 예술이 아닙니다. 제품 관리는 제품을 사용할 사람들의 이야기를 전하고, 그것이 그들의 삶에서 왜 중요한지를 설명하는 것입니다. 대화 상대라면 누구나 즉시 이해할 수 있어야 하며, 반복 가능(repeatable) 해야 합니다. 즉, 당신이 방에 없어도 사람들이 그 내용을 충실히 전달할 수 있어야 하죠.
이는 완전히 다른 문서이며, 완전히 다른 업무입니다.
10 년 전 제품 관리에 관한 강연을 했는데, 사람들은 지금까지도 그 영상을 저에게 보내줍니다. 칭찬일 수도 있지만, 업계가 제자리걸음이라는 신호일 수도 있겠네요. 둘 다 고려해 보겠습니다. 어쨌든 그 강연의 핵심은 한 문장으로 요약됩니다: “제품 관리자는 팀(및 회사) 이 사용자들에게 올바른 제품을 출시하도록 돕는다.” 저는 대부분의 시간을 이 문장을 단어별로 분석하는 데 할애했습니다.
- 팀을 돕는다. 당신은 리더가 아닙니다. 많은 사람이 제품 관리자를 리더라고 생각하지만, 당신은 일이 일어나도록 돕는 사람입니다. 따라서 다음을 수행해야 합니다…
- 당신의 팀 과 회사 를 이해한다. 팀은 당신의 영역(domain) 입니다. 이를 반드시 이해해야 합니다! 또한 더 큰 그림 속에서 팀이 어디에 위치하는지도 파악해야, 개인적 목표뿐 아니라 회사의 목표를 달성하는 데 기여할 수 있습니다.
- 출시(Ship) 한다. 아무리 많은 대화를 나눈다 해도, 궁극적으로 중요한 것은 제품을 고객 앞에 내놓는 것입니다.
- 사용자를 위한 올바른 제품. 드디어 본론에 도달했습니다. ‘올바른(right)’ 이 실제로 무엇을 의미하는지 날카롭게 다듬어 가는 과정입니다.
AI 시대에는 이 중 얼마나 많은 부분이 변할까요?
변화하는 것들
분명히 무언가 는 변했습니다. 정확히 말하면 여러 가지가 바뀌었죠. 한편으로는 코딩 방식과 아이디어를 실제 작동하는 것으로 전환하는 속도가 변했습니다. 다른 한편으로는 사용자가 제품에 기대하는 바 자체가 변했습니다. 특히 소비자 분야에서 우리는 아직 이 가능성을 거의 탐험하지 않았다고 생각합니다. 에이전트가 백그라운드에서 작동하면서, 사용자가 복잡한 인터페이스를 익힐 필요 없이 필요한 것을 설명하기만 하면 제품이 그것을 제공해 주는 세상이 오고 있습니다.
무언가를 만드는 비용이 급격히 하락했다는 점은 의심의 여지가 없습니다. 범위를 정하고 시도하는 것이 더 이상 그렇게 어렵지 않으며, 이는 엄청난 유연성을 제공합니다. 하지만 판단(judgment) 의 비용은 전혀 변하지 않았습니다. 무엇을 만들지 결정하는 일은 그 어느 때보다 중요해졌습니다.
제품 개발은 루프(loop) 입니다. 과거에는 누군가가 아이디어를 떠올리면 (좋은 회사에서는 당신만이 아니라 어디서나 나올 수 있죠), 그것을 시도했습니다. 명세서나 제품 브리핑 등 각자 부르는 이름으로 문서를 작성했죠. 사전 비용이 발생했습니다: 범위 설정, 디자인, 논의—소중한 엔지니어링 시간을 투입하기 전에 반드시 거쳐야 할 과정들이었습니다. 이는 잘못된 결정으로부터 엔지니어링 시간을 보호하기 위해 우리가 고안한 의식(ritual) 들이었습니다. 왜냐하면 연간 고작 6~8 번 정도만 이 루프를 돌릴 수 있었으니까요.
그러다가 무언가를 만드는 비용이 터무니없이 저렴해졌습니다. 조금 싸진 것이 아니라, 차원이 다르게 낮아진 것입니다. 그리고 흥미로운 일이 벌어졌습니다. 그 오래된 루프는 여전히 존재하지만, 순서가 재배열되었습니다.
과거의 루프는 다음과 같았습니다: 아이디어 → 명세서 → 원가 계산 → 범위 설정 → 기타 모든 것 → 그 다음에 구축. 이제:
- 먼저, 아이디어를 가지고 AI 로 빠르게 구축하여 작동 방식과 느낌을 확인합니다.
- 직접 플레이하며 그것이 전체 그림 안에서 어떻게 느껴지고 맞는지 파악합니다. 프로토타입은 항상 “만약에(if)” 를 이깁니다.
- 그 다음에 디자인합니다. 직접 만져본 후, 그것이 무엇인지 알게 되었으므로 이제 프로토타입을 넘어설 수 있는 조건이 무엇인지 구체적으로 논의할 수 있습니다. 여기서 디자인이란 시각/UX 디자인과 엔지니어링 설계 양쪽을 모두 포함합니다.
- 마지막으로 출시하고 학습합니다.
이는 완전히 역전되었습니다: 명세서 작성 및 범위 설정 중심에서, 구축 및 플레이 중심으로요. 저는 이것이 현재 일어나는 다른 어떤 변화보다 제품 관리에 더 큰 영향을 미친다고 생각합니다.
결국 명세서는 더 이상 최종 산출물이 아닙니다; 진짜로. 긴 문서를 처음부터 작성하고 종이 위에서 모든 것을 완벽하게 맞추려고 시작할 필요가 없습니다. 예전에는 지향점(aspirational sense) 으로만 참이었지만, 이제는 문자 그대로(literal sense) 명백한 사실이 되었습니다.
하지만 조심해야 합니다. 반대편에서도 동일한 실수를 저지를 수 있기 때문입니다.
데모는 이제 거의 무료입니다. 하지만 작동하는 제품은 그렇지 않습니다. 저는 이 새로운 접근법의 이면을 계속 목격합니다: “좋네, 그냥 출시하자.” 하지만 여전히 그렇게 작동하지 않습니다. 우리는 모두 프로토타입에서 실제 제품으로 가는 거리는 여전히 시간이 걸린다 는 점을 존중해야 합니다.
제품 관리자에 대한 통념 중 하나는, 그들의 일이 주로 “일정에 맞나요?” 라고 묻는 것이라는 점입니다. 그 생각을 완전히 버리세요. 가장 중요한 질문은 이것입니다: 제품에 맞는가?
우리 모두 훌륭한 아이디어가 있고, 이제 우리 대신 코드를 짜줄 에이전트도 있습니다. 무엇을 만들지 결정하는 일은 공식적으로 리소스 배분 논쟁이 아닙니다. 그것은 임팩트(impact) 논쟁입니다. “이것 아니면 저것”, “이것 아니면 아무것도 아님” 이 아니라요. 세계를 위해 무엇을 하려는지에 대한 비전이 있고 그것을 정말로 알고 있다면, 취향(taste) 과 큐레이션(curation) 은 매우 중요합니다. 하지만 구축하는 시스템은 여전히 완성되어 있어야 합니다.
AI 에 대한 저의 가장 큰 우려는, 그것이 우리를 더 빠르게 만들어 모든 것을 억지로 끼워 넣게 한다는 점입니다. 콘텐츠에서 “AI 슬롭(slop)” 을 이야기하듯, 이것은 제품에서의 AI 슬롭을 의미합니다. 이미 몇몇 곳에서 이런 현상을 봤고, 우리 모두 이에 대해 약간 걱정하고 있다고 생각합니다. 누구나 무엇이든 만들 수 있게 된 지금, 무엇을 만들지 결정하는 것이 곧 전체 업무입니다. 그리고 이것은 스토리의 문제입니다. 어떤 이야기를 하고 싶은가요? 고객이 이해하기를 원하는 이야기는 무엇인가요? 고객의 머릿속에 살아 숨 쉬기를 원하는 이야기는 무엇인가요?
PM 으로서 당신의 일은 제품이 무엇을 할 것인지에 대한 명세서를 작성하는 것이 아닙니다. 공유된 이해(understanding) —우리가 무엇을 하고 있으며 왜 하는지에 대한 공통된 그림—를 만드는 것입니다. 사용자가 왜 여기 있는가? 각 단계에서 그들은 무엇을 느끼며, 그것이 왜 중요한가? 어디가 인상적이고 어디가 지루한가? 제품이 가끔 지루해도 괜찮습니다, 어디가 지루한지 알고 있다면요. 하지만 좋은 대본(script) 을 쓸 수 없다면, 제품은 단조로울 것입니다.
AI 가 주는 선물은 이제 이러한 것들을 무료로, 바로 앞에서 확인할 수 있다는 점입니다. 빠르게 구축하고, 느낌을 파악하고, 플레이하며, 그 한 문장을 찾아낼 수 있습니다: 이 제품은 누군가의 삶에서 무엇을 해주는가? 만약 여기에 답할 수 있다면, 제 질문에 답할 수 있습니다: “사람들이 실제로 사용하고 있는가?” 이제 당신은 그것이 무엇을 하는지 말했고, 그들이 그것을 하는지 묻고 있는 것이니까요.
변하지 않는 것들
제품에 대한 ‘비전(vision)’ 을 가진다는 것은 무슨 의미일까요?
제가 비전이라고 말할 때, 사명 선언문(mission statement) 을 뜻하는 것이 아닙니다. 그것들도 중요하지만 비전은 아닙니다. 비전은 사용자를 위한 제품이 존재하는 이유(end-to-end reason for the product to exist for users) 입니다. 저는 이를 위한 간단한 프레임워크를 가지고 있습니다:
- 목적(Purpose). 누군가가 당신의 제품을 집어 들고 자신의 삶에 들여놓는 이유는 무엇인가?
- 핵심 행동(Core actions). 그들이 제품을 열었을 때 실제로 무엇을 하는가? 여러 가지가 있을 수 있으며, 모두 이해해야 합니다.
- 주기(Cycle). 각 핵심 행동의 예상 빈도는 어떠한가?
커리어 내내 창업자들과 다른 제품 전문가들을 만나면서 저는 항상 이렇게 묻습니다: 사람들이 당신의 제품을 사용하고 있나요? 그리고 그들은 거의 항상 사용자 데이터로 바로 달려갑니다. “DAU/MAU 비율이 50% 입니다. 가입자 1 만 명을 돌파했습니다. 대기자 명단에 100 만 명이 있습니다. ARR 은 100 만 달러입니다. 하루에 40 억 토큰을 처리합니다. 앱스토어 3 위를 기록했습니다.”
이 중 제 질문에 대한 답이 되는 것이 있나요?
때로는 질문을 다시 하는데, 한 단어를 추가합니다: 사람들이 정말로(really) 당신의 제품을 사용하고 있나요? 그러면 때때로 그들은 제가 무엇을 묻고 있는지 깨닫습니다.
LinkedIn 의 목적은 찾는(find) 것과 찾히는(be found) 것이었습니다. 아마 일부 사람들에게는 핵심 행동이 단순히 연락이 올 때 응답하는 것일 수 있습니다. 대부분의 사람에게 이것은 일상적인 일이 아니며, 일년에 한두 번 정도일 수 있습니다.
그 주기를 보세요—일년에 한두 번 요. 이 점을 이해하는 것은 LinkedIn 이 작동하는 데 결정적이었습니다. 왜냐하면 네트워크는 찾히기를 기꺼이 willing 한 매우 많은 수의 사람들과, 적어도 일부는 찾는(finding) 행동을 하는 사람들이 필요했기 때문입니다.
LinkedIn 은 결국 소셜 네트워크였으므로, 매일 행동을 하도록 사용자를 유도하고 싶을 수 있습니다. 우리는 그렇게 하지 않았습니다. 대신 초기에는 사람들이 프로필을 정확하게 유지하도록 하는 데 막대한 시간을 투자했습니다. 일년에 한두 번만 발견되는 것도 전혀 문제가 되지 않았습니다. 다만 그것이 일어날 때, 클릭해서 “누군가 나에게 연락하고 있구나, 좋네” 라고 이해할 수만 있다면요.
제품이 작동하는지 측정할 때, 이러한 핵심 행동이 중요합니다. 직접 트래픽(direct traffic) 에 집중하세요: 말 그대로 당신에게 온 사람들을 찾으세요. 앱을 설치하고 아이콘을 누르거나, 도메인을 직접 입력한 사람들입니다. 그들은 스스로의 의지로 당신에게 왔습니다. 이것이 중요한 트래픽이며, 순간적으로 누군가를 다시 끌어오는 다른 모든 방법들과는 구별됩니다.
그리고 나서 핵심 행동을 수행한 사람들만 실제로 카운트하세요. “앱을 잠깐 열었다” 가 아니라, 실제로 참여(engaged) 한 사람을요. Discord 라면 “라이브 세션에 들어갔다. 실제로 메시지를 읽고 보냈다” 가 되겠죠.
핵심 행동이 무엇인지 정의할 수 없다면, 당신에게는 제품이 없습니다. 왜냐하면 당신이 이해하는 것이 없기 때문이죠.
새로운 점이자 제가 좋아하는 점은, 사용자가 제품과 대화하거나 프롬프트를 입력하는 AI 제품에서는 이제 사용자 여정의 문자 그대로의 전사(transcript) 를 얻을 수 있다는 것입니다. 사람들이 자신의 언어로 무엇을 말하는지 볼 수 있습니다. 누군가가 포기하고 표현을 바꾸는 정확한 순간을 볼 수 있습니다. 제품이 해주기를 기대했지만 하지 않은 것을 볼 수 있습니다. 이것들을 읽으세요! AI 는 이전에 보지 못했던 것을 드러내는 데 훌륭하지만, 모든 것을 요약하게 하거나 당신의 의견을 대신 형성하게 해서는 안 됩니다. 당신의 의견을 형성하는 것—실제로 이야기가 무엇인지 파악하는 것—이 제품 관리의 업무이자 예술입니다.
온보딩(Onboarding)
온보딩은 고객에게 당신의 이야기를 전달할 수 있는 가장 중요한 단일 순간입니다. 그들은 당신의 제품을 발견했습니다—아마도 광고, 바이럴 초대, 기사 등을 통해서요. 그들은 당신의 존재를 알고 있으며, 호기심을 갖고 시도하려 합니다. 당신은 그로부터 다시는 이만큼의 관심을 받지 못할 것입니다.
이 시점에서 기억해야 할 것은, 모든 사람이 같은 동기로 당신의 제품에 나타나는 것은 아니라는 점입니다. 열정적인(Eagers) 그룹이 있습니다. 그들은 간절히 들어오고 싶어 합니다. 준비가 되어 있죠. 분명히 해두자면, 회사에서 일한다면 당신은 열정적인 나라(eager-land) 에 살고 있습니다. 내부 구성원은 모두 열정적인 사람처럼 취급되어야 합니다. 그들은 이미 매일 제품에 깊이 빠져 있으니까요. 온보딩할 때 그들은 “내가 뭘 하는지 알아, 이건 지루해, 왜 이 단계가 있지?” 라고 생각합니다.
반면에 스쳐 지나가는(Fly-bys) 그룹도 있습니다. 그들은 당신에게 그다지 관심이 없습니다. 소문을 듣고 살펴봤지만, 메시지가 와닿지 않아 떠날 것입니다.
이 두 종류의 사용자는 분포(distribution) 의 끝단(edges) 입니다. 그 사이에는 크고 흐릿한 중간층(big fuzzy middle) 이 있습니다. 이들은 이유를 가지고 나타난 사람들입니다: 호기심이 많습니다! 더 알고 싶어 합니다! 그리고 당신은 진정으로 그들을 제품의 핵심 사용자로 전환할 수 있습니다. 당신이 구축해야 할 대상은 바로 이들입니다. 열정적인 사람들은 어차피 옵니다. 당신이 이해해야 할 대상은 중간층입니다.
사용자들이 동기 부여가 되어 있고 호기심이 많다고 가정하세요. 제품을 단계별로 소개하는 데 시간을 들이세요. 더 단순한 단계들이 덜 복잡하지만 큰 단계들보다 낫습니다. 저는 여러 회사에서 A/B 테스트를 통해 이를 입증했습니다. 모든 단계가 개별적이고 단순하며, 당신이 무엇을 요청하고 무엇을 가르치는지 명확하다면, 단계 수를 줄이기 위한 단일 대형 화면이나 복잡한 선택지보다 항상 낫습니다. 매번요.
그렇다면 실제로 그것을 어떻게 구축하나요?
핵심 메시지를 반복하는 것부터 시작하세요: 이것이 무엇인지를 위한 것이다. 제품 내에서 맥락을 명시하세요. 기본 정보(이메일, 비밀번호, 전화번호) 를 요청하는 것은 괜찮습니다. 그 외의 모든 것에 대해서는 왜 요청하는지, 그것이 어떻게 관련되는지 설명하세요. 그런 다음 제품을 주요 개념으로 나누고, 각 개념마다 사용자가 취할 명확한 행동을 지정하세요.
AI 제품들은 이 과정을 더 쉽게 만든 것이 아니라 더 어렵게 만들었습니다. 빈 프롬프트 상자를 받게 되죠. 어떤 면에서는 지금까지 디자인된 최악의 온보딩 화면입니다. 마법 상자입니다. 무엇이든 할 수 있습니다. 그래서… 무엇을 하고 싶으신가요?
요즘 많은 제품들이 “안녕하세요, 도와드릴게요, 무엇이든 물어보세요!” 로 시작합니다. 제 개인적으로는, 그 순간에 제가 가장 유창하거나 창의적인 사람이 아닙니다. 능력(capabilities) 을 개념별로 가르쳐야 합니다. “이런 식으로 물으면, 저는 이렇게 할 수 있어요.” 그리고 제품이 그것을 하게 하세요. 사용자의 데이터를 활용하여, 그들에게 실제로 가치 있는 최소한 하나의 유용한 사례(use case) 에 빠르게 도달하게 하세요.
사람들이 가끔 저에게 묻습니다: 흐름(flow) 이 길어지면 이탈(drop-off) 하는 사람이 더 많아지지 않나요? 네! 하지만 통과한 사람들은 당신의 제품을 실제로 사용할 가능성이 훨씬, 훨씬 높습니다. 두 가지 다른 온보딩 플로우를 A/B 테스트한다면, 플로우 끝에 도달한 사람의 수를 보지 마세요. 다음 날 또는 다음 주에 돌아온 사람의 수와 핵심 행동을 취한 사람의 수를 보세요. 그 순간에 “이 제품은 무엇인가요?” 라고 물었을 때, 그들은 대략적으로라도 올바른 답을 주어야 합니다. 이 시점 이후의 리텐션(retention) 데이터가 당신의 성적표(report card) 입니다.
Twitter 의 이야기
이 모든 것을 Twitter 의 한 이야기로 마무리하겠습니다.
저는 2009 년 말에 Twitter 에 합류했습니다. 성장 문제가 있었습니다—하지만 사실 그것은 성장 문제가 아니었습니다. Twitter 는 끊임없이 뉴스에 올랐습니다. 사람들은 블로그에 글을 썼고, 미디어는 그에 대해 이야기했으며, 많은 사람들이 물었습니다: “이 Twitter 라는 게 뭐지? 알아보고 가입해야겠어.” 그리고 수백만 명이 그렇게 했습니다. 하지만 그들은 돌아오지 않았습니다.
문제는 아무도 Twitter 가 *무엇인지* 설명할 수 없었다는 점입니다. 저는 실제로 이를 증명할 수 있습니다:
캡션: “우리는 결국 1 위를 차지했다.”
우리가 하던 온보딩 방식은, 사람들이 가입하고 “친구 찾기” 또는 “무작위 20 명 팔로우” 옵션을 보는 것이었습니다. 대부분은 이를 건너뛰었고, 다음과 같은 페이지에 도착했습니다:
이건 꽤 형편없습니다! 크고 빈 상자일 뿐이죠. 사람들은 그것을 보고 “…할 말이 없어” 라고 생각했습니다. 그리고 떠나버렸죠. 그 순간 “Twitter 는 무엇인가요?” 라고 물으면, 그들은 “세상에 뭔가를 말하는 거라고 생각해요? 아니면 친구를 찾는 거요? 잘 모르겠어요” 라고 답했습니다.
그래서 우리는 몇 년에 걸쳐 온보딩을 재구축했고, 효과가 있는 방법을 찾았습니다. 바로 Learn Flow 였습니다. 우리는 Twitter 를 개념 하나씩, 스토리 형태로 가르쳤습니다. 그리고 그것은 그 해에 우리가 출시한 다른 어떤 것보다 리텐션을 더 크게 개선시켰습니다.
Learn Flow, 화면별 상세
먼저, 새로운 홈 페이지: “Welcome to Twitter.” 우리는 콘텐츠를 배치하려고 하지 않았습니다. 단지 이렇게 했습니다: “당신이 관심 있는 사람들과 조직들의 현재 happening 한 일을 알아보세요.” 솔직히 이것은 Twitter 에 대한 꽤 좋은 설명입니다.
다음: 이것은 트윗(tweet) 입니다. 짧은 메시지이며, 최대 140 자이고 링크를 포함할 수 있습니다. 이제 트윗이 이 서비스의 단위(unit) 임을 알게 됩니다.
다음으로 타임라인을 구축해야 합니다. 그래서 우리는 타임라인을 보여주었습니다. 왼쪽에 있는 사람들을 클릭하여 “팔로우” 하도록 했습니다. 그들이 팔로우를 클릭하면, 오른쪽에 그들의 트윗이 나타났습니다. 즉, 한 동작으로 전체 개념을 얻게 됩니다: 클릭하여 팔로우하면, 트윗이 나타나고, 그것이 내 타임라인이다. 이것이 바로 Twitter 의 실제 개념—트윗, 팔로우, 그리고 타임라인입니다.
그리고 마침내, 당신의 타임라인이 됩니다. 거기 있는 모든 계정을 알아볼 수 있을 텐데, 왜냐하면 당신이 실제로 직접 팔로우했기 때문입니다.
온보딩은 당신의 스토리입니다.
사용자를 위한 올바른 제품
제품 관리자로서의 당신의 일은 팀과 회사가 사용자들에게 올바른 제품을 출시하도록 돕는 것입니다. AI 시대에는 출시(shipping) 는 예전만큼 문제가 되지 않습니다. 올바른 제품과 당신의 사용자가 누구인지 파악하는 일은 그 어느 때보다, 어쩌면 그 이상으로 중요합니다.
항상 사람들이 실제로 당신의 제품을 사용하는지 물으세요. 그것이 무엇을 의미하는지 이해하세요. 목적, 핵심 행동, 주기에 대해 생각하세요. 합리적이라고 느껴지는 것보다 온보딩에 더 많은 시간을 쓰세요. 그곳이 흐릿한 중간층을 전환시키는 곳이며, 실제로 당신의 제품 이야기를 전달하는 곳입니다.
프로토타입 작업 속도를 높이는 데 AI 를 활용하세요—하지만 당신의 판단력을 서두르지 마세요. 판단력을 포기하지 마세요. 그저 “음, 테스트해 보고 보자” 라고만 말하지 마세요. 그렇게 하면 대충대충 만든 제품이 됩니다. 모든 곳에서 당신의 판단력을 유지하세요. 이 직무에서 가장 어려운 부분은 여전히 제품 관리자로서의 우리의 모든 창의성과, 이제 접근할 수 있게 된 모든 데이터 사이의 균형을 맞추는 것입니다.
행운을 빕니다!
