일반적인 제품 로드맵이 약속된 비즈니스 결과를 제공하지 못하는 이유, 복잡한 것이 복잡한 것과 매우 다른 이유, 그 차이가 제품 담당자에게 중요한 이유, 새로운 것을 만들려고 할 때 로드맵이 어떤 모습이어야 하는지.

오늘날의 로드맵

아마도 경력의 어느 시점에서 이와 같은 제품 로드맵을 접했을 것입니다. 계획된 산출물(즉, 새로운 제품 또는 기능)과 함께 왼쪽에서 오른쪽으로 실행되는 분기 또는 기타 시간 척도는 내년 정도를 채우기 위해 연속적으로 쌓입니다. 당신은 하나를 만들었을 수도 있습니다 – 나는 내가 가지고 있다는 것을 압니다. 그러나 실제로 계획대로 완료된 제품 로드맵을 본 적이 없을 가능성이 높으며 비즈니스 목표를 달성한 로드맵을 본 가능성은 더욱 적습니다. 왜 그런 겁니까? 그리고 우리는 왜 그것들을 계속 그리는 걸까요?

제품 로드맵은 기본적으로 두 가지 용도로 사용됩니다. 첫째, 조직의 관리자는 예를 들어 다른 프로젝트 및 마케팅 캠페인과 같이 그에 따라 계획을 세울 수 있도록 예정된 사항을 알고 싶어합니다. 중요한 것은 관리자는 우리가 목표를 달성하기 위해 물건을 배송할 때를 알고 싶어하며 제품 로드맵은 우리가 모든 것을 통제할 수 있다는 편안한 느낌을 줍니다. 둘째, 관리자는 ROI가 가장 높은 프로젝트에 비용을 지출하기를 원하므로 팀은 투입된 노력에 대해 가장 큰 가치를 제공한다고 생각되는 결과물에 대해 작업해야 합니다.

두 가지 이유 모두 타당하고 이해할 수 있습니다. 그들이 잘못된 가정에 의존하여 전체 운동을 무가치하게 만들거나 더 나쁘게 만드는 것이 너무 안타깝습니다.

잘못된 가정 #1 — 노력을 미리 예측할 수 있습니다.

팀이 새 프로젝트를 완료하는 데 시간이 얼마나 걸릴지 묻는 질문을 받을 때 흔히 받는 질문은 처음에는 그러한 질문이 의미가 있다고 가정합니다. 그렇지 않습니다. 매번 우리가 예상하지 못한 일이 있을 것 입니다 . 때로는 더 작고 때로는 더 크고 때로는 몇 개만, 때로는 매우 많습니다.

잘못된 가정 #2 - 값을 미리 알 수 있음

관리자가 기능의 우선 순위를 원할 때 얼마나 많은 돈을 벌 수 있는지 정교하게 계산합니다. 문제는 기능을 구축하기 전에는 기능이 근본적인 문제를 얼마나 잘 해결하는지 알 수 없기 때문에 얼마나 많은 가치를 창출할지 알 수 없다는 것입니다. 우리가 그것을 모르고 있다는 것뿐만 아니라 기능의 가치는 본질적으로 미리 알 수 없습니다 .

관리자가 마음에 드는 프로젝트를 승인받도록 동기를 부여했을 때 숫자를 마사지하는 것이 얼마나 쉬운지에 대해서는 아무 말도 하지 않습니다.

잘못된 가정 #3 — 우리가 만드는 것은 가치를 창출합니다.

더 악화됩니다. 이전 질문은 가치의 양을 알 수 있는지 여부였습니다. 사실, 시행착오 없이는 기능이 어떤 가치를 창출할지 여부를 아는 것은 불가능합니다. 실험과 측정에 능숙한 팀은 그들이 만드는 모든 개선의 절반이 영향이 없다고 말할 것입니다. 기능이 절반입니다. 영향이 없습니다. Standish Group(유명한 소프트웨어 컨설팅 회사)은 모든 애플리케이션의 기능 중 절반이 거의 사용되지 않는다고 추정합니다. 낭비되는 현금 더미를 상상해보십시오.

문제는 펜, 종이, 그리고 한 시간의 시간을 가지고 있다면 아마도 수십 개의 잠재적인 기술 제품을 생각해 낼 수 있을 것입니다. 회사의 관리자와 전문가도 마찬가지입니다. 유일한 차이점은 그들의 아이디어 대부분도 가치가 없다는 사실을 갑자기 잊어버린다는 것입니다. 비결은 하나의 가치 있는 아이디어를 찾는 것이며 의견은 이를 수행하는 끔찍한 방법입니다.

잘못된 가정 #4 — 가치 창출은 최초 출시 시점에 발생합니다.

가치를 창출 하는 기능은 즉시 가치를 창출하는 경우가 거의 없습니다. 성공적인 기능이 가치 창출을 시작하려면 3~5번의 반복이 필요합니다. 로드맵이 기능의 기한에 고정된 경우 기능을 릴리스할 수 있지만 가치를 창출하지 못할 수 있습니다. 그 시점에서 실제로 가치를 창출할 때까지 첫 번째 기능을 반복하는 대신 다음 작업으로 이동하면 무의미한 분주함만 달성한 것입니다. 설상가상으로, 황금 시간대에 거의 준비가 된 것은 결코 빛날 기회를 얻지 못합니다. 가치를 창출하려면 아직 두 번의 반복이 필요하기 때문입니다.

환경이 접근 방식을 결정하도록 하십시오.

지금까지 우리는 제품 로드맵이 의존하는 가정 목록을 찾았습니다. 면밀히 조사하면 현실에 근거하지 않는다는 가정입니다. 환원주의적 성향을 지닌 단순한 사상가로서, 내 두뇌는 아마도 프로세스, 구조 및 지침을 추가하여 각 가정에 대한 문제를 하나씩 즉시 해결하기를 원합니다. 결국 관리자가 하는 일이 아닌가? 슬프게도, 그 첫 번째 반응은 처음에 우리에게 제품 로드맵을 가져온 것과 동일한 기계론적 사고 방식에 근거하고 있습니다. 그러나 [필수 아인슈타인 인용문 입력] "우리는 문제를 생성한 것과 동일한 수준의 사고로 문제를 해결할 수 없습니다 . " 기계적인 사고는 사라지고 새로운 것이 자리를 잡아야 합니다.

각각의 잘못된 가정은 사실 알 수 없는 것을 우리가 안다고 믿는 것으로 요약될 수 있습니다. 그 때문에 우리는 미리 계획을 세울 수 있다고 생각하고 계획을 실행하기만 하면 됩니다. 짜잔, 최종 결과는 분명 가치가 있을 것입니다. 즉, Agile이 유행한 지 20년이 지난 지금도 여전히 Waterfall 방식을 사용하여 제품을 만들고 있습니다.

내가 아는 대부분의 회사는 Waterfall에서 일하는 것을 결코 인정하지 않을 것이지만 실제로는 그렇습니다. 대부분의 스크럼 팀에는 매우 폭포수 백로그가 있습니다. SAFe는 애자일이라는 이름에도 불구하고 Waterfall의 전형입니다. 제품 로드맵은 폭포수입니다. 먼저 계획한 다음 실행하는 모든 방법은 정의상 Waterfall입니다. 그것이 반드시 나쁜 것은 아닙니다. 때때로 Waterfall이 갈 길입니다. 하지만 새로운 것을 만들려고 할 때는 그렇지 않습니다.

우리는 한 걸음 물러서서 일반적인 제품 로드맵, SAFe 및 Waterfall이 일반적으로 이러한 가정에 의존하는 이유와 제품 개발이 이러한 가정을 위반하는 이유를 이해해야 합니다. 그것은 우리에게 로드맵과 제품 개발에 대해 중요한 것을 가르쳐줄 뿐만 아니라 앞으로 나아가는 길에 대한 힌트도 제공할 것입니다.

구체적으로 이제 상황에 맞는 올바른 도구를 더 잘 선택할 수 있도록 다양한 유형의 의사 결정 환경과 성공에 필요한 것이 무엇인지 살펴보고 각각의 "게임 규칙"을 파악해야 합니다. 네 가지 유형이 있습니다. 하나씩 이야기해 봅시다.

명백한 환경

길을 걷다가 신발끈이 풀린 것을 발견합니다. 몸을 구부리고 매듭을 묶고 계속 움직입니다. 문제 해결됨. 당신은 길 건널목에 와서 차들이 도로를 질주하는 것을 봅니다. 차가 지나갈 때까지 기다렸다가 안전하게 길을 건넙니다. 문제 해결됨.

명백한 종류 의 문제에 대한 두 가지 예가 발생했습니다 . 그들은 본질적으로 단순하므로 무슨 일이 일어나고 있는지 알아차리면 즉시 조치를 취할 수 있습니다. 문제 해결됨. 멋진 것은 없습니다. 삶의 수많은 상황이 이런 종류입니다. 우리가 처음에 거의 알아차리지 못하는 작은 문제들입니다. 우리는 (거의 무의식적으로) 상황을 분류한 다음 (무의식적으로) 잘 알려진 모범 사례를 적용합니다.

혼란스러운 환경

지금 빨리! 건물에 불이 났어요! 당신은 문으로 달려갑니다. 막혔어! 연기가 방을 가득 채우고 있습니다. 어서 창문을 깨고 그쪽으로 탈출하세요!

명백 함의 반대는 혼돈 , 즉 네 번째이자 마지막 유형의 환경입니다. 완전히 새로운 상황에 즉각적으로 대응해야 하는 행동-선-생각-나중에의 세계입니다. 혼란스러운 환경 에서는 모든 것이 너무 빨리 변하기 때문에 다른 환경 유형의 초석인 계획과 학습이 무용지물이 됩니다. 행동 자체가 중요해집니다.

다행스럽게도 정말 혼란스러운 상황에 직면하는 경우는 거의 없습니다.

복잡한 환경

청사진과 체크리스트의 세계에 오신 것을 환영합니다. 스마트폰을 조립하는 공장 노동자, 비행기를 조종하는 조종사, 관상동맥 우회술을 시행하는 외과의사. 내 인생이 달려 있다면 그런 일을 할 수 없지만 전문가에게는 일상적이고 지루한 일상입니다.

Airbus가 새로운 A350을 제작하는 예를 들어 보십시오. 그것은 거대한 비행기이고 하나를 만드는 것은 큰 노력입니다. 비행기를 만드는 것은 날개를 달는 것과는 반대입니다 . 모든 구성 요소에는 청사진에서 찾아볼 수 있는 미리 결정된 위치가 있습니다. 2010년부터 현재까지 Airbus는 522대의 개별 A350 비행기를 제작했습니다. 그들은 자신이 무엇을 하고 있는지, 얼마나 오래 걸릴지, 일단 완성되면 실제로 조종할 수 있다는 것을 정확히 알고 있습니다. 지금까지 전 세계 A350 항공기는 사고 없이 934,000회 이상의 비행을 완료했습니다.

본질적으로 항공기 제작은 복잡 합니다. 이를 위해서는 전문가가 필요할 수 있지만 명확한 규칙이 있으므로 환경을 매우 예측 가능합니다. 린 최적화, 분산( 식스 시그마 생각 ) 및 고도로 전문화된 기술 세트를 최소화하는 세계입니다 . 소프트웨어에서 이것은 WordPress에 또 다른 웹 사이트를 구축하는 대행사, 또 다른 고객의 시스템을 구성하는 시스템 전문가 또는 단종 시스템을 유지 관리하는 팀이 될 것입니다.

복잡함은 어려울 수 있지만 예측 가능하기 때문에 계획이 필요합니다. 이것이 로드맵이 빛나는 세상입니다.

복잡한 환경

이전에 해결되지 않은 문제를 해결할 수 있도록 새로운 것을 구축하려는 아이디어가 떠오를 때, 당신은 복잡한 세계를 떠나 복잡한 세계 로 들어간 것 입니다 . 앞으로 6개월 동안 해야 할 일을 스타트업 창업자에게 단계별 지침으로 작성할 수는 없습니다. 왜냐하면 지금부터 2주 후에 전체 계획을 무가치하게 만드는 새로운 정보를 얻게 될 것이기 때문입니다. 모든 움직임을 미리 계획하여 Battleship을 플레이하는 것과 같습니다( 여기에서 시도해 볼 수 있습니다 . 재미있습니다).

모든 차이를 만드는 한 가지 차이점은 미리 알 수 없는 것이 있기 때문에 진행하면서 파악해야 한다는 것입니다. 가장 분명한 예는 고객이 이것을 좋아할까요 ? 미리 알 수는 없습니다. 중요한 것은 얼마나 빨리(그리고 저렴하게) 알아낼 수 있느냐입니다.

복잡한 환경 에서는 프로빙과 실험이 중심이 되며 장기 계획은 지속적인 수정이 필요하거나 무용지물이 될 위험이 있습니다. 새로운 학습에 빠르게 적응하고 방향을 바꾸는 것이 게임의 이름이 되었습니다. 복잡성을 해결하기 위한 전체 움직임이 애자일이라고 불리는 것은 우연이 아닙니다.

복잡하거나 단순히 복잡합니까?

복잡함과 복잡함의 차이는 정복되지 않은 봉우리에서 볼더링과 등산의 차이와 같습니다. 둘 다 등반의 형태입니다. 볼더링에서는 바위를 등반합니다(duh). 기술적으로 도전적이고 극도로 물리적입니다. 결정적으로 경로가 너무 짧아서 바닥에서 전체 경로를 볼 수 있습니다. 벽에 닿기도 전에 경로의 모든 단일 이동을 상상할 수 있습니다. 루트를 완료하면 마스터할 때까지 해당 루트를 반복해서 연습할 수 있습니다. 공학 학위를 가진 내 친구 절반이 볼더링을 좋아하는 것은 우연이 아니라고 생각합니다. 각 루트는 해결해야 할 깔끔한 퍼즐과 같습니다.

이전에 확장되지 않은 산을 확장하는 것과 대조하십시오. 지도도 없고 일기 예보도 없고 정상도 볼 수 없습니다. 밑바닥에서 정상까지 어떤 길을 택할 것인가? 오르는데 얼마나 걸릴까요? 단순히 알 방법이 없습니다그런 것들을 미리. 당신이 시도하는 경로가 당신을 위험한 빙하로 데려다 줄지 아니면 눈사태 위험의 사전적 정의처럼 보이는 절벽 아래로 데려갈지 알 수 없습니다. 해발 7000m에서 눈보라가 당신을 강타할지도 모릅니다. 당신은 미리 알지 못합니다. 올라가는 길을 조사해야 합니다. 숙련된 등반가는 어떤 경로가 유망해 보이는지 또는 저기 있는 랜드마크까지 하이킹하는 데 한 시간이 걸릴지 알 수 있을 정도로 다른 산을 충분히 보았을 수 있지만, 그것은 그 산을 오르는 데 얼마나 걸릴지 아는 것과는 다릅니다. 산. 등반가에게 산 정상에 오르기 위한 기한을 정하도록 강요하는 것은 예측 가능성에 대한 환상을 줄 뿐입니다.

볼더링은 복잡합니다 . 정복되지 않은 산을 확장하는 것은 복잡 합니다 . 그러나 물론 완전히 이것 또는 완전히 저것이라는 이분법적인 선택은 아닙니다. 한 번 산에 올라 일기예보를 들었다고 생각해보세요. 같은 산을 다시 오르는 것은 여전히 ​​어느 정도 복잡 합니다 (여전히 지도가 없습니다). 이제 대신 훨씬 더 복잡해 보입니다 . 첫 번째 등정 전에 대부분의 초점은 미지의 세계에 적응하는 것이었지만 지금은 분석과 효율적인 실행에 중점을 두고 있습니다. 마찬가지로, 모든 제품 작업이 복잡한 것은 아닙니다. 제품 팀이 종료 계획과 함께 수명 종료 시스템을 유지하고 혁신할 의도가 없다고 생각해보세요. 아마도 대부분 복잡할 것입니다 .(또는 명백한 ), 전통적인 로드맵은 그들에게 잘 제공되어야 합니다.

Cynefin — 모두 함께 가져오기

인기 있는 의사 결정 환경 모델인 Cynefin에 따르면 우리가 접할 수 있는 네 가지 환경 유형은 명백 함, 혼돈, 복잡함, 복잡함 입니다 . 방금 논의한 것처럼 의사 결정 상황은 해독하기 쉬운 정도에 따라 다릅니다. 아래에 네 가지 환경 유형을 요약했습니다.

각 환경에는 가장 적합한 접근 방식이 있습니다. 명백한 상황 에서는 분석이나 조사가 필요하지 않습니다. 그냥 하세요. 복잡한 상황 에서는 상황에 분석, 계획 및 아마도 전문 지식이 필요하기 때문에 "그냥 하세요"할 수 없습니다. 따라서 "그냥 하세요"는 "그냥 계획을 실행합니다"가 됩니다. 그러나 상황이 복잡 할 때 계획을 고수하면 위험에 처할 수 있습니다. 대신 탐색, 학습 및 적응을 통해 파악해야 합니다. 그리고 이러한 접근 방식 중 어느 것도 혼란스러운 환경에서 작동하지 않습니다. 대신 혼란 은 단호하게 행동하고 빠르게 움직이며 필요한 경우 부수도록 요구합니다.

우리가 사용하는 접근 방식이 우리가 처한 상황과 일치하지 않을 때마다 문제가 발생합니다. 이러한 이유로 Cynefin에서는 네 가지 유형 사이의 영역을 Disorder 라고 합니다 .

로드맵의 진짜 문제

긴 철학적 접선처럼 느껴졌을 수도 있지만 로드맵의 실제 문제를 쉽게 찾아낼 수 있습니다. 로드맵, 즉 무엇을 어떤 순서로 구축할지에 대한 장기 계획은 본질적으로 복잡한 환경 을 위한 도구입니다 . 새로운 것을 구축하려는 제품 담당자로서 우리는 복잡한 환경에서 운영됩니다.

새로운 제품을 만들기 위해 로드맵을 사용하는 것은 치노를 입고 스쿠버 다이빙을 하는 것과 약간 비슷합니다. Roadmaps와 같은 Chinos는 훌륭합니다. 치노가 문제가 아니라 치노에 완전히 부적합한 환경에서 치노를 사용하는 것이 문제입니다. 당면한 작업에 적합하지 않은 도구를 선택하는 것은 도구의 잘못이 아닙니다. 로드맵은 유용한 도구입니다. 문제는 우리가 장기적인 제품 개발을 계획하기 위해 로드맵을 사용하고 복잡한 상황 에 적합한 도구를 선택하여 복잡한 환경 에서 사용한다고 주장하는 데 있습니다 .

보다 일반적으로 복잡한 게임 에서 승리하기 위한 경주는 (이미 확립된) 비즈니스를 보다 효율적으로 운영하는 경주입니다. 즉, 정의된 책임, 예산 책정 라운드, 개인 보너스가 있는 이사, 다음과 같은 장기 계획을 가진 매트릭스 조직이 생깁니다. 로드맵. 일반적인 부작용에는 사일로, 영역 전쟁 및 위험 회피가 포함됩니다. 이러한 선의의 관행의 부작용이 복잡한 세계에서 성공하는 데 필요한 것과 어떻게 충돌하는지 확인하십시오. 교차 기능 협업, 조직 전체의 변경 명령, 계산된 위험 감수, 빠른 반복, 피벗 및 학습. 로드맵은 회사가 실제 문제(효율성)를 해결하기 위한 도구를 사용하는 이러한 광범위한 문제의 예이며, 이는 혁신 능력에도 해를 끼칩니다.

로드맵을 수정하는 방법?

앞으로 나아갈 길을 찾으려면 지금까지 논의한 두 가지 사항을 염두에 두어야 합니다.

1. 제품 로드맵은 관리자가 미래를 계획할 수 있도록 하고 팀이 가장 중요한 일을 하도록 하는 두 가지 중요한 목적을 제공합니다. 우리가 제안하는 모든 대안은 이러한 목적에 부합해야 합니다.

2. 제품 로드맵은 세상이 복잡하다고 가정하므로 복잡한 환경 에서는 실패합니다 . 우리가 제안하는 모든 대안은 복잡한 환경 에 적합해야 합니다 .

무엇을 만들지 미리 결정하지 않고 가장 중요한 작업을 수행하도록 하는 것은 해결할 수 없는 문제처럼 들립니다. 그러나 이를 수행하는 솔루션을 구축하는 데 사용할 수 있는 건전한 원칙이 있습니다.

원칙 #1 — 팀이 솔루션을 찾도록 하십시오.

정의상 복잡한 새 제품을 구축할 때 실험과 탐색만이 사용자가 지불할 의사가 있는 제품에 도달하는 데 필요한 통찰력을 제공할 수 있습니다. 따라서 실험을 수행하고 탐색을 수행하는 사람만이 그러한 통찰력을 갖게 됩니다. 보다 일반적으로, 어떤 문제에 가장 가까이 있는 사람들이 그 문제에 대해 가장 많은 통찰력을 가질 것이고, 따라서 그들은 일반적으로 문제를 해결할 수 있는 가장 좋은 위치에 있습니다.

회사 계층 구조가 높을수록 문제에서 멀어지고 실제 실험이 줄어들고 의사 결정에 대한 통찰력이 줄어 듭니다. 역설적이게도 그런 사람들은 주어진 문제를 해결하는 방법을 팀에 알려야 한다고 믿는 경우가 많습니다. 이것은 실수입니다. (설상가상으로 일부 소위 리더는 자신의 업무가 어떤 문제를 해결해야 하는지 팀에 알리지도 않습니다.)

우리가 새로운 것을 구축하는 한 복잡한 환경 에 처해 있으므로 성공으로 가는 길을 모색해야 합니다. 조사하고, 배우고, 구축하고, 반복하십시오. 아이디어를 확인합니다. 데이터와 일치하지 않는 가설을 폐기하십시오. 증거를 수집한 다음 그 증거를 사용하여 방에서 편향된 의견을 몰아내십시오. 문제는 문제를 만지작거리는 경험이 가장 많은 사람이 해결해야 하며, 문제가 있는 사용자와 대부분의 시간을 보냅니다. 그 문제에 대해 생각하면서 하루의 대부분을 보내는 사람들. 소프트웨어에서는 관리자나 일부 "비즈니스 이해 관계자"가 아니라 제품 팀입니다.

실수하지 마십시오. 실험은 팀 시간의 상당 부분을 차지하며 그 "낭비된" 시간에 반대하는 사람들이 있을 것입니다. 그러나 실험하지 않는다는 것은 배우지 않는다는 것을 의미하며, 복잡 하게도 학습은 필수입니다. 물론 구축하는 기능의 절반이 0의 가치를 생성하기를 원하지 않는 한. 그 사람들이 앞에서 논의한 잘못된 가정을 이해하도록 도와주세요.

원칙 #2 — 결과보다 결과

복잡한 세상 에서 산출물과 가치 사이에는 명확한 관계가 있으며 산출물은 가치보다 측정하기가 훨씬 쉽기 때문에 산출물은 대부분의 조직에서 중심 척도가 되었습니다. 공장에서는 생산 단위를 측정하고, 병원에서는 교체된 엉덩이를 측정하고, 소프트웨어 팀에서는 완료된 티켓을 측정합니다. 그 모델은 바뀌어야 합니다. 결국 중요한 것은 의사가 고관절 치환술을 올바른 절차에 따라 완료했는지 여부가 아니라 환자가 통증 없이 걸을 수 있는지 여부입니다. 중요한 것은 팀이 티켓을 완료했는지 여부가 아니라 제품이 최종 사용자에게 더 가치가 있는지 여부입니다.

우리는 사람들이 산출한 결과에 따라 사람들을 안내하고, 측정하고, 보상해야 합니다. "이탈 감소"와 같이 팀에 달성할 결과를 제공하고 문제를 해결하도록 합니다. 리더는 팀에게 무엇을 구축할지 지시하는 대신 팀에게 어떤 목표와 그 이유를 알려야 합니다. 즉, 전략을 설정해야 합니다. 목표가 목표로 위장한 기능이 아니라 의미 있는 비즈니스 목표인지 확인하십시오. 좋은 목표는 "우리 제품의 고수익 버전을 구매하는 고객의 점유율을 높이는 것"과 같은 것입니다. 나쁜 목표는 "우리 제품의 고마진 버전을 만들고 배송하는 것"과 같은 것입니다.

리더의 임무는 가치 있는 목표를 선택하는 것입니다. 팀의 임무는 거기에 도달하는 방법을 찾는 것입니다. 따라서 우리는 팀이 기능을 할당하지 않고 가장 중요한 작업을 수행하도록 했습니다.

원칙 #3 — 기한을 넘기는 타임박스

처음 두 가지 원칙을 적용한 후에 문제는 팀이 해당 비즈니스 결과를 개선하는 데 얼마나 오래 투자해야 하는지가 됩니다. "이동률 감소"는 "이 기능 제공"과 같은 방식으로 완료할 수 있는 것이 아니므로 기한이 이상해집니다. 현재 인기 있는 OKR 프레임워크(다음으로 심각하게 남용되는 유행어가 될 예정임)의 지지자들은 이를 해결하기 위해 시간 상자를 사용합니다. 본질적으로 팀은 결과에 대해 작업할 수 있는 몇 개월의 시간을 가지며, 그 후 리더는 팀이 다음 달 동안 어떤 결과에 집중해야 하는지 결정합니다. 매우 간단합니다.

안타까운 사실은 기한을 없애고 싶은 만큼 기한이 필요할 때가 있다는 것입니다. GPDR은 지정된 날짜에 발효되었으며 우리가 구축해야 하는 규제 중심의 모든 것에 대해서도 마찬가지입니다. 때때로 시장 진출에는 기한이 필요합니다. 이러한 경우 기한을 사용할 수 있습니다. 규칙이 아니라 예외라는 점을 기억하세요.

원칙 #4 — 반복을 위한 시간 허용

위의 세 가지 원칙에 따라 팀은 특정 시간 제한 기간 동안 비즈니스 결과를 개선하기 위해 노력해야 합니다. 그 기간 동안 프로덕션에 무언가를 릴리스하면 관리자는 다음 작업으로 넘어가고 싶어질 수 있습니다. 하지 않다. 이 시점에서 팀은 릴리스가 실제로 비즈니스 결과에 바늘을 이동했는지 확인해야 합니다. 반복해야 합니다. 그들은 배움을 취하고 그것을 사용하여 비즈니스 결과를 개선하는 더 나은 방법을 찾아야 합니다. 제한 시간이 만료된 경우에만 동일한 목표를 위해 계속 작업할지 아니면 다음 기간에 개선을 시작하기 위해 다음으로 가장 중요한 비즈니스 결과를 선택할지 결정할 때입니다.

결과 기반 로드맵

네 가지 원칙을 결합하면 복잡한 환경 에서 로드맵이 어떤 모습이어야 하는지 , 즉 기본적으로 모든 제품 로드맵이 어떤 모습이어야 하는지에 대한 좋은 아이디어를 얻을 수 있습니다.

1. 팀이 문제 해결 방법을 조사하게 하십시오.

2. 달성해야 할 비즈니스 결과를 팀에 할당

3. 주어진 결과를 개선하기 위한 노력을 시간 제한

4. 팀이 반복하도록 허용

다른 말로 표현하면, 부정을 통해 우리는 습관적으로 하는 일 중 일부를 버려야 합니다.

1. 팀에게 문제를 해결하는 방법(즉, 세부 사항 관리)을 말하지 마십시오.

2. 팀에 기능 할당 중지

3. 기한 사용 중지 — 반드시 필요한 경우에만 기한 사용

4. 앞으로 몇 달 이상 팀의 작업 계획을 세우지 마십시오.

마지막으로 제품 로드맵이 너무 자주 수행되는 방식에 대한 대안을 그릴 수 있습니다. 극적으로 달라 보이지 않을 수도 있지만, 겉보기에 사소해 보이는 차이가 어떻게 사고 방식의 주요 변화를 나타내고 오늘날 제품 조직에서 가장 일반적인 문제 중 일부를 해결하는 데 도움이 되는지 이제 이해하셨기를 바랍니다.

이제 이 (이미 너무 긴) 텍스트를 마무리할 시간입니다. 유용한 학습에 도움이 되었기를 바랍니다. 그리고 저는 여러분이 전통적인 제품 로드맵에서 벗어나 대부분의 제품 사람들이 활동하는 복잡한 세계 에 훨씬 더 적합한 것으로 전환하는 데 동참하기를 진심으로 바랍니다 .

주소 니술라

컨설턴트, 넷라이트 헬싱키

추가 정보

위 게시물의 많은 아이디어는 내 머리가 아닌 다른 곳에서 시작되었습니다. 7년 이상의 컨설팅 경험과 Netlight 동료들과의 깊은 대화 외에도 책, 팟캐스트, 강의 및 기타 출처에서 많은 정보를 얻습니다. 여기에는 다음이 포함됩니다.

영감 Marty Cagan
Escape the Build Trap: Melissa Perri
Product Thinking 팟캐스트
The Product Experience 팟캐스트
Lenny의 팟캐스트
Lenny의 뉴스레터
Radical Focus: Christina Wodtke
Art of Action: Stephen Bungay
Bruce Maccarthy의 프레젠테이션
Black Swan: Nassim Nicholas Taleb
The Cynefin Framework