기능 목록이 사이클에 들어가지 않을 때 /scoping-cutting은 고정 투자 의지에 맞춰 범위를 교환해 반쪽짜리 자동차가 아니라 scooter를 출시하게 합니다. — Claude Skill

범위 지정과 축소 - 모든 게스트 인사이트

게스트 15명, 언급 19개

---

Anton Osika

Anton Osika

"제가 우리가 추구해야 할 것을 강조하기 위해 즐겨 쓰는 많은 용어는 최소 사랑 가능 제품을 만들고, 그다음 사랑 가능한 제품을 만들고, 그다음 완전히 사랑스러운 제품을 만드는 것입니다. 그래서 그 용어를 회사 이름에도 가져갔습니다."

인사이트: 초기 출시가 사용자에게 감정적으로 공명하도록 초점을 '최소 실행 가능 제품'에서 '최소 사랑 가능 제품'으로 옮기세요.

전술 조언:

• 초기 버전에서는 단순한 '실행 가능성'보다 '사랑받을 가능성'을 목표로 하세요.
• 최소 사랑 가능에서 완전히 사랑스러운 상태로 반복하세요.

Timestamp: 00:00:31

Crystal W

Crystal W

"정말 Wizard of Oz 경험이었습니다. 우리는 아무것도 만들 필요가 없었습니다. 저는 인턴 여러 명과 조율했고 구독 서비스에서 기대할 가치 제안과 전환율 일부를 검증할 수 있었습니다."

인사이트: 엔지니어링 리소스에 투자하기 전에 수동 'Wizard of Oz' 테스트로 제품 가치 제안을 검증하세요.

전술 조언:

• WhatsApp 그룹을 사용해 자동화 기능을 수동으로 시뮬레이션하세요.
• 기존 화면 위에 단순한 앱 내 메시지 오버레이를 올려 온보딩 흐름을 테스트하세요.
• 성격 퀴즈 같은 빠른 기능 검증에는 Typeform을 사용하세요.

Timestamp: 00:14:46

Daniel Lereya

Daniel Lereya

"저는 데드라인 함정을 사용하는 것을 정말 좋아합니다. 집중하게 만들기 때문입니다. 사람들이 하는 모든 이론적 논의와 그런 것들을 없애 줍니다."

인사이트: 단단한 시간 박스, 즉 함정은 팀이 핵심 가치에 우선순위를 두게 만들고 과도한 엔지니어링으로 인한 '천 개의 상처로 죽기'를 막습니다.

전술 조언:

• 고정 마감(예: 3주)을 정하고 날짜를 늘리는 대신 그 시간에 맞게 범위를 자르세요.
• 실적 발표 같은 외부 이벤트를 제품 전달을 강제하는 '함정'으로 사용하세요.

Timestamp: 00:53:48

Dharmesh Shah

Dharmesh Shah

"HubSpot 제품에는 규칙이 있었습니다. 우리가 노브나 다이얼이라고 생각하는 기능을 하나 추가할 때마다 어딘가에서 하나를 빼야 했습니다. 순증가를 막는 것입니다. 적어도 생각하게 만들기 때문입니다."

인사이트: 제품 엔트로피와 싸우려면 기능에 대해 '하나 넣으면 하나 빼기' 규칙을 적용해 복잡도를 일정하게 유지하세요.

전술 조언:

• 기능의 '3차 비용'을 평가하세요. 앞으로의 모든 결정과 차트에 더하는 차원적 복잡도입니다.

Timestamp: 00:41:00

Eeke de Milliano

Eeke de Milliano

"차축이 아니라 킥보드를 만드세요. 자동차의 최소 실행 가능 제품을 만들려 한다면 바퀴와 차축만 만들지 말고 먼저 킥보드를 만드세요. 그리고 거기서 자전거, 오토바이, 자동차로 갑니다."

인사이트: MVP는 더 큰 것의 불완전한 조각이 아니라 더 작은 가치 제안의 작동하는 end-to-end 버전이어야 합니다.

전술 조언:

• 고객이 가치 있는 작업을 완료할 수 있게 하는 가장 작은 '슬라이스'를 식별하세요.
• MVP가 부품(차축)이 아니라 독립적으로 작동하는 제품(킥보드)인지 확인하세요.

Timestamp: 00:47:34

Eric Ries

Eric Ries

"MVP는 우리가 테스트하려는 가설이 무엇이든, 그 가설이 참인지 아닌지에 대해 필요한 검증을 얻는 가장 효율적인 방법일 뿐입니다."

인사이트: MVP는 단순한 저품질 제품 버전이 아니라 특정 가설을 검증하는 도구입니다.

전술 조언:

• 먼저 핵심 가설을 식별하세요.
• 검증을 얻는 가장 효율적인 방법을 정하세요.
• 실수했을 때의 책임 범위를 제한하세요.

Timestamp: 00:28:22

---

"첫 번째 팁은 MVP에 필요하다고 생각하는 기능 목록을 적는 것입니다. 그것을 반으로 자르고 다시 반으로 자른 뒤 그것을 만드세요. 솔직히 그렇게만 해도 그렇게 나쁘지 않습니다."

인사이트: 창업자는 MVP에서 무엇이 '최소'인지 일관되게 과대평가합니다. 진짜 기준선에 도달하려면 공격적인 축소가 필요합니다.

전술 조언:

• '필요하다'고 여기는 모든 기능을 나열하세요.
• 목록을 반으로 줄이세요.
• 남은 목록을 다시 반으로 줄이세요.

Timestamp: 00:43:02

Jackson Shuttleworth

Jackson Shuttleworth

"우리는 큰 V1을 하려는 충동에 정말 저항합니다. 예전에 연속 목표 예시를 공유했는데, 무언가를 탐색할 때 우리는 자주 '좋아, 멋지네. 많은 것을 걷어내고 우리의 핵심 가설이 무엇인지 알아보자. 그리고 그것을 먼저 V1으로 출시하자'라고 말합니다."

인사이트: 가설의 가장 단순한 버전을 출시하면 더 빠르게 학습하고 '장식' 편향을 피할 수 있습니다.

전술 조언:

• 핵심 가설을 분리하기 위해 필수적이지 않은 모든 기능을 걷어내세요.
• V1이 이기도록 보장하려고 '장식'을 붙이지 말고 핵심 메커니즘을 먼저 테스트하세요.

Timestamp: 01:10:44

Jason Fried

Jason Fried

"우리는 대신 투자 의지를 둡니다. 개별 기능에 대한 우리의 투자 의지는 최대 6주입니다. 본질적으로 그것이 우리가 기꺼이 쓰는 예산입니다. 저는 어떤 기능에도 6주만 쓸 의향이 있습니다. 그래서 두 사람이 6주 안에 끝낼 수 있는 가장 단순하고 효과적인 버전을 찾아야 합니다."

인사이트: 추정이 아니라 고정 시간 예산, 즉 '투자 의지'를 사용해 팀이 가장 단순하고 효과적인 기능 버전을 찾도록 강제하세요.

전술 조언:

• 어떤 기능 개발에도 최대 6주라는 상한을 두세요.
• 시간을 추정해야 하는 마감이 아니라 쓸 수 있는 예산으로 다루세요.
• 집중을 유지하려면 팀 크기를 두 명(디자이너 한 명, 프로그래머 한 명)으로 제한하세요.

Timestamp: 00:34:21

---

"우리가 6주를 준다고 해 놓고 7주, 8주, 9주, 10주를 준다면 실제로는 6주를 준 것이 아닙니다. 10주를 준 것입니다. 그러면 시스템이 없는 것입니다. 아직 언덕 왼쪽에 남은 작업, 즉 여전히 밀어 올리는 중이고 어떻게 할지 모르며 시간 제한에 도달했다면 거의 확실히 죽습니다."

인사이트: 할당된 '투자 의지' 창 안에 완료되지 않은 프로젝트는 죽여서 시간 제약의 무결성을 유지하세요.

전술 조언:

• 끝없는 작업을 막기 위해 사이클 안에 끝나지 않은 프로젝트는 '죽게' 하세요.
• 작업이 최종 실행 단계, 즉 '내리막'에 있을 때만 며칠의 연장을 허용하세요.
• 엄격한 사이클 종료를 적용해 장기 프로젝트의 사기 저하를 피하세요.

Timestamp: 00:36:27

Matt LeMay

Matt LeMay

"그들은 해냈고, 빼기를 통해 해냈습니다. 경험을 간소화했습니다. 사람들이 막히던 단계를 없앴습니다. 더 쉽게 만들었습니다. 전통적인 기능 출시가 축하받던 방식으로는 거의 축하받지 못하는 일을 했지만, 성공이 어떤 모습인지 명확하고 영향력 있고 구체적으로 알고 있었기 때문에 그 일을 직접 맡을 수 있었습니다."

인사이트: 영향은 새 기능 추가보다 빼기와 간소화를 통해 달성되는 경우가 많습니다.

전술 조언:

• 추가할 기능보다 제거할 사용자 여정 단계를 찾으세요.
• 무엇을 자를지 결정할 때 사업의 '상업적 심장', 예를 들어 첫 성공 행동에 집중하세요.

Timestamp: 00:32:15

Ronny Kohavi

Ronny Kohavi

"재설계를 한 번에 한 요소로 분해할 수 없다면, 작은 요소 묶음으로라도 분해해 보세요. 그리고 더 작은 변경에서 무엇이 작동하고 무엇이 작동하지 않는지 배우세요. 더 작은 증분으로 하고 배우세요. 이것은 OFAT, one-factor-at-a-time이라고 부릅니다. 한 요소를 하고, 배우고, 조정하세요."

인사이트: 대형 재설계는 '한 번에 한 요소'(OFAT) 증분으로 분해해 한 번의 거대한 실패 위험을 피하세요.

전술 조언:

• 복잡한 프로젝트를 더 작고 테스트 가능한 증분으로 나누세요.
• 증분 테스트를 사용해 재설계의 어떤 구체적 변경이 실제 가치를 제공하는지 식별하세요.

Timestamp: 00:38:42

Ryan Singer

Ryan Singer

"우리는 반대로 갈 겁니다. 실제로 무언가를 끝내기 전까지 우리가 기꺼이 쓸 최대 시간은 얼마인가? 사업이 쓰고 싶어 하는 시간 안에서 작동할 아이디어를 어떻게 생각해 낼 것인가?"

인사이트: 기능이 얼마나 걸릴지 추정하는 대신 고정 시간 예산(투자 의지)을 정하고 그 안에 맞는 해결책 버전을 설계하세요.

전술 조언:

• 가시성과 통제를 유지하기 위해 어떤 프로젝트에도 최대 시간 제한(예: 6주)을 설정하세요.
• 출시를 보장하려면 마감이 아니라 해결책의 범위를 바꾸세요.

Timestamp: 00:00:37

---

"두 번째 조각은 우리가 셰이핑이라고 부르는 작업입니다. 셰이핑 작업은 우리가 스스로에게 준 고정 시간 안에서 실제로 범위를 어떻게 바꾸느냐입니다. 사업이 쓰고 싶어 하는 시간 안에서 작동할 아이디어, 그 어떤 버전을 어떻게 떠올리느냐입니다."

인사이트: 셰이핑은 해결책의 복잡도를 사용 가능한 시간 예산에 맞추는 창의적 과정입니다.

전술 조언:

• 아이디어가 시간 박스에 맞을 때까지 문제와 해결책을 동시에 씨름하세요.
• 기능을 가치 있게 만드는 '반드시 필요한' 움직이는 부분을 식별하고 나머지를 자르세요.

Timestamp: 00:21:07

---

"프로젝트가 6주 뒤 실제로 끝날 궤도에 있지 않다면 우리는 그냥 취소하고 다시 생각할 겁니다. 이해하지 못한 것에 계속 재투자하지 않을 겁니다. 그러니 이것을 구축 모드에서 빼내 셰이핑 모드로 되돌립시다."

인사이트: 시간 박스를 초과한 프로젝트가 끝없이 끌리지 않도록 '회로 차단기'를 사용해 멈추세요.

전술 조언:

• 프로젝트가 출시에 실패하면 숨은 복잡도를 식별하기 위해 셰이핑 단계로 되돌리세요.
• 사이클 끝을 재투자 결정의 단단한 정지점으로 다뤄 '초과 근무' 부채를 피하세요.

Timestamp: 00:31:34

Sander Schulhoff

Sander Schulhoff 2.0

"사용자가 원하는 것에 따라 에이전트가 할 수 있는 행동을 미리 제한할 수 있을지도 모릅니다. 그러면 악의적인 일을 할 수 없습니다. CAMEL은 제 프롬프트를 보고 '이 프롬프트에는 이메일 작성과 전송 외 권한이 필요 없어 보입니다'라고 말할 것입니다."

인사이트: CAMEL 프레임워크는 구체적인 사용자 의도에 따라 에이전트 권한을 동적으로 범위화해 공격 표면을 줄입니다.

전술 조언:

• 특정 작업에 필요한 최소 행동으로 에이전트 동작을 제한하는 동적 권한 부여를 구현하세요.
• 자동화된 데이터 유출을 막기 위해 '읽기'와 '쓰기' 권한을 분리하세요.

Timestamp: 01:05:34

Vijay

Vijay

"추정치를 계획의 산출물로 만드는 대신, 시간 박스나 투자 의지를 입력으로 삼고 '우리는 X 문제를 풀고 싶고 그 문제 해결에 6주를 투자할 의향이 있다'고 말합니다."

인사이트: 가변 추정치를 산출물로 쓰기보다 '투자 의지'(고정 시간)를 입력으로 사용해 범위를 강하게 두드려 맞추세요.

전술 조언:

• 문제에 대해 고정 시간 박스(예: 6주)를 정하고 그 안에 맞게 범위를 조정하세요.
• '4주만 있다면 무엇을 다르게 할까? 8주라면?'이라는 사고 실험으로 비용과 영향의 효율 경계를 찾으세요.

Timestamp: 27:23

Zoelle Egner

Zoelle Egner

"웃길 만큼 작은 MVP의 힘입니다. 처음에는 정말 사실상 스프레드시트와 전화, 그게 전부였습니다. 그것만으로도 엄청난 영향을 냈을 뿐 아니라, 실제로 무엇을 만들어야 도움이 될지에 대한 정보를 아주 많이 주었습니다."

인사이트: 가능한 가장 작은 인프라로 시작하면 빠르게 학습하고 잘못된 가정에 기반해 만들지 않게 됩니다.

전술 조언:

• 맞춤 소프트웨어를 만들기 전에 스프레드시트, 전화 같은 기존 단순 도구로 개념을 검증하세요.
• 즉각적 영향을 제공하는 핵심 유틸리티에 집중하세요.
• 요구사항이 바뀔 때 민첩성을 유지하려면 기능을 공격적으로 가지치기하세요.

Timestamp: 00:15:51

Paige Costello

Paige Costello

"로드맵에 올렸다는 이유로 반드시 해야 하는 것처럼 느껴졌고, 그것은 똑똑하지 않기 때문에, 로드맵에 올린 것에서 피벗하거나 자를 수 있다는 개념을 제품 프로세스에 넣었습니다."

인사이트: 로드맵의 '매몰 비용' 오류를 피하려면 제품 프로세스 안에 기능을 피벗하거나 자를 선택지를 명시적으로 넣으세요.

전술 조언:

• 팀이 이미 로드맵에 올라간 항목에서 잘라내거나 피벗할지 결정할 수 있는 프로세스 단계를 공식화하세요.
• 범위를 일찍 검증하기 위해 반복 출시와 프로토타이핑을 장려하세요.

Timestamp: 00:10:38