Minimum Worthy Product

ResumeGeni의 공개 영역을 재구축하면서, 저는 계속해서 같은 불편한 선에 부딪힙니다. 기술적으로는 작동하는 버전이라도 구직자 앞에 내놓을 버전은 아닐 때가 있습니다. 파서가 돌아갑니다. 출력이 로드됩니다. 플로우가 완료됩니다. 그런데도 경험의 어딘가가 신뢰를 얻기보다 소모시킵니다. 저는 한 시간 동안 그것과 마주 앉아 표면을 재구축하고, 그 느낌은 사라지지만, 시간은 사라지지 않습니다.

이 긴장이 바로 이 글의 주제입니다. 두 힘이 서로를 잡아당깁니다. 제품을 세상에 내놓을 만큼 충분히 빨리 출시하려는 힘과, 사용자의 믿음을 소모하는 제품을 출시하지 않으려는 힘입니다. 대부분의 빌더들은 한쪽 편을 골라 방어함으로써 이 긴장을 해소합니다. MVP 문화는 속도를 고릅니다. 완벽주의는 마감을 고릅니다. 두 답 모두 실패합니다. 긴장 그 자체가 핵심이기 때문입니다.

Minimum Worthy Product는 다른 기준입니다. 기능적이라고 변호할 수 있는 가장 작은 제품이 아니라, 믿음을 얻어내는 가장 작은 제품을 출시하는 것입니다. Worthy는 천장이 아니라 바닥입니다. Minimum은 품질 할인이 아니라 범위 제약입니다. MWP 빌더는 제품이 출시될 수 있을 때까지 기능을 잘라내고, 남은 모든 표면을 사용자가 느낄 수 있는 기준까지 유지합니다. MVP 빌더는 너무 자주 그 반대로 합니다. 범위를 보호하기 위해 품질을 잘라냅니다. 이 치환이 바로 사용자가 데이터에서 느끼는 것입니다.

TL;DR

MVP는 학습 도구가 되어야 했습니다. 실제 사용자와 함께 실제 가설을 테스트하는 가장 작은 산출물 말입니다. 변질된 버전은 약한 작업을 출시해도 된다는 허가증이 되었습니다. Minimum Worthy Product는 사라진 제약을 복원합니다. 저렴하게 검증한 다음, 믿음을 얻어내는 가장 작은 제품을 만드세요. Minimum은 범위를 잘라냅니다. Worthy는 남은 표면을 사용자가 느낄 수 있는 기준으로 유지합니다.

---

MVP가 제대로 한 것

원래의 MVP 아이디어는 약한 작업을 출시해도 된다는 허가를 주지 않았습니다. 창업자들이 잘못된 것을 만드는 데 몇 달을 낭비하지 않도록 하는 방법을 제공했습니다.¹

Eric Ries는 특정한 실패 양상을 다루기 위해 The Lean Startup을 썼습니다. 바로 엔지니어들이 존재하지 않는 시장을 위한 정교한 제품을 만들고 있었다는 문제입니다. MVP는 학습 도구였습니다. 특정 가설을 실제 사용자와 테스트할 수 있는 가장 작은 산출물을 만들고, 실험을 실행하고, 일어난 일을 측정하고, 그 가설이 현실과의 접촉에서 살아남았는지에 대한 이해를 업데이트하는 것이었습니다. MVP에서 “minimum”은 출시를 위한 품질 축소가 아니라 학습을 위한 범위 축소를 의미했습니다.

원래의 프레이밍은 여전히 유효합니다. 저도 씁니다. 저의 스타트업 검증 시퀀스(문제, 솔루션, 채널, 매출, 규모)는 Ries의 하위 파생입니다. 코드에 투자하기 전에 검증하기 쉬운 가정을 테스트한다는 논리는, 검증 이후의 MWP 논리와 동일합니다. 모든 단계의 도구는 그 단계에 맞아야 합니다. 랜딩 페이지와 인터뷰는 바람직성에 대한 MVP입니다. 프로토타입과 스파이크는 실현 가능성에 대한 MVP입니다. MWP는 검증 증거가 이미 확보된 상태에서, 실제 사용자가 믿음을 걸게 될 첫 번째 실제 제품을 만들 때 적용하는 기준입니다.

그래서 저는 MVP에 반대하는 것이 아닙니다. 저는 실무에서 MVP가 변해버린 모습에 반대하는 것입니다.

MVP 문화가 어디서 물러졌는가

어느 순간 “빠르게 배우자”가 “아무거나 출시하자”가 되었고, 그 치환은 실제 피해를 낳았습니다.

세 가지 번역이 원래의 아이디어를 깨뜨렸습니다.

1. “당신이 제품의 첫 버전에 당황하지 않는다면, 너무 늦게 출시한 것이다” (Reid Hoffman의 문구⁴)는 범위가 아니라 장인 정신에 당황해도 된다는 허가가 되었습니다. 원래의 주장은 기능 개수에 관한 것입니다. 미래의 당신이 제품이 얼마나 적은 일을 했는지에 당황할 만큼 적은 기능으로 출시하라는 뜻입니다. 변질된 버전은 솜씨에 관한 것입니다. 미래의 당신이 제품이 어떻게 보이고 느껴졌는지에 당황할 만큼 거칠게 출시하라는 뜻입니다. 이 두 문장은 같은 문장이 아닙니다.

2. “빠르게 출시하자”가 측정 가능한 결과로서 “빠르게 배우자”를 대체했습니다. 학습은 질적인 통찰을 만들어내는 느리고 귀찮은 과정입니다. 출시는 날짜가 찍힌 산출물을 만들어내는 빠르고 읽기 쉬운 과정입니다. 둘을 구분할 수 없을 때, 산출물이 기본값으로 승리합니다. 팀은 매주 출시하고 학습을 완전히 멈춥니다. 아무도 팀이 무엇을 배웠는지 측정하지 않기 때문입니다.

3. 벤처 패턴(투자 유치, 성장, 엑시트)은 올바르게 출시하는 것보다 뭐라도 출시하는 것을 보상합니다. 당신의 일이 다음 수표를 위한 모멘텀을 증명하는 것이라면, 물탄 제품이라도 최소한 “우리는 출시했다”는 기준선은 넘습니다. 지연된 가치 있는 제품은 외부에서 보기에 멈춰버린 팀과 구분되지 않습니다. 인센티브의 기울기가 아래를 향합니다.

이러한 변질들 중 어느 것도 원래 쓰인 MVP의 잘못이 아닙니다. 약한 것을 출시하기 위한 방어 논리가 필요했던 사람들의 입에서 MVP가 변해버린 모습일 뿐입니다.

사용자는 그 결과를 느낍니다. 당신은 그것을 데이터에서 느낍니다. 온보딩은 완료되지만 두 번째 세션은 일어나지 않습니다. 사용자가 가입 이메일을 열지만 링크를 클릭하지 않습니다. 지원 티켓이 제품이 처리한다고 주장하는 작업 주변에 몰립니다. 이탈 곡선이 코어로 평평해지는 대신 0을 향해 감쇠합니다. 이러한 결과들은 엣지 케이스가 아닙니다. 사용자가 믿을 수 없는 기준으로 만든 것의 핵심 비용입니다.

Minimum이 미완성을 의미하지 않는다

Minimum은 품질 할인이 아니라 범위 제약입니다.

운영적으로 보면, 사용자를 정의하고, 제품이 전달한다고 주장하는 하나의 결과를 정의한 뒤, 그 결과에 필요하지 않은 모든 기능을 제거하세요. 그런 다음 남은 표면을 완전한 품질 기준으로 유지하세요. Minimum은 제품이 출시될 수 있을 때까지 범위를 자릅니다. Minimum은 제품이 더 일찍 출시되기 위해 기준을 자르지 않습니다.

두 기준은 나란히 놓입니다.

차원	MVP (실무상)	MWP
목표	움직임을 증명하기 위한 무언가의 출시	사용자 믿음을 얻어내는 무언가의 출시
범위	기능적이라고 변호할 수 있는 가장 작은 산출물	검증된 약속을 전달하는 가장 작은 표면
품질 기준	돌아갈 만큼은 작동함	사용자가 느낄 수 있는 기준
중단 규칙	“우리는 출시했다”	두 테스트 모두 통과; 세 번의 실패한 재구축 후에는 브리프를 재구축
성공 신호	체인지로그의 날짜	다섯 가지 신뢰 프록시: 두 번째 성공률, D30/D1 비율, 코호트 모양, 유기적 추천, 품질 마찰
실패 양상	약한 첫인상이 사용자 신뢰를 태움	리파인먼트가 은폐가 됨

워크드 예시. ResumeGeni의 약속은 지원자 추적 시스템을 깔끔하게 통과하여 구직자에게 채용 관리자에게 도달할 실제 기회를 주는 ATS-ready 이력서입니다. 약속의 최소 버전은 다음을 제외할 수 있습니다.

• 커스텀 템플릿
• 팀 협업
• 분석 대시보드
• LinkedIn, Indeed, 채용 사이트와의 통합
• 버전 히스토리
• 한 가지를 넘어서는 내보내기 형식

최소 버전이 제외할 수 없는 것은 다음과 같습니다. 원본 이력서의 정확한 파싱, 격차에 대한 정직한 평가, 직무 설명에 실제로 맞는 구체적인 재작성, Word에서 깔끔하게 열리는 내보내기, 구직자가 안전하다고 느끼게 하는 플로우. 템플릿 없이 출시할 수 있습니다. 모호한 조언, 깨진 내보내기, 또는 취약한 사용자를 얼간이처럼 대하는 것으로 느끼게 하는 카피로는 출시할 수 없습니다.

Minimum은 제품 백로그에 적용하는 칼입니다. Worthy는 남은 표면에 적용하는 칼입니다.

Worthy는 바닥이다

가치 있는 제품이 당신이 상상하는 모든 것을 담고 있어야 하는 것은 아닙니다. 담겨 있는 모든 것이 사용자를 존중해야 합니다.

운영적 의미에서 Worthy란, 제품이 검증된 문제를 충분히 잘 해결해서 사용자가 다음 상호작용으로 신뢰를 가지고 넘어간다는 뜻입니다. 사용자는 당신이 무엇을 만들고 있었는지를 보고, 더 많은 것이 올 것이라고 믿습니다. 첫 번째 세션이 견뎌야 할 시련이기를 멈추고, 두 번째 세션의 문을 여는 악수가 됩니다. 가치 있는 제품은 믿음을 쌓습니다. 반쯤만 가치 있는 제품은 믿음을 소비합니다.

신뢰는 가짜로 만들 수 없습니다. 사용자가 이미 알고 있는 제품들이 당신의 제품에 대한 기대를 형성합니다.⁵ 당신의 제품이 그 기대 아래에 있을 때(반응하지 않는 버튼, 얼버무리는 카피, 중간에 사용자를 버리는 플로우), 사용자는 그것을 말로 표현하기 전에 그 격차를 감지합니다. 그들은 떠나고, 돌아오지 않으며, 어떤 리텐션 이메일도 이미 포기한 세션을 구해낼 수 없습니다.

이것은 가치 있는가?라는 질문은 취향의 질문이 아닙니다. 신뢰의 질문입니다. 사용자의 답은 행동으로 나타납니다.

검증이 먼저, Worthiness는 그 다음

MWP에 대한 가장 강력한 반박은, 가치는 제작자의 확신이 아니라 접촉을 통해 사용자가 결정한다는 것입니다. 맞습니다. MWP는 사용자의 판단을 대체하지 않습니다. MWP는 첫 번째 실제 사용자가 판단하기 전에 검증된 신뢰를 태워버리는 것을 막습니다.

사용자 접촉은 검증에 속합니다. 만들기 전에, 문제가 실제인지, 당신이 제안한 솔루션이 그것을 다루는지, 사용자에게 도달할 수 있는지, 그리고 그들이 돈을 낼 것인지 테스트합니다. 증거는 랜딩 페이지, 인터뷰, 컨시어지 테스트, 프로토타입, 대기자 명단에서 나옵니다. 저는 그 시퀀스에 대해 자세히 썼습니다. 그 관문을 통과한 가설은 만들어질 권리를 얻은 것입니다.

MWP는 검증 이후에 시작됩니다. 검증은 누가 그 약속을 원하는지를 묻습니다. MWP는 출시된 표면이 검증이 이미 얻어낸 신뢰를 받을 자격이 있는지를 묻습니다. 리텐션, 추천, 품질 마찰 데이터가 그 판단이 유지되는지를 결정합니다.

검증을 건너뛰고 그 결과를 MWP라고 부르는 것은 아무도 묻지 않은 질문에 대한 아름다운 답을 만들어냅니다. MWP를 건너뛰고 그 결과를 린하다고 부르는 것은 검증이 이미 얻어낸 신뢰를 대가로 치르는 물탄 제품을 만들어냅니다.

올바른 순서는 다음과 같습니다. 실제 사용자와 저렴하게 검증한 다음, 검증된 약속을 위한 가장 작은 가치 있는 제품을 만드세요. 둘 다 하세요. 어느 쪽도 건너뛰지 마세요.

두 가지 테스트: Jiro와 Steve

제품이 완료되었다고 부르기 전에 두 가지 다른 테스트를 통과해야 합니다.

Jiro Test는 작업이 정확한지를 묻습니다. 제품이 작동한다는 증거. 제품이 엣지 케이스를 처리합니다. 보이지 않는 디테일이 지켜집니다. 주장은 구체적인 증거를 인용합니다. 얼버무림 없음. 믿습니다는 증거가 아닙니다. Jiro Test는 장인 정신과 열망을 구분합니다. 저는 AI 에이전트에 적용되는 규율로서 Jiro 품질 철학에 대해 썼습니다. 같은 규율이 모든 제품 표면에 적용됩니다. Evidence Gate는 제가 코드 보고서에서 이 테스트를 운영화하는 방식입니다.

Steve Test는 작업이 존재할 자격이 있는지를 묻습니다. 관점이 보입니다. Whole-widget 일관성. 표면이 사용자의 존엄성을 보존합니다. 독자가 손짓으로 대충 말하는 것이 아니라 식별할 수 있는 기쁨이나 명료함의 메커니즘. Steve Test는 제품과 재고를 구분합니다. 출시된 것이 자동으로 가치 있는 것은 아닙니다. 기술 시스템으로서의 취향에 대한 완전한 논증은 별도의 에세이에 있습니다. 이 글에서는 위의 운영적 정의가 그 무게를 견딥니다.

두 테스트 모두 통과해야 합니다. Jiro가 실패하면 멈추고 고치세요. Steve가 실패하면 재구축하세요. 둘 다 실패하면, 문제는 브리프 상류에 있습니다.

판단이 불확실할 때 핵심 질문은 스택에서 가장 단순한 것입니다. 움츠러들지 않고 내 이름을 서명할 수 있는가? 답이 아니오라면, 작업은 아직 가치 있지 않습니다.

당신 발 밑의 증거: blakecrosley.com

지금 읽고 있는 이 페이지는 저의 pathless transition에서 작은 실험으로 시작되었습니다. 또한 논증의 일부이기도 합니다.

React가 없습니다. Tailwind가 없습니다. webpack도, Vite도, 번들러도, 빌드 스텝도 없습니다. FastAPI가 사이트 전체를 직접 서빙합니다. HTMX, Alpine.js, Jinja2, 그리고 일반 CSS, 그 사이에 아무것도 없습니다. 2026년 4월 17일 빌드에서, 초기 페이지 전송은 45-60KB에 해당하고 Lighthouse는 성능, 접근성, 모범 사례, SEO 전반에 걸쳐 100/100을 보고합니다.³ 사이트는 10개 언어로 운영되며, 새로운 가이드와 블로그 콘텐츠를 단일 git push로 처음부터 끝까지 출시하고, 저장소 어디에도 node_modules/가 없습니다.

이 사이트의 MVP 버전은 2026년의 기본 조언(Next.js, Tailwind, Vercel)을 따랐을 것입니다. 주말에 출시되었을 것입니다. 괜찮았을 것입니다. 당신은 여기에 도착해서, 페이지는 그럴듯한 시간 안에 로드되었을 것입니다. 차이는 능력이 아니었을 것입니다. 차이는 취향이었을 것입니다. 저는 완벽한 Lighthouse 점수가 실제로 어떻게 만들어지는지에 대해 썼습니다. 짧은 버전은, 독자가 다운로드하지 않는 페이로드의 모든 KB가 하나의 존중의 형태라는 것입니다.

MWP 버전은 더 오래 걸렸습니다. MWP 버전은 HTMX 패턴을 처음부터 작성하고, 타이포그래피를 수동으로 튜닝하고, 폰트를 셀프 호스팅하고, Cloudflare D1을 통해 i18n 파이프라인을 실행하고, 빌드 도구의 부재를 하나의 기능으로 취급해야 했습니다. MWP 버전은 기본 스택보다 기술적으로 더 유능하지 않습니다. MWP 버전은 더 의도적입니다. 그 의도는 독자가 알아챌 이음새가 더 적은 것으로 나타납니다.

보이지 않는 장인 정신. 독자는 결정을 보지 못합니다. 독자는 마찰의 부재를 느낍니다. 마찰의 부재가 바로 메커니즘입니다.

고객을 향한 증거: ResumeGeni

ResumeGeni는 기준을 더 높입니다. 사용자는 둘러보고 있는 것이 아니기 때문입니다. 사용자는 인터뷰를 볼지 말지를 결정할 수 있는 문서를 개선하려고 하고 있습니다.

ResumeGeni의 검증은 깔끔하게 돌아왔습니다. 랜딩 페이지, 대기자 명단, Reddit과 LinkedIn의 타깃 포스트, 2주 동안 340명의 이메일 가입, 제품이 언제 열리는지 직접 문의한 12건, 그리고 얼리 액세스 비용을 지불하겠다는 요청되지 않은 3건의 제안.⁷ 검증 시퀀스는 만들라고 했습니다. 만드는 것은 쉬운 결정이었습니다. 무엇을 만들 것인지가 어려운 결정이었고, MWP가 실제 작업을 한 곳입니다.

두 가지 범주의 컷. 첫 번째 범주는 기능이었습니다. 템플릿, 협업, 분석, 수십 가지 내보내기 변형, 채용 사이트 통합. 전부 잘라냈습니다. 그들 중 어느 것도 약속의 일부가 아닙니다.

두 번째 범주는 남은 것에 대해 제가 유지하려는 기준이었습니다. 그 기준은 잘리지 않습니다. 파서는 약할 수 없습니다. 조언은 모호할 수 없습니다. 내보내기는 깨질 수 없습니다. 카피는 취약한 사용자를 전환 지표로 대할 수 없습니다. 플로우는 해피 패스만이 제가 가진 시간이었다는 이유로 누군가를 중간에 버릴 수 없습니다.

MVP 버전은 10단계 마법사, 일반적인 출력, 최적의 순간에 구독 벽, 그리고 잘린 모든 것을 약속하는 로드맵 페이지를 출시했을 것입니다. 기능적이었을 것입니다. 한 번은 일부 사용자를 전환시켰을 수도 있습니다. 또한 첫 번째 코호트에게 제품을 믿지 말라고 가르쳤을 것이고, 그 교훈은 취약한 사용 사례의 나쁜 기반이 됩니다.

MWP 버전은 제가 원하는 것보다 작습니다. 제가 잘라낸 모든 기능을 저는 다시 원하게 될 것입니다. 기준은 사용자가 도착하는 제품이 그들을 존중한다는 것입니다. 그 기반이 제가 그 위에 짓는 방법을 아는 유일한 기반입니다.

사용자가 실제로 당신에게 말해주는 것

사용자는 이제 이 제품을 믿어요라고 거의 말하지 않습니다. 하지만 그들의 행동이 흔적을 남깁니다.⁶

제가 주시하는 다섯 가지 신호는, 빌더 대상으로 보정된 것입니다.

1. Second-success rate. 활성화된 사용자 중 자연스러운 사용 창 내에서 돌아와 핵심 결과를 두 번째로 완료하는 비율. 신뢰는 첫 번째가 아니라 두 번째 성공에서 쌓입니다. 반복 제품의 경우, 30% 미만의 second-success를 재구축 신호로 봅니다. 에피소딕 제품의 경우, 30일 창을 강제하는 대신 다음 자연스러운 사용 주기를 측정합니다.

2. Day-1 활성화 대비 Day-30 리텐션. 재참여 이메일이 raw 리텐션을 속일 수 있습니다. 비율은 속일 수 없습니다. 주간 또는 월간 사용 제품의 경우, 이 비율은 활성화가 신뢰였는지 일회성 호기심이었는지를 알려줍니다. 저는 0.25 미만을 경고로, 0.15 미만을 판결로 사용합니다.

3. 코호트 리텐션 곡선 모양. 가치 있는 제품은 초기 하락 이후 평평해집니다. 약한 제품은 계속 감쇠합니다. 곡선을 그리세요. 모양이 평균이 숨기는 이야기를 들려줍니다. 곡선이 결코 평평해지지 않는다면, 제품을 실제로 신뢰하는 사용자의 코어가 없는 것입니다.

4. 인센티브 없는 유기적 추천 점유율. 직접 추천, 공유된 출력물, 입소문을 통해 도착하는 새로운 활성화 사용자의 비율. 유료 채널이나 추천 프로그램 뇌물이 아닙니다. 사용자는 가치 있는 제품에 대해 이야기합니다. 사용자는 약한 제품을 잊습니다. 카테고리에 자연스러운 공유 순간이 있는데도 유기적 추천이 여전히 새로운 사용자 획득의 10% 미만이라면, 제품은 추천을 얻어내지 못하고 있는 것입니다.

5. Quality-friction rate. 100명의 활성화 사용자당 환불, 분노 클릭, 지원 티켓, 실패한 내보내기, 수동 수정을 코호트별로 추적하세요. 그 비율은 제품이 섬기겠다고 주장하는 사용자들에게 제품이 가하는 고통입니다. 그 비율은 제품이 성숙함에 따라 하락하는 추세여야 합니다. 비율이 평평하거나 상승하는 추세라면, 문제는 지원 프로세스가 아니라 제품입니다.

이 신호들 중 어느 것도 허영 지표가 아닙니다. 각각 속이기 어렵습니다. 각각 믿음을 얻거나 얻지 못한 실제 사용자 경험을 추적합니다. 다섯 가지 모두에서 특정 코호트의 숫자를 이름 지어 말할 수 없다면, 아직 당신의 제품이 가치 있는지 알지 못하는 것입니다.

MVP나 프로토타입이 여전히 올바른 움직임일 때

MWP가 모든 산출물에 올바른 기준은 아닙니다.

MVP나 프로토타입 논리가 여전히 맞는 세 가지 경우.

• 검증 이전. 랜딩 페이지, 인터뷰, 컨시어지 테스트, 클릭 가능한 프로토타입. 목표는 학습이지 장인 정신이 아닙니다. 가설을 테스트하는 못생긴 버전을 출시하세요. 오늘 출시하세요. 여기서는 MWP가 아니라 검증 시퀀스가 올바른 플레이북입니다.

• 실현 가능성 스파이크. 알려지지 않은 것이 기술적일 때(필요한 레이턴시로 모델이 이런 종류의 쿼리에 답할 수 있는가? API가 부하를 처리하는가? 파서가 실제 입력의 긴 꼬리에서 작동할 것인가?), 질문에 답하는 가장 작은 일회용 도구를 만드세요. 가치 있게 만들려고 하지 마세요. 진실되게 만드세요.

• 네트워크 효과 베타 표면. 마켓플레이스, 커뮤니티 제품, 네트워크 효과 도구는 누군가가 그것을 판단할 수 있기 전에 실제 사용자 기반이 필요합니다. 그래서 올바른 산출물은 코호트 계측이 있는 명확하게 라벨이 붙은 베타입니다. 베타를 출시하는 것은 가치 있는 버전의 대체물이 아닙니다. 베타를 출시하는 것은 가치 있음이 무엇을 의미하는지 발견하는 유일한 방법입니다. 표면을 정직하게 베타로 라벨링하세요. v1로 치장하지 마세요.

MWP는 첫 번째 실제 제품 표면을 위한 것입니다. 당신이 여전히 표면 상류에 있다면(학습, 테스트, 발견), 올바른 도구는 시퀀스의 더 뒤쪽에 있습니다.

재구축 상한선

중단 규칙 없는 높은 기준은 회피가 됩니다.

제가 모든 사소하지 않은 작업에 적용하는 교리는 세 번의 정직한 시도라는 재구축 상한선을 가지고 있습니다.² 정직한 시도란 실패한 축을 식별하고, 구체적인 교정 움직임을 명명하고, 접근 방식을 실질적으로 변경하고, 작업을 두 테스트 모두에 대해 재평가했다는 것을 의미합니다. 같은 폴리시 패스를 세 번 반복한 것은 세 번의 시도로 간주되지 않습니다. 그 반복은 세 번 반복된 한 번의 실패한 시도로 간주됩니다.

가치 있는 제품을 만들어내지 못하는 세 번의 정직한 재구축 이후, 문제는 장인 정신이 아닙니다. 문제는 상류에, 프레이밍, 범위, 브리프, 또는 팀에 있습니다. 표면을 재구축하는 것을 멈추고 전제를 보세요. 때로는 약속이 현실적으로 기준까지 유지할 수 있는 범위에 비해 너무 컸습니다. 때로는 검증이 생각보다 물렀습니다. 때로는 문제가 제품 문제가 전혀 아닙니다.

재구축 상한선은 두 가지 반대의 실패를 해결합니다. 약한 작업을 축복하기를 거부하고, 리파인먼트가 은폐가 되는 것을 막습니다. 목표는 완벽이 아닙니다. 목표는 가치 있고 출시됨입니다. 순수하고 영원히 보류 중이 아닙니다.

완벽주의는 용기 없는 장인 정신입니다. 같은 표면의 네 번째 재구축 중이라면, 제품 만들기를 멈추고 프로젝트를 숨을 장소로 사용하기 시작한 것입니다.

핵심 요점

창업자와 솔로 빌더를 위해: - 어떤 코드 전에도 저렴하게 검증하세요. MWP는 검증이 시장 적합성을 확인한 이후에 적용됩니다. - 기능을 공격적으로 잘라내세요. 남은 표면을 완전한 품질 기준까지 유지하세요. - 가치 있을 때 출시하세요. 재구축은 세 번으로 상한선을 두세요. 그 이후에는 브리프를 에스컬레이션하세요.

제품 리더와 PM을 위해: - 신뢰 프록시를 직접 측정하세요. 두 번째 성공률, day-30 대 day-1 리텐션 비율, 코호트 곡선 모양, 유기적 추천 점유율, 100명의 사용자당 품질 마찰율. - 범위 대화를 품질 대화와 분리하세요. 범위 컷은 협상 가능합니다. 품질 컷은 아닙니다. - 첫 번째 코호트 경험을 보호하세요. 취약한 사용자에 대한 저하된 첫인상은 회복하는 데 몇 년이 걸립니다.

엔지니어링 리드를 위해: - 출시하는 모든 표면에 대해 Jiro 게이트와 Steve 게이트를 명명하세요. 둘 다 통과해야 합니다. - 보이지 않는 장인 정신을 위한 예산을 책정하세요. “작동”과 “가치 있음” 사이의 차이는 보통 누구도 가리키지 않는 디테일에 있습니다. - 완벽주의가 리파인먼트로 숨는 것을 멈추도록 프로세스에 재구축 상한선을 넣으세요.

디자이너를 위해: - 관점은 장식이 아닙니다. 제품을 알아볼 수 있게 만드는 메커니즘입니다. - 가치 있는 표면은 눈에 띄게 거부합니다. 팀이 아무것도 거부하지 않았다면, 범위가 잘못된 것입니다. - 애매함 속의 핵심 테스트는 움츠러들지 않고 결정에 이름을 서명할 수 있는가입니다.

마무리: 믿음을 얻을 때 출시하라

제품의 지배적 질문은 완성되었는가?가 아닙니다. 지배적 질문은 존재할 자격이 있는가?입니다.

답이 예라면, 출시하세요. 답이 “아직은 아니지만, 세 번의 정직한 재구축 이내에 될 것이다”라면, 계속 작업하세요. 답이 아니오이고, 세 번의 시도 이후에도 아니오로 유지된다면, 표면이 아니라 브리프를 재구축하세요.

이 접근은 제가 제 이름을 건 모든 제품을 만드는 방식입니다. MVP 마인드셋은 사이클을 최적화합니다. MWP 마인드셋은 작업의 몸체로 복리로 쌓입니다.

존중할 수 있는 가장 작은 제품을 출시하세요. 그 전에 출시하지 마세요. 그 이후로 기다리지 마세요. Minimum과 worthy는 동시에 유지되는 같은 지시입니다.

---

FAQ

Minimum Worthy Product란 무엇입니까?

Minimum Worthy Product는 사용자 믿음을 소비하기보다 얻어내는, 검증된 제품의 가장 작은 공개 버전입니다. Minimum은 범위가 핵심 약속으로 잘린다는 것을 의미합니다. Worthy는 남은 표면이 사용자가 느낄 수 있는 품질 기준을 만족한다는 것을 의미합니다. 실제 사용자가 보는 첫 번째 실제 물건은 단지 기능하는 것이 아니라 그들의 신뢰를 받을 자격이 있어야 합니다.

MWP는 MVP와 어떻게 다릅니까?

원래 쓰인 Minimum Viable Product는 학습 도구였습니다. 특정 가설을 테스트하는 가장 작은 산출물이었습니다. 실무에서 MVP는 약한 작업을 출시해도 된다는 허가로 변질되었습니다. Minimum Worthy Product는 사라진 제약을 복원합니다. 검증은 누가 그것을 원하는지를 다룹니다(MVP, 랜딩 페이지, 인터뷰의 일). MWP는 검증이 확인한 것의 첫 번째 실제 버전을 만들 때 유지하는 기준을 다룹니다.

팀은 언제 MWP 대신 MVP를 사용해야 합니까?

Minimum Viable Product 또는 프로토타입 논리가 여전히 적용되는 세 가지 경우. 검증 이전(랜딩 페이지, 인터뷰, 컨시어지 테스트, 클릭 가능한 프로토타입), 실현 가능성 스파이크 동안(레이턴시나 품질을 테스트하는 일회용 코드), 그리고 팀이 가치 있음을 정의하기 전에 실제 사용자가 있는 라벨이 붙은 베타가 필요한 네트워크 효과 제품의 경우. MWP는 첫 번째 실제 제품 표면에 적용되며, 그 상류의 모든 산출물에 적용되지 않습니다.

제품이 가치 있는지 어떻게 측정합니까?

허영 지표가 아니라 다섯 가지 행동 신뢰 프록시를 통해서입니다. 두 번째 성공률(활성화된 사용자가 핵심 결과를 두 번째로 완료하는 비율), day-1 활성화 대비 day-30 리텐션(절대값이 아니라 비율), 코호트 리텐션 곡선 모양(평평 대 감쇠), 인센티브 없는 유기적 추천 점유율, 그리고 품질 마찰율(100명의 활성화 사용자당 환불, 실패한 내보내기, 지원 티켓). 가치 있는 제품은 다섯 가지 모두에서 강점을 보입니다. 약한 제품은 최소 하나, 종종 모두에서 그것을 드러냅니다.

---

Worthy Gate

프레임워크를 자신의 작업에 적용하기 위한 의사 결정 도구. 다섯 가지 입력을 거친 다음, 세 가지 교리 레일을 거치세요. 점수 없음, 게임화된 미터 없음. 축을 명명하고 다음 움직임을 지정하는 판결.

---

References