빌딩, 그리고 Whatnot

지난 2년 동안 31,832명이 Whatnot의 프로덕 제품 관리자(PM) 직에 지원했습니다. 저희는 단 한 명을 채용했습니다. 단순히 지원서를 내서 입사할 가능성보다 골프에서 홀인원을 할 확률이 두 배나 높습니다.

이는 프로세스의 실패가 아닙니다. 저는 10년 넘게 제품과 제품 팀을 만들어 왔으며, 약 3년 전 Whatnot에 합류하기로 결정한 가장 큰 요인 중 하나는 매우 의도적인 제품 문화였습니다. AI 시대에 PM이 무엇을 의미하는 일을 한다는 것이 무엇을 의미하는지 아무도 모르지만, 업계가 우리와 우리가 여기서 구축하는 방식으로 나아가고 있다는 모든 징후가 보입니다. 올바른 일을 하지 않는다면 어떤 도구도 당신을 유용하게 만들지 못하기 때문입니다.

먼저 인정해야 할 점은 평균적인 PM은 매우 평범하다는 것입니다.

제품 관리라는 기능은 확장에 대한 대응으로 등장했습니다. 엔지니어링 팀이 너무가 너무 커져서 CEO나 GM이 직접 관리할 수 없게 되자, 비즈니스와 기술 사이의 연결고리가 필요해 필요한 것입니다. 시간이 지나면서 우리는 게을러져 "엔지니어링 매니저를 뽑을 때마다 PM도 뽑아라"는 식으로 역할을 일반화했습니다. 하지만 엔지니어링 디렉터가 30-40명의 직원을 EM을 통해 관리하는 반면, PM 디렉터는 고작 5명을 관리했습니다. 인센티브가 세상을 지배하기 때문에, 그 디렉터들의 임무는 "내 엔지니어링 파트너의 인원수를 늘리는 것을 정당화하는 것"이 되었고, 그래야 자신도 VP가 될 수 있었기 때문입니다. 서서히 주니어 PM의 역할은 "제품의 CEO"에서 "버튼의서 "버튼의 베이비시터"로 바뀌었고, 제품 지향적인 엔지니어들은 유아화된 명령 수신자로 전락했습니다.

그러다 COVID가 닥쳤고, 업계는 불과 4년 만에 믿기간 동안 믿기 어려운 50만 명의 새로운 소프트웨어 엔지니어를 고용했으며, 이에 맞춰 약 8만 명의 새로운 PM이 새로 배출되었습니다. 그 8만 명의 PM들은 FAANG의 거대한 팀 속에 파묻혀, 고객과는 동떨어져, 의사 결정이 이루어지는 회의에서 50단계나 떨어져 있었고, 제품 스쿨에서 번호판 찍기식 PM 교육을 받았으며, 모든 것이 먹혀들던 부당한 참여 성장 시대에 있었습니다.

그러한 환경에서 훌륭한 제품 감각, 경험, 투지를 가진 인재가 나올 가능성은 실제로 홀인원을 칠 확률보다 낮아 보입니다.

둘째, 우리는 최고의 인재를 더 나쁘게 만들었습니다.

당신의 일이 5명을 감독하는 것이라면, 하루 종일 할 수 있는 일은 다른 사람들의 일에 간섭하는 것뿐입니다. 그들은 그것을 싫어하고 익명 설문조사에서 미시 관리라고 낙인찍기 때문에 당신은 물러서게 됩니다. 그러면 어떻게 시간을 보낼까요? 스토리를 만들고, 검토 과정을 통해 팀이 '성공'하도록 이끌고, 자원을 정당화합니다. 하지만 어떤 스토리를 만들어야 할지 모르기 때문에 사용자 리서치 팀을 세워 해야 할 일을 알려주고, PMM 기능을 만들어 그 스토리를 고객에게 전달합니다. 전략적으로 중요해진 이 기능은 맥락을 모으고 명확성을 전달했지만, 점점 더 상아탑으로 스스로를 추상화했습니다.

하지만 실제 진실은 시스템의 데이터 모델, 영업 전화, CX 티켓, 분석 데이터에 있습니다. 모든 것을 단순화하기 위해 만든 예쁜 2x2 매트릭스에 있는 것이 아닙니다.

관리에 보내는 모든 시간은 문제에 대한 본질적인 이해를 낡게 만들고, 고객에 대한 직감을 무디게 하며, 당신이 옳을 확률을 떨어뜨립니다.

기능으로서의 우리의 타율은 분모가 확장되었기 때문이기도 하지만, 그 확장으로 인해 7년 전에 제품을 잘했던 모든 사람들이 실제 업무에서 승진했거나 (또는 충분히 부자가 되어 남아서 정치를 할 인센티브가 낮아 낮아졌기 때문에) 떨어졌습니다.

Whatnot의 방식

Whatnot 제품 팀은 초창기부터 다소 간단한 전제 위에 구축되었습니다. 제품 관리가 존재한다는 것을 우리는 후회합니다. 영업과 엔지니어링은 우리가 고용되기 전에도 잘 지내고 있었습니다. 따라서 가능한 곳에서는 절차적 게이트키핑이나 불필요한 서류 작업 없이 그냥 출시해야 합니다. 제품은 기술이지 자격이 아닙니다. 잘하는 사람은 직접 해보고 훌륭한 사람들과 함께 일하면서 배웁니다.

최근 최근 면접에서 누군가 Whatnot이 Twitch와 eBay의 아기 같다고 말하는 것을 들었습니다. 문화적으로는 더 틀릴 수 없지만, 제품 범위 측면에서는 괜찮은 비교입니다. 보수적으로 추정해도 두 조직을 합치면 400명 이상의 PM이 있습니다. 우리는 20명입니다. 1200명 이상의 전체 직원을 위해 20명의 PM이 일하고 있습니다.

우리의 PM은 문제에 매핑되고, EM에 매핑되지 않습니다. 둘은 자주 겹치지만, 같은 것은 아닙니다. 패션 셀러를 위한 새로운 판매 형식을 구축한다면, 상품 목록과 재고를 담당하는 EM과는 물론 긴밀히 협력해야 하지만, 물류 및 결제 EM과도 마찬가지로 협력해야 합니다.

여러 스택에 걸쳐 작업하고 다양한 고객에 대한 영향을 평가하는 것은 쉽지 않습니다. 비즈니스에 대한 폭넓은 맥락, 모든 기능 변경의 하류 영향을 예측하는 능력, 컨텍스트 스위칭 능력, 한 명의 파트너가 아닌 전체 조직에 걸쳐 신뢰를 구축하고 사용하는 능력이 필요합니다. 이것이 우리가 거의 시니어 PM만 채용하는 이유입니다. 끝없는 정렬 회의에 지쳐 다시 구축하고 싶어하는 PM들 말입니다. 또는 유망한 영업이나 운영 인력을 전환시켜 직접 해보면서 배우게 합니다. 우리는 항상 경력 중반의 L5/L6 인재를 찾고 있지만, 통계는 우리가 그들을 얼마나 자주 찾는지에 대해 거짓말을 하지 않습니다.

마지막으로, 모든 사람이 출시에 참여합니다. 저를 포함해서요. 저는 항상 엔지니어와 디자이너 팀과 직접 협력하여 IC로서 기능을 출시하고 있으며, 두 공동 창업자도 마찬가지로 합니다. PM이 작은 기능을 '바이브코딩'하는 것이 가능한지 테스트할 때, 제가 실험 대상이었습니다. 호주에서 첫 번째 셀러를 온보딩할 때는 공동 창업자 Logan이 직접 했습니다. Zendesk에서 고객 티켓이 떨어지기 시작했을 때는 CEO Grant가 그들의 지원 엔지니어와 직접 통화했습니다.

회사로서 우리는 모든 직원이 판매, 구매, CX 업무를 수행하도록 요구하며, 그렇지 않으면 기대 이하 평가를 받습니다. 고객 중심에 대한 이러한 헌신을 가진 회사에서 PM이 리더 역할을 하려면, 우리는 일이 어떻게 돌아가는지 깊이 이해하고 왜 그 이유에 대한 폭넓은 이해를 가져야 합니다. 우리는 이것을 "T자형"이라고 부릅니다. 동시에 맥락의 폭은 맥락과 해당 영역의 깊이를 가지는 것입니다. 깊이와 경험을 통해 빠르게 결정을 내릴 수 있으며, 5단계의 관리 검토를 기다릴 필요가 없다는 것은 그 결정이 행동이 됨을 의미합니다.

기술 스태프 멤버

요즘 "구축"에 대한 소음이 너무 많습니다... 아니요, 제품 요구 사항 문서(PRD)는 죽지 않았습니다. PRD는 단지 문제에 대해 명확하게 생각하고 그것을 다른 사람에게 전달하기 위한 그릇일 뿐입니다. 원한다면 대화형으로 만들어도 됩니다. 아무도 신경 쓰지 않습니다. 아니요, 나쁜 제품을 출시하는 비용이 0이 된 것은 아닙니다. 여전히 고객이 지불합니다. 그들에게 스파게티를 16배 더 빠르게 던지는 것은 사실 혁명이 아니라 단지 짜증날 뿐입니다. 그리고 아니요, 모든 사람이 S급 엔지니어이자 디자이너이자 PM이 되는 것은 아닙니다. 소수는 그렇게 되겠지만, 전문화의 동인, 즉 사람들이 좋아하고 잘하는 것은 여전히 우리가 일하는 방식을 결정할 것입니다.

변화하고 있는 것은 IC가 되는 것이 많은 사람들의 기술, 경험, 그리고 이 지상에서의 제한된 시간을 다섯 번째로 같은 문서를 다시 작성하여 현재의 깐깐한 사람들이 선호하는 형식에 맞추는 것보다 훨씬 더 잘 활용할 수 있다는 깨달음입니다. Whatnot의 몇몇 PM은 관리자이지만, 각자 시간의 90% 이상을 IC로 보냅니다. 관리 여부에 따라 직함이나 보상에 차별을 구분하지 않습니다. 우리는 그것에 본질적인 미덕을 보지 않기 때문입니다. AI는 우리에게 놀라운 레버리지를 제공합니다. 개발 프로세스의 거의 모든 작업에서 더 빠르게 움직일 수 있습니다. 데이터 과학자가 풀어야 했던 데이터를 이해하거나, PRD를 출시 주간에 사무실에서 늦게까지 작업해야 했던 모든 CX SOP의 CX SOP로 변환하는 것까지 말입니다. 영업팀으로부터 매주 오는 100개의 질문을 분류하거나 최근 실험에서 놓친 현지화 격차이 격차를 찾는 봇 봇 위해 봇을 만들 수 있습니다.

PM에게 AI의 가장 파괴적인 점은 사람을 코칭하고 그들을 통해 일을 통해 레버리지를 얻는 것이 더 이상 유일한 레버리지 원천이 아니라는 것을 보여주었다는 것입니다. 특히 그 사람들이, 그들의 잘못은 아니지만, 깊게 평범하다면 더욱 그렇습니다. 하지만 그 레버리지는 여전히 일을 하는 방법을 아는 사람들에게만 가능합니다.

이 추세에서 특히 고무적인 점은 최고의 PM들이 실제 PM 업무로 돌아오도록 유인할 것이라는 점입니다. 고객과 비즈니스의 필요에 대해 생각하고, 최선의 방법으로 문제를 해결하는 좋은 안목을 발휘하는 것입니다. 다른 회사의 고객으로서, 저는 업계의 거물들이 다시 구축에 나서는 것을 보게 되어 기 기쁩니다. 그들의 제품을 더 좋게 만들 것이기 때문입니다. 역사상 가장 작은, 가장 높은 레버리지 PM 팀을 구축하는 데 집착하는 사람으로서, 지난 5년 동안 로드맵 검토에 형식적으로 참여해 온 놀라운 인재들이 해방되는 것을 보게 되어 기쁩니다.

말보다 행동

아래에 Whatnot에서 제품 업무를 어떻게 수행하는지에 대한 유일한 문서를 (전체) 복사하겠습니다. 우리가 한 번이라도 만났다면 저자가 누가 작성했는지 말할 필요가 없을 것입니다. 이것이 우리가 말하고 일하는 방식입니다.

또한 우리 팀에서 일하는 사람들을 살펴보세요. 오늘날 팀에는 시리즈 B-C 스타트업의 CPO가 될 수 있는 사람이 적어도 6명 있으며, 저녁 시간을 셀와 통화, Hex Thread에서 400개 쿼리, 또는 내일 출시를 위한 초안 작성에 보냅니다. 네 명의 전직 창업자로, 자신의 관할 밖의 일이라는 데 동의한 적이 없습니다. 네 명의 전직 FAANG 디렉터로, 더 이상 9박스 그리드에서 사람들이 어디에 있어야 하는지 논쟁하며 시간을 보내지 않습니다. 여섯 명의 초기 단계 PM으로, 놀라운 안목을 가지고 있으며, 더 많은 것을 시도하라는 조언을 듣고 있습니다. 우리는 행동을 통해서만 배우기 때문입니다.

우리의 20명 PM 상한선 선언이 오래 지속될 것 같지는 않습니다. Whatnot 앞에 놸 기회가 너무나 방대하기 때문에 인위적으로 제약하지 않을 것입니다. 하지만 우리가 채용하는 기준은 업계와 AI 도구가 뛰어난 IC에게 계속해서 레버리지를 제공함에 따라 기준은 더욱 높아질 것입니다. 당신이 그러한 사람 중 하나이고, 위에서 설명한 내용이 당신을 움직이게 한다면, 저에게 연락하는 방법을 찾을 것입니다.

Whatnot에서의 구축

훌륭한 제품을 구축하는 것은 어렵습니다. 문제에 대한 올바른 통찰력을 가지고, 세부 사항을 정확히 하고, 시장에 올바르게 출시하고, 성과를 이해하기 위해 올바르게 측정하고, 빠르게 반복해야 할 뿐만 아니라, 이 모든 것을 해야만 작동하기 때문입니다. 설상가상으로, 실패는 비용이 많이 듭니다. 우리는 팀이 적고 앞에 엄청난 기회가 있습니다. MLB에서 타율 .300은 훌륭하지만, 우리의 포부를 실현하려면 .500에 가까워야 합니다. 높은 타율이 없으면 단기적으로 성장기적으로 성장을 제한하거나 비즈니스 성장을 인원수 증가에 묶어 장기적으로 제약을 받게 됩니다.

이 문서는 2부분으로 구성되어 있습니다.

1. 우리의 철학 - 이것은 변하지 않습니다.
2. 우리의 프로세스 - 이것은 진화할 것이며 현재 상태는 여기에 유지됩니다.

우리가 구축하는 방식이 우리에게 레버리지를 줍니다

건물을 방 하나씩 지을 수는 없습니다. 전체 건물을 한 번에 설계하고 한 번에 지어야 합니다. 고맙게도 우리는 건설업이 아니라 소프트웨어 업계에서 일합니다. 반복적으로 구축하는 것이 우리의 초능력입니다. 우리는 항상 실제 사용자 가치와 견고한 사용자 경험을 제공하는 가장 작은 단위를 출시하지만, 확장할 수 있도록 더 먼 미래까지 설계합니다.

여기서 성공적인 제품의 행복한 경로는 7단계를 일관을 일관되게 밟습니다.

1) 사용자와 비즈니스에 중요한 일이어야 합니다.

사용자와 비즈니스 요구를 해결하는 가장 영향력 있는 일을 냉혹하게 우선순위를 정하십시오.

• 그 가치를 명시적으로 설명할 수 있어야 합니다. "여러 위치에 보관 장소에 보관된 제품을 단일 쇼에서 판매할 수 있도록 대규모 소매업체를 지원하기 위해 '배송지'를 쇼 필드가 아닌 제품 필드로 업데이트"
• 시스템에 대해 생각하십시오.

1. 이 제품이 출시되면 즉시 가치가 있습니까?
2. 다른 것들을 위한 '구축 블록'입니까?

(1)이 사실이 아니라면 진행하지 마십시오. (1)이 사실이라면 시간이 지남에 따라 (2)가 될 수 있는 방법을 찾으십시오.

2) 사람들이 원하는 것이어야 합니다.

그들의 고통점, 욕구, 행동을 이해하여 그들을 위한 제품을 만드십시오.

• 구축하는 사용자를 세부적으로 이해하지 않으면 알 수 없습니다. 질적 정성과 정량을 결합하십시오.
• 기존 제품 워크플로우의 맥락에서 제품을 생각하십시오.
• 형편없는 것 위에 레이어를 덧씌우지 마십시오.
• 문제 A에 집중하고 있다고 해서 문제 B를 해결하는 워크플로우를 망치지 마십시오.
• 문제가 실제라면 - 그들이 오늘날 어떻게 해결하고 있는지 알고 있습니까?
• 반짝이는 물건을 조심하십시오. 특히 과거에 다른 곳에서 구축한 반짝이는 물건을 조심하십시오.

3) 고객의 요구는 우리의 조직도와 일치하지 않습니다 / 단일 기능으로 충족되지 않습니다.

지역적으로 구축한다면 순진하게 구축하는 것입니다.

• 코드 소유권이 아닌 완전한 고객 경험에서 거꾸로 작업해야 합니다. 문제를 해결하십시오. 그게 전부입니다.
• 그 반대도 마찬가지입니다. 다른 PM들이 "당신의 영역"으로 들어와야 할 것입니다. 그들을 도우십시오.
• 이 원칙이 우리가 가능한 가장 작은 제품 및 디자인 팀을 위해 노력하는 이유입니다. 역할이 좁게 정의된 사람이 많을수록 로드맵은 더 근시안적이 되고 조정과 협의에 낭비하는 시간이 더 많아집니다.

4) 문제를 해결하는 가장 간단한 해결책이어야 합니다.

사용자가 사랑하는 빠르가 좋아하는 빠르고 안정적인 제품을 구축하는 열쇠는 불필요하고 영향력 없는 작업을 피하는 것입니다.

• 간단함은 구축하기 빠를 뿐만 아니라 일반적으로 가장 성공적입니다.
• 시스템에 대해 생각한다고 해서 전체 시스템을 미리 구축하라는 의미는 아닙니다.
• 당신이 옳다는 것을 알기 전에 더 많이 구축할수록, 당신이 틀렸을 때 비용이 더 많이 듭니다.

5) 가능한 가장 작은 대상으로 검증되었어야 합니다.

누군가가 사용하기 전까지는 추측에 불과합니다.

• 종이 프로토타입이나 클릭 가능한 프로토타입을 가능한 한 빨리 셀러 손에 쥐어 주십시오. 직원 도그푸딩은 솔루션을 검증하기보다 버그를 잡는 데 더 효과적입니다. 우리는 고객이 아니기 때문입니다.
• GTM 전략을 생각하십시오.
• 셀러 대상 제품: 10명 미만의 셀 시작하여 시작하고, 셀러 수 또는 몇몇 카테고리로 확장한 후 GA로 전환하십시오.
• 구매자 대상 제품: 카테고리 또는 소수 비율로 시작하고 신호에 따라 확장하십시오.
• 생태계 제품(양측 모두에게 보임): 카테고리 또는 소규모 시장으로 시작하십시오.
• 검증 모드에 있다면, 인지도(내부 또는 외부)를 해결하는 것은 실패 모드입니다.
• 너무 소규모여서 실제로 사람들에게 영향을 미치지 않습니다.
• 아직 작동할지 모릅니다. 사람들의 시간을 낭비하지 마십시오.

6) 일단 검증되면 미친 듯이 반복하십시오.

고객에게 라이브로 제공되면, 매주 또는 매일 개선 사항을 출시합니다.

• "X를 출시하면 Y로 넘어갈 수 있다"는 말은 큰 위험 신호입니다.
• 그것이 중요한 것이 될 것임이 확인되면 Catex와 CX를 위해 돌아가서 해결해야 합니다.
• 출시, 검증, 측정, 반복, 반복, 반복 > 그런 다음 다음 우선순위로 넘어가십시오.

7) 베타 버전에서는 벽을 뚫고 나가십시오.

불꽃을 일으키는 것은 어렵습니다. 일단 불꽃이 생기면 연료를 부어야 합니다. 그렇지 않으면 꺼집니다.

• 초간단, 초조기 제품을 출시할 때 가장 큰 위험은 불완전하여 장기적으로 진정으로 유용하지 않다는 것입니다. 일단 출시하면 높은 잠재력에서 높은 영향력으로 가기 위한 시간이 촉박합니다.
• 창출하는 가치를 극대화하는 데 집중하고 모든 작은 불만, 위험 또는 영향을 관리하지 마십시오.
• 어떤 불만, 위험 및 영향을 걱정해야 하는지 파악하는 것은 각 출시에 대한 판단 문제입니다. 위험이 아닌 것을 걱정하는 것은 걱정하지 못하는 것만큼 위험합니다.

8) 이것은 '더 배철러'가 아닙니다. 모든 것을 분리하십시오.

시스템을 설계할 때 여러 부분을 동시에 출시하고 싶은 자연스러운 경향이 있습니다. 우리처럼 충분히 복잡한 시스템에서는 여러 팀이 시스템의 구성 요소를 병렬로 작업할 가능성이 높으며, 하나의 큰 변경 사항으로 함께 출시하는 것이 두 개로 나누는 것보다 합리적으로 보일 수 있습니다. 이것은 함정입니다.

• 각 조각이 독립적으로 실행 가능하고 고객에게 유익하다면 가능한 한 빨리 출시하십시오.
• 각각을 더 효과적으로 측정하고 상대적 기여도를 이해할 수 있습니다.
• 유익한 제품을 다른 제품을 위해 스테이징에 남겨두는 것은 고객에게 좋지 않습니다.

검토 및 피드백의 역할

우리는 올바른 일을 올바른 방식으로 하고 있는지 확인하기 위한 제품 프로세스를 문서화했습니다. 여기에는 가시성, 승인 및 책임 기능이 포함됩니다. 그러나 맹목적으로 프로세스를 따르는 것보다 더 중요한 것은 그 기반이 되는 철학을 내면화하는 것입니다. 이는 이 트위터 스레드에 잘 설명되어 있습니다... (진지하게, 진행하기 전에 읽어보십시오)

1. 복잡한 시스템에서는 올바른 답을 얻기 위해 생각보다 훨씬 더 많은 정렬이 필요합니다. 이 단어가 오해될 수 있기 때문입니다.
2. 정렬이 합의를 의미하지는 않습니다. 합의는 좋은 의사 결정의 적입니다.
3. 정렬이 작업 스트림을 결합하는 것을 의미하지는 않습니다. 조정은 속도의 적입니다.
4. 정렬의 리트머스 시험 - 서면 계획. Grant가 요청한다면, 우리는 정렬되지 않은 것입니다.
5. Whatnot에서의 자율성은 구현의 자율성입니다. 아무도 전략의 자율성을 가지거나 기대해서는 안 됩니다. 정렬 없이 자율성은 낭비됩니다.

Whatnot에서 기대치를 충족시키기 위해 PM 또는 디자이너는

1. 즉시 정렬이 필요한 사항을 식별하고 적극적으로 추구합니다.
2. 논의와 정렬을 깊이 이해하기 때문에 정렬에서 구현으로 빠르게 이동합니다. 논의에서 '예'라는 말만 듣지 않습니다.
3. 팀과 함께 구현 세부 사항을 채우거나 / 정렬을 따르는 결정을 신속하게 결정을 차단 해제할 수 있습니다.

속도가 중요한 이유

우리 전체 시스템은 올바른 것을 출시하는 속도를 최대화하는 데 기반을 두고 있습니다. 행복한 경로의 1-3단계는 올바른 것이 무엇인지 파악하는 것이고, 4-7단계는 그것을 검증, 반복 및 확장하는 방법에 관한 것입니다. 우리는 이렇게 합니다.

1) 우리 시스템의 모든 것은 복리 효과를 냅니다. 좋은 것과 나쁜 것 모두.

2025년에 우리는 약 250영업일 동안 750개의 실험을 실행했으며, 이는 하루에 약 3번의 출시/미출시 결정에 해당합니다. 각 결정을 단 3일만 더 빨리 내렸을 때의 장기적 영향을 시뮬레이션하면 2년 동안 Whatnot 셀러를 위해 약 11억 달러의 추가 수익이 발생합니다. 이는 해당 제품의 영향이 아니라, 결정을 조금 더 빨리 내린 영향입니다. 올바른 것을 출시하는 모든 지연은 고객에게 해를 끼치며, 우리가 커질수록 속도의 기회 비용은 더 커집니다.

2) 일단 속도를 잃으면 다시는 되돌릴 수 없습니다.

인간은 자연스럽게 프로세스에 순응하고 의존하게 됩니다. 따라서 좁은 사용 사례를 위해 만들어진 프로세스라도 의도보다 더 자유롭게 적용됩니다. 인센티브는 시스템을 따르는 쪽으로 이동하고, 시스템이 보장하기 위해 설계된 시스템을 갖는 영향력에서 벗어나며, "알고 있지만 실행한다"는 조직의 근육 기억은 위축되고 사라집니다. 우리가 막을 수 있는 거의 유일한 실수는 장기적으로 구축 속도를 늦추는 좋은 거래가 될 것입니다.

3) 속도는 실수/오류의 원인이 아닙니다.

위원회는 진전을 막는 부산물로만 실수를 방지합니다. 판단이 실제로 실수를 실제로 방지합니다. 더 자주 출시하면 판단력이 향상됩니다. 운동선수가 반복을 통해 강해지는 것처럼 말입니다. 반복을 쌓는 동안 팀은 더 많은 반복과 더 많은 맥락을 가진 사람들의 판단을 활용할 수 있습니다. 제품 리더십의 지속적인 임시 지도, 계획의 초기 단계에서 법무 및 커뮤니케이션과 같은 주요 위험 완화에 대한 가시성 (대서양에 피해야 할 허리케인이 있다면, 출항할 때가 아니라 항로를 계획할 때 알아야 합니다), 특정 고객이 어떻게 반응할지 대리할 수 있는 카테고리 또는 국가 리더 등이 있습니다. 시스템에 대해 생각의 일환으로 PM은 출시의 영향을 예측해야 하지만, 조언을 구하거나 받는 것에 의해 차단되지는 않습니다. 제품 검토만이 우리 개발 프로세스의 유일한 게이트입니다.