화성에서 온 maker, 금성에서 온 stakeholder

8개월전쯤에 회사 위키에 적었던 글.

Stakeholder와 Maker 사이에서 일하면서 

사용자를 대변하기도 해야하는 Product manager는

때론 힘들기도 하고 때론 큰 보람을 느끼기도 한다.

오랫만에 다시 읽어보니 

감회가 새롭다.

---

#_01

• '화성에서 온 남자 금성에서 온 여자'라는 오래된 베스트셀러가 있습니다. 
  읽은지 오래되어서 내용이 잘 기억이 나지는 않지만, 서로의 다름을 인정하고 이해하기 위한 노력을 얘기했던 걸로 기억합니다.
  남자와 여자의 특성은 맞고 틀림이 아닌 다름이기 때문에 완전히 서로를 바꾼다는 것은 거의 불가능에 가깝습니다.
  대신에 서로를 이해하려는 노력으로 그 간극을 줄여나가는 것이 가장 현실적인 해결책이라고 생각합니다.

• 프로덕을 만드는 사람들과 요청사항을 내는 사람들도 관계도 마찬가지인 것 같습니다
   - 화성에서 온 maker, 금성에서 온 stakeholder

#_02

• 프로덕트 매니져로써 이 글을 적습니다.

• 경력이나 경험을 내세워서 설득을 하거나 주장하는 것을 개인적으로 좋아하지 않습니다. 
  고백하자면 병적으로 회피하는 경향까지 있습니다. 때로는 그런 것이 가장 쉽고 효율적일 때가 있음에도 불구하고 말입니다. 

• 경력, 경험, 자리 같은 것들이 영향력이나 권위를 만들어주는 것은 아주 잠깐입니다. 사람의 본질은 곧 드러나고 누구나 알게됩니다.
  특히나 경험은 지극히 개인적인 것들이기 때문에 나의 경험을 타인이 쉽게 공감할 수 없습니다. 그러기에 그것이 사람을 움직이기는 매우 어렵습니다.
  그리고 특정한 경험을 기반으로 한 논리와 주장은 타인의 다른 경험으로 너무나도 쉽게 반박될 수 있습니다. 결국 답없는 평행선이 되고 맙니다. 

#_03

• 하지만 오늘은 프로덕과 관한 일을 해온 경험과 시간들을 기반으로 이야기를 하려고 합니다.

• 긴시간동안 일을 하며 느꼈던 만드는 사람들과 요청하는 사람들의 특성에 대해 공유 드리고, 

• 서로를 조금 더 이해하고, 오해와 간극을 줄여 궁극적으로 좋은 협업관계를 만드는 것이 이 글을 적는 저의 목적이자 바람입니다.

#_04

• 위키를 꼭 써야하나요? 이미 구글 닥스로 충분히 잘 쓰고 있는데, 굳이 이런 새로운 툴을 왜 도입해야 할지 모르겠어요.

• 지라가 너무 어려운데, 꼭 이걸 귀찮게 써야 하나요? 너무 복잡해요. 그냥 트렐로 쓰면 안되요?

• 스크럼을 왜 굳이 매일 해야하나요? 한 일/한 일 공유를 매일해야해요? 시간낭비 같아요. 일주일에 그냥 한번 정도만 하면 안되나요?

• 1년전 쯤 새로운 툴들과 프로세스를 처음 도입할 때 많이 주셨던 피드백들 중의 일부입니다. 현 시점에도 위 질문들은 여전히 유효할 수도 있습니다.
  지금의 우리의 일하는 방식이 최선이 아닐수도 있지만, 적어도 위의 물음표들에 대해 그때와 지금의 체감은 달라졌다는데에는 공감하시리라 믿습니다.

• 당시의 준비는 그 당시를 위함이 아닌 지금을 위한 것이었습니다. 
  작년에 비해 사업적으로 그리고 조직적으로 엄청난 성장을 한 지금 툴과 프로세스가 없고 우리가 익숙하지 않았다면 어떤식으로 일을 하고 있을지 상상하기 어렵습니다.

• 스타트업이라는 것이 당장 몇 달 후의 상황을 알기 어렵다고 하더라도 누군가는 더 멀리내다보고 고민을 해야한다고 생각합니다.
  그 고민을 하는 사람이 누구냐가 중요하기 보다는, 누군가가 고민을 하고 있느냐 없느냐가 훨씬 더 중요한 것 같습니다.

• 작년의 고민이 저러했다면, 이제는 좀 더 어려운 고민을 미리, '함께' 준비하고 싶습니다.

#_05

• 적당히 일하면서 쉽고 편한 직장 생활을 위해서 스타트업에 계신 분은 없으실거라고 생각합니다.
  모두 다 맡은 업무와 다양한 이슈들 속에서 치열하게 일하며 시간을 보내고 계신걸 잘 알고 있습니다.

• 다양한 팀과 중요한 업무들이 많음에도 불구하고 굳이 프로덕만 왜 예외적인 취급을 받아야하는지, 
  굳이 이런 글까지 읽고 있어야 하는지 이해가 되지 않으실 수도 있습니다.

• 인터넷과 온라인을 기반으로 한 비즈니스에서는 프로덕이 고객과의 유일한 접점이고 가치를 제공하며 수익을 내는 수단이기 때문입니다.
  사업은 프로덕 없이는 사용자를 만날 수 없습니다. 프로덕은 가치를 제공해서 수익을 내지 못하면 계속 존재할 수 없습니다.

• 프로덕을 둘러싼 두 개의 그룹이 존재합니다.
  프로덕을 만드는 maker 그룹과, 사업/마케팅/운영 등 요청사항을 내는 stakeholder 그룹입니다.

#_06

• maker와 stakeholder 그룹은 정말 다른 특성을 가지고 있습니다. 틀림이 아닌 다름을 강조하고 싶습니다.

• 이런 차이는 우리만의 이야기가 아닌 일반적인 특징들과 속성들입니다.

• '내가 지금 편한건 누군가가 그 고생을 대신해주기 때문이다'라는 말이 있습니다.

• 조직과 사업의 규모가 작을 때는 누군가의 노력으로 빈자리를 메꿔가며 일이 되도록 만드는 일이 가능합니다.

• 하지만 그 규모가 성장하는 순간, 그 누군가로는 더 이상 불가능합니다. 절차와 프로세스 그리고 구성원 모두의 더 높은 이해도를 필요로 합니다. 그런 것들이 결국 문화로 자리잡게 됩니다.

• 경험해보지 못한 것을 단지 상상만으로 받아들이는데에는 한계가 있다는 걸 잘 알고 있습니다. 사실 경험해보지 못한 것은 상상할 수도 없습니다.

• 그래도 때로는 경험한 누군가는 그 길이 옳다고 이야기해야 합니다. 그 시행착오와 어려움을 감수하면서.

  

For Stakeholders

 

#_07

• Stakeholder분들께, 먼저 아래 세 가지를 꼭 기억해주시기 부탁드립니다.
  1) 나는 요청자 중에 하나이고, 나의 요청은 많은 요청 중에 하나이다.
  → 요청사항의 중요도과 시급도는 충분히 이해합니다만, 그것이 처리되어야 할 유일한 단 하나의 요청이 될 수는 없습니다.
  
  2) 현재 많은 작업들이 병렬적으로 진행 중이다.
  → 이미 maker 분들은 부지런히 작업 중이세요. 당장 착수할 수 있는 작업은 사실 거의 없어요.
  
  3) 이 것을 하면, 저 것을 할 수 없다.
  → 시총 560조에 개발조직 규모가 2만명인 아마존도, 여전히 개발 리소스는 부족합니다.
  → 현실적인 리소스의 제한 때문에, 동시에 진행할 수 있는 과제에는 한계가 있습니다. 무조건 밀어넣는다고 답이 나오는 건 아닙니다.

   

#_08

• 문제와 해결책 그리고 HOW - 이거 정말 간단한 요청인데 금방 해주시면 안되나요?
  → 보통의 대답은 '네, 어렵습니다.' 입니다. 아래와 같은 이유 때문입니다.
  
  

  • 1) 정말 간단한 요청인지는 maker가 판단해야 합니다

    • 정말 단순한 텍스트를 변경하는 요청이라고 해봅시다. 

      • 이 텍스트가 서버에서 내려주는 메세지인지, 웹과 앱에 박혀있는 텍스트인지 확인을 해봐야하고요.

      • 이에 따라 플랫폼별 개별적인 변경이 필요한지, 아니면 공통으로 한번에 변경할 수 있는건지, 
        그리고 변경시점은 꼭 한번에 되어야 하는건지 혹은 순차적으로도 가능한지 고려가 필요합니다.

    • 겨우 텍스트 하나 바꾸는데도 이렇게 복잡하게 여러가지를 고려해야 하냐고요?
      네. 원래 프로덕은 만들어지는 방식입니다. 저희만 유별난게 아니라 모든 회사의 프로덕이 비슷한 과정을 거칩니다.
      
      

  • 2) 정말 간단한 변경이라 하더라도 고려할 사항들이 무척이나 많습니다. 

    • 진행 중인 다른 과제의 순서를 망가뜨릴 수 있습니다.

      • 일반적으로 과제들은 기획 → 디자인 → 백앤드(서버) → 클라이언트(웹/앱)의 순서로 개발이 진행됩니다.

      • 하지만 항상 앞단계의 작업이 끝난 이후에 착수되는 것은 아니며 병렬적으로 복수개의 과제들이 진행됩니다.

      • 즉, 내가 맡은 일은 일의 끝이 아니라 중간 단계이며, 나의 작업 이후에 다른 사람이 작업을 진행해야하는 경우가 대부분입니다.

      • 나의 급작스런 작업 순서의 변경이 다른 모든 과제의 순서와 일정을 변경시킬 수 있습니다. 
        물론 그렇지 않을 수도 있지만 리스크를 방지할 수 있다면 최대한 막는 것이 맞다고 봅니다.

    • 잦은 스위칭 비용은 업무의 효율을 낮춥니다.

      • 어느 직무든간에 업무 전환간 스위칭 비용이 발생합니다만, 작은 시간 덩어리를 모두 합쳐놓는다고 긴 시간의 연속적인 시간과 같지는 않습니다.
        가능하면 스위칭 비용을 최소화하는 룰과 프로세스를 만들려고 노력하는 것이 좋다고 생각합니다.

#_09

• 언제나 프로덕은 현재 진행형 - 우리 회사 프로덕에서는 이것도 안되고 저것도 안되서 이걸 할수가 없어요. 저 회사의 프로덕에서는 그거 되던데요.

  • 위 문장을 몇 가지 버전으로 변형해 보겠습니다.

    • 우리 회사 사업 수익률은 왜 이렇게 낮아요? 상품 수수료를 더 높게 받아서 수익을 많이 내면 안되요?

    • 우리 회사 컨텐츠 마케팅을 좀 더 활발히 할 수 없나요? 저 회사는 엄청 많이 찍어내던데 우리도 많이 돌려서 새로운 고객들을 획득하면 안될까요?

    • 우리 회사 근무 환경과 복지는 이것밖에 안되나요? 저 회사는 이런 복지도 있고 이런 제도도 있어서 좋아보이던데 우리도 만들면 안되나요?

  • 프로덕을 만드는 일이 다른 조직과 다른 것은 만드는 사람은 특정 인원으로 한정되어 있지만, 
    누구나 그 직접적인 사용자가 되고 피드백을 줄 수 있다는 것인데요.

  • 건설적인 피드백과 개선의견, 혹은 버그나 오류 등의 제보는 얼마든지 환영합니다만, 
    저런식의 이야기는 결국 함께 일하는 동료에게는 매우 실례가 되는 이야기라고 생각합니다.

  • 누구보다도 프로덕을 만드는 사람들이 그것을 왜 못하고 있는지, 혹은 왜 미뤄지고 있는지 가장 잘 알고 있고 마음 아파하며 고민하고 있기 때문입니다.

  • 우리의 고객은 그 어떤 피드백이라도 자유롭게 할 수 있습니다만, 
    최소한 함께 일하는 우리는 사내의 공적인 미팅 자리 등에서는 저런 식의 이야기는 지양해주셨으면 좋겠습니다.

  • 프로덕은 마치 생물처럼 이 시간에도 끊임없이 바뀌며 개선되고 있습니다.

  • 아직도 많이 부족하고 갈 길이 멀다는 걸 잘 알고 있습니다. 더 열심히 달릴테니 함께 해주세요.

#_10

• 요구사항에 관하여 - 누가보더라도 같은 이해를 할 수 있는 명시적인 문장으로

  • 논리적으로 설명할 수 있는 모든 것들은 모두 프로덕으로 구현할 수 있습니다.

  • 이 논리적이라는 것은 사고의 영역보다는 공유와 표현의 영역에 가깝습니다 - 내 생각을 타인에게 전달하는 일

  • 아이디어는 누구나 생각할 수 있지만, 결국 중요한 것은 실제 실행능력입니다. 

  • 머릿속에 있는 요구사항을 실제 글로 써보고, 또 말고 타인에게 전달하는 것은 모두 완전하게 다른 일입니다. 당연히, 후자로 갈수록 더 어려운 작업입니다.

  • 서식이나 포맷은 관계 없습니다. 어떤 분이 작업하시더라도 이해할 수 있는 명확한 요구사항을 문장으로써 전달을 부탁드립니다.

#_11

• 피드백과 의사결정에 관하여 - 요구사항이나 추가적인 피드백은 기본적으로 기획단계까지, 그 이후에는 최소화

  • 요구 사항을 통해서 풀려는 문제와 그 해결책을 정의합니다.

  • 기획 단계에서 사용자에게 제공되는 기능과 예상되는 이슈나 리스크 혹은 정책적인 내용들을 결정합니다.

  • 최소한 기획 단계가 마무리 될 때는 요청자 stakeholder와 관련된 maker 모두 구현될 프로덕의 모습에 대한 같은 그림을 그리고 있어야 합니다.

  • 디자인 산출물이나 실제 개발을 통한 동작되는 프로덕을 확인하기 전까지 피드백을 할 수 없는 건 태도나 노력의 문제입니다.

  • 프로덕을 만드는 maker 분들은 다른 전문성을 가진 우리의 같은 동료입니다.

  • 단순한 요청사항을 그대로만 구현한다면 maker분들이 존재할 이유가 없습니다. 

  • 프로덕을 만드는 maker 분들의 전문성을 기반으로 사용자에게 추가적인 가치와 경험을 제공하는 프로덕을 만들어가고 있습니다.
    그 과정에 있어서 세부적인 디테일까지 모두 결정 및 피드백을 받기는 현실적으로 어렵습니다.

  • maker분들을 믿어주시고 존중해주시고 응원해주세요.

#_12

• 일정에 관하여 - 그래서 언제 되요?

  • 사업/마케팅적인 플래닝 및 향후 추진을 위해 가능한 사전에 예측 가능한 일정을 공유드리는게 마땅합니다만,
    일정에 대한 에스티메이션을 하기 위해서는 명확한 요구사항 정리와 기획의 픽스가 필요합니다.

  • 명확한 요구사항으로 기획이 픽스되었다면 뒤에 후속작업들에 대한 플래닝 및 순서를 정하기가 수월해지고 전반적으로 명확하게 일정을 공유드릴 수 있겠습니다.
    그리고 그 일정을 준수하는 신뢰도를 달성하기도 수월할 것 같고요.

  • 명확한 요구사항 정리와 빠른 피드백과 의사결정을 부탁드립니다.

For Makers

 

#_13

• 양보할 수 없는 프로덕의 가치에 대하여 - 사업 vs 프로덕?

  • 프로덕은 사용자를 만나는 접점이자, 가치를 제공하고 수익을 일으키는 수단입니다.
    maker는 프로덕을 만드는 입장으로 사용자에게 제공하는 경험에 대해 타협할 수 없는 가치와 기준이 존재할 수 있습니다.
    그리고 그러한 주관과 기준은 maker에게 꼭 있어야 한다고 생각합니다.

  • 그렇기에 자연스럽게 때로는 그것이 사업적인 방향과 조금은 부딪히거나 다른 의견일 수도 있습니다.

  • maker로써 사용자 경험을 위하여 지켜야 할 가치와 기준에 대해서 고민하고 그것을 공유하고,
    서로 다른 의견이 있을 때는 논의를 통해서 결정을 내리는 것이 건강한 문화라고 생각합니다.

  • 그 과정은 단기적으로 괴로울 수 있습니다만, 괴로움에 외면이나 회피는 장기적으로 더 큰 문제가 되어 돌아옵니다.

  • 가까이 볼때는 서로 다른 방향을 향하고 있을 수도 있지만, 멀리서 보면 결국 같은 방향을 향할 수 밖에 없다고 생각합니다.

#_14

• 사업에 대한 관심 - 내가 하는 일이 무슨 의미가 있는거지?

  • 맡은 업무만으로도 하루는 빡빡하고 금방 지나갑니다. 회의에 이슈 처리에 몇 가지 일을 처리하다보면 오늘 하려고 했던 일은 밀리기 마련입니다.

  • 프로덕은 사용자를 만나고 가치를 제공해서 수익을 내는 수단입니다. 그리고 그 어떤 프로덕도 사업과 수익모델에서 자유로울 수 없습니다.
    아무리 아름답고 훌륭한 프로덕도 수익을 내지 못한다면 그 지속 가능성 및 영속성은 아무도 보장할 수 없습니다.

  • stakeholder와 같은 수준으로 그리고 그 만큼의 노력과 시간을 쏟아 이해할 수는 없습니다. 그래서도 안되고요.
    하지만 최소한의 이해 하려는 노력은 필요하고 아주 중요합니다.

  • 사업적인 기본에 대한 이해를 기반으로 한 이견과 논쟁은 얼마든지 가능하고 생산적이지만, 그 시도조차 없는 무조건적인 반대는 그저 반대를 위한 반대입니다.

  • 결국은 그 사업적인 이해가 maker로써 만드는 프로덕에 대한 의미와 동기부여에도 도움이 된다고 생각합니다.

#_15

• 일이 되도록 만드는 것이 일 - 다 차려진 밥상을 먹기 vs 밥상을 같이 차려서 먹기

  • 대기업은 프로세스를 기반으로 움직입니다. 조직도 크고 사람도 많고, 프로세스 없이는 효율적으로 일하기 어렵습니다.

  • 내가 할 일의 정의와 범주가 명확하고, 거기까지만 끝낸다면 나의 일은 끝납니다. 장점도 있고 단점도 있습니다.

  • 하지만 스타트업은 다릅니다. 프로세스는 존재하지만 대기업의 그것과는 다른 목적과 성격입니다.

  • 나의 할 일의 정의와 범주가 존재하지만 그 경계는 희미합니다. 나의 일만 끝냈다고 본래 전체의 일의 목적이 달성되기도 어렵습니다.

  • 누군가는 그 사이사이의 빈자리를 메꾸고 채워야 합니다. 그게 결국 본래의 목적을 달성할 수 있는 진짜 일을 만듭니다.

  • 힘듭니다. 대기업처럼 쉽고 편하게 일할 수 없습니다. 그래서도 안됩니다.

  • 똑같은 짓을 하면서 다른 결과를 기대하는 것은 바보이듯이, 다른 접근 방식과 형태로 접근해야하는 게 스타트업입니다.

  • 일이 목적을 달성할 수 있는 형태가 될 수 있도록 조금만 더 도와 주세요. 함께 만들어요.