월말 정산을 앞둔 매장 관리자가 영수증 사진 이백 장을 다시 열어 본다고 해보자. 자동 분류는 작동했지만 누락이 겁나 결국 모든 항목을 손으로 대조한다. 제품은 기능을 제공했지만 고객이 사고 싶었던 변화, 즉 정산을 제때 끝내고 안심하는 상태는 만들지 못했다. 기획의 단위를 기능에서 변화로 바꾸면 자동화 정확도만 높일지, 틀린 항목을 빠르게 고치게 할지, 아예 누락 경고를 먼저 만들지의 우선순위가 달라진다.
핵심 제품의 가치는 기능의 개수가 아니라 사용자가 현재 상태에서 원하는 상태로 이동하도록 얼마나 확실하게 돕는지에 있습니다.
먼저 보면 좋은 점
- 기능을 사용 장면과 원하는 결과로 번역합니다.
- 고객이 이미 쓰는 대안과 새 제품의 부담을 함께 봅니다.
- 한 기능이 누구에게 어떤 변화를 만드는지 기획안에 적습니다.
기능 뒤에 있는 일을 찾는다
사용자는 제품을 켜는 것 자체를 목표로 삼지 않습니다. 쇼핑몰의 재입고 알림은 알림을 받기 위해 쓰는 기능이 아니라, 원하는 상품을 매번 확인하지 않고 살 기회를 놓치지 않기 위해 씁니다. 화상회의의 녹화도 영상을 쌓기보다 참석하지 못한 사람이 결정 내용을 따라오게 하는 데 가치가 있습니다.
기획자는 기능명 옆에 "누가, 어떤 순간에, 무엇을 끝내려고 쓰는가"를 한 줄로 적어볼 수 있습니다. 이 문장이 모호하면 대상 고객이 너무 넓거나 해결할 상황이 아직 확인되지 않았을 가능성이 큽니다.
경쟁자는 비슷한 앱만이 아니다
새 협업 도구의 경쟁자는 다른 협업 도구뿐 아니라 메신저, 스프레드시트, 주간 회의, 담당자의 기억일 수 있습니다. 기존 방식이 불편해도 익숙하고 무료라면 고객에게는 강한 대안입니다. 새 제품은 기능 우위뿐 아니라 이동에 드는 학습과 설정 비용까지 이겨야 합니다.
그래서 경쟁 비교표에 기능 유무만 적으면 중요한 판단을 놓칩니다. 현재 방식으로 일을 마치는 데 걸리는 시간, 실수 가능성, 다른 사람을 설득해야 하는 부담, 데이터를 옮기는 비용까지 비교해야 실제 전환 가능성이 보입니다.
변화를 기준으로 범위를 고른다
원하는 변화가 분명하면 기능을 줄이기도 쉬워집니다. 첫 버전의 목표가 "팀장이 이번 주 병목을 10분 안에 찾게 한다"라면 화려한 보고서 편집보다 지연된 업무를 정확히 모으는 기능이 먼저입니다. 반대로 보고서를 외부 고객에게 보내는 상황이 핵심이라면 내보내기와 권한이 중요해집니다.
제품 요구사항마다 연결할 변화가 없다면 관성적으로 들어온 범위일 수 있습니다. 기능을 삭제하기 어려울 때는 그 기능이 없으면 어떤 사용자의 어떤 일이 끝나지 않는지 물어보면 우선순위를 다시 볼 수 있습니다.
사용자 변화 문장을 기획안에 쓰는 법
기획안의 목표를 "자동 분류 기능 제공"이라고 쓰면 완료 기준은 배포 여부가 됩니다. 이를 "매장 관리자가 매주 월요일에 지난주 비용 누락을 15분 안에 찾는다"로 바꾸면 대상, 시점, 결과와 측정 기준이 생깁니다. 아직 근거가 없는 15분은 목표 가정이라고 표시하고 현재 걸리는 시간부터 조사합니다.
변화 문장 아래에는 시작 상태, 바뀐 행동, 확인 신호를 적습니다. 시작 상태는 여러 파일을 번갈아 열어보는 상황이고, 바뀐 행동은 한 화면에서 누락 항목을 확인하는 것이며, 확인 신호는 과업 완료 시간과 재확인 횟수일 수 있습니다. 만족도만으로는 실제 일이 달라졌는지 알기 어렵습니다.
기능과 결과를 잇는 가정 지도
한 기능이 원하는 변화를 바로 만들지는 않습니다. 자동 분류가 정확해야 하고, 사용자가 결과를 믿어야 하며, 틀린 항목을 쉽게 고칠 수 있어야 누락 확인 시간이 줄어듭니다. 기능에서 결과까지 필요한 조건을 화살표로 이어보면 기술 정확도만 높여서는 부족한 이유가 보입니다.
각 화살표는 검증할 가정입니다. 분류 정확도는 시험 데이터로 확인하고, 신뢰 여부는 사용자가 결과를 다시 전수 검사하는지 관찰하며, 수정 편의는 과업 시간으로 측정합니다. 이 지도는 기능을 늘리는 목록이 아니라 결과가 나오지 않을 때 어느 연결부터 살펴볼지 알려주는 진단 도구입니다.
변화를 입증하지 못하면 범위를 바꾼다
누락 주문 알림의 목표를 "마감 담당자가 10분 안에 오늘 출고 분을 확정한다"로 정했다면 비교할 현재값이 필요하다. 세 명의 업무에서 평균 24분이 걸렸고 누락을 두 번 발견했다면, 10분은 약속이 아니라 검증할 가정이다. 배포 후에는 시간과 함께 재확인 횟수, 잘못 확정한 주문을 같이 본다.
처리 시간이 9분으로 줄어도 잘못된 출고가 늘었다면 팀은 성공을 선언하지 않는다. 과업 시간만 줄이고 결과를 망친 실패이므로 자동 알림 범위를 늘리는 대신 판단 근거와 수정 경로를 다음 배포로 옮긴다. 반대로 시간과 오류가 함께 줄었다면 이제야 그 기능을 고객이 산 변화의 일부라고 부를 수 있다. 이 판정이 다음 백로그를 가른다.
메모
- 기능을 쓰기 전과 후에 사용자의 상태가 어떻게 달라지는가?
- 고객은 지금 같은 일을 어떤 도구나 습관으로 해결하는가?
- 기능별로 반드시 끝내야 할 사용자 일을 한 문장으로 적었는가?