인터콤의 제품 원칙: 문제에서 시작하여 더 나은 솔루션을 달성하십시오.

"우리가 해결하려는 문제는..."

인터콤에서 흔히 하는 말입니다. 제품 리뷰, 로드맵 회의 또는 제품 담당자의 디자인 비평뿐만 아니라 회사 전체에서.

이것은 제품 원칙을 탐구하는 시리즈 의 여덟 번째 게시물입니다 . 여기에서 Stephen은 "문제부터 시작"이라는 엔지니어링 원칙에 대해 설명합니다.

금요일 오후의 'Show and Tell' 의식에서 회사 전역의 사람들이 작업한 내용을 시연하고 프레젠테이션을 시작하는 방식으로 문제를 설명합니다. 새로운 사람이 Intercom에 합류하면 온보딩 팩에는 문제 설명의 이름인 첫 번째 "Intermission"이 포함됩니다. 시작할 때는 문제에 집중하는 것으로 시작합니다.

우리는 정당한 이유로 문제에 집착합니다.

귀하의 솔루션은 문제에 대한 귀하의 이해만큼만 좋습니다.

대부분의 회사는 실패합니다. 많은 사람들이 특히 초기 단계에서 실패하는 이유 중 하나는 고객에게 존재하는 실제 문제에 대한 강력한 솔루션을 제공하지 않았기 때문입니다.

실패한 솔루션에는 몇 가지 일반적인 패턴이 있습니다.

• 팀은 처음부터 문제를 잘 이해하지 못했습니다.
• 팀은 문제에 대한 이해와 시간이 지남에 따라 솔루션에 매핑되는 방식을 지속적으로 업데이트하지 못했습니다.
• 문제는 해결할 가치가 없었습니다. 조치를 취하기에 너무 협소하거나 시급하지 않았을 수 있습니다.

너무 자주 기업은 문제에서 사랑에 빠지는 단일 솔루션으로 빠르게 이동합니다. 그들은 이 솔루션에 시간, 돈, 에너지를 투자하지만 결국 아무도 실제로 그것에 대해 관심을 갖지 않는다는 것을 깨닫게 됩니다.

"진정으로 위대한 기업은 사람들이 원하는 것을 만드는 것보다 사람들이 원하는 것을 만드는 것이 더 쉽다는 것을 알고 있습니다."

진정으로 위대한 기업은 사람들이 원하는 것을 만드는 것보다 사람들이 원하는 것을 만드는 것이 더 쉽다는 것을 알고 있습니다. 그것이 우리가 Intercom에서 하려고 하는 것입니다. 우리는 목표 고객이 경험하는 실제 문제를 이해하는 것으로 시작합니다. 너무 간단해 보이지만 문제에 초점을 맞추는 것이 그렇게 중요하다면 왜 소수의 회사에서 그렇게 합니까?

사람들은 해결책을 생각하도록 연결되어 있습니다.

우리는 모두 "문제를 가져오지 말고 해결책을 가져오세요"라는 말을 들어봤을 것입니다. 우리의 두뇌는 우리 앞에 있는 문제를 해결하기 위해 끊임없이 노력하고 있습니다. 그러나 고객의 문제를 분석, 탐색 및 분석하는 데 시간을 소비하지 않으면 솔루션이 목표를 놓칠 위험이 있습니다. 다음은 즉각적인 해결을 위해 문제를 간과하는 몇 가지 이유입니다.

"문제는 시스템 보기를 만들고 시스템이 함께 작동하는 방식 또는 작동하지 않는 방식을 이해하는 것입니다."

1. 당신의 제품은 시스템이다

제품, 회사 및 고객 기반이 커질수록 모호한 문제를 정확하게 진단하는 것이 더 어려워질 수 있습니다.

점점 더 많은 요인이 작용하고 있으며, 문제는 시스템 보기를 생성하고 시스템이 함께 작동하는 방식 또는 작동하지 않는 방식을 이해하는 것입니다. 예를 들어 제품 사용량이 낮은 경우 그 이유는 무엇입니까? 사용자 경험이나 교육 문제, 누락된 기능 또는 다른 문제입니까?

2. 문제 정의가 어렵다

사람들은 종종 그들이 원하는 솔루션의 형태로 자신이 가지고 있는 문제를 설명합니다. 많은 제품 팀이 거기서 멈추고 솔루션을 구축합니다. 실제 문제는 몇 층 더 깊이 묻혀 있기 때문에 일반적으로 표시를 놓치게 됩니다. 좋은 제품 팀은 계속해서 그 이유를 묻습니다.

"문제 정의는 머리에서 벗어나 그들의 실제 필요를 파악하는 것입니다. 그들이 설명하는 첫 번째 것이 아닙니다."

이것은 감정적으로 힘들고 시간이 많이 소요될 수 있습니다. 많은 고객과 계속해서 이야기하고 새로운 각도와 새로운 질문 방식으로 파고들어야 합니다. 그것은 당신의 머리에서 벗어나 그들의 속으로 들어가 그들이 설명하는 첫 번째 것이 아니라 그들의 실제 필요의 바닥에 도달하는 것을 의미합니다.

3. 솔루션이 반짝입니다.

더 흥미로운 것은 연구 보고서입니까, 아니면 새로운 작업 프로토타입입니까? 우리 대부분은 새롭고 멋진 일을 보는 것을 좋아합니다. 보고서를 읽을 시간이 없습니다. 깊은 지식을 반영하고 얻는 것은 종종 지루하거나 중요하지 않은 것으로 간주됩니다.

Intercom은 화려함보다 임팩트가 더 중요하다는 것을 알고 있습니다. 우리는 다음 작업에 대한 강력한 나침반이 될 것이라고 알고 있는 훌륭하게 작성된 문제 설명을 볼 때 흥분합니다.

4. "진행"에 대한 가시적 산출 및 편향

때때로 팀은 몇 주 동안 작업을 하고 해결해야 할 문제를 설명하는 짧고 간단한 단락의 출력을 생성할 수 있습니다. 이 과정을 소중하게 여기지 않는 사람은 결과물로 중요도를 팔기 어렵습니다.

실제 문제에서 더 멀리 떨어져 있는 이해 관계자는 '실질적인 진전'을 지향할 것입니다. 즉, 문제를 해결할지 여부에 관계없이 어떤 솔루션으로도 위안을 받을 가능성이 더 큽니다.

그래서 그것이 문제라면 해결책은 무엇입니까?

"문제부터 시작하라"는 핵심 R&D 원칙 중 하나로 전면 중앙에 나타나며, 그 중요성을 의미하고 우리가 작업할 때 이를 염두에 두도록 합니다. 그것은 또한 방아쇠입니다. 그것은 우리 모두가 활용할 수 있는 구체적인 기대와 도구를 활성화합니다. 다음은 Intercom에서 문제의 우선 순위를 정하는 몇 가지 방법입니다.

문제에 집중할 수 있는 권한을 부여합니다.

Intercom에서는 프로세스보다 원칙을 중시하므로 애자일, 린 또는 기타 제품 개발 프로세스를 따르든 상관없이 이 원칙은 우리가 어디에 집중해야 하는지 알려줍니다.

대부분의 기업은 해결해야 할 문제를 이해하고 우선 순위를 지정하는 데 너무 집중하지 않고 솔루션을 설계하고 구축하는 데 시간을 보냅니다. 각 팀에 100단위의 초점이 주어지면 다음과 같이 사용하는 경우가 많습니다.

대부분의 기업은 대부분의 시간을 솔루션을 설계하고 구축하는 데 보냅니다.

대부분의 회사는 솔루션을 설계하고 구축한 다음 베타 버전을 고객에게 출시하는 데 대부분의 시간을 할애합니다. 우리는 이것이 결함이 있는 접근 방식이라고 생각하며, 약한 문제 이해를 기반으로 솔루션을 구축하는 데 너무 치우쳐 있습니다. 대조적으로, 다음은 Intercom에서 시간을 보내는 방법에 대한 대략적인 안내입니다.

Intercom에서는 문제의 우선 순위를 지정하고 개선하는 데 많은 시간을 할애하여 단계 간에 더 균등하게 시간을 분배합니다.

100개 단위 중 3분의 1은 디자인을 시작하기도 전에 소비됩니다. 우리는 이 단계에서 문제 우선 순위 지정과 문제 정의에 집착하고, 더 많이 배우면서 문제에 대한 이해를 지속적으로 재정의합니다. 프로세스 초기에 이 시간을 할애한다는 것은 우리가 무엇을 구축해야 하는지 알고 있으며 이를 고객의 손에 더 빨리 전달할 수 있음을 의미합니다.

문제 정의 기대치를 식별합니다.

우리의 모든 원칙은 규모나 노력이 다를 수 있으며 문제를 정의하는 데 소비해야 하는 고정된 시간은 없습니다. 한 시간, 하루, 한 주 또는 10주 동안 이 프로세스를 끝에서 끝까지 달리면서 보낼 수 있습니다. 개인과 팀이 주어진 문제에 투자하기 위한 적절한 노력을 분류하고 결정할 수 있도록 돕기 위해 다음과 같은 몇 가지 지침을 사용합니다.

1. 문제와 솔루션 사이를 오가는 것은 괜찮습니다.

Bulletproof Problem Solving 이라는 책에서 Charles Conn과 Robert McLean은 이것을 "문제와 솔루션 사이의 porpoising"이라고 부릅니다. 아이디어는 둘 사이를 이동하면 각각에 대한 이해가 더 깊어지지만 핵심은 문제나 솔루션에 대한 관점과 사랑에 빠지지 않는 것입니다.

"고객과 비즈니스 요구를 동시에 설명하려고 하면 혼란을 야기할 수 있습니다."

2. 사업이 아닌 고객의 문제에서 시작하라'

고객과 비즈니스 요구 사항을 동시에 설명하려고 하면 혼동을 일으킬 수 있습니다. 우리는 이러한 문제의 비즈니스 영향을 고려하기 전에 의도적으로 고객의 문제에 초점을 맞추는 것으로 시작합니다. 해결하려는 것이 비즈니스 문제라면 이를 고객 문제와 직접 연결해야 합니다.

3. 누가 이 문제를 겪고 있으며 해야 할 일은 무엇입니까?

고객의 기대와 현실 사이에 괴리가 있는 곳에 문제가 존재합니다. 당신은 당신이 집중하고 있는 기대와 경험뿐만 아니라 그들이 달성하고자 하는 결과를 정의해야 합니다.

4. 문제의 심각성에 중점을 둡니다.

얼마나 많은 고객에게 문제가 영향을 미치며 얼마나 심각한 영향을 받고 있습니까?

"너무 자주, 문제 진술은 엉성하고 높은 수준입니다"

5. 영향을 따르십시오

Intercom에서는 문제 정의 프로세스의 일부로 성공 메트릭을 미리 지정합니다. 이를 통해 문제를 해결했는지 확인하기 위해 주의해야 하는 주요 고객 행동 변경 사항을 알 수 있습니다.

6. 구체적이어야 한다

너무 자주, 문제 설명은 푹신하고 높은 수준입니다. 솔루션을 찾는 데 도움이 될 만큼 문제 정의에서 특정 수준에 도달하는 것이 중요합니다.

7. 문제 범위

문제에는 레이어가 있는 경우가 많으며 고객과 제품에 따라 문제가 촉발될 수 있습니다. 문제를 세분화하여 각 차원에 대한 집중도를 높이는 것이 중요하지만 이를 통해 솔루션 옵션에 매핑하고 가장 적합한 것을 결정할 수 있습니다.

우리는 모든 사람이 공통 형식을 따르고 있는지 확인하기 위해 템플릿을 가이드로 사용하지만 이 문서에는 다른 곳에서 진행되는 많은 배경 조사가 수반되는 경우가 많습니다.

"우리는 프로세스 동안, 그리고 가장 중요한 것은 배송 후 더 많은 것을 배우면서 문제에 대한 생각을 업데이트합니다."

문제 정의는 기초입니다. 거기에서 우리의 원칙은 문제에서 솔루션으로 우리를 이동시키는 시스템으로 함께 작동합니다. 우리는 그 과정에서 그리고 가장 중요하게는 우리가 배송된 후에 더 많은 것을 배우면서 문제에 대한 우리의 생각을 업데이트합니다.

우리는 문제에 대한 전체 팀 접근 방식을 취합니다.

Intercom에서 우리는 모두 다른 전문 분야를 가진 제품 사람들입니다. 제품 관리자는 문제 정의를 소유할 수 있지만 모든 사람은 자신이 직면한 문제를 실제로 해결하기 위해 파고들고 이해하고 책임을 져야 할 책임이 있습니다.

이것은 문제 정의에 대한 접근 방식을 알려줍니다. 더 많은 사람들을 연구에 참여시키고 인터뷰와 통찰력을 공유하여 이해를 공유하는 것을 의미합니다. 사람들이 이 접근 방식에 적응하고 가치를 확인하는 데 시간이 걸릴 수 있지만 빌드의 효율성과 솔루션의 정확도를 높이려는 노력은 충분히 가치가 있습니다.

문제부터 시작하여 Intercom의 엔지니어링 팀은 보다 사려 깊고 적합한 솔루션을 설계할 수 있습니다. Intercom에서 일하는 방식에 관심이 있습니까? 엔지니어링 팀에 대해 자세히 알아보십시오.