How Roadmaps Accidentally Make Teams Powerless / 로드맵은 어떻게 우연히 팀을 무력화 시키는가?

https://bootcamp.uxdesign.cc/how-roadmaps-accidentally-make-teams-powerless-848dad373b1a

How Roadmaps Accidentally Make Teams Powerless

팀을 무력하게 만들며, 팀으로부터 도망치게 만들고 싶게 만드는 로드맵의 네 가지 흔한 함정들:

 

프로덕트의 로드맵을 봤을 때, 당신의 가장 흔한 리액션은 무엇인가?

 

내 감정은 불안과 공포라고 말하고 싶다. 매 분기가 끝나갈때마다, 나는 굉장히 불안해진다. 이유는 항상 동일하다: 최고 경영 관리 조직은 로드맵을 보여주고, 나는 뭐가 나올지 모르니 긴장하는 거다.

로드맵은 대부분의 경우 나를 어쩔줄 모르게 하는데, 그 기대를 어떻게 전달해야할지 모르겠기 때문이다. 나는 무력감을 느끼고 때때론 직업을 잃을 것 같다는 두려움이 들 때도 있다.

로드맵 프레젠테이션 자리에서, CEO가 "전 당신이 이 모든걸 가능하게 할거라 믿어요, 이 프로젝트를 잘 끝내지 못하면 우리는 다 채용시장에 나가야해요"라고 말했다. 로드맵은 각 팀에게 할당된 대규모의 기능들 리스트로 가득했다. 그 때 궁금해진게, "아니, 어떻게 이게 애자일하게 굴러갈 수가 있지? 시도하고 배우는 단계는 어딨는거야?"였다.

이 이야기가 그리 놀랍지 않게 들릴 수도 있다. 아마 비슷한 상황에 처해본 적이 있기 때문이겠지. 그렇지 않다고? 뭐, 이 일을 겪는 건 시간문제다. 내가 배운건, 로드맵은 디자인의 악이 아니라는 거다. 그저 몇몇 사람들이 일을 다르게 해본 경험이 없어서, 우연히 잘못 만들어진 것이다. 

팀을 위험에 빠트리는 로드맵의 네가지 이유를 가볍게 살펴보자. 그리고 실제로 그것을 어떻게 개선시킬지도. 이 아티클 말미에서 바로 실행할만한 인사이트를 얻길 바란다.

 

1. 기밀의 로드맵

아래 그림을 보라. 어떻게 해석이 되는가?

 

이 이미지는 로드맵과 관련한 내 경험 중 중요한 부분을 보여준다. 보통 상황은 이런 느낌으로 진행된다:

• 최고 경영관리 조직은 무엇이 가장 큰 문제인지 평가하기 위해 모인다.
• 그들은 단기/중기/장기적 관점에서 가능성을 판단한다.
• 그들은 아이디어와 잠재적인 솔루션들을 맞바꾼다.
• 그들은 로드맵의 다음 스텝에서 어떻게 갈것인지 합의한다.
• 그들은 누가/무엇을/언제 할지 결정한다.
• 그 멋진 플랜을 다 만들고 나면, 그 로드맵을 스크럼 팀에게 넘긴다.
• 스크럼 팀은 로드맵의 구체화 과정에 없었으니, 로드맵을 받고 나선 압도되어 어쩔줄 모른다.
• 최고 경영관리 조직은 그들이 정의내렸던 것들을 스크럼 팀이 잘 풀어나가길 바란다.
• 스크럼 팀은 혼란스러워한다. 애초에 풀고자 했던 문제들에 대해 인지하지 못하고 있었기 때문이다.

그 결과는? 불 보듯 뻔하지. 모든 과정에 좌절이 생긴다. 최고 경영관리 조직은 팀이 데드라인을 못지키는데 화가 날거고, 스크럼팀은 그들이 풀어야 하는 문제에 대해 어떤 결정도 내릴 수 없기 때문에 무력감을 느낄 것이다.

로드맵이 펜스 너머로 던져졌을 때, 모두가 고통받는다. 이 과정으론 어떤 값진 것도 나올 수 없다.

 

2. 더 많은 '기능'이 문제다

당신에게 있어 전형적인 로드맵이 있는가? 나에겐 제작해야 할 기능 리스트가 그 전형적인 로드맵이다. 온라인 쇼핑몰을 예로 들어보자. 그럼 그 기능 리스트는 다음과 같다 :

• 추천인 프로그램
• 장바구니와 결제 단계에서 다른 물건 추천
• 별점과 리뷰

몇년 전, 내 팀에서 일할 때 한 분기의 하이레벨 로드맵으로 받았던 것들이다. 이걸 보고서 "뭐가 문제지? 각각의 기능마다 어떻게 해결할지 결정을 내릴 수 있잖아."라고 말할 수도 있겠다.

그러나 기능 위주의 로드맵엔 추정 문제가 발생한다. 추천인 프로그램을 예로 들어보자. 추천인 프로그램은 '아웃풋(생산, 출력)'이지, 결과가 아니다. 추천인 프로그램을 만든 목적은 고객을 데려오는데 발생하는 비용을 줄이기 위함이며, 여러가지 다른 방법으로 달성될 수 있다. (즉 어떤 목적을 달성하고자 하느냐가 중요하지, 목적을 달성하기 위한 특정 기능을 만들자가 로드맵이 되어선 안된다는 것)

로드맵이 아웃풋에만 집중되어 있으면, 팀은 무언가를 해결하는 목적으로만 일할 수 있다. 그러나 로드맵이 '결과'를 정의한다면, 팀은 더 좋은 더 좋은 솔루션을 찾아나서는 여유를 가질 수 있을 것이고, 목표하는 결과를 향할 수 있을 것이다.

아웃컴 중심 업무는 가치를 만드는 기회를 주고, 아웃풋 중심 업무는 이상한 결과물을 내는 확률을 최대화 한다.

아웃풋(생산)과 아웃컴(결과) 로드맵의 차이를 살펴보자.

• 아웃풋 : 프로덕트의 디테일 페이지나 장바구니 화면에서 보이는 상품 추천 도구
• 아웃컴 : 이번 1분기 말까지 장바구니의 담긴 물건의 양을 10% 늘리기.

아웃풋 로드맵은 팀이 솔루션을 제작하는 데 중점을 맞추고, 아웃컴 로드맵은 팀들이 문제를 푸는 데 권한을 준다.

 

3. 콜라보할 여유가 없다

완벽한 세상에선 ㅡ 팀들은 자동 조직화되고 가치를 자체적으로 전달한다. 하지만 현실 세상에선 팀은 다른 팀에게 의존해 가치를 생산한다. 나는 조직이 팀들에게 한 줄로 책임을 부여하도록 하지만, 이 과정은 레거시나 다른 요소에 의해 시간이 오래 걸릴 수 있다.

아마 당신은 디자인 로드맵이 다른 팀 의존 없이 로드맵을 그리는게 불가능한지 궁금해 할 수도 있겠다. 혹은 최소한 현실적인 숫자만을 반영하지 못하는지도 궁금할 수 있겠지. 사실 그게 맞다. 일반적으로, 이 로드맵엔 아주 많은 의존들이 포함되는데, 이들을 만든 사람이 의존에 대해 아예 인지하지 못했기 때문이다. 

로드맵은 스크럼 팀과 최고 경영 관리 조직이 함께 만들 때 콜라보할 더 좋은 기회를 준다. (솔직히 이 단락 이해못하겠어서 쿨타임 가지고 다시 번역해봐야 함)

 

4. 계획과 관계 없는 로드맵

세상의 얼마나 많은 로드맵들이 계획과 관련없이 만들어지는걸 알면 믿기 어려울 것이다. 로드맵이 영향력 있는 주주들의 '위시리스트'가 되면, 팀에게 기대할 수 있는건 의미없는 결과일 뿐일 것이다. 명확한 예시를 들어보자. 나는 스케일 업에 참여했으며, 우리의 계획은 고객에게 도달하는 지점을 늘리는 것이었다. 그게 일년간 revenue를 buying하는걸 의미할 지라도. 내가 처음 로드맵을 봤을 때, 내가 봤던 건:

• 프로덕트의 상세 페이지 리디자인
• 검색 경험 리디자인
• 장바구니와 결제 리디자인

이 리디자인과 계획(스케일업)의 관계가 대체 뭔가? 일단 우리 팀의 결론은 : 없다. 였다. 이런 현상이 왜 발생했는가? CPO(최고 프로덕트 관리자)가 UX 리더에서 CPO로 승진했기 때문이다. 그는 프로덕트의 전반적인 계획보단 사용자의 경험을 더 중시했기 때문이다.

그럼 프로덕트 계획과 관계없는 로드맵의 문제는 뭘까? 스크럼 팀은 그들이 앞으로 어떻게 할지와 회사가 제일 고민하고 있는 것을 연결시키지 못한다는 것이다. 이 경우에, 당신은 물론 사용자 경험이 중요하다 할 수도 있겠다. 인정한다. 그러나 John Wick이 말했던 것을 다시 상기해보자. "선택과, 선택에 따른 결과."

계획은 무시할만한 것이 아니며, 팀이 매일매일 할 일에 결정을 내리는 데 도움을 주는 것이다.

 

함정들을 제거하고 의미있는 로드맵을 만들기

당신의 로드맵이 상술한 네가지 요소 중 하나라도 가지고 있다면 함정 지도를 갖고있는 셈이다. 확실하게 할 것은 당신 앞의 문제다. 그것은 그렇게 되선 안된다.

나는 현 상황을 최대한 받아들이려고 했다. 나는 내가 최고 경영 관리 조직이 일하는 방식을 바꿀 수 없다고 생각했다. 이윽고, 나는 내가 틀렸다는 것도 알았다. 당신이 진실로 무언가를 더 잘하기를 의도한다면, 사람들은 당신의 말을 들을 것이다.

여기 로드맵을 바꿀만한 네가지 팁이 있다 :

• 질문해라 : 아웃풋 로드맵을 받았다면, 다른 사람들이 묻지 않는 질문을 하는데 거리낌이 없어야 한다. 데드라인에 크게 영향받지 마라 : 결국 달성하고자 하는 목적에 신경써라. 솔루션이 어떤 가치를 만들어내는지 이해하는 데 총력을 다하라. 당신이 목적을 확실히 이해했을 때, 아웃컴(결과)를 향하는 다른 방안을 제시할 수 있을 것이다.
• 책임을 다해라 : 바라지 않은 결과를 냈을 때, 담대해져라. 그리고 팀원들로 하여금 솔루션을 제작하는게 아닌 원하는 결과를 향할 수 있도록 가이드하라. 당연히 저항을 마주하겠지만, 작은 '실험'에 초점을 맞추면 승인을 받을 수 있을 것이다. 이게 자신감을 보여줄 수 있는 키가 될 수 있다.
• 방안의 코끼리에 대해 말하라 : 아웃풋 중심의 로드맵이 의미없는 결과를 만들어내지만, 이에 대해 말하지 않는다는건 대부분의 팀이 알 것이다. 당신은 컨설턴트 역할로, 현재 접근 방식과 더 좋은 대안을 제시하며 잠재적인 결과를 공유할 수 있을 것이다. 가치있는 결과에 도달하고자 한다는 걸 확실히 하고, 아웃컴(결과) 중심의 업무를 추천해라. 그러나 최고 경영 관리 조직이 어떤 길을 선택할 것인지 선택권은 그들에게 남겨둬야 한다.
• 협업(콜라보레이션) : 로드맵 제작에 참여할 수 있을지 물어라. 스스로 로드맵 제작 단계에서 숨거나 하지 마라. 내가 알게된 대부분의 리더 팀은 로드맵을 혼자 짰었는데, 그건 그게 그들의 일이라고 생각했기 때문이었다. 내가 참여 여부를 물었을 때, 그들은 나를 환영하며 변화하는 데 열려있었다.

대부분의 로드맵은 회사가 더 좋은 길로 가기 위한 전문지식이 없기 때문에 그저 거기에 머물러 있다. 현재 상태가 당신을 한계짓지 않도록 해라. 당신은 그것을 바꿀 기회가 있다.

 

 

 

 

---

원문

 

Four usual traps with roadmaps that make teams helpless and how to escape from them.

What’s your common reaction when you see your product roadmap?

I’d summarize my feelings as anxiety and fear. As we got closer to the end of the quarter, I often got anxious. The reason has always been the same: top management would present the roadmap, and I would get nervous as I didn’t know what to expect.

Most times, the roadmap made me panic because I had no idea how to deliver on the expectations. I felt powerless and even feared losing my job. 

Once during a roadmap presentation, the CEO said, “I count on all of you to make it possible. We may all go to the job market if we cannot get this done.” The roadmap had an extensive list of features for each team. I wondered, “How can this be agile? Where’s the learning part?”

This story may not surprise you. You’ve probably been in a similar situation already. If not, it’s just a matter of time. I learned that roadmaps aren’t evil by design—they are accidentally miscreated because some people simply lack the experience to do things differently.

Let me walk you through four common reasons roadmaps trap teams and how you could improve them. I hope you get some actionable insights by the end of this read.

1.  The Top Secret Roadmap

Please, have a look at the following image. How do you interpret it?

Throwing roadmaps over the fence — Author’s courtesy — d-pereira.com

 

This image represents a significant part of my experience with roadmaps. It goes more or less like this:

1. Top management gets together to evaluate what matters most
2. They assess possibilities for the short, medium, and long term
3. They exchange ideas and potential solutions
4. They agree on what will go into the following roadmap
5. They define who does what by when
6. After crafting a shiny plan, they throw it to Scrum teams
7. Scrum teams get overwhelmed by the roadmap as they weren’t part of its conception
8. Top management expects Scrum teams to deliver on what they defined
9. Scrum teams feel confused because they are unaware of the problems they have to solve

What’s the result of that? Frustration on all layers. Top management will be mad when teams cannot meet deadlines, and Scrum teams will feel powerless as they cannot make any decision beyond the solution they have to deliver.

When roadmaps are thrown over the fence, everyone suffers. Nothing valuable comes out of that.

2.  More Features Is All That Matters

What’s a typical roadmap for you? For me, it used to be a list of features to deliver. Let me give you an example from an online shop:

• Referral program
• Product recommendation at cart & checkout
• Rating & review

That’s the high-level roadmap I got for a quarter with one of my teams some years ago. You may look at this and say, “What’s the problem with that? You can still make decisions on how to implement a solution for each one of the items.”

The problem with a feature roadmap is assuming impact. Take the referral program as an example. That’s an output, not an outcome. The goal behind this was to reduce customer acquisition costs, and it could be achieved in different ways.

When roadmaps focus on output, teams can only work on the solution space. But when roadmaps define outcomes, teams have room to discover better solutions that can drive the desired outcomes. 

Outcome orientation increases the chance of creating value, while output orientation maximizes the odds of delivering crap.

Let me make a comparison between an output and outcome roadmap.

• Output: Implement product recommendations on the product detail page and cart.
• Outcome: Increase average basket size by 10% by the end of Q1.

The output roadmap forces teams to implement a solution, while an outcome roadmap empowers the team to solve a problem.

3.  No Room for Collaboration

In the perfect world, teams are self-organizing and can autonomously deliver value. In the real world, teams depend on other teams to create value. I encourage organizations to give teams end-to-end responsibilities, but this journey may take a while due to legacy and other aspects.

No matter the reality you’re in, collaboration is mandatory for success. Unfortunately, most roadmaps are too extensive and leave no room for collaboration. This situation is horrible because teams need one another and know if they help each other, they won’t conclude their roadmap. 

You may wonder, why not design roadmaps without dependencies? Or at least reduce them to a realistic number? You’ve got it right. Generally, too many dependencies are part of the roadmap because those who crafted it were unaware of dependencies.

Roadmaps will have better chances of fostering collaboration when Scrum teams and top management craft them together.

4.  Unrelated to Strategy

It’s unbelievable how many roadmaps have no relation whatsoever with strategy. When roadmaps become a wishlist from influential stakeholders, you can only expect teams to deliver pointless results.

Let me give you a clear example. I joined a scale-up, and our strategy was to expand our reach, even if that would mean buying revenue for a year. When I first looked at the roadmap, here’s what I saw:

• Redesign product detail page
• Redesign the search experience
• Redesign the cart & check-out

What’s the relation of such a massive redesign with the strategy? In our case: none. Why did that happen? The Chief Product Officer (CPO) was recently promoted from UX Lead to CPO. She cared more about user experience than product strategy. 

What’s the problem with a roadmap unrelated to product strategy? Scrum teams cannot connect their actions to what matters most for the company. Taking my example, you may say that user experience is also important, and I agree. But as John Wick wisely said, “Choices. Consequences.” 

Strategy isn’t something to ignore, but it’s something to help product teams make decisions on their daily activities.

Moving From Trap Maps to Meaningful Roadmaps

You have a trap map when your roadmaps have any of the four elements I mentioned above. Your only certainty is trouble ahead of you. It doesn’t have to be that way.

I used to perceive the status quo[현 상태] as ultimate. I thought I couldn’t influence top management to change how they work. In time, I learned I was wrong. When you genuinely intend to do something better, people will listen to you. 

Here are four golden tips on how to change roadmaps for the better:

1. Ask Questions: When you receive an output roadmap, don’t be shy about asking questions no one asks. Don’t bother about deadlines; care about understanding the desired outcome. Strive to comprehend what the solution aims to create. As you learn that, you can offer different ways of driving the outcome.
2. Take Responsibility: As you uncover undesired outcomes, be brave and offer to guide the team on delivering the result instead of implementing the solution. You will face resistance, that’s for sure, but you can get buy-in[승인] if you aim for a small experiment. It’s key to show confidence.
3. Talk About the Elephant in the Room: Almost all teams know that an output-oriented roadmap will create pointless results, but they don’t speak up. You can play the consultant role, share the potential results with the current approach and offer a better alternative. Make it clear that you want to achieve valuable results and recommend outcome orientation, but let top management decide which direction to take. 
4. Collaboration: Ask to be part of the roadmap creation. Don’t hold yourself back from it. Most leadership teams I got to know created roadmaps alone because they thought it was their job. When I asked to be part of it, they welcomed me and were open to change. 

Most roadmaps are the way they are because companies lack the expertise to do it in a better way. Don’t let the status quo limit you. You’ve got a chance to change it. 

https://www.goretro.ai/post/product-roadmap-traps-to-avoid

How Roadmaps Accidentally Make Teams Powerless