프로덕트를 볼 줄 알아야 한다는, 말의 의미

보이지 않는 것들을 볼 수 있어야 한다.

 이커머스에서는 모든 직군이 프로덕트를 이해하고 프로덕트를 바탕으로 업무를 설계할 수 있어야한다는 말을 자주 했다.

 문제는 이런 말을 들으면 기능과 UI중심으로 아이디어를 제안하는 것이 필요하다는 오해하는 사람들이 있다. 사실 해결책보다 더 중요한 건 문제를 제대로 분석하는 것이다. 기능을 자꾸 채우려하기 전에 선후행 결과를 예상하려는 노력은 해야한다.

 예상을 '잘하는 것'이 아니라 '노력'을 해야하냐면 사실 결과는 아무도 예상하기 어렵기 때문기 때문이다. 하지만 예상가능한 것도 분명 있다. 그건 투입량이다. 새로운 기능을 만들기 위해 소모되는 자원들과 그 기능을 유지하고 계속 사용하게 하기 위해서 소모되는 운영인력의 수고로움이 예상되어야한다.

 예를 들어 멋진 매장을 하나 만들 때 그 성과는 추정하기 어렵다. MVP를 만들어서 테스트한다는 말로 유동성없는 레거시를 만들어야 할 경우에는 더더욱 고민에 휩싸인다. 이 레거시를 다시 뜯어서 개선하는 것은 그만큼 비용이 너무 많이 들기 때문이다. 심지어 생각보다 잘 작동하고 있다면 추가 기능에 대한 요구사항은 빗발친다.

 문제는 사실은 요구하는 사람도 그걸 만들지 선택하는 사람도 명확한 기준이 없기 때문에 합리적인 선택을 하기 어렵다는 점이다.

타사의 베스트 플랙틱스만
 더하기만 하다보면 누더기가 된다

 비극은 오퍼레이션과 PM이 어디서 본거 너무 많을 때 생겨난다. 모든 해결책을 타사에서 만들어진 기능을 따라하거나 흉내내서 해결하려고 할 때 모든 프로덕트의 방향성이 '더하기'만 된다. 우선순위를 매기면 되지 않냐는 말은 전쟁통같은 현장속에서는 어쩌면 뜬 구름같은 말처럼 보이기도 한다. 결국 누더기에 덕지덕지 붙어서 리팩토링을 기다려야하는 신세가 되고 만다.

 프로덕트를 볼 줄 안다는 말이 새로운 기능을 발견하고 개발거리를 찾아내는 능력은 아닌 것 같다. 해결책을 찾기위해 타사 프로덕트을 뒤져가며 눈에 불을 켜고 신기능을 찾으려고 하지 말자. 때론 맞지 않는 것을 빼거나 줄이는 것이 문제 해결에 가까울 때도 있는 것 같다.

프로덕트를 볼 줄 안다는 것은 무엇일까

 그래서 대체 프로덕트를 보고 제대로 파악한다는 것은 무엇일까. UI나 기능 자체가 아닌 행간의 목적을 찾고 그 기능과 공간을 유지시키기 위해 필요한 노력들도 볼 줄 알아야한다는 말이다. 안내문구 사이에 숨겨진 정책과 그 정책이 만들어진 이유를 예상할 수 있다. 그리고 그걸 만들기 위한 구조적인 특이사항까지도 예상해볼 수 있다. 눈에 보이는 UI에 잠식당하지 않으려면 연습은 필요하겠지만, 그쯤 됐을 때 우선순위나 판단력이 생기지 않을까,

 남의 프로덕트에 감탄하고 부러워하다가도 내 프로덕트에 그게 정말 필요한지 고민이 된다면 그게 정상인 것 같다. 무조건 따라만들 생각만 한다면 고수는 아니다. (고수를 흉내라도 내보자.)

 장표나 멋진 데이터 그래프는 어차피 겉치레다. 노션에 갈겨 쓴 몇줄 문장과 무뚝뚝한 엑셀로도 문제해결을 할 수 있고, 종이에 휘갈긴 낙서같은 그림으로도 디자이너와 소통은 가능하다. 겉치레가 너무나 중요해보일 때에 본질을 바라보는 게 더 중요한 때가 올 거라 믿는다.