
명의 제품관리자 (PO나 PM), 1명의 디자이너, 2명의 엔지니어가 제품팀을 구성하는 최소 조건이다.
회사에 따라 데이터 애널리스트, 마케터. BO등이 있다.

기능조직
* 유사한 직무끼리 구성된 팀으로 챕터라고 불림
비슷한 일을 하는 사람들끼리 모였기 때무에 전문 분야에 대해 깊게 공부하고 서로 발전을 도모할 수 있다.

매트릭스 조직
* 구성원이 기능조직과 목적조직이 교차된 형태로 구성됨
ex) 프로덕트 디자이너는 기능조직인 팀에 속하면서 동시에 목적조직인 스쿼드에 속할 수 있다.
린스타트업
낭비를 줄이기위해 적은 리소스로 제품을 만들어서 빠르게 시장에 검증해 나가면서 기능을 고도화시키는 방법.
만들기, 측정, 학습을 반복하면서 피드백 받고 사용자 중심으로 제품을 만든다.

애자일
일정한 주기로 뻐르게 제품을 배포해 피드백을 받고 요구사항을 수정해 나가는 과정을 반복한다.1~4주의 스프린트 단위로 개발, 피드백, 테스트를 반복




문제 정의
PO/PM과 함께 우선순위가 높은 문제를 정함
아이데이션
문제를 해결한 아이디어를 내고 적절한 솔루션을 선택
프로덕트 스펙 문서 작성
디자인에 들어가기 전, 솔루션의 상세 내용을 글로 먼저 적어본다.
미리 상상하고 준비할 수 있다는 장점이 있다.
디자인
디자인을 개발할 수 있도록 엔지니어에게 전달하는 것
핸드오프 전달 내용

유저 플로우
처음 시작하는 화면부터 시작해 어떻게 연결되는지와 같은
기능의 전체 흐름이 잘 보이도록 구성한다.
유즈 케이스
시스템 동작을 사용자의 입장에서 표현한 시나리오.
회원가입 화면에서는 정상 입력, 입력값 오류, 입력 가능 시간 초과 등 다양한 상황이 생긴다. 모든 케이스에 달라지는 화면을 놓치지 않고 정의해 주어야 한다.
https://blog.naver.com/vinylx/20207250669

디자인 피드백 요청 시 포함할 것
1. 기획배경
2. 솔루션의 의도
3. 필수 리뷰어
4. 참고 문서
5. 피드백 기한
실험을 위한 제품 분석 도구

제품이 출시되기 전에 기능을 테스트 하는 것
기능을 만든 담당자라면 대부분 직접 QA한다.
체크리스트
예/아니요 같은 확인 성격의 항목
테트리스 시나리오
사용가자 기능을 사용하면서 경험하게 되는 과정을 상세하게 적음

테트리스 케이스

디자인 QA
잘못된 부분을 엔지니어가 정확하게 알 수 있도록 작성해야 한다.
지라나 트렐로 같은 프로젝트 관리 툴을 사용한다면 관리하기 좋게 발견한 이슈를 업무 티켓으로 전달하는 것을 추천.

