인터널 제품의 목표와 방향성을 잊어버리지 말자

내부 제품은 고객인 내부 임직원과 매우 밀접하게 맞닿아있기 때문에 다양한 요구사항을 전달받게 된다. 특히 누구나 제품에 접근이 가능하다는 점에서, 최초 정의했던 제품의 목표와 방향성에 맞지 않는 기능을 반영하게 될 수 있다. 예를 들면, 이런 경우가 발생할 수 있다. 1. A유저를 타겟으로 한 제품을 B유저가 사용한다. 2. B유저를 타겟으로 한 제품은 없는 상태이다. 3. B유저가 “이 기능만 있으면 우리도 쓸 수 있겠는데?” 라는 생각으로 기능추가를 요청한다. 4. B유저도 불편을 겪고있는것은 명백하기 때문에 B유저의 문제를 해결해주고 싶은 욕망에 휩쌓인다. (특히 추가를 요청한 기능이 작고 간단할수록 그렇다.) 그렇지만, 타겟이 아닌 유저들을 위한 기능이 추가될수록 최초 타겟으로 한 유저들을 위한 기능 반영이 늦어질 수 있다는 위험성이 있다. 제품이 최초에 해결하려고 했던 문제에서 벗어나는것 뿐만 아니라, 그 누구의 불편도 해소하지 못해 모두가 힘들어질 수 있다. 위에서 언급한 사례에서 발생할 수 있는 최악의 시나리오는... B유저도 일단 불편은 하니까 B유저의 요청사항 수용 → 이번에는 C유저가 등장 → C유저 문제도 해결 → B,C 유저의 요청사항을 반영하고 있기 때문에 A유저는 리소스가 확보되기를 기다림 → (팀에서는) 이제는 A유저에게 집중해야지! 라고 생각 → B, C 유저의 계속된 요청사항 → A유저에게 집중해야 하니 B,C 유저 문의 거부 → B,C 유저는 예전에는 들어줬는데 왜 안들어주지? 불만 → A유저는 A유저대로 우리를 위한 제품인데 우리의 우선순위가 낮아져 불만 ... 이런 상황이 발생하지 않도록 다양한 유저들로부터 오는 요청사항들을 경계하고, 정말 이 제품의 목표와 방향성과 맞는지 냉정하게 판단해야 한다. 제품에 어떤 기능을 추가할지 결정하는 최종 의사결정권은 PM에게 있다. 때문에 기능을 반영할지, 반영하지 않을지를 결정하고 적절하게 유저와 팀원들을 설득해야 한다. PM이 똑바로 방향성을 설정하지 않으면, PM을 믿고 디자인한 디자이너, 기능을 개발한 개발자, 제품을 기다리는 유저 모두 고통받는다는 사실을 기억하자.