정말로 만들어야 할 기능 요청 (그리고 가려내는 법)

당신은 나쁜 기능 요청에 ‘아니오’라고 말하는 법을 압니다. 범위 확장과 핵심 기능을 구별하는 법을 익혔습니다. 당신은 제품의 경계를 지키고 있습니다.

그런데 이제 다른 곤경에 빠졌습니다. 전부 통과한 요청이 열두 개나 됩니다. 전부 당신 앱을 위한 것입니다. 전부 합당합니다. 전부 사용자가 정말로 원하는 것입니다. 그런데 그중 셋만 만들 수 있습니다.

어느 셋일까요?

여기서 대부분의 제품 결정이 어긋납니다. 창업자들은 가장 인상적으로 들리는 것, 또는 가장 돈이 되는 것, 또는 가장 중요한 고객한테서 온 것을 고릅니다. 가끔은 맞습니다. 대개는 틀립니다.

중요한 신호들

신호 1: 시키지 않은 반복

서로 이야기를 나누지도 않은 세 명의 사용자가 같은 것을 요청한다면, 그건 신호입니다. 그들은 짜고 한 게 아닙니다. 다들 그냥 그게 떠오른 거죠. 다섯 명이 요청한다면, 그건 우연이 아닙니다 — 진짜 필요입니다.

그 반대도 중요합니다. 한 사용자가 요청하고 다른 누구도 요청하지 않는데 당신이 그걸 만들면, 이제 당신은 다른 누구도 쓰지 않는 기능을 유지하게 됐고, 그 한 사용자조차 만족하지 못할 수 있습니다(당신이 살짝 틀리게 만들었을 테니까요).

만들기 전에 요청을 세어 보세요. 가장 목소리 큰 고객이나 가장 큰 거래처에서 온 것 말고 — 시키지 않은 반복을 세어 보세요. 독립적인 사용자 두세 명이 같은 것을 요청하는 것이, 중요한 고객 하나가 다섯 가지를 요청하는 것보다 훨씬 강한 신호입니다.

신호 2: 우회법이 중요하다

사용자가 있고 그들이 머물러 있는데 그 기능이 없다면, 그들은 우회법을 찾은 겁니다. 어쩌면 앱 밖에서 하고 있을 수도요. 어쩌면 수동으로 하고 있을 수도요. 어쩌면 다른 도구를 병행해 쓰고 있을 수도요.

하지만 그들은 머물러 있고, 이는 앱을 쓰는 데 그 기능이 필요하지 않다는 뜻입니다. 앱을 더 잘 쓰는 데 필요한 거죠. 그건 차단 요소와는 다릅니다.

가장 중요한 기능은 사람들이 앱을 아예 쓰지 못하게 막는 것들입니다. 있으면 좋은 기능은 사람들이 우회하는 것들이죠.

어떤 요청이 차단 요소인지에 주목하세요. 누군가 “X를 해 주기 전까진 이걸 못 써요”라고 말하는 것과, 누군가 “X가 있으면 좋겠어요”라고 말하는 것. 그 구별이 금입니다.

신호 3: 기능이 비즈니스 모델과 묶인다

어떤 기능은 돈을 버는 완전히 새로운 길을 엽니다. “내 고객에게 인보이스 보내기”는 인보이스 발행에 요금을 매기는 비즈니스 모델을 엽니다. “Salesforce로 내보내기”는 연동 수익을 엽니다. “리셀러를 위한 화이트 라벨”은 파트너 채널을 엽니다.

하지만 여기 함정이 있습니다. 이미 출시하기 전까지는 그 모델들이 통할지 알 수 없습니다. 그것들을 미리 계획할 수 없죠. 출시한 다음에야, 사람들이 실제로 쓰는지 보고 알아챌 수 있을 뿐입니다.

가장 성공적인 기능 추가는 기능을 출시하는 것이 당신이 존재하는지도 몰랐던 시장을 드러내는 경우입니다. 당신은 내보내기를 만들었습니다. 알고 보니 회사들이 당신의 내보내기를 자기네 워크플로에 끼워 넣고 싶어 합니다. 이제 당신에겐 계획에 없던 연동 스토리가 생겼습니다.

기능은 사용자에게 필요하기 때문에 만드세요. 그다음에 사용자가 새로운 사업을 만들어 내는 방식으로 그걸 필요로 하는지 지켜보세요. 비즈니스 모델을 먼저 예측하지 마세요.

신호 4: 도와주겠다는 제안

사용자가 무언가를 만들어 달라고 하면, 그건 요청입니다. 사용자가 무언가를 만들 수 있는지 묻고 테스트를 돕겠다고 제안하면, 그건 다릅니다.

테스트를 돕겠다는 사람은 결과에 투자한 사람입니다. 그들은 그 기능을 꼼꼼히 쓸 겁니다. 버그를 신고할 겁니다. 그게 정말로 자기 문제를 해결하는지 말해 줄 겁니다.

그냥 요청만 하는 사람은 당신이 자기가 상상하는 것을 마법처럼 만들어 주길 바라는 사람입니다. 가끔은 그렇게 됩니다. 자주는 안 되죠.

테스터들과 먼저 만드세요. 나머지는 부차적입니다.

명성 기능을 만들고 싶은 유혹

모든 제품에는 출시하면 당신을 더 인상적으로 들리게 만드는 기능 하나가 있습니다. 일정 관리 앱이라면 Calendly와의 연동이죠. 할 일 앱이라면 Slack과의 연동이고요. 그게 뭔지 다들 압니다. 다들 원하죠.

그런데 핵심은 이겁니다. 다들 그걸 다른 데서도 얻고 있습니다. 당신의 기능이 Slack과의 가장 좋고 가장 쉬운 연동이 아니라면, 그건 당신을 유명하게 만들지 못한 채 앱에 복잡성만 더할 뿐입니다.

당신을 유명하게 만드는 기능은, 당신이 특정 사용자의 문제를 누구보다 잘 이해하기에 유일하게 만들 수 있는 위치에 있는 것들입니다. 그건 명성 기능이 아닙니다. 진짜 사람들의 진짜 문제를 해결하는 지루한 기능들이죠.

Slack 연동은 인상적입니다. 사용자가 Slack이 생각조차 못 한 특정 한 가지를 훨씬 빠르게 하게 해 주는 도구는 가치 있습니다.

실제로 결정하는 법

“이게 범위 안인가?” 테스트를 전부 통과한 기능 요청 한 묶음이 있을 때, 다음 기준으로 순위를 매기세요.

몇 명이 (독립적으로) 요청했나? 많을수록 좋습니다.
차단 요소인가, 있으면 좋은 것인가? 차단 요소가 더 급합니다.
사용자가 오늘 이걸 우회할 수 있나? 없다면, 더 중요합니다.
누군가 이걸 테스트하도록 도와줄까? 그렇다면, 먼저 만드세요.
이게 새 시장을 드러낼까? 어쩌면이라면, 그건 보너스이지 이유가 아닙니다.

그런 다음 그 순서대로 만드세요. 인상적으로 들리는 순서가 아니라. 가장 큰 고객의 순서가 아니라. 당신 앱을 쓰는 사람들로부터 온 진짜 신호의 순서로요.

(아직) 만들지 않을 기능

순위에 들지 못하는 요청도 있을 겁니다. 언젠가 만들 거라고 시늉하지 마세요. 사용자에게 말하세요. “그건 지금은 만들지 않습니다. 이유는 이렇습니다. 대신 만들고 있는 건 이것입니다. 당신에게 통할 만한 대안은 이것입니다.”

그 정직함은 생각보다 더 중요합니다. 사용자는 당신이 하지 않을 거라는 걸 아는 편이, 여섯 달간 바라며 기다리는 것보다 낫습니다.

그리고 가끔은, 당신이 ‘아니오’라고 한 다음에, 사용자가 우회법을 찾거나, 다른 도구를 찾거나, 문제를 다른 방식으로 해결합니다. 그래도 괜찮습니다. 모두에게 모든 것이 될 수는 없으니까요.

이기는 제품은 자기 일을 잘하고 사용자가 실제로 무엇을 필요로 하는지 귀 기울이는 것들이지, 모든 것이 되려다 결국 아무것도 아닌 게 되는 것들이 아닙니다.