<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Steve Kim</title>
  <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE" />
  <author>
    <name>ceoxino</name>
  </author>
  <subtitle>두 번의 창업, 성공과 실패를 경험하고 지금은 PO로 일하고 있습니다. 저서 : 프로덕트 개발의 모든 것.</subtitle>
  <id>https://brunch.co.kr/@@1XsE</id>
  <updated>2016-05-15T02:27:53Z</updated>
  <entry>
    <title>작은 일로 싸우는 세계에서 느끼는 이질감 - 이렇게까지 싸울 일인가?</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/107" />
    <id>https://brunch.co.kr/@@1XsE/107</id>
    <updated>2026-01-19T03:42:54Z</updated>
    <published>2026-01-19T03:42:54Z</published>
    <summary type="html">작은 일로 싸우는 세계에서 느끼는 이질감  누군가는 지금 이 순간에도 화성으로 사람을 보내는 방법을 고민하고 있다. 생존 가능한 환경은 무엇인지, 자원은 어떻게 확보할 것인지, 수십 년 뒤를 전제로 한 기술과 조직을 설계한다. 인간이 지구 밖에서도 살아갈 수 있는가라는 질문은, 그 자체로 인류의 시간 스케일을 전제로 한다.  그런데 다시 고개를 돌리면, 이</summary>
  </entry>
  <entry>
    <title>Outlining Session - 실행을 향한 첫 합의</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/106" />
    <id>https://brunch.co.kr/@@1XsE/106</id>
    <updated>2025-10-15T16:00:01Z</updated>
    <published>2025-10-15T16:00:01Z</published>
    <summary type="html">Outlining Session - 실행을 향한 첫 합의  Outlining Session은 제품 개발의 출발점이자, 실행을 위한 첫 정렬의 장입니다. 이 세션은 단순한 아이디어 회의가 아닙니다. 문제 정의(Problem Definition),&amp;nbsp;범위 설정(Scoping),&amp;nbsp;구조화(Structuring), 프로토타이핑(Prototyping)까지 이 네 가지</summary>
  </entry>
  <entry>
    <title>Structuring - 아이디어를 풀어내기</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/105" />
    <id>https://brunch.co.kr/@@1XsE/105</id>
    <updated>2025-10-14T15:00:07Z</updated>
    <published>2025-10-14T15:00:07Z</published>
    <summary type="html">Structuring - 아이디어를 풀어내기  1주, 3주, 6주라는 기간 안에서 해결해야 할 문제의 범위가 정해졌다면, 이제 아이디어를&amp;nbsp;구체적인 소프트웨어 구성 요소로 풀어내는 단계, 즉 Structuring이 필요합니다. 이 단계는 단순히 그림을 그리는 일이 아니라,&amp;nbsp;&amp;ldquo;어떤 뼈대 위에 기능이 올라갈 것인가&amp;rdquo;를 탐색하는 과정입니다.  화면보다 구조, 형태</summary>
  </entry>
  <entry>
    <title>스프린트의 2주, 왜 문제인가 - 새로운 개발 사이클 Adaptive cycle</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/104" />
    <id>https://brunch.co.kr/@@1XsE/104</id>
    <updated>2025-10-13T15:00:07Z</updated>
    <published>2025-10-13T15:00:07Z</published>
    <summary type="html">스프린트의 2주, 왜 문제인가  많은 제품팀이 스프린트를 이야기할 때 거의 자동처럼 &amp;ldquo;2주 단위&amp;rdquo;를 떠올립니다. 애자일의 기본 교재에서 권장하는 기간이기도 하고, 대부분의 관리 툴에서&amp;nbsp;기본값으로 설정된 옵션이기도 합니다. 그러나 실제 제품 개발의 현실에서 이 2주 주기는 오히려&amp;nbsp;불균형과 비효율을 낳는 구조로 작동합니다.  1. 애매한 기간, 불완전한 결과</summary>
  </entry>
  <entry>
    <title>왜 1주&amp;middot;3주&amp;middot;6주인가 - 새로운 사이클</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/103" />
    <id>https://brunch.co.kr/@@1XsE/103</id>
    <updated>2025-10-12T15:00:13Z</updated>
    <published>2025-10-12T15:00:13Z</published>
    <summary type="html">왜 1주&amp;middot;3주&amp;middot;6주인가  제품팀이 일하는&amp;nbsp;리듬은 곧 조직의 학습 속도를 결정합니다. 주기가 너무 짧으면 항상 눈앞의 태스크 처리에 쫓기게 되고, 너무 길면 방향이 틀린 채 리소스를 낭비할 위험이 커집니다.  그래서 Adaptive Cycle은&amp;nbsp;1주&amp;middot;3주&amp;middot;6주라는 세 가지 호흡을 제안합니다. 이 조합은 팀이 상황에 맞게 속도를 조절하면서도,&amp;nbsp;학습과 실행을 균</summary>
  </entry>
  <entry>
    <title>Scoping&amp;nbsp; - 범위 설정하기</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/102" />
    <id>https://brunch.co.kr/@@1XsE/102</id>
    <updated>2025-10-11T15:00:10Z</updated>
    <published>2025-10-11T15:00:10Z</published>
    <summary type="html">Scoping - 범위 설정하기  Outlining 과정에서 문제 정의가 마무리되어 갈 때쯤, 우리는 자연스럽게 좋은 솔루션을 떠올리게 됩니다. 회의나 대화 중에 새로운 아이디어가 나오면 본능적으로 &amp;ldquo;좋다, 해보자&amp;rdquo; 혹은 &amp;ldquo;지금은 어렵다&amp;rdquo;라는 반응이 나옵니다. 그리고 곧바로 실행 논의로 넘어가곤 합니다. 하지만 이때 잠시 멈춰서 스스로에게 이렇게 물어보는</summary>
  </entry>
  <entry>
    <title>Problem Definition - 제품의 출발점</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/101" />
    <id>https://brunch.co.kr/@@1XsE/101</id>
    <updated>2025-10-10T15:00:20Z</updated>
    <published>2025-10-10T15:00:20Z</published>
    <summary type="html">Problem Definition  제품의 출발점은 기능이나 화면이 아니라&amp;nbsp;문제 정의입니다. 문제를 명확히 정의하지 않은 실행은 분주함만 남기고, 성과는 남기지 않습니다.  문제는 어디에나 존재합니다. 고객센터의 불만, 전환율이 떨어진 대시보드, 영업 현장의 망설임, 마케팅 효율 저하 등 모든 것이 신호가 됩니다. 그러나 이 신호들은 문제 그 자체가 아닙니&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.daumcdn.net%2Fbrunch%2Fservice%2Fuser%2F1XsE%2Fimage%2F92Rusf1AGOWAQWfC8KoQFTN57M4.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>About Adaptive Cycle Framework - 제품 개발의 균형을 되찾는 새로운 실행 체계</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/100" />
    <id>https://brunch.co.kr/@@1XsE/100</id>
    <updated>2025-10-10T14:04:27Z</updated>
    <published>2025-10-10T14:04:27Z</published>
    <summary type="html">Adaptive Cycle은 스프린트를 비롯한 기존 애자일 방법론과 린 철학을 기반으로 하며, 최근 등장한 Shape Up Framework의 장점과 한계를 보완하기 위해 제안된 새로운 방법론입니다. 각 방법론의 강점을 살리고 약점을 극복하기 위해 만들어진, 일종의&amp;nbsp;하이브리드 실행 체계라고 할 수 있습니다. 먼저 그 배경부터 살펴보겠습니다.  제품을 만든다</summary>
  </entry>
  <entry>
    <title>우리는 데이터 기반으로 일합니다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/99" />
    <id>https://brunch.co.kr/@@1XsE/99</id>
    <updated>2025-09-24T12:00:02Z</updated>
    <published>2025-09-24T12:00:02Z</published>
    <summary type="html">&amp;ldquo;우리는 데이터 기반으로 일합니다&amp;rdquo;라고 말하지만, 실제로는 직관과 습관, 개인의 의견에 더 많이 의존한다. 회의에서는 &amp;ldquo;내 생각에는&amp;rdquo;이라는 말이 더 자주 등장하고, 리더의 경험이나 직급이 판단의 근거가 되는 일이 반복된다. 그러나 데이터 기반이란 단순히 숫자를 확인하는 것이 아니라, 모든 판단과 실행이 데이터를 참고하고 그 해석 과정을 거쳐 이루어진다는 것</summary>
  </entry>
  <entry>
    <title>살아있는 미션, 비전과 정렬된 조직</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/98" />
    <id>https://brunch.co.kr/@@1XsE/98</id>
    <updated>2025-09-23T12:00:04Z</updated>
    <published>2025-09-23T12:00:04Z</published>
    <summary type="html">조직은 다양한 배경과 역량을 가진 사람들이 모여 하나의 결과를 만들어내는 집합체다. 그러나 이들이 같은 이유로 같은 목표를 향해 움직이지 않는다면 조직은 하나의 엔진이 아니라 서로 다른 방향으로 돌아가는 모터들의 모음일 뿐이다. 겉으로는 모두가 열심히 일하지만 결과는 충돌하거나 흩어진다. 정렬이란 이 모터들이 같은 방향으로 회전하게 만드는 과정이자 상태다.</summary>
  </entry>
  <entry>
    <title>잘 세워진 전략의 조건</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/97" />
    <id>https://brunch.co.kr/@@1XsE/97</id>
    <updated>2025-09-22T11:25:25Z</updated>
    <published>2025-09-22T11:25:25Z</published>
    <summary type="html">전략이라는 단어는 흔히 멋있고 거창한 말로 포장된다. 많은 조직이 전략을 세운다고 말하지만, 실제로 그 전략이 조직을 움직이는 경우는 드물다. 이유는 단순하다. 전략이 구호로만 남거나 너무 모호해서 실행으로 이어지지 못하기 때문이다. 그렇다면 잘 세워진 전략은 무엇일까? 그것은 두꺼운 보고서나 정교한 계획이 아니라, 오늘 조직이 무엇을 해야 할지를 명확히</summary>
  </entry>
  <entry>
    <title>존재 이유와 도착점 - 방향(方)과 전략(略)</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/96" />
    <id>https://brunch.co.kr/@@1XsE/96</id>
    <updated>2025-08-27T05:15:56Z</updated>
    <published>2025-08-27T05:15:56Z</published>
    <summary type="html">모든 조직은 언젠가 자기 존재의 이유를 묻는다. 왜 우리는 여기에 있는가. 무엇을 위해 매일 같은 회의를 반복하고, 수많은 결정을 내리며, 끝없는 기능을 만들고 고치고 있는가. 이 질문에 답하지 못한다면, 아무리 훌륭한 전략과 전술을 갖추어도 결국 그 모든 활동은 공허해진다. 미션과 비전은 바로 이 질문에 답하는 언어다. 미션은 조직이 존재하는 이유다. 고</summary>
  </entry>
  <entry>
    <title>선언이 아닌 실행이 되는 문장의 조건 - 方略 방략 - 방향(方)과 전략(略)</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/95" />
    <id>https://brunch.co.kr/@@1XsE/95</id>
    <updated>2025-08-27T05:15:00Z</updated>
    <published>2025-08-14T03:50:57Z</published>
    <summary type="html">&amp;ldquo;우리 미션은 좋긴 한데&amp;hellip; 딱히 쓸 일은 없어요.&amp;rdquo; 많은 구성원들이 이렇게 말한다. 이 정도의 피드백도 사실 대단한 것이다. 대부분은 회사의 미션 따위는 신경 쓰지 않는 게 일반적이다. 물론 규모에 따라 다르기도 하겠지만 미션을 이해하는 것에 앞서 &amp;lsquo;알고 있는 구성원&amp;rsquo; 수 자체가 많지 않은 게 현실이다. &amp;ldquo;좋은 말이긴 해요. 근데 실제로 의사결정할 땐 안</summary>
  </entry>
  <entry>
    <title>방향과 방법 사이를 연결하는 설계 - 方略 방략 - 방향(方)과 전략(略)</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/94" />
    <id>https://brunch.co.kr/@@1XsE/94</id>
    <updated>2025-08-13T15:00:15Z</updated>
    <published>2025-08-13T15:00:15Z</published>
    <summary type="html">전략 없이도 일은 된다. 하지만 오래가지 않는다. 스타트업에서 우리는 흔히 이런 장면을 마주하게 된다. &amp;lsquo;열심히 일하는 팀, 매일 업데이트되는 칸반 보드, 각자 맡은 기능을 책임지고 릴리스하는 개발자와 디자이너, 일주일 단위의 스프린트와 회고&amp;rsquo; 일의 과정을 겉으로 보기엔 무척 생산적이다. 그러나 왜 이 기능을 만드는지, 어떤 목표를 향해 가는지는 아무도 말</summary>
  </entry>
  <entry>
    <title>순환과 재정의의 흐름을 읽는 사고 - 배움</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/93" />
    <id>https://brunch.co.kr/@@1XsE/93</id>
    <updated>2025-08-12T13:38:40Z</updated>
    <published>2025-08-12T13:38:40Z</published>
    <summary type="html">모든 제품이 &amp;lsquo;도입 &amp;rarr; 성장 &amp;rarr; 성숙 &amp;rarr; 쇠퇴&amp;rsquo;를 따르진 않는다. 우리는 제품 생애주기를 교과서처럼 배운다. 처음에는 도입기, 그다음은 성장기, 성숙기, 그리고 쇠퇴기. 그러나 현실은 그렇게 깔끔하게 흐르지 않는다. 어떤 제품은 도입기 없이 한순간에 폭발적인 반응을 얻기도 하고, 또 다른 제품은 성장기에서 수년간 머물다 갑자기 쇠퇴한다. 또 다른 제품은 성</summary>
  </entry>
  <entry>
    <title>제품의 나이에 따라 PO의 역할도 달라진다 - 제품, 전략, 비전</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/92" />
    <id>https://brunch.co.kr/@@1XsE/92</id>
    <updated>2025-08-06T13:00:02Z</updated>
    <published>2025-08-06T13:00:02Z</published>
    <summary type="html">제품에도 나이가 있다. 태어나고, 성장하고, 정체되고, 쇠퇴한다. 마치 사람처럼. 그런데 많은 제품 관리자들은 이 모든 단계를 같은 방식으로 관리하려고 한다. 아이에게 어른의 기준을 요구하거나, 노인에게 청년의 속도를 강요하는 것과 다르지 않다. 제품의 생애주기를 이해하지 못한 채 일하면, PO의 역할도, 팀의 판단도, 조직의 전략도 왜곡된다. 결과적으로</summary>
  </entry>
  <entry>
    <title>배우면서 성장하는 구조 - 배움</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/91" />
    <id>https://brunch.co.kr/@@1XsE/91</id>
    <updated>2025-08-05T13:00:02Z</updated>
    <published>2025-08-05T13:00:02Z</published>
    <summary type="html">가끔 모임에서 만나는 창업자들은 스스로 &amp;ldquo;내가 전문가가 아니어서 투자를 못 받을까 봐 걱정된다&amp;rdquo;는 말을 많이 하곤 한다. 그도 그럴 것이 일부 창업자가 학업을 통해 이미 전문성을 어느 정도 갖추고 있거나 관련 분야에서 오랜 기간 일을 해오면서 &amp;lsquo;전문가&amp;rsquo;로 인정받기도 한다. 실제 전문 자격을 갖춘 사람이 창업을 하기도 한다. 그리고 그들의 전문성은 그들이 걸</summary>
  </entry>
  <entry>
    <title>미래를 만든다는 것 - 배움</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/90" />
    <id>https://brunch.co.kr/@@1XsE/90</id>
    <updated>2025-08-04T11:00:07Z</updated>
    <published>2025-08-04T11:00:07Z</published>
    <summary type="html">창업하면서 속으로 수백 번 되새긴 말이 &amp;lsquo;참 먹고살기 어렵다&amp;rsquo;라는 것이다. 밖으로 내뱉지 않았지만 투자자와의 미팅, 백번에 가까웠던 IR은 나의 정신을 꽤나 좀먹고 있었다. 한 때는 IR(Investor Relations)이라는 행위를 하는 것만으로도 감사하기도 했다. 결국 투자를 받아야만 회사가 운영되는 상황이었다는 것은 우리 제품이 돈을 벌지 못하고 있</summary>
  </entry>
  <entry>
    <title>어제의 습관으로 내일을 만들 수는 없다 - 배움</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/89" />
    <id>https://brunch.co.kr/@@1XsE/89</id>
    <updated>2025-08-03T11:30:57Z</updated>
    <published>2025-08-03T11:30:57Z</published>
    <summary type="html">어제의 습관으로 내일을 만들 수는 없다 하나의 조직이 무너지는 데엔 의외로 거창한 이유가 필요하지 않다. 무능한 리더, 엉망인 기획, 실패한 투자, 방향 없는 실행. 이런 것들이 반복되는 동안, 사람들은 서서히 &amp;lsquo;생각&amp;rsquo;을 멈춘다. &amp;ldquo;지금은 어쩔 수 없잖아.&amp;rdquo; &amp;ldquo;나중에 잘 되면 그때 바꾸자.&amp;rdquo; &amp;ldquo;윗선에서 정리되면 우린 그에 맞춰 움직이면 돼.&amp;rdquo; 그렇게 말하면</summary>
  </entry>
  <entry>
    <title>방향 없는 실행은 팀을 소모시키고, 고객을 잃는다 - 배움</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@1XsE/88" />
    <id>https://brunch.co.kr/@@1XsE/88</id>
    <updated>2025-08-01T14:15:31Z</updated>
    <published>2025-08-01T14:14:47Z</published>
    <summary type="html">계획보다 실행을 중시하는 일부 스타트업의 문화는, 반대로 느리고 절차가 많아 비효율적이라 느껴지는 대기업의 프로세스를 경험한 사람들에게는 경이롭다는 수준의 속도로 다가온다. 그리고 이런 문화에서 상당 기간 사람들은 &amp;lsquo;일 하는 느낌&amp;rsquo;을 받는다. ​ 그런데 몇 달 지나지 않아 알게 된다. 우리는 빠르게 움직이긴 했지만, 어디로 가고 있는지는 아무도 모른다는 사</summary>
  </entry>
</feed>
