<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>일이삼사</title>
  <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@cey8" />
  <author>
    <name>work1234</name>
  </author>
  <subtitle>일 &amp;middot; 실험 &amp;middot; 배움의 기록</subtitle>
  <id>https://brunch.co.kr/@@cey8</id>
  <updated>2021-03-29T06:41:51Z</updated>
  <entry>
    <title>같은 지표를 보는데 왜 다른 이야기를 할까 - 팀마다 다른 언어로 말하던 지표를 하나의 언어로 만들기까지</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@cey8/11" />
    <id>https://brunch.co.kr/@@cey8/11</id>
    <updated>2025-12-17T08:00:12Z</updated>
    <published>2025-12-17T08:00:12Z</published>
    <summary type="html">IT 조직에서 꽤 자주 발생하는 문제 중 하나는 팀 간 언어와 지표 정의가 다를 때 생기는 혼란이다. 각자 팀마다의 이해관계가 다르고 동일한 시야를 가지고 있지 않다보니 같은 데이터를 보더라도 전혀 다른 결론에 도달하기 쉽다.  이번 글에서는 실제로 내가 경험한 &amp;ldquo;제품 사용 기준 정의 불일치 문제&amp;rdquo;를 어떻게 구조화하고, 어떻게 조직 간 Alignment를 &lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.daumcdn.net%2Fbrunch%2Fservice%2Fuser%2Fcey8%2Fimage%2FY5_R32CvBWRfdcZecjOmBSXY6oo.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>내부 구성원이 제품을 '같은 시선'에서 이해하게 만들기 - 기능 설명이 아닌 &amp;quot;왜 필요한가&amp;quot;를 중심으로 재구성한 경험</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@cey8/10" />
    <id>https://brunch.co.kr/@@cey8/10</id>
    <updated>2025-11-25T04:15:02Z</updated>
    <published>2025-11-25T04:15:02Z</published>
    <summary type="html">고객을 설득하는 사람과 제품을 만드는 사람, 고객을 돕는 사람은 종종 같은 제품을 다른 방식으로 이해한다. 나는 그 작은 차이가 세일즈 메시지, 데모 흐름, 고객 경험 전체를 뒤흔든다고 생각했다.  그래서 두 번째로 시도한 내부 정렬 작업은 &amp;quot;이 제품을 어떻게 설명해야 하는가&amp;quot;를 조직 전체가 같은 언어로 말할 수 있도록 만드는 일이었다.   문제 정의  동</summary>
  </entry>
  <entry>
    <title>프로덕트팀이 고객을 더 잘 알도록 만드는 일 - 주요 타겟 전환기에서 배운 것들</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@cey8/9" />
    <id>https://brunch.co.kr/@@cey8/9</id>
    <updated>2025-11-20T07:09:50Z</updated>
    <published>2025-11-20T07:09:50Z</published>
    <summary type="html">고객을 이해하는 것은 당연한 일처럼 보이지만, 실제로는 팀마다 &amp;lsquo;고객을 어떻게 정의하느냐&amp;rsquo;에 따라 완전히 다른 제품이 나온다. 회사 차원 전략의 주요 타겟이 SMB에서 엔터프라이즈 고객으로 전환되던 시기에 모든 팀이 겉으로는 &amp;ldquo;엔터프라이즈 공략&amp;rdquo;을 말하고 있었지만, 주요 타겟이 바뀌었다고 해서 조직의 사고방식이나 제품의 형태가 하루아침에 달라지는 건 아니다</summary>
  </entry>
  <entry>
    <title>고객 인터뷰(3) - 고객의 진짜 신호는 행동이다 - 말은 공짜지만 행동에는 비용이 든다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@cey8/8" />
    <id>https://brunch.co.kr/@@cey8/8</id>
    <updated>2025-10-09T07:15:20Z</updated>
    <published>2025-10-09T07:15:20Z</published>
    <summary type="html">왜 &amp;lsquo;말&amp;rsquo;만 믿으면 위험한가 앞선 글에서 살펴봤듯, 고객은 쉽게 이렇게 말한다. &amp;ldquo;좋은 아이디어네요.&amp;rdquo; &amp;ldquo;시장성 있어 보이네요.&amp;rdquo; &amp;ldquo;출시되면 알려주세요.&amp;rdquo;  겉보기에 긍정적이지만, 이건 아무런 리스크가 없는 말이다. 말은 공짜다. 하지만 행동에는 반드시 비용이 든다. 따라서 진짜 질문은 &amp;ldquo;고객이 실제로 움직였는가?&amp;rdquo;다.   행동 신호의 두 가지 축 고객의 &lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.daumcdn.net%2Fbrunch%2Fservice%2Fuser%2Fcey8%2Fimage%2FWL83XUEloyp5Nmqx9gk0ThJtklk.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>고객 인터뷰(2) - 쓸모없는 대답은 걸러낸다 - 칭찬, 추측, 회피는 모두 가짜 데이터다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@cey8/7" />
    <id>https://brunch.co.kr/@@cey8/7</id>
    <updated>2025-10-04T09:35:06Z</updated>
    <published>2025-10-04T09:35:06Z</published>
    <summary type="html">좋은 질문을 해도 왜 실패할까? 좋은 질문을 던졌다고 해서 안심할 수는 없다. 왜냐하면 고객이 건네는 말이 겉보기에 긍정적이지만, 실제로는 아무런 가치가 없는 경우가 많기 때문이다.  그래서 &amp;ldquo;인터뷰 n회 달성&amp;rdquo; 같은 지표가 위험하다. 아무리 많이 만나도, 가짜 데이터만 쌓이면 더 잘못된 결정을 하게 된다.   나쁜 데이터의 세 가지 유형 고객이 흔히 주는</summary>
  </entry>
  <entry>
    <title>고객 인터뷰(1) - 좋은 질문이 결과를 바꾼다 - 인터뷰 횟수가 중요한 게 아니다</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@cey8/6" />
    <id>https://brunch.co.kr/@@cey8/6</id>
    <updated>2025-10-02T10:18:54Z</updated>
    <published>2025-10-02T10:18:54Z</published>
    <summary type="html">많은 팀이 &amp;ldquo;고객 인터뷰 30회 진행&amp;rdquo; 같은 목표 지표를 세운다. 하지만 그건 함정이다. 인터뷰 횟수는 배움의 보증 수표가 아니다. 잘못된 질문을 수십 번 반복하면, 오히려 거짓된 확신만 쌓일 뿐이다.  실제로 수십 명을 만나고도 제품을 출시하면 반응이 싸늘한 경우가 많다. 문제는 인터뷰 자체가 아니라, 우리가 잘못된 질문을 던졌기 때문일 수 있다.  인터&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.daumcdn.net%2Fbrunch%2Fservice%2Fuser%2Fcey8%2Fimage%2Fmc-YQqHtWZqYbLrucVJEwWB0Rzg.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>복잡한 제품 정책이 팀을 헤매게 만들 때 - SSOT + LLM 챗봇으로 &amp;lsquo;정보 파악 비용&amp;rsquo;을 줄인 방법</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@cey8/5" />
    <id>https://brunch.co.kr/@@cey8/5</id>
    <updated>2025-09-23T11:22:19Z</updated>
    <published>2025-09-23T11:22:19Z</published>
    <summary type="html">제품이 고도화되면서 정책의 수와 복잡도는 빠르게 늘어났다. 하지만 실제 업무에서는 다음과 같은 문제가 반복됐다. 정책 히스토리와 의사결정 맥락을 아는 사람이 제한적이었다. 문서화가 되어 있어도 버전 불일치와 갱신 누락으로 신뢰성이 낮았다. 검색 시 구글 드라이브, 위키, 노션 등 다양한 저장소를 거쳐야 했고, 결과적으로 사람에게 직접 묻거나 코드 확인에 의&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.daumcdn.net%2Fbrunch%2Fservice%2Fuser%2Fcey8%2Fimage%2FudAyamKhxM4Z8Rmna5JAu3Qrcuo.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>ChatGPT로 VOC 분석하기 - AI가 드러낸 패턴, 사람이 만든 인사이트</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@cey8/4" />
    <id>https://brunch.co.kr/@@cey8/4</id>
    <updated>2025-09-22T05:17:08Z</updated>
    <published>2025-09-22T05:15:02Z</published>
    <summary type="html">고객 경험의 최전방에서 일하다 보면 끝없이 쏟아지는 VOC(Voice of Customer)를 마주하게 된다. 단순히 &amp;ldquo;얼마나 많이 들어왔는가&amp;rdquo;를 세는 건 어렵지 않다. 하지만 그 안에서 패턴을 뽑고 의미를 정리하는 건 전혀 다른 문제다. 수천 건이 모이면 사람이 일일이 분류하고 요약하는 데는 한계가 있다. 그래서 이번엔 ChatGPT를 활용하여 VOC를 &lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.daumcdn.net%2Fbrunch%2Fservice%2Fuser%2Fcey8%2Fimage%2FGCJIxaUF7krJ3xyhOFnn6EYM5FA.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>더하기(+)가 아닌 곱하기(&amp;times;): CX팀 구조 실험 - 인력 충원이 아닌, 구조 혁신으로 효율을 키운 도메인 페어링 시도</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@cey8/3" />
    <id>https://brunch.co.kr/@@cey8/3</id>
    <updated>2025-09-22T05:06:00Z</updated>
    <published>2025-09-22T05:06:00Z</published>
    <summary type="html">B2B SaaS에서 제품이 성장할수록 정책은 점점 복잡해진다. 기능은 늘어나고, 연동은 촘촘해지고, 업데이트는 쏟아진다. 업무가 몰리고 버거워질 때 가장 먼저 떠올리는 해법은 보통 &amp;ldquo;사람을 더 뽑자&amp;rdquo;는 것이다. 당시 우리 팀에서도 인원 충원이 필요하다는 이야기가 자주 나왔다.  하지만 무조건 채용이 답은 아닐 수 있다. 단순히 &amp;lsquo;더하기(+)&amp;rsquo;로 인력을 늘리&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.daumcdn.net%2Fbrunch%2Fservice%2Fuser%2Fcey8%2Fimage%2F8HZrAesz0zxHK69SbPCz_GXJkeY.png" width="500" /&gt;</summary>
  </entry>
  <entry>
    <title>고객이 길을 잃지 않는 헬프센터 만들기 - 원하는 순간에 원하는 답을 주는 헬프센터로</title>
    <link rel="alternate" type="text/html" href="https://brunch.co.kr/@@cey8/2" />
    <id>https://brunch.co.kr/@@cey8/2</id>
    <updated>2025-09-22T05:00:33Z</updated>
    <published>2025-09-22T05:00:33Z</published>
    <summary type="html">B2B SaaS 제품은 도입 자체가 복잡하고, 이후에도 조직 차원의 최적화 과정이 필요하다. 당시 팀은 이를 돕기 위해 1:1 컨설팅을 제공했지만, 기본적으로는 헬프센터를 통해 고객이 스스로 답을 찾길 기대했다.  문제는 헬프센터가 제 역할을 하지 못했다는 점이다. 원하는 내용이 문서에 있어도 고객은 찾지 못했고, 특정 기능을 쓰려해도 어디서 시작해야 할지&lt;img src= "https://img1.kakaocdn.net/thumb/R1280x0/?fname=http%3A%2F%2Ft1.daumcdn.net%2Fbrunch%2Fservice%2Fuser%2Fcey8%2Fimage%2FwSEspzMcIKfqWU-37S9JEO7WfiU.png" width="500" /&gt;</summary>
  </entry>
</feed>
