프로덕트 소식은 넘쳐나지만 대부분 이런 게 나왔대에서 끝납니다. 그래서 뭘 어떻게 하라고? 내 작업에 어떻게 써먹지? 거기까진 연결이 잘 안 되죠. 따라서 요즘 프로덕트 메이커는 바로 쓸 수 있는 것, 그 중에서도 주목해볼 만한 것을 엄선해서 매주 금요일에 전달드리려 합니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: DESIGN.md + getdesign.md - AI에게 우리 디자인 규칙을 알려주는 파일 하나
참고할 것: 10년차 빌더가 제품을 만들기 전, 확인하는 세 가지 기준
적용해볼 것: 앤트로픽 Claude Code 제품 총괄이 말하는, AI 시대 PM의 희소 능력

1. 써볼 것: AI에게 우리 디자인 규칙을 알려주는 파일 하나

DESIGN.md는 Google이 자사 디자인 도구 Stitch에서 만들어 오픈소스로 공개한 마크다운 파일 규격입니다. 4월 21일 Apache 2.0 라이선스로 공개되자마자 개발자 커뮤니티에서 큰 반응을 얻었는데요. 공식 GitHub 레포는 공개 72시간 만에 스타 5,000개를 넘겼고, 커뮤니티에서 이 규격을 활용해 만든 awesome-design-md 레포는 한 달 만에 스타 6.8만 개를 돌파했습니다.

이 파일이 하는 일은 간단합니다. 프로젝트 루트에 DESIGN.md 파일을 넣어두면, AI 코딩 에이전트가 그 파일을 읽고 우리 브랜드에 맞는 UI를 만들어줍니다. 매번 색상 코드, 폰트, 간격 규칙을 프롬프트로 설명하지 않아도 되는 거죠.

무슨 문제를 해결해 주나요?

Claude Code, Cursor, Copilot 같은 AI 코딩 에이전트로 UI를 만들어본 적이 있다면 이런 경험이 있을 겁니다. 기능적으로는 잘 작동하는데, 결과물이 어딘가 범용적이에요. 우리 브랜드 색상도 아니고, 폰트도 다르고, 버튼 모양도 우리 제품과 안 맞죠. 그래서 매번 프롬프트에 이렇게 써야 합니다. 우리 메인 색상은 #1A73E8이고, 본문 폰트는 Inter 16px, 버튼은 border-radius 8px로 해줘. 프로젝트를 새로 열 때마다, 대화가 길어질 때마다 이걸 반복해야 하고요.

DESIGN.md는 이 반복을 없앱니다. README.md가 프로젝트를 사람에게 설명하듯, DESIGN.md는 디자인 시스템을 AI 에이전트에게 설명하는 파일입니다. 한 번 만들어 프로젝트 루트에 넣어두면, 에이전트가 매 작업마다 이 파일을 자동으로 읽고 반영합니다.

우선, 파일 구조는 두 부분으로 나뉩니다. 앞쪽에 YAML로 정확한 디자인 토큰 값(색상 코드, 폰트 크기, 간격 등)을 적고, 뒤쪽에 마크다운으로 그 값들이 왜 존재하는지, 어떤 맥락에서 써야 하는지를 설명합니다. 토큰은 에이전트에게 정확한 숫자를 주고, 마크다운 설명은 그 숫자를 언제 어떻게 쓸지 판단하게 해주는 구조죠.

어떻게 쓰나요?

DESIGN.md를 만드는 방법은 세 가지입니다.

방법 1. Google Stitch에서 자동 생성하기

가장 쉬운 방법입니다. stitch.withgoogle.com에 접속해서 프로젝트를 만들거나 기존 디자인을 가져오면, Stitch가 디자인 시스템을 분석해서 DESIGN.md를 자동으로 생성해줍니다. 기존 웹사이트 URL만 넣어도 그 사이트의 디자인 규칙을 추출할 수 있고요. Stitch는 무료이고, 구글 계정만 있으면 월 550회까지 생성할 수 있습니다.

방법 2. getdesign.md에서 브랜드 디자인 시스템 가져오기

여기가 사실상 우리에게 가장 실용적인 부분일 수 있는데요. VoltAgent라는 팀이 만든 getdesign.md에 가면, Apple, Notion, Figma, Spotify, Vercel 등 70개 브랜드의 DESIGN.md 파일이 정리되어 있습니다. GitHub의 awesome-design-md 레포에서도 같은 파일들을 받을 수 있고요. (링크는 아래에 모아두었습니다)

사용법은 간단합니다. 마음에 드는 브랜드의 DESIGN.md 파일을 다운로드하고, 내 프로젝트 루트에 넣은 뒤, AI 코딩 에이전트에게 작업을 시키면 됩니다. 예를 들어 핀터레스트(Pinterest)의 DESIGN.md를 넣고 이미지 갤러리 페이지를 만들어달라고 하면, 핀터레스트 특유의 둥근 모서리와 깔끔한 카드 레이아웃이 적용된 결과물이 나오는 식이죠.

물론 이 파일들은 해당 브랜드의 공개된 CSS 값을 기반으로 추출한 것이라, 그대로 쓰기보다는 출발점으로 활용하는 게 좋습니다. 마음에 드는 브랜드의 파일을 기반으로 색상과 폰트를 내 브랜드에 맞게 수정하면 됩니다. 마크다운 파일이니까 아무 텍스트 에디터에서 편집할 수 있고요.

방법 3. 직접 작성하기

이미 디자인 시스템이 잡혀 있는 팀이라면 직접 쓰는 것도 어렵지 않습니다. Figma에 정리된 디자인 토큰이나 Tailwind 설정 파일이 있다면, 그 값들을 DESIGN.md 포맷으로 옮기면 됩니다. 공식 스펙 문서가 GitHub에 공개되어 있고, 공식 스펙 문서가 GitHub에 공개되어 있고, CLI 도구도 함께 제공됩니다. 터미널에서 명령어 한 줄로 파일이 제대로 작성됐는지 검증할 수 있고, WCAG 접근성 기준에 맞는지까지 자동으로 확인 받을 수 있습니다.

어떤 에이전트에서 쓸 수 있나요?

DESIGN.md는 마크다운 파일이기 때문에 특정 도구에 종속되지 않습니다. 프로젝트 파일을 읽을 수 있는 에이전트라면 어디서든 작동합니다. 현재 Claude Code, Cursor, GitHub Copilot, Kiro, Windsurf, 그리고 Google Stitch에서 호환이 확인됐고요. 별도 플러그인이나 설정 없이, 프로젝트 루트에 파일만 넣으면 됩니다.

누구에게 좋을까요?

AI 코딩 에이전트로 UI를 자주 만드는데, 매번 디자인을 설명하는 게 번거로운 사람
디자이너 없이 사이드 프로젝트를 진행하면서, 그래도 일관된 디자인을 유지하고 싶은 사람
팀 내 디자인 시스템을 AI 에이전트에게 전달할 표준 포맷이 필요한 팀
프로토타입이나 MVP를 빠르게 찍어내야 하는데, 범용적인 UI에서 벗어나고 싶은 사람

반대로 이미 Figma 기반 디자인 시스템이 잘 갖춰져 있고 AI 에이전트를 쓸 계획이 없다면 당장 필요하지는 않겠습니만, DESIGN.md 규격 자체가 아직 알파 단계이고, Google이 업계 표준으로 만들려는 움직임을 보이고 있어서 흐름은 지켜볼 만합니다.

DESIGN.md 공식 문서: stitch.withgoogle.com/docs/design-md/overview
DESIGN.md GitHub 레포: github.com/google-labs-code/design.md
getdesign.md (브랜드별 DESIGN.md 모음): getdesign.md
awesome-design-md GitHub 레포: github.com/VoltAgent/awesome-design-md

2. 참고할 것: 10년차 빌더가 제품을 만들기 전, 확인하는 세 가지 기준

10년간 여러 제품을 만들어온 개발자 Jordan Lord가 자신의 블로그에 올린 글입니다. 이 글은 해커뉴스에 공유되며 나름의 화제가 됐는데요. 제품을 만들기 전에 반드시 통과해야 하는 세 가지 제을 제시하고, 하나라도 통과하지 못하면 만들지 않는다는 원칙을 공유합니다.

이 글이 반응을 얻은 건 아마 많은 빌더들이 겪는 공통적인 문제를 건드렸기 때문일 겁니다. 뭔가 만들고 싶은 아이디어는 많은데, 만들다 보면 범위가 커지고, 정체성이 흐려지고, 결국 아무도 안 쓰는 제품이 되는 경험. 이 글은 그 문제를 만들기 전 단계에서 잡는 방법을 이야기합니다.

기존 제품 판단 방식과 무엇이 다른가요?

보통의 사람들은 제품 아이디어를 평가할 때는 시장 크기, 경쟁자 분석, 사용자 니즈 같은 요소를 따집니다. 하지만 Jordan Lord의 접근은 방향이 조금 다릅니다. 아이디어가 좋은지 나쁜지를 판단하는 게 아니라, 만들 준비가 됐는지 안 됐는지를 판단하는 필터입니다. 그래서 세 가지 제약 모두 아이디어의 가치가 아니라 아이디어의 상태를 봅니다. 충분히 정리됐는가, 누적 가능한 구조인가, 정체성이 있는가. 같은 것들입니다.

세 가지 제약은 무엇인가요?

제약 1. 한 페이지를 넘기면 만들지 않는다

모든 아이디어는 한 장짜리 문서(one pager)로 정리해야 합니다. 이 문서가 north star(제품의 방향을 잡아주는 기준점) 역할을 하고요. 투자자한테도, 팀원한테도, 친구한테도 같은 문서를 보여줄 수 있어야 합니다.

핵심은 양쪽 극단을 모두 필터링한다는 점입니다. 한 페이지를 채우지 못했다면 아직 만들 준비가 안 된 거라고 하죠. 더 조사하고, 간단하게라도 만들어보고, 다시 써야 한다고요. 반대로 한 페이지를 넘어갈 정도라면 너무 복잡한 거라고 하죠. 협업에서도 이 문서가 기준이 됩니다. 의견 충돌이 생겼을 때, one pager에 없는 내용이라면 싸울 가치가 없고, 정말 중요하다면 문서를 수정해서 반영하면 된다고요.

제약 2. 핵심 기술은 제품과 분리되어야 한다

제품 자체와 별개로, 그 제품을 떠받치는 core tech(제품이 바뀌어도 남는 핵심 기술 자산)를 함께 만들어야 합니다. 이 core tech는 현재 제품이 없어져도 살아남을 수 있어야 하고요.

왜 이게 중요한지는 예시를 보면 바로 이해됩니다. Linus Torvalds가 Linux 커널 개발 워크플로를 개선하려고 만든 게 git이에요. Linux가 아니더라도 git은 살아남잖아요. HashiCorp의 HCL, Google의 Kubernetes도 마찬가지고요.

꼭 이런 대규모 프로젝트일 필요는 없습니다. 코드베이스에서 분리한 라이브러리, 계속 다듬어가는 방법론도 core tech가 될 수 있어요. 요점은 제품이 방향을 바꾸더라도 축적이 끊기지 않는 구조를 만들라는 겁니다. 피봇은 흔한 일이지만, 피봇할 때마다 모든 걸 처음부터 다시 시작하면 누적의 이점이 사라지니까요.

제약 3. 하나의 결정적 제약이 제품을 규정해야 한다

제품의 중심에 사용자가 항상 마주치는 하나의 defining constraint(제품의 정체성을 규정하는 핵심 제약)가 있어야 합니다. 이 제약이 제품의 정체성을 만들고, 사용자 경험 전반에 스며드는 거죠.

Minecraft는 블록만으로 세상을 만들 수 있습니다. IKEA는 납작한 상자에 담긴 자가 조립 가구죠. 이 제약을 들으면 제품의 느낌이 바로 떠오르잖아요. 잘 설계된 제약이 있으면 디자인은 그 제약에서 자연스럽게 따라 나온다는 게 Jordan Lord의 주장입니다.

해커뉴스 댓글에서 한 사용자는 이걸 product primitives(제품 전체를 구성하는 가장 작은 기본 단위)라는 개념으로 연결했는데요. Notion의 블록, Figma의 프레임과 레이어, Twitter의 트윗, Excel의 셀이 모두 같은 구조라는 거예요. 제품의 중심에 있는 하나의 기본 단위가 전체 경험을 규정한다는 점에서 맥이 닿습니다. 반대로 이 제약을 정하지 않거나 잘못 정하면, 모든 걸 하려는 비대한 제품이 된다고 합니다.

무엇을 얻어가야 하나요?

이 글의 가치는 프레임워크 자체보다 태도에 있다고 봅니다. 세 가지 제약 중 하나라도 통과하지 못하면 만들지 않는다는 원칙이요. AI 덕분에 만드는 속도가 빨라진 만큼, 만들지 말아야 할 것을 거르는 기준도 더 중요해지고 있으니까요.

모든 제품에 이 프레임워크가 딱 맞는 건 아닐 수 있습니다. 특히 core tech 분리는 초기 탐색 단계에서는 과한 요구일 수 있고, B2B SaaS처럼 범위가 넓어질 수밖에 없는 제품에서는 defining constraint가 좁은 게 오히려 제약이 될 수도 있습니다. 해커뉴스 댓글에서도 이런 반론이 나왔고요. 그래도 만들기 전에 세 가지 질문을 스스로에게 던지는 습관은 가져갈 만합니다.

한 페이지로 정리할 수 있는가? 피봇해도 살아남는 게 있는가? 이 제품의 정체성을 한 문장으로 말할 수 있는가?

원문: jordanlord.co.uk/blog/3-constraints
해커뉴스 토론: news.ycombinator.com/item?id=47903541

3. 적용해볼 것: 앤트로픽 Claude Code 제품 총괄이 말하는, AI 시대 PM의 희소 능력

Cat Wu는 앤트로픽에서 Claude Code와 Co-work의 프로덕트를 이끌고 있는 제품 총괄입니다. 최근 Lenny's Podcast에 출연해서 앤트로픽 프로덕트 팀이 어떻게 일하는지, AI 시대에 PM에게 필요한 능력이 무엇인지를 공유했는데요. 이 에피소드는 현재 Lenny's Podcast의 최근 영상 중 가장 빠르게 조회수가 올라가고 있는 영상 중 하나입니다.

흥미로운 건 인터뷰 전반을 관통하는 메시지가 하나라는 점인데요. 코드가 싸지면, 무엇을 만들지 결정하는 능력의 가치가 올라간다. Cat Wu는 이걸 product taste라고 부릅니다.

무슨 문제를 해결하려 하나요?

AI 덕분에 만드는 속도가 올라갔습니다. 그건 모두가 체감하고 있죠. 그런데 속도가 올라간 세계에서 PM은 뭘 해야 하는 건지, 엔지니어와 PM의 경계가 흐려지면 PM의 존재 이유가 뭔지, 이런 질문에는 아직 명확한 답이 없습니다.

Cat Wu는 실제로 수백 명의 PM을 인터뷰하고 있다고 합니다. 그리고 많은 지원자들이 AI 시대의 PM 역할을 잘못 이해하고 있다고 느낀다고요. 기존처럼 6~12개월 로드맵을 짜고, 팀 간 조율에 시간을 쓰는 방식으로 접근하는 사람들이 많다는 겁니다.

속도는 어떻게 만들어졌나요?

앤트로픽 프로덕트 팀의 출시 속도는 이례적입니다. Cat Wu에 따르면, 피처 출시 타임라인이 6개월에서 1개월로, 다시 1주로, 때로는 하루로 줄었다고 합니다. 이 속도를 가능하게 만든 건 세 가지 구조입니다.

첫째, 거의 모든 피처를 Research Preview로 먼저 출시합니다. 사용자에게 이건 초기 제품이고, 피드백을 받기 위한 단계라는 걸 명확히 알린 뒤 출시하는 거예요. 이렇게 하면 출시에 대한 부담이 줄어들어서, 1~2주 만에 뭔가를 내보낼 수 있게 됩니다.
둘째, 엔지니어링-마케팅-문서화 사이의 프로세스가 매우 타이트합니다. 엔지니어가 내부 테스트를 마친 피처를 evergreen launch room이라는 채널에 올리면, 마케팅과 문서 팀이 바로 다음 날 발표를 준비하는 구조라고 해요. PM의 역할은 이 흐름이 막히지 않도록 만드는 것이고요.
셋째, 팀 전체가 공유하는 원칙 문서가 있습니다. 핵심 사용자가 누구인지, 왜 그들이 핵심인지, 어떤 트레이드오프를 감수할 수 있는지가 적혀 있어서, 팀원 누구나 PM에게 물어보지 않고도 스스로 판단할 수 있게 만들었다고 합니다.

빠른 세계에서 뭐가 더 중요해졌나요?

그런데 이 속도에는 비용이 따릅니다. Cat Wu가 직접 인정한 부분인데요. 제품 일관성이 떨어집니다. 기능끼리 겹치는 경우도 생기고, 새로운 사용자 입장에서는 어떤 기능을 써야 할지 헷갈릴 수 있다고요. 사용자들도 매일 트위터를 확인해야 최신 기능을 놓치지 않는다는 느낌을 받는다고 합니다.

Cat Wu는 이 맥락에서 product taste를 이야기합니다. 코드가 싸지면, 뭘 만들지 결정하는 능력이 더 중요해진다고요. GitHub 이슈에 수만 개의 요청이 쌓여 있는데, 그중 어떤 것을 만들 가치가 있는지, 만든다면 어떤 방식이 맞는지를 판단하는 능력이 가장 희소하다는 겁니다.

현재는 엔지니어링 배경이 도움이 된다고 합니다. 이걸 만드는 게 얼마나 어려운 일인지 감이 있으면, 토론 대신 그냥 한 시간 만에 만들어보는 판단을 내릴 수 있으니까요. 다만 Cat Wu는 이 역시 몇 달 뒤에는 달라질 수 있다고 덧붙였습니다. 모델 역량이 올라갈 때마다 가치 있는 스킬셋도 바뀌고 있어서, 너무 먼 미래를 예측하는 건 어렵다고요.

앤트로픽이 PM보다 product taste가 있는 엔지니어를 적극적으로 뽑고 있다는 점도 눈여겨볼 만합니다. Cat Wu 본인도 엔지니어 출신이고, 팀의 PM 대부분이 엔지니어 경험이 있으며, 디자이너들도 프론트엔드 엔지니어 출신이라고 합니다. 역할이 합쳐지는 흐름이 이미 실행되고 있는 셈이죠.

어떻게 기르나요?

Cat Wu가 인터뷰에서 공유한 방법들을 정리해보면 이렇습니다.

모델에게 실수 이유를 물어보세요.

Cat Wu가 가장 과소평가된 AI 스킬이라고 부른 방법입니다. 모델이 예상과 다르게 행동했을 때, 왜 그렇게 했는지 모델에게 직접 물어보는 거예요. 예를 들어 모델이 프론트엔드를 수정하고 테스트는 돌렸는데 실제 UI는 확인하지 않았다면, 왜 UI 확인을 안 했는지 물어보는 겁니다. 그러면 시스템 프롬프트에서 헷갈리는 부분이 있었다든지, 서브 에이전트에게 검증을 맡겼는데 그쪽에서 빠뜨렸다든지 하는 이유가 나온다고요. 이런 피드백이 쌓이면 어떤 부분을 고쳐야 모델이 더 잘 작동하는지 파악할 수 있게 됩니다.

피드백을 잘하는 5명을 찾으세요.

모든 사용자의 피드백이 같은 무게를 가지는 건 아닙니다. Cat Wu는 모델이나 제품의 품질을 정확하게 짚어내는 사람이 따로 있다고 합니다. 그런 사람 5명 정도를 찾아서 빠른 피드백 루프를 만드는 게 중요하다고요. 앤트로픽 내부에서도 새 모델이 나오면 팀 점심 시간에 한 명씩 돌아가며 모델에 대한 인상을 물어보고, 그 피드백을 기반으로 데이터에서 검증할 가설을 세운다고 합니다.

AI의 결과물을 테스트하는 기준(eval)을 만드세요.

eval은 "이 프롬프트를 넣으면 이런 결과가 나와야 한다"는 테스트 케이스입니다. 백 개를 만들 필요 없이, 10개만 잘 만들어도 충분하다고 합니다. 좋은 eval은 목표를 구체적으로 정의하고, 진행 상황을 측정하게 해주고, 부족한 부분을 보여줍니다. Cat Wu는 eval이 PM과 엔지니어 모두에게 과소평가된 스킬이라고 강조했어요.

자동화를 95%에서 멈추지 마세요.

95% 정확도의 자동화는 자동화가 아니라고 합니다. 나머지 5%를 사람이 매번 확인해야 한다면, 그건 여전히 수작업이니까요. Cat Wu 본인도 Co-work로 이메일을 자동 분류하는 워크플로를 만들고 있는데, 아직 100%에 도달하지 못해서 계속 다듬고 있다고요. 자동화를 만드는 건 직접 하는 것보다 느릴 수 있지만, 100%에 도달하면 진짜 레버리지가 생긴다는 점을 강조합니다.

프로토타입이 아니라 매일 쓰는 앱을 만드세요.

AI로 뭔가를 만들어보고 대단하다 하고 넘어가는 건 배움도 레버리지도 제한적입니다. Cat Wu는 실제로 매일 쓰는 도구를 만들어야 진짜 학습이 일어난다고 합니다. 앤트로픽 내부에서도 영업팀이 고객 맞춤 덱을 자동 생성하는 웹앱을 직접 만들어 쓰고 있고, Applied AI 팀은 Co-work로 다음 날 고객 미팅 브리핑을 자동으로 만들어둔다고요. 이런 도구들이 계속 쓰이면서 점점 더 나아지는 구조입니다.

이 인터뷰가 가리키는 한 가지 방향

이 인터뷰에서 나온 이야기들을 모아보면 하나의 패턴이 보입니다. 앤트로픽은 속도를 높이기 위해 프로세스를 줄이고, 역할 경계를 없애고, 출시 부담을 낮추는 쪽으로 움직이고 있습니다. 그리고 그 결과 더 중요해진 건 도구를 잘 쓰는 능력이 아니라, 무엇을 만들고 무엇을 만들지 않을지 판단하는 능력입니다.

Cat Wu의 좌우명도 이 맥락과 맞닿아 있는데요. Just do things. 역할에 갇히지 말고 필요한 일을 하라는 뜻이라고 합니다. 다만 아무거나 하라는 게 아니라, 제약 조건을 이해하고, 첫 번째 원칙에서 출발해서, 올바른 행동 방향을 스스로 도출한 뒤 바로 실행하라는 의미에 가깝다고요.

적용을 위해 실행해볼 수 있는 것

이번 주에 AI 에이전트가 예상과 다르게 행동한 순간이 있었다면, 왜 그렇게 했는지 모델에게 직접 물어보기. 시스템 프롬프트나 지시가 어떻게 해석됐는지 확인하면, 다음에 같은 실수를 줄일 수 있습니다.
지금 만들고 있는 자동화 중에 90~95%에서 멈춰 있는 게 있다면, 이번 주에 시간을 내서 100%를 향해 한 단계 더 밀어보기. 되는 만큼만 쓰는 것과 완전히 맡기는 건 레버리지가 전혀 다릅니다.
AI로 만든 프로토타입 중에 한 번 써보고 끝낸 게 있다면, 그중 하나를 골라 매일 쓰는 도구로 키워보기. 매일 쓰면서 부딪히는 문제를 고치는 과정이 가장 빠른 학습입니다.

영상: Lenny's Podcast - 앤트로픽의 제품 팀이 다른 어떤 팀보다 빠르게 움직이는 비결 | 캣 우

정리

이번 주 세 소재를 관통하는 키워드는 구조화된 판단입니다.

DESIGN.md는 디자인 규칙을 파일 하나로 구조화해서 AI가 매번 추측하지 않게 만듭니다. 3 Constraints는 만들기 전에 세 가지 필터를 거는 구조로 복잡하거나 정체성 없는 제품을 걸러냅니다. Cat Wu가 말하는 product taste는 만들 수 있는 것이 넘쳐나는 세계에서 무엇을 만들지 판단하는 구조를 자기 안에 갖추라는 이야기고요.

AI가 실행 속도를 올려줄수록, 우리에게 판단의 구조가 없으면 빠르게 잘못된 방향으로 빠질 수 있습니다. 도구는 계속 바뀌겠지만, 무엇을 만들지, 왜 이 규칙인지, 어디서 멈출지를 정하는 건 여전히 사람의 몫이니까요.

이렇게 적용해보세요

DESIGN.md를 한 번 만들어보세요. getdesign.md에서 마음에 드는 브랜드 파일을 가져와 내 프로젝트에 맞게 수정하는 것부터 시작할 수 있습니다. 매번 디자인을 설명하는 시간이 줄어드는 걸 체감하게 됩니다.
지금 진행 중인 프로젝트를 one pager로 정리해보세요. 한 페이지 안에 담기는지, 이 제품의 defining constraint가 뭔지 써보는 것만으로도 범위가 잡히는 경우가 많습니다.
내가 반복적으로 하고 있는 작업 중 하나를 골라 AI 자동화를 시작해보세요. 90%에서 멈추지 말고 100%를 향해 밀어보는 게 핵심입니다.

다음 주에도 여러분이 놓치지 말아야 할 프로덕트 메이커 소식을 정리해서 찾아뵙겠습니다. 요즘 프로덕트 메이커 콘텐츠가 도움이 되셨다면, 꼭 작가 알림 설정을 부탁드립니다. 콘텐츠 내용 중 잘못된 정보나 정정이 필요한 부분이 있다면 댓글로 알려주세요. 빠르게 수정하겠습니다. 다음 주에 또 만나요!