이해관계자 관리: 아니오라고 말하는 기술

우수한 제품 개발을 위해서는 혁신이 존재하는 바람직함, 실행 가능성 및 실행 가능성 사이의 마법처럼 중첩되는 부분을 식별하고 파악해야 합니다. 제품 관리자는 항상 다른 영역을 희생시키면서 한 방향으로 제품을 너무 멀리 끌어들이기 위해 경쟁하는 세력에 맞서 이러한 영역 간의 균형을 방어해야 하는 위치에 있습니다. 이는 제품 개발 과정에서 여러 번 그리고 많은 사람들에게 아니오라고 말하는 것을 의미합니다.

경력 초기에는 환경 데이터와 사용자 행동을 기반으로 하는 기계 학습을 사용하여 운전자에게 현명한 제안을 제공하는 앱을 개발하는 자동차 분야 프로젝트에 참여했습니다. 내가 팀에 합류했을 때, 앱은 출시 준비가 되어 있었고 경영진은 그것을 출시하기를 열망했지만 곧 프로덕션을 위한 준비가 아직 멀었다는 것을 깨달았습니다.

앱은 시각적으로 매력적이었지만 "누구를 위해 어떤 문제를 해결하고 있습니까?"와 같은 가장 기본적인 디자인 질문 중 일부는 무시되었습니다. "사람들이 이 문제를 해결하기 위해 얼마나 필사적입니까?"

이 앱은 운전자의 목적지의 날씨를 표시하는 기능을 자랑했습니다. 사용자 습관과 교통 데이터로부터 알고리즘은 운전자가 어디로 향할 것인지, 거기에 도착하는 데 걸리는 시간을 추론할 수 있으며, 간단한 날씨 API 통합은 도착 시점에 목적지에 대한 일기 예보를 보여줍니다. 이것은 좋은 사용 사례처럼 보이지만 실제로는 아무도 신경 쓰지 않았습니다. 유럽 ​​운전자를 대상으로 한 유료 설문 조사를 포함하여 자체 사용자 조사를 수행했을 때 응답은 "으악"이었습니다. 그것은 틀림없이 당신이 얻을 수 있는 최악의 피드백입니다: 그것은 당신의 제품이 관련 없는 문제를 해결했다는 것을 의미하고 바람직함 차원이 극도로 낮다는 것을 나타냅니다. 생존 가능성은 잃어버린 원인입니다. 아무도 원하지 않는 제품으로 실행 가능한 비즈니스를 구축하는 것은 불가능합니다. 우리는 모든 것을 폐기해야 했습니다.

어떻게 이런 일이 일어날 수 있었습니까? 대답은 복잡하지만 중요한 단어가 말해야 할 때 말하지 않았다는 사실로 귀결됩니다. 아니요.

회사의 핵심 역량과 자산은 기계 학습 추론 엔진과 확장성이 뛰어난 아키텍처 설계였습니다. 데이터 과학 책임자인 그는 자신의 추론 엔진이 고객 애플리케이션에서 잘 사용되기를 원하는 강력한 이해 관계자였습니다. 그의 영향력은 부분적으로 완전히 기술 중심적인 제품으로 이어졌습니다. 개발은 고객이 원하는 것이 아니라 기술적으로 실현 가능한 것에 의해 주도되었습니다.

아무도 이 이해 관계자에게 아니오라고 말하지 않은 것 같았고 그들이 시도했다 해도 효과가 없었습니다.

제품 전략은 아니오를 의미합니다

아니오라고 말하는 것은 어렵습니다. 사람들은 항상 그 말을 듣는 것을 좋아하지 않으며, 그 말을 하면 중요한 관계가 손상될까 두려워하는 경우가 많습니다. 제품 관리자로서 관계는 우리 역할의 핵심이지만 우리 제품이 성공하고 균형을 유지하는 것도 중요합니다.

그렇다면 관계를 그대로 유지하면서 다른 사람의 요청을 거부하는 방법은 무엇입니까? 다음 방법을 권장합니다.

• 성공을 위해 자신을 설정하십시오.
• 너무 빨리 거절하지 마세요.
• 요청을 재구성합니다.
• 기여하는 분위기를 장려하십시오.

성공을 위한 준비

프로젝트를 시작할 때 모든 사람이 제품의 성공에 대한 공유된 비전("우리가 이것을 하는 이유는 무엇입니까?")과 진행 상황을 측정하는 데 사용할 일련의 지표("우리가 어떻게 알 수 있습니까? 우리가 잘하고 있다면?”). 성공의 모습에 동의하지 않는다면 갈등이 발생하는 것은 시간 문제일 뿐입니다.

프레임워크를 사용하여 목표를 문서화하고 측정 가능한 것에 매핑하는 것이 도움이 됩니다. 저는 사용자 경험을 행복, 참여, 채택, 유지 및 작업 성공에 대한 범주로 구성한 다음 각 범주에 대한 목표, 신호 및 측정항목을 명확히 하는 Google HEART 프레임워크의 느슨한 버전을 사용하는 것을 좋아합니다. 목표는 달성하려는 목표를 다루고, 신호는 각 목표를 사용자 행동으로 분류하며, 지표는 이러한 행동을 추적하여 수량화할 수 있는 방식으로 당신이 하고 있는 일을 측정합니다.

최근 소비자 앱 프로젝트에서 저는 사용자가 프로토타입이 유용하다고 생각하고 계속해서 상호 작용하기를 원하는지 확인하기 위해 제한된 파일럿을 수행하고 싶었습니다. 저는 주로 HEART 프레임워크의 참여 범주에 집중했습니다. 그런 다음 해당 목표를 향한 진행 상황을 추적하기 위해 신호와 지표를 식별해야 했습니다.

• 목표: 사용자는 앱과 상호 작용하고 계속 사용하기를 원합니다.
• Signal: 사용자가 앱을 자주 엽니다.
• 측정항목: 하루에 두 번 이상 앱을 여는 사용자의 비율입니다.

목표를 식별하고 정렬하는 이 프로세스는 간단해 보이지만 쉽지 않습니다. 이 경우 클라이언트 및 영업 팀과의 통화, 독립적인 연구 및 여러 팀 워크샵이 포함되었습니다. 이 발견에서 수집한 정보를 바탕으로 클라이언트와의 킥오프 미팅에서 완성된 HEART 프레임워크를 발표할 수 있었습니다. 우리는 모든 항목을 살펴보고 필요한 부분에 적용했습니다.

모든 이해 관계자가 목표 설정 프로세스에 참여하도록 하는 것이 중요하며 모든 사람이 추적해야 하는 신호와 지표에 대해 동의하게 하면 프로젝트가 진행되면서 반복적으로 거절할 필요가 없습니다. 또한 누군가가 계획의 매개변수를 벗어나는 요청으로 귀하에게 접근하는 경우 지시할 데이터를 제공합니다.

너무 빨리 아니오라고 말하지 마십시오

주요 이해 관계자가 성공의 모습에 동의하고 앞날이 분명해 보일 때에도 한 가지는 확실합니다. 누군가가 어딘가에서 예상치 못한 질문으로 당신에게 다가갈 것입니다.

그럴 때 너무 빨리 거절하지 마십시오. 요청이 부당하다고 확신하더라도 완전히 거부하면 대화가 중단되고 관계가 손상될 수 있습니다. 또한 제품 검색 프로세스를 훼손합니다. 제품 관리자로서 우리는 전체 그림을 볼 필요가 있으며 우리와 동의하지 않는 사람들의 말에 귀를 기울이면 사각지대가 줄어듭니다.

물론 여전히 아니오라고 말할 수 있지만 무릎 꿇는 반응을 피해야 합니다. 그것들은 흑백, 옳고 그름, 승패 사고의 결과인 이진 토론으로 이어집니다. 무언가를 구현하거나 구현하지 않습니다.

보다 효과적이고 미묘한 논의를 진행하려면 목표 설정 프로세스의 일부로 설정한 합의된 기준에 따라 요청을 구성해야 합니다.

이해 관계자에게 "이 기능이 귀하에게 가치가 있습니까?"라고 묻는 대신 "이 기능이 귀하에게 얼마나 가치가 있습니까?" 결과 대화는 중요도에 따라 정렬된 "원하는" 목록에 대해 협업하는 데 필요한 정보를 제공해야 합니다. 여러 항목이 계층 구조에서 동일한 위치를 공유하는 것을 허용하지 않고 이 순위 범위가 1에서 n까지여야 합니다. 이렇게 하면 우선 순위 지정 프로세스에서 모든 사람이 목소리를 낼 수 있고 일방적으로 요청을 거부해야 하는 상황을 피할 수 있습니다. 그룹이 더 중요한 요청을 위해 요청을 다운그레이드할 때 일부 요청은 중단됩니다.

요청 재구성

처음에는 불합리해 보이는 요청이 약간의 재설계를 통해 긍정적인 결과를 얻을 수 있습니다. 첫째, 말하는 것을 들어라. 정말 들어요. 가정을 제쳐두고 다른 사람이 어디에서 왔는지 이해하려고 노력한 다음 공통점을 찾으십시오. "왜"라고 물음으로써 조금 더 깊이 파고든다면—꼭 5번은 들어본 적이 있는 것은 아닙니다. 일반적으로 2~3개면 충분합니다. 공유 목표를 나타내는 요소를 찾을 수 있습니다.

완벽하게 합리적인 요청일지라도 더 깊은 잠수와 약간의 재구성을 통해 이점을 얻을 수 있습니다. B2B 모빌리티 서비스를 위한 비즈니스 인텔리전스 도구 작업을 하던 상황이 기억난다. 내 고객은 예상치 못한 것이 아니라 구독자 수를 늘려달라고 요청했습니다. 유료 가입자를 늘리는 동기는 자명해 보일 수 있지만 전체 그림을 담고 싶었기 때문에 "왜?"라고 물었습니다.

문제의 제품이 수명 주기가 거의 끝나가고 있다는 사실이 밝혀졌고, 제 고객은 새 제품으로 교체하기 전에 마지막 한 방울의 이익을 짜내려고 했습니다. 이 정보를 바탕으로 "향후 제품 출시를 위한 토대를 마련하면서 단기적으로 수익을 크게 높일 수 있는 방법은 무엇입니까?"라는 요청을 재구성했습니다.

궁극적으로 가장 좋은 해결책은 가입자 수에 전혀 신경 쓰지 않고 가격과 가치를 더 잘 맞추는 것이었습니다. 고객은 라이더 거래에 도구를 얼마나 자주 사용했는지에 관계없이 고정된 월간 구독료를 지불하고 있었습니다. 그러나 처리한 라이더 트랜잭션이 많을수록 도구에서 더 많은 가치를 얻을 수 있습니다. 고객은 월간 거래가 소수에 불과한 개인 택시 운전사부터 수십 개의 자회사와 수천 대의 차량이 있는 다국적 화물 운송업체에 이르기까지 다양했습니다. 동일한 고정 월간 구독료가 소규모 고객에게는 너무 높고 대규모 고객에게는 너무 낮습니다.

약간의 가격 조정을 통해 수익을 늘리는 동시에 곧 출시될 제품에 대한 계층화된 가격 구조(거래 건수 기준)를 향한 걸음마를 뗐습니다. 새 모델은 대부분의 고객에 대해 가격을 낮추고 불균형적으로 혜택을 받고 있는 가장 큰 고객에 대해 가격을 인상했습니다.

이러한 방식으로 요청을 재구성하여 윈-윈 상황을 만들 수 있습니다. 요청을 전달하는 사람은 경청하고 존중받는다고 느끼며 제품 개발 프로세스를 방해하지 않으면서 가치를 추가할 수 있는 통찰력을 얻습니다.

공헌의 분위기를 장려

거절의 가장 큰 위험 중 하나는 거절이 팀 내부와 외부 모두에서 육성하려는 개방성과 협업 정신을 훼손할 수 있다는 것입니다. 관련성이 있든 없든 아이디어는 영감을 주고, 마지막으로 하고 싶은 일은 창의성과 커뮤니케이션의 흐름을 막는 것입니다.

나는 한때 풍부한 아이디어를 가진 주니어 QA 엔지니어와 함께 일한 적이 있습니다. 거의 모든 회의에서 그는 여러 질문을 하고 자발적인 제안을 했습니다. 그의 해결책은 종종 실행 가능한 해결책이 아니었으며, 그 중 일부는 도움이 되지 않거나 관련이 없는 것으로 무시될 수 있었습니다. 그러나 그의 헌신과 열정은 매우 귀중했습니다. 그는 가능한 최고의 제품을 제공하는 데 전적으로 투자했으며 그의 기여는 다른 사람들에게 활력과 영감을 주었습니다. 그런 태도는 전염성이 있습니다.

당신은 사람들이 생각과 아이디어를 공유하도록 격려받고 그렇게 함으로써 보상을 받을 수 있는 환경을 만들고 싶습니다. 당신의 팀은 무시당하거나 무시당하거나 조롱을 당할 것이라는 생각에 낙담하기보다는 개선할 수 있는 가능성에 동기를 부여해야 합니다. 몇 가지 간단한 관행을 구현하면 팀의 심리적 안전을 보장하는 데 도움이 될 수 있습니다.

아이디어와 요청을 공개적으로 인정합니다. 이것은 신뢰를 구축하고 귀하가 제안을 소중히 여기고 고려하기 위해 최선을 다하고 있음을 보여줍니다. 모든 이해 관계자가 액세스할 수 있는 요청 상자, Confluence 페이지 또는 기타 공개 포럼을 설정합니다. 요청이 들어오면 이를 기록하고 요청자에게 메시지를 보내 기여에 대해 감사를 표합니다.

이것이 논란의 여지가 있다는 것을 알고 있지만 때로는 모든 사람에게 제품 백로그를 공개하기까지 합니다. 이는 QA 테스터 및 디자이너와 같은 팀 구성원이 경험한 내용을 메모할 수 있을 뿐만 아니라 제품 팀의 참여를 촉진하는 데 특히 도움이 될 수 있습니다. 규칙은 간단합니다. 누구나 백로그 끝에 추가할 수 있으며 개선(또는 기타 주간 회의) 중에 팀 구성원은 추가한 내용을 공유하고 이유를 설명합니다. 제품 관리자만 문제의 순서를 변경하거나 항목을 삭제할 수 있습니다. 많은 사람들은 모든 사람에게 이 수준의 액세스 권한을 부여하면 혼돈과 무정부 상태로 이어질 것이라고 생각하지만 그렇지 않습니다. 다양한 규모의 조직에서 이것을 시도했지만 사람들이 너무 부끄러워 아이디어를 제공할 수 없을 때만 실패합니다.

솔루션을 구현했거나 이러한 기록된 요청 중 하나와 대략적으로 관련된 기능을 출시한 후에는 요청자에게 공개적으로 크레딧을 제공하십시오. 이는 솔루션이 원래 요청의 명확한 이행이 아니라 재구성된 버전인 경우에 특히 중요합니다. 성공에 관련된 모든 사람에게 감사를 표하는 것은 친선을 형성하고 동료애를 구축하며 사람들이 계속 참여하도록 권장합니다.

아니오라고 말할 때의 장단점을 따져보기

이해 관계자가 어디에서 오는지 진정으로 경청하고 이해하는 데 시간을 할애한다면 제안을 완전히 거부할 필요가 거의 없습니다. 적극적인 경청, 투명한 의사소통, 상호 존중은 처음에는 문제가 있거나 범위를 벗어나는 것처럼 보일 수 있는 요청을 처리하는 핵심 요소입니다. 대부분의 경우 아니오라고 말하는 기술은 실제로 "아니오"라고 말하는 것을 포함하지 않습니다.

공통점을 찾는 것이 불가능하고 제품과 프로젝트를 보호하기 위해 직접적인 no가 필요한 상황이 있을 것입니다. 다른 경우에는 동의하지 않는 사항을 처리해야 할 수도 있습니다. 당신의 임무가 바람직함, 실행 가능성 및 실행 가능성의 균형을 보호하는 것만큼 고려해야 할 네 번째 차원이 있습니다. 바로 실용주의입니다. 일이 계속 진행되도록 하려면 타협이 핵심이며 때로는 아예 아니오를 피하는 것을 의미합니다.

애자일 제품 개발의 장점은 반복적인 특성이 코스 수정을 위한 많은 기회를 제공한다는 것입니다. 결국 목표는 토론-분쟁-탈락이 아니라 구축-측정-학습입니다.