💦나만 모르는 프로덕트 관리 이야기 [✏️새로운 기능을 만들기 위한 최악의 설득 근거] (👀간단 요약) 많은 모바일 제품 기반 비즈니스에서, 프로덕트의 변화는 제품팀 뿐 아니라 사업, 운영, 마케팅 등 전사 여러 조직에 영향을 미칩니다. 모든 팀에서 제품팀을 보며 이건 왜 안 고쳐주나요- 이것 추가해주세요- 라며 요청하죠. 이 때 프로덕트 매니저는 중심을 잘 잡고 모두를 설득하며 올바른 방향으로 제품 개선을 이끌어야 합니다. 오늘 소개하는 글에서는 타협의 길로 접어들게 만드는 '최악의 주장'들을 짚어줍니다. 당신의 백로그에 있는 99%의 프로덕트 아이디어는 대부분 쓰레기다. 프로덕트 매니저로서 우리는 리소스 제약으로 인해 1%의 좋은 아이디어를 찾고 그 중에서도 오로지 최고만을 선택해야 한다. 이는 "안된다"는 말을 많이 해야 한다는 뜻이다. 최근 몇 년간 나는 기능을 만드는 데 기반이 되는 많은 주장들이 근본적으로 잘못되었다는 것을 깨달았다. 논거의 오류가 있는 잘못된 주장은 심각하게 제품을 망칠 수 있으며, 조직에도 수년간 영향을 줄 수 있다. 내가 들었던 최악의 주장들은 다음과 같다. 📌 But our competitors have it, too. 우리 경쟁자들은 갖고 있는데요. ✓ 경쟁자들을 살펴보는 것은 좋지만 그들의 시도를 평가하고 학습하라. ✓ 그들은 당신과 다른 고객, 다른 제품 비전을 가지고 있을 가능성이 높다 ✓ 경쟁자들을 베끼는 회사들은 항상 한 발자국 뒤에 있을 수밖에 없다. 📌 “Sales team needs it…” 영업 팀이 필요로 해요. 프로덕트 비전이나 전략, 로드맵에 대해 굉장히 친숙한 경우가 아닌 이상, 누가 요청하든 당신의 대답은 "안돼요"여야 한다. 소프트웨어 회사의 영업팀은 왜 갖고 있지 않은 것을 파는지 생각해본 적 있는가? 프로덕트 매니저는 좀더 장기적인 관점으로 우선순위를 결정할 필요가 있다. 📌 “It only takes a few hours to create this feature.” 이 기능을 만드는 데 몇 시간 안 걸려요. 모든 피쳐는 새로운 복잡성을 만들어내며 향후 유지보수를 필요로 한다. 무언가를 만드는 데 있어 작업의 범위가 핵심 논거가 되어서는 안된다. 따라서 여기서도 당신의 대답은 "안돼요"가 되어야 한다. (핵심적인 가설 검증을 할 수 있는 피쳐가 아닌데도 단순히 얼마 안걸린다고 시작했다가 큰코 다칠 수...) 📌 “We can make it optional.” 선택적으로 사용하도록 하면 되잖아요. 선택적으로 만들어진 모든 기능은 제품의 복잡성을 배가시킨다는 것을 기억하자. 당신의 제품은 두개의 삶을 살게 될 것이고, 당신은 두가지 사용성을 더 좋게, 더 다르게 해달라는 요청을 받게 될 것이다. (하나의 안을 선택하기 위한 목적이 아니라 두가지 옵션을 동시에 서비스하기 위해 분기 처리를 하게 된다면 모든 미래의 기능에 영향을 주게 됩니다.) 📌 “It has been in our backlog since last year.” 작년부터 백로그에 있었어요. 시간이 지남에 따라 사용자 니즈는 변화한다. 당신의 제품이나 경쟁자도 마찬가지다. 필요한 모든 데이터와 최신의 인사이트 없이 몇년 또는 몇달 간의 기능 기반 로드맵을 미리 만들기는 어렵다. 백로그에서 뭔가 꺼내는 것보다는, 전략과 목적 기반의 문서를 만드는 것을 추천한다. 좋은 백로그는 잘 다듬어지고, 정리되고, 최신 상태로 유지되어야 함을 기억하라. 📌“We have nothing else planned.” 우리 다른 것 계획한 것이 없어요. 단순히 개발자들을 바쁘게 하기 위해 기능을 만드는 것은 늘 해가 될 수 있다. 새로운 것을 만드는 것 대신 기술 부채를 청산하는 데 추가적인 시간을 쓰는 것이 나을 수 있다. 개발자들과 가장 리팩토링이 필요한 것이 무엇인지 논의하라. 📌“If we don’t build it, somebody else will.” 우리가 안 만들면 누군가가 만들 거예요. 다른 세그먼트로 제품 라인을 확장하는 게 문제되지는 않지만, 핵심 비즈니스에 집중할 때 성공할 확률이 높아진다. (고객에 미친듯이 집중한 아마존처럼 시장에서 선두를 달리고 있는 서비스들을 보면 자신만이 제공할 수 있는 본질과 핵심에 초점을 맞추고 있는 것을 볼 수 있습니다) 훌륭한 제품과 나머지 전체 고객보다 중요한 일부 고객이나 이해관계자는 없다. 죄책감없이 "안된다"고 이야기해도 괜찮다. 더 넣은 시야에서 제품을 보고 우선순위를 정해서 개선이나 최적화가 필요한 부분 또는 새 기능을 추가할 부분을 찾는 것이 당신의 일이다. (👋중요한 이유가 뭔가요?) 음. 팩폭. 난 아닐거야 하고 읽기 시작했다가 팩폭 팩폭 팩폭. 제가 가장 많이 한 실수 중 하나는 우리가 먼저 해야 해, 와 백로그에 있었기에- 라는 내용이에요. 전자는 우리가 먼저 서비스를 출시한 상황에서 많이 발생했는데요. 격차를 벌리기 위한 방법은 상대방이 준비하기 전에 한 단계 먼저 나아가는 거라 생각했기 때문입니다. (상황에 따라 정답일수도, 정답이 아닐수도 있지만, 이 자체가 근거가 되진 못해요.) 후자는 백로그에 오래전부터 있었다는 건, 그만큼 오랫동안 발생해왔을 가능성이 높거나 처리해야 할 우선순위가 높다고 판단 할 수 있기 때문입니다. 사실 백로그에 있는 숫자가 중요한게 아니라, 우리에게 맞는게 무엇이고 우리가 우선순위를 설정하는 기준이 무엇인지가 더 중요하다는 것을 이제야 하나, 둘 깨닫고 있네요. 목적 기반의 문서요. 본문에서도 언급 된. 지난번 프로젝스 스펙 문서 작성 법을 공유한 적 있는데 저도 늘 새로운 기능이나 서비스를 준비하면서 가장 먼저 작성하는 문서이기도 하고요. 이런 기준을 잘 만들어 놓는게 정말 중요하다고 생각해요. 언제 등록된 백로그야? 가 아니라 이 백로그가 우리가 가장 먼저 해결해야 하는거야 라는 질문에 답을 하고 다음 단계로 나아갈 수 있도록 해주는. 조금 극단적으로 분류가 되어 있지만, 위와 같은 상황을 한 번 이상 겪어보지 않은 PM은 없을거라 생각하기에 짧은 생각을 덧붙여 공유하게 되었습니다. (💌함께 읽어보세요!) 👉 함께 만드는 기준, 프로덕트 스펙 문서 작성법 : https://news.publy.co/comments/8149 👉 프로덕트 매니저에게 필요한 7가지 능력 : https://news.publy.co/comments/9861