링글잉글리시에듀케이션서비스

링글

개발팀 리뷰

위 내용은 링글잉글리시에듀케이션서비스 전 • 현 재직자의 응답 결과입니다.

기술 스택

프론트엔드

React

Next.js

Webpack

백엔드

Ruby

AWS

Datadog

Circle CI

언어

javascript

typescript

재직자가 작성한 글

profile picture

진용진

Product manager

Pre-mortem으로 비즈니스 가설을 사전에 검증한다

어제 PM 멤버들이 모여서 PRD(Product requirement document) 작성에 대해서 서로 피드백을 가지는 시간을 가졌다. 프로젝트의 진행, 완료 여부 관계 없이 관련 PRD를 리뷰하면서 의미있는 피드백을 나누었다. 멤버들끼리 문제점 정의, 문서를 읽은 대상자 고려한 도메인 지식의 상세한 정도, 시각화, current state와 desired state를 어떻게 문서화하면 좋을지 의견을 주고 받았다. 그 중에서 내와 유사하게 공통된 문제인식을 가지셨던 멤버가 있었다. 과거에 진행되었던 특정 프로젝트를 같이 돌아보면서 프로젝트 초기 시점에 놓쳤던 중요한 business feasibilty를 어떻게 그 시점에 체크할 수 있을지 이야기했다. 미팅에선 관련해서 구체적인 액션 아이템은 나오지 못했다. 그 뒤 오늘 Lenny's Podcast의 링크드인 글에서 과거 포커 플레이어였고 현재 decision making 관련 코칭을 하는 Annie Duke 인터뷰 글을 읽었다. Annie Duke는 pre-mortem이라는 기법을 소개했다. pre-mortem은 프로젝트 시작 전에 팀이 모여서 프로젝트가 실패하는 상황을 가정하고, 관련 원인과 assumption을 찾아내는 기법이다. 의사결정 관점에서 위험 징후를 사전에 가정해봄으로써 실제 상황에서 방향성을 선회하는 것이 유연해지고, 소위 말하는 매몰비용과 확증 편향이 커지기 전에 포기하기 쉬워진다는 것이다. "Use pre-mortems to set kill criteria. Before starting a project, imagine failure and what early warning signs might have predicted it. Commit in advance to reassess or pivot if you notice those red flags later on. This makes it easier to walk away when sunk costs and overconfidence bias loom large." - Annie Duke 최근에 읽었던 Continuous Discovery Habits에서도 비슷한 개념이 언급이 되었고, 그 내용은 아래와 같다.' 1. 아이디어를 중심으로 일을 하는 것은 리스크가 크다. 많은 사람들이 제품 개발 의사결정 과정에서 고객의 요구사항을 듣고, 떠오르는 첫번째 아이디어에 바로 뛰어든다. 2. 몰입 상승 효과(escalation of commitment)에 빠지게 된다. 이 아이디어를 개발해야하나? 좋은 아이디어인가? 결국 해당 아이디어 틀에서 일을 하다보니 소위 몰입 상승 효과(escalation of commitment)라 불리는 인지적 편향에 빠지기 쉽다. 즉, 우리가 아이디어에 더 많이 투자할수록 그 아이디어와 자신을 동일시하게 된다(‘아이디어에 반했다’라고 표현하는 상황). 3. 우리가 아이디어에 반하게 되면, 두 번째로 확증 편향(confirmation bias)에 빠지게 된다. 우리가 사랑한 아이디어가 좋다는 증거를 더 쉽게 받아들이고, 아이디어에 결함이 있음을 제안하는 증거를 놓치게 된다. 보통 일하다보면 특정 아이디어와 솔루션 중심으로 product feasiblity만 체크하고 프로젝트를 진행하는 경우가 많다. 앞서 소개한 pre-mortem을 통해 프로젝트가 실패했다고 가정하고 product feasibilty 외 business 관점에서 여러 assumption을 생성해보고, 나열된 assumption을 비교 및 대조해보는 것만으로 많은 인사이트를 발견할 수 있다.

profile picture

진용진

Product manager

문제 해결 관점에서 Assumptions와 Hypotheses 구분하여 설명한 글이 있는데요. 한글로 이 두개 단어를 잘 번역할 수 있을까요? 번역기 돌리면 각각 가정, 가설 이렇게 번역되는 것 같은데요. 비슷한 뜻처럼 느껴지는 것 같습니다. 제품팀이 일주일에 10여개의 테스트를 동시에 운영한다는 컨셉이 아이디어를 테스트하기 보다 물리적으로 Assumptions을 사전에 검증하는 것에 가까운 개념이라서 용어를 어떻게 잡으면 좋을지 궁금했습니다 :) https://www.linkedin.com/advice/0/how-do-you-map-out-your-product-assumptions?utm_source=share&utm_medium=member_desktop&utm_campaign=copy