Product

이 주제의 항목 · 21

• 공감하는 제품 만들기: 경청 세션과 스트레스 케이스공감은 친절이 아니라 상대의 사고 흐름을 이해하는 기술이다. 표면 의견 밑의 이유와 망설임을 듣는 경청 세션 진행법, 엣지 케이스를 스트레스 케이스로 바꿔 보는 관점, 사전 부검으로 해로운 시나리오를 미리 찾는 법을 정리했다.
• 기능 공장: 출시량이 아니라 결과를 보는 팀기능을 많이 내보내는 것을 성과로 착각하는 팀을 기능 공장이라 부른다. 측정·회고·사후 점검이 없고 로드맵이 기능 목록인 12가지 신호로 진단하고, 출력(output) 대신 결과(outcome)와 학습을 기준으로 일하도록 바꾼다.
• 기술 부채기술 부채는 지금 빠른 길을 택한 대가로 나중에 치르는 추가 작업이다. 원금(고치는 비용)과 이자(고치지 않아 매번 더 드는 비용)로 생각하고, 파울러의 사분면으로 원인을 나누며, 백로그 항목으로 보이게 만든 뒤 이자가 큰 곳부터 갚는다.
• 디자이너와 함께 일하기: 역할·채용·협업그래픽·인터랙션·UX 디자인의 차이, 디자이너를 뽑기 전에 정할 권한과 성공 기준, 서로 다른 관점을 섞는 팀 구성(경쟁가치모형), 디자이너·개발자·고객·브랜드 에이전시가 함께 일하는 원칙을 정리했다.
• 백로그와 추정: 에픽·사용자 스토리·스토리 포인트큰 목표를 에픽과 사용자 스토리로 쪼개고(3C, INVEST, 인수 기준), 스토리 포인트와 플래닝 포커로 상대 크기를 추정하고, 속도와 번다운·번업 차트로 진척을 본다. 각 도구는 계획을 돕는 설명 지표이지 성과 지표가 아니라는 점이 핵심이다.
• 사용자 리서치: 방법 고르기, 페르소나·시나리오, 사용성 평가더블 다이아몬드의 단계마다 맞는 리서치 방법이 다르다. 사용자를 직접 못 만나면 리뷰·상담 기록·포럼을 쓰고, 조사 결과는 근거 있는 페르소나와 사용 전·중·후 UX 시나리오로 정리해 UX 전략으로 잇는다. 화면은 닐슨의 10가지 휴리스틱 평가와 5명 단위 사용성 테스트로 검증하고, 큰 조직에서는 정기 세션으로 학습 문화를 만든다. 급할수록 맥락·분석 시간·자기 디자인에 대한 애착을 경계하고, 참가자 보호를 위한 윤리 절차를 갖춘다.
• 상세페이지 9단계 구조상세페이지는 고객이 의심을 하나씩 풀며 구매 버튼까지 스크롤을 내리게 하는 싸움이다. 유입과 전환, 세일즈 퍼널을 바탕으로 판매 증거 → 판매 관리 → 인증 → 메인 이미지 → 문제 → 상세 이미지 → 공감 → 액션 → 상세 정보의 9단계를 고객의 질문 순서로 정리하고, 강점을 위로 올리는 조정법과 표시·광고 규정, 접근성 주의점을 덧붙인다.
• 새 서비스 개발 프로젝트 진행 순서기획 → 개발 기반 구축 → 개발 진행 → 서비스 진화의 기승전결로 정리한 서비스 개발 절차.
• 스크럼: 책임·이벤트·산출물스크럼은 한 달 이하의 스프린트 안에서 투명성·검토·적응을 반복하는 가벼운 프레임워크다. 세 가지 책임(PO·스크럼 마스터·개발자), 다섯 가지 이벤트, 세 가지 산출물과 각각의 약속(제품 목표·스프린트 목표·완료의 정의)으로 구성된다. 2020년판 스크럼 가이드 기준으로 정리하고, 흔히 잘못 알려진 운영 방식을 함께 짚었다.
• 스포티파이 모델: 스쿼드·트라이브·챕터·길드와 그 한계자율적인 교차 기능 팀(스쿼드)을 트라이브로 묶고 직군별 챕터·길드로 가로지르는 매트릭스 조직 모델. 자율이 정렬보다 앞서고, 엔지니어링 책임자가 팀 밖에 있고, 협업 기술을 가정만 한 탓에 잘 작동하지 않았다. 모델을 통째로 들여오지 말고 책임 구조와 정렬 장치부터 설계한다.
• 애자일과 스프린트애자일의 핵심은 만들고-보여주고-피드백 받고-방향을 맞추는 주기를 모두가 함께 짧게 만드는 것이다. 스프린트는 목표를 쳐내는 마감 장치가 아니라 정해진 주기마다 속도와 방향을 점검하는 장치이며, 일정은 미리 예측하지 말고 만들어 보며 측정한다. 구글 스프린트 5일 구성과 장치들, 폭포수와 애자일을 고르는 기준도 함께 정리했다.
• 유스케이스 다이어그램UML 유스케이스 다이어그램으로 시스템이 누구에게 어떤 기능을 제공하는지 한 장에 그려 범위를 합의하는 법. 액터·유스케이스·시스템 경계, 연관·일반화·include·extend 관계, 작성 4단계, 정상·대안·예외 흐름과 시나리오를 담는 유스케이스 명세, 흔한 실수를 정리한다.
• 제품 중심 개발자 (Product-Minded Engineer)기획을 구현만 하지 않고 제품의 이유를 묻고, 제품·엔지니어링 트레이드오프를 함께 제안하며, 출시 후 데이터까지 책임지는 개발자의 9가지 특징과 성장 방법. 목적 조직에서 개발자가 맡는 역할과 OKR·애자일의 관계까지.
• 조직의 디지털 전환과 웹 거버넌스디지털 전환은 기술 도입이 아니라 고객 행동 변화에 조직을 맞추는 일이다. 디지털 성숙도 5단계, 웹 거버넌스의 네 영역(전략·관리·실행·측정), 권한 없는 실무자가 변화를 이끄는 방법을 정리했다.
• 초기 스타트업과 창업: 개발자가 빠지기 쉬운 함정초기 스타트업 엔지니어는 아키텍처부터 고객 대화·온콜·채용까지 맡는다. 개발자가 창업할 때는 기술 중심 피벗, 복잡한 사업 모델, 장인 정신이라는 세 함정을 피하고, 작은 제품을 빨리 내서 검증 횟수를 늘린다.
• 칸반과 린: 흐름과 낭비린은 고객 가치를 기준으로 낭비를 없애고 흐름을 만드는 사고방식이고, 칸반은 그것을 일에 적용해 보드로 시각화하고 진행 중인 일(WIP)을 제한해 당기는 흐름을 만드는 방법이다. 칸반·스크럼·스크럼반 비교, 흐름 지표와 리틀의 법칙, 낭비 유형, 가치 흐름 매핑, 병목과 제약 이론, 카이젠·PDCA를 정리했다.
• 콘텐츠 전략과 핵심 모델콘텐츠는 목적·핵심 메시지·다음 궁금증·운영 계획을 갖춰야 전략이 된다. 메인 페이지가 아니라 사업 목표와 사용자 작업이 겹치는 핵심 페이지부터 설계하는 핵심 모델(core model)과 워크숍 진행법을 정리했다.
• 투자자가 보는 IR 자료: 시장·비즈니스 모델·숫자스타트업이 기관 투자를 받을 때 거치는 실사에서 투자자가 듣고 싶은 것. 회사 소개보다 시장(TAM)과 성장, 좁혀 말한 비즈니스 모델, 경영진이 보는 지표와 숫자로 표현한 고객, 유닛 이코노믹스와 성장 요인을 쪼갠 브리지 분석, 고정비·변동비와 재무 계획, 약점의 솔직한 공개, ESG를 숫자로 설명하는 법을 정리한다.
• BDD·SDD로 기획서를 태스크로 나누기기획·디자인·개발·QA가 같은 문서를 보도록 기획을 사용자 행동(BDD의 given-when-then)과 데이터 구조(SDD)로 정리해 태스크를 만드는 방법. then 하나가 태스크 하나가 되어 진척도·일정·테스트 범위가 함께 보이고, Figma에 디자인과 기획을 합쳐 두면 최신 화면까지 한곳에서 관리된다.
• EoA: 불확실성을 다루는 애자일 메커니즘EoA(Essence of Agility, 기민함의 맥)는 정해진 실천법을 따라 하는 대신, 불확실할 때 효과적인 메커니즘을 이해하고 맥락에 맞는 실천법을 스스로 설계하게 하는 프레임워크다. 네 가지 상위 목표, 결과 관찰 질문(OOQ), 병목 정의, 팀 템플릿과 세션 운영법을 정리했다.
• Shape Up: 6주 사이클 제품 개발 방식Basecamp가 만든 제품 개발 방식. 견적 대신 투입할 시간의 상한(appetite)을 먼저 정하고, 거칠지만 위험을 제거한 형태(shape)로 다듬은 피치를 베팅 테이블에서 골라 6주 동안 팀에 맡긴다. 백로그를 두지 않고, 시간이 다 되면 범위를 줄여서라도 끝낸다.