성장의 피땀눈물

회사의 디자인 프로세스가 모호하다고, 내 디자인 포트폴리오가 망했을까?

필자는 시니어 디자이너 생활을 하면서 디자인 리더는 기술에 초점을 맞추는 것보다 사람과 비지니스에 맞추는 것이 더 가깝다고 느꼈습니다. 아래 6가지의 비유를 통해 리더의 책임을 설명합니다. 1. 훌륭한 리더는 중매인이다. 전문 지식을 비지니스 요구 사항과 일치 시킬 수 있다. - 사람과 기업을 연결하여 최상의 결과를 얻는 것이 리더의 임무다. 2. 좋은 리더는 주장이다. 더 큰 그림을 보며 팀의 방향성을 제시한다. - 훌륭한 리더는 팀에게 영감을 주고 참여하고 결집 시키는 비전을 구축한다. - 리더는 팀원 한명 한명을 세세히 관리 하는게 않는 대신 방향성을 제시한다. - 리더는 팀원들이 자신만의 방식으로 솔루션을 탐색할 수 있게 여유를 제공해야 한다. 3. 훌륭한 리더는 외교관이다. 팀의 요구를 대변하고 클라이언트의 요구를 이해하며 그들의 기대치를 관리한다. - 리더는 모든 것이 실현 가능한 척 하지 않는게 좋다. - 문제에 대해 클라이언트와 신뢰를 구축해라. 4. 좋은 리더는 치어리더다. 동료의 노력을 인정하고 참여하게 한다 - 디자이너에게 자유와 소유권을 제공하고 참여를 유지해라. - 사람들은 칭찬 받기를 좋아한다. 긍정적인 피드백은 긍정적인 행동을 강화하고 장점을 발휘 시켜준다. 5. 좋은 리더는 정원사다. 디자이너가 성장할 수 있도록 안전한 환경을 조성한다. 안전한 환경이 중요한 이유 - 디자이너는 신뢰감을 느꼈을 때 위험을 감수하고 건설적인 피드백을 제공하는게 안전하다고 느낀다. - 개인이 결정을 내리는 것이 위험하다고 느끼면 리더가 결정을 내려야한다. - 사람들은 안전하다고 느낄 때 피드백을 위한 디자인을 공유하는 경향이 있다. 안전한 환경을 구축하려면? - 리더 자신이 취약하다는 걸 보여줄 때 팀원들의 필요성을 보여줄 수 있다. 리더가 항상 옳다면 실패를 두려워 하게 된다. - 팀과 함께 정기적인 확인을 한다. - 실패를 통해 학습해라. - 디자인 비평 문화를 장려해라. 6. 때로는 훌륭한 리더가 코치다. - 팀원이 예상과 상반된 결과를 제공할 경우, 문제를 개선할 수 있도록 도와준다.

일하는 방법

마인드셋

디자이너 성장

협업

김예진

2022/06/20

“더 이상 시간을 낭비할 여유가 없어요. 저는 이곳에 온 지 2년이 조금 넘었고 제안 할 때마다 벽에 부딪혔습니다. 디자인 과정은 없고 앞으로도 없을 것이 분명해요.” 디자이너로서 받아들여야 했던 가장 어려운 진실은 “어떤 기업들은 디자인에 대해 신경을 쓰지 않는다.” 는 것 입니다. 디자이너, 특히 주니어 디자이너는 디자이너가 된다는 것이 무엇인지에 대해 이상주의적인 견해를 가지고 있습니다. 우리는 사용자 중심의 기대치를 가지고 있지만, 때로는 그 기대치를 충족시킬 수 없습니다. 아마도 비즈니스에 다른 우선 순위가 있을 수 있습니다. 혹은 자금이나 자원이 부족할 것입니다. 아니면, 정말 회사가 연구에 관심이 없고 고객과 이야기하지 않을 수도 있습니다. 경험에 비추어 볼 때, 대규모 글로벌 회사조차도 기본 디자인 전략을 구현하기 매우 어렵습니다. 혹은 회사안 누군가의 자아가 가장 큰 장애물이 될 수 있습니다. 그럼에도 불구하고상황에 관계없이 최선을 다하는 사람들이 있고, 자신의 노력이 다른 곳에서 가장 적합하다고 느끼는 사람들이 있습니다. 두 가지 결정 모두 존중받아야합니다. 그리고 만약 이직으로 결정을 내렸다면, 이번 직장 경험을 기반으로 이직하는 것에 대해 걱정하지 마세요. 실제 경험이 중요! 디자인 프로세스가 없는 회사에서 시간을 보내는 것은 낭비라는 일반적인 오해입니다. 경험이 없는 대학을 갓 졸업한 사람들보다 앞서게 되므로 절대 그렇지 않습니다. 실제 경험이 현업에서 매우 중요 합니다. 여러분의 기대에 부응하지 못하지만, 엔지니어링 팀, 이해 관계자, 다른 디자이너와 협력하여 실제 솔루션을 제공했던 프로세스가 있었음을 잊지 마세요. 평등한 회사는 없으며, 디자인 프로세스가 다른 회사와 다르다고 해서 경쟁에서 벗어난 것은 아닙니다. 조사를 한 적이 있습니까? 다른 팀원들이 리서치를 할 때 협력 했습니까? 디자인 워크숍을 주최한 적이 있습니까? 연구/워크샵이 디자인 작업이나 최종 제품에 어떻게 반영되었습니까? 그것이 회사의 디자인 문화에 영향을 미쳤습니까? 와이어프레임, 프로토타입 또는 최종 디자인을 제작했습니까? 그렇다면 이를 엔지니어링 팀에 어떻게 넘겼습니까? 엔지니어링 팀을 반복적으로 참여시키셨습니까? 프로세스가 더 좋았더라면 어떻게 했는지 설명하십시오. 팀 내 마찰의 순간에 어떻게 대처했습니까? 포트폴리오를 검토할 때 어떤 면접관도 완벽을 기대하지 않습니다. 리서치 방법에 대한 경험이 없는 것은 전적으로 허용되지만, 열망을 보여주는 것이 중요합니다. 관심과 열정을 보여주세요! 면접관은 여러 분야의 팀과 어떻게 지냈는지, 사무실의 문제점과 역경이 유일한 선택일 것 같았을 때 어떻게 조언 했는지 알고 싶어할 것입니다. 역경을 이겨낸 방법을 설명할 수 있다면, 당신은 훌륭한 사람이 되기 위해 필요한 기술을 보여주고 있는 것입니다.

마인드셋

일하는 방법

디자이너와 엔지니어가 보다 긴밀하게 협업할 수 있는 방법

2022/06/13

최고의 비즈니스 아이디어를 연마하고 이를 실행할 제품을 구축할 때 디자이너와 개발자 간의 건전한 협업이 특히 중요하다. 서로 생각하는 스타일이 다른 두 직군이 모이려면 무엇이 필요할까? 이 글은 4개 테크 기업의 시니어급에게 이 두 핵심 직군간 협업을 어떻게 개선했는지 묻고 답변을 기록한 글이다. 그 중 인터뷰 2세트를 번역 및 요약했다. ① Chime - 핀테크 회사 디자이너에게 질문) 개발자와 함께 작업할 때 가장 큰 어려움은 무엇이며, 어떻게 극복했는가? 답변) ...(중략) 개발 협업을 언제, 어떻게 하는지 정확히 알기 어렵다. 이러한 잠재적 마찰 지점에 앞서 대응하기 위해 개발 파트를 포함한 다른 유관 분야 담당자들과 함께 디자인 프로세스의 각 단계에서 검토를 수행한다. 이를 통해 우리는 타 팀의 관점을 디자인 의사결정에 통합하며, 개발 시작에 필요한 방향을 제시할 수 있다. 디자이너에게 질문) 디자이너와 개발자는 작업에 대해 매우 다른 관점을 제시한다. 디자이너로서 서로를 더 잘 이해하기 위해 무엇을 했는가? 답변) 나는 항상 디자인 솔루션이 디자이너에게서 나올 필요는 없으며 디자이너는 최고의 솔루션을 촉진해야 한다고 말한다. 디자인 프로세스 초기에 회의할 때 개발자와 같이 있으면 최종 제품을 염두에 두고 다른 관점에서 디자인 솔루션을 고안할 수 있다. 이런 일을 조기에 하면 제약 조건 하에서 창의적으로 생각할 여지가 생긴다. 디자이너에게 질문) 여러 팀이 같은 목표를 바라보게(Align) 할 때 효과적이었던 전략은 무엇인가? 답변) 스프린트 기간 내내 동료 개발자와 협력할 의도를 가지고 작업에 임한다. 최근에 기업용 제품에 필요한 디자인 시스템을 만들었다. 우리는 해당 제품을 프론트엔드 측에서 복제 가능한 방식으로 컴포넌트 등 디자인 요소를 구성하고, 용어 및 구현 방법을 정리하는데 스프린트 일부분을 할애했다. ② Granular - 농장 관리 소프트웨어 제작사 개발자에게 질문) 디자이너와 함께 작업할 때 가장 큰 어려움은 무엇이며, 어떻게 극복했는가? 답변) 신뢰다. 개발자와 디자이너는 신뢰가 없다면 서로의 동기와 능력에 의문을 제기하기 쉽다. 신뢰가 부족한 시기에 디자이너와 협업할 때, 우리는 개발팀 스크럼에 디자이너를 초대해 관계와 상호 존중을 구축했다. 결과적으로 더 긴밀하게 작업하게 되었다. 최근에는 반대로 디자인 쪽에서 먼저 작업을 미리 살펴보고 새로운 기능을 구현하는 방법을 생각해보기 위해 우리에게 연락을 해왔다. 개발자에게 질문) 디자이너와 개발자는 작업에 대해 매우 다른 관점을 제시한다. 개발자로서 서로를 더 잘 이해하기 위해 무엇을 했는가? 답변) 다시 말하지만 신뢰다. 함께 일한 적이 없는 두 팀은 서로를 알아가는 시간을 보내야 한다. 이런 일이 발생하면 엔지니어와 디자이너는 서로를 팀원으로 보기 시작한다. 이 과정이 부족하면 "이 디자인의 의도가 뭔가요?" 라든지, "그게 왜 구현하기 어렵죠?"와 같은 단순한 질문이 비난에 가깝게 느껴지게 된다. ...(중략)... 우리는 종종 다른 팀의 구성원이 하는 일과 일하는 방식에 대한 대화를 제공한다. 개발자에게 질문) 여러 팀이 같은 목표를 바라보게(Align) 할 때 효과적이었던 전략은 무엇인가? 답변) 준비하고, 고려하고, 공유하고, 피드백을 받고, 조정하고, 공개적으로 의사 소통하고, 모든 단계에서 동의를 얻으라. 공유가 중요하며, 피드백을 들은 다음에 그것을 처리하라. 팀원을 존중하는 이 일련의 과정은 매우 중요하다. 프로젝트를 실제로 시작하기 전에 조정의 모든 당사자가 참여하고 있는지 확인하라. 팀을 Align하려면(모두가 같은 수준으로 지식을 공유하고 같은 목표를 바라보는 상태) 많은 노력이 필요하지만 이것은 동시에 프로젝트의 추진력이 된다.

경험 공유

실 사례

커뮤니케이션

일하는 방법

달팽이

2022/06/09

UX디자인을 애자일 방법론에 적용하는 방법

UX 디자인 프로세스는 애자일 방법론보다 Waterfall 방법론과 더 유사합니다. UX 디자인은 구조화된 단계로 구성되어있고, 각 단계는 연구과정에 중점을 두면서 개별적으로 수행됩니다. 그렇다면 UX디자인을 애자일에 적용하는 동시에 사용자 중심의 디자인을 하는것이 가능할까요? Agile과 Waterfall 방법론 Waterfall 방법론은 순차대로 구성된 단계를 따르고 각 단계는 이전 단계가 완료될 때까지 시작할 수 없습니다. 이는 매우 엄격하고 신중한 계획을 기반으로 하는 반면, Agile은 보다 유연하고 변화에 적응할 수 있어 훨씬 더 빠르게 앞으로 나아갈 수 있습니다. UX 디자인 프로세스 UX디자인은 더블 다이아몬드를 기반으로하는 4단계를 통해 로드맵을 만듭니다. 디자인 프로세스는 명확하고 구조화된 워크 플로우가 있고 대부분 Waterfall 방식을 기반으로 합니다. [리서치 리서치 결론 도출 브레인 스토밍 프로토타이핑 사용성 테스트(UT) 최종 디자인] 이 모든 프로세스를 마친 후 디자인을 개발자에게 넘겨줍니다. 이 과정에서 한 단계가 완료되면 디자이너는 다음 단계를 진행하거나, 일부 변경이 필요한 경우 단계를 반복 한 후 다음 단계로 이동하길 결정할 수도 있습니다. 좋은 것을 취하고 더 좋게 만들고 싶은 것은 지극히 자연스럽고, 이런 경우 효율적이고 유연하게 만드는 동시에 Agile방식과 유사할 수 있습니다. 이것이 Lean UX가 작동하는 방식입니다. Lean UX Lean UX는 리서치와 문서작성의 양을 최소로 줄이고, 대신 빠른 가설 검증으로 빠르게 전진하는 것을 목표로 합니다. 디자인 프로세스의 단계를 줄이고, 빠른 솔루션을 만들고, 이를 측정/검증해 피드백을 받고 무엇이 효과가 있는지 확인한 다음 최상의 옵션으로 적용하는 것 입니다. Agile 과 Lean UX의 공통점 워크 플로우: Lean UX의 솔루션 기반 접근방식은 전통적인 UX프로세스에서 파생되지만 반복되는 워크플로우는 Agile과 같습니다. 원칙: Agile 과 Lean UX 모두 협업, 반복, 지속적인 테스트, 신속한 피드백, 빠른 결정 등 동일한 가치와 원칙을 공유합니다. Agile 과 Lean UX는 함께 잘 작동할 수 있을까? 디자인 프로세스가 Lean/Agile 할 수 있지만 이 경우 리서치로 부터 도출되었을 몇가지 중요한 인사이트와 결론이 간과될 수 있습니다. 또한 디자이너의 스프린트는 항상 개발자의 스프린트보다 1-2 단계 앞서는 방식으로 진행하는 경우에만 작동할 수 있습니다. 이런식으로만 개발자가 인계받기 전 목업을 디자인하고, 필요한 사양을 준비할 시간을 갖게됩니다. 문제는 애자일에서 아무도 디자이너가 고품질의 사용자 중심의 디자인을 하는데 필요한 시간과 리소스를 고려하지 않는다는 것입니다. 디자이너의 작업시간은 워크플로우를 가능한 효율적으로 만드는데 중점을 두고 최소한으로 축소됩니다. 그렇다면 UX디자인은 어떻게 애자일 방법론에 잘 적응할 수 있을까요? UX디자인은 다음과 같은 경우에만 Lean/Agile 방법론에 따라 잘 수행될 수 있습니다. 디자이너, 개발자, 경영진 간에 공유된 이해가 있습니다. 회사 전체가 UX프로세스를 전적으로 지원합니다. UX디자이너의 요구는 개발 워크플로우에 통합됩니다. UX디자이너는 개발자와 동등하며 팀의 중요한 부분입니다. 그러나 한 방법론에 의존하기보다는 Waterfall과 Agile의 일부 측면을 결합해 유연하게 적용하는 것이 더 좋습니다. 리서치를 위한 Waterfall: 실제적이고 깊은 인사이트를 발굴한 다음 이러한 내용을 팀과 공유하는 것이 포함되며, 이는 시간이 걸리므로 제품 개발 초기에 완료해야합니다. 디자인을 위한 Agile: 협업, 프로토타이핑, 테스트, 피드백과 지속적인 개선을 프로세스에 통합합니다. 사물은 흑과 백만 있는것이 아닙니다. 우리는 지속적으로 우리가 사용하는 모든 방법을 최대한 활용하도록 교육해야합니다. 이런식으로 우리는 우리와 우리 프로젝트의 특성에 가장 잘 맞는 솔루션을 찾을 수 있습니다.

일하는 방법

프레임워크

2022/06/03

바우하우스에서 배울 수 있는 UX적 관점

우리는 바우하우스에서 UX적으로 어떤 것을 배울 수 있을까요? 구글의 UX 디렉터인 Jens Riegelsberger는 아티클을 통해 바우하우스에서 받은 여러 영감과 구글에서의 경험을 공유했습니다. Simplicity 바우하우스는 단순함이라는 유산을 남겼습니다. 디자이너들이 장식적인 것을 비판적으로 바라보고 사용자들에게 실용적인 방법을 제공하기 시작한 것이죠. 우리는 작고 사소한 결정을 내리면서 UI는 점점 밀도가 높아지고 있는 것을 경험합니다. 때문에 단순하고 쉬운 디자인을 유지하는 것은 간단해 보이지만 복잡성에 계속 의문을 제기하고 어떤 것이 단순한 것인지 정의하는 노력이 요구되는 것입니다. Gesamtkunstwerk: 종합예술 바우하우스의 설립자인 Walter Gropius는 예술을 완전히 경험하려면 예술을 종합적으로 바라보아야 한다고(Gesamtkunstwerk) 믿었습니다. 디지털 프로덕트를 디자인하는 우리에게도 이런 관점이 필요한 때입니다. 우리는 2D 화면에서 시작해 AR, VR을 만나게 됐고 다양한 차원과 감각을 디자인하는 세상을 마주하게 되었습니다. 모든 감각에 영향을 미치는 경험의 모든 측면을 디자인하게 된 우리의 작업은 Gesamtkunstwerk를 가능하게 하는 것으로 생각할 수 있습니다. Staying connected to practice 바우하우스 선생님들은 각자 스튜디오 안에서 학생들과 협업하며 작업했습니다. UX팀의 리더라면 이처럼 다음 세대의 디자이너를 양성할 책임이 있습니다. 이를 위해 우리는 협업하며 배울 수 있는 조건을 형성해야 합니다. 의도적으로 일상적인 연습과 연결되는 공간을 만들고 그 안에서 유대감을 형성하기 위해 전문 분야와 상관없이 나란히 앉아 일하는 것이 방법이 될 수 있습니다. 구글에서는 좋은 아이디어를 위해 디자인 스프린트를 할 때 위계를 내려놓은 상태에서 문제 해결을 위한 다양하고 과감한 시도들을 한다고 합니다. Creative collaboration 바우하우스에서는 각기 다른 분야의 전문가가 모여 서로에게 배우고 영감을 줬습니다. 관점과 경험이 다른 사람들에게 배우며 자신의 분야에서 성장하기를 원했던 것이죠. 요즘 UX나 “창의적인” 팀들은 그저 그들끼리 일하고 있는 것을 볼 수 있습니다. 하지만 디자이너와 엔지니어들이(다른 분야의 사람들끼리) 단결되었을 때, 우리는 새로운 기술이 제공하는 기능을 예상 및 활용할 수 있을 것입니다. 실제로 Jens Riegelsberger의 동료 중 가장 성공한 동료는 파트너 엔지니어들과 강한 유대감을 가지고 있으며 예술, 디자인, 인문학뿐만 아니라 과학과 공학의 언어에 능통하다고 합니다. Personal bonds 전문적인 네트워크를 넘어 재미있는 상호작용을 위한 공간을 만들고 지속적인 유대를 형성하는 것 또한 중요합니다. 바우하우스의 여러 파티들은 전설이 됐고 지속적인 유대를 형성할 수 있는 이유가 되기도 했습니다. 현재 UX 컨퍼런스나 전문 협회를 통해 우리가 같이 모이기도 하지만 이런 모임들이 과연 재미와 실험 정신을 제공하기에 충분할까요? 이런 맥락으로 구글에서도 공부와 놀이를 목표로 하는 팀을 구성하기도 했다고 합니다. Social good 바우하우스는 기술과 디자인을 통해 인류가 발전할 수 있다는 믿음을 가지고 있었습니다. 이는 Jens Riegelsberger가 동료들과 매일 대화하는 주제이기도 합니다. 우리의 디자인 결정의 장기적인 결과는 무엇일지, 어떻게 하면 사용자를 더 이해하고 인문학적인 내용을 디자인에 적용할 수 있을지 등과 같은 대화는 구글의 자연스러운 디자인 문화라고 합니다. 이렇듯 구글에서는 단일 분야 또는 한 사람이 모든 답을 가지고 있지 않다는 강한 인식이 있기에 직원에게 권한을 부여하고 하향식으로 의사를 결정하기도 하죠. 이를 통해 더 개방적이고 다양한 관점을 위한 토대를 마련한다고 합니다.

커뮤니케이션

일하는 방법

정은희

2022/05/30

UX리서처의 커리어패스

PM겸 디자이너가 전략에 더 많은 영향력을 만드는 방법

UX리서처란 어떤 직무인가를 실무 경험과 함께 볼 수 있는 영상을 소개드려 봅니다. 디자이너와 다른 점은 무엇인지, UX리서처가 되거나 역할을 하려면 어떤 역량이 요구되는지, 국내에 아직 널리 퍼지지 않은 직무인데 커리어패스는 어떠한지 등을 알아보는데 도움이 되는 영상입니다. 몇 가지 질문과 답변을 글로 옮겼습니다. UX리서처는 어떤 일을 하는 직무일까요? - 사용자의 경험을 조사하는 사람 - 사람이 제품이나 앱을 사용하면서 경험을 하게 되는데, 이 때 불편한 요소가 있는지 관찰을 통해 파악 - 더 편리한 사용성을 제공하려면 솔루션으로 어떻게 해드릴 수 있는지를 프로덕트 제작 담당자에게 리포트하는 조사관 역할 UX디자인도 참여를 하는지? - 어느 정도는 함 - UX리서처는 무엇을 어떻게 만들면 사용성이 더 좋아질 것 같다고 리포트를 할 수 있다. - 다만 보통 UX리서처가 디자인 전문가가 아니기 때문에 아주 깊이 있는 디자인까지 참여하지 않는다. - 디자인 관련 역량이 없더라도 UX리서처가 될 수 있다는 뜻이기도 함 UX리서처 업무 중 어려웠던 점 - 사용자 개개인 의견을 다 수용할 수 없다. - 개인적으로는 문제 해결 목적에 맞게 인터뷰이들의 의견에서 필요한 부분만 빼고 알맞게 조합해서 솔루션으로 구축하는 과정이 어려웠다. 스타트업에서의 UX 리서치 실무내용 - 에이전시에서나 스타트업에서나 업무 내용은 같다. - 에이전시에서는 리크루팅(인터뷰이 섭외)을 대신해 주는 부서가 있다거나 데이터 처리를 대신해주고 그걸 테이블화해주는 부서가 따로 존재함. - 스타트업에서는 리쿠르팅, 응답자와의 컨택, 데이터 분석 등 타 부서 도움이 필요한 부분들을 UX리서처가 거의 담당한다. - 에이전시와 다르게 리포팅 이후 follow-up을 할 수 있다. 조사 방향이 옳았는지 제품 개발 이후 2차 조사를 하면서 확인해보고 개선해나갈 여지가 있음. 스타트업에서의 진행했던 프로젝트 중 어려웠던 프로젝트는? - 패션업계 회사에 처음 입사했을 때 필드를 잘 알지 못해서 어려움을 겪었음 - UX리서처는 사용자 조사를 하기 위해서 이 사용자의 모든 것을 알아야 된다고 생각함 - 필드를 알지 못하는 상태에서 조사를 진행하다보니 사장님들이 쓰는 용어도 알아듣기 힘들었다. - 해당 산업 분야를 아주 깊이있게, 제품에 대해서 모든걸 알 정도가 되어야 하므로 UX리서처가 스타트업에 입사하려면 정말 좋아하는 분야를 택하는 것이 중요할 것 같다. UX리서처로서 향후 커리어패스는? - UX리서치 과정에서 내 가설을 가지고 바로바로 테스트를 해보려면 디자인적 역량, 데이터 분석 역량도 필요하다고 생각함 - 사용자 중심적으로 생각을 하는 리서처지만 나중에는 디자인과 분석까지 총괄적으로 일할 수 있는 PM, PO가 되고자 하는 큰 비전을 가지고 있다. UX리서처가 되기를 희망하는 취준생들이 가장 갖춰야할 역량 - 가장 중시하는 역량은 사람에 대한 관심과 통찰력 - UT를 하거나 사용자와 인터뷰를 하다 보면 사용자가 항상 생각하는 그대로를 인터뷰어에게 말하지는 않는다. - 특히 인터뷰 상황에서는 인터뷰어-인터뷰이 관계에서 진솔한 응답을 얻기 힘든데, 관찰을 통해서 인사이트를 뽑아내야 하는 역량이 필요하다. 예를 들어 인터뷰이가 말끝을 흐린다든가, 고민하는 모습을 보일 때. - 불편함을 느끼는 부분에 대해 계속해서 꼬리 질문을 함으로써 어떻게든 통찰해내는 능력이 필요

스타트업

리서치

직무 분석

경험 공유

달팽이

2022/05/25

McKinsey가 경력 발전에 대해 가르쳐준 7가지 교훈

이 글은 프로덕트 디자이너인 저자가 Tally의 그로쓰 팀 PM으로 250일 동안 업무하면서 얻은 4가지 레슨 런에 대한 글입니다. 저도 현재 회사에서 프로덕트 디자이너와 PM 역할을 동시에 수행하고 있어 공감하며 읽을 수 있었습니다. 1. 목표를 우선순위화 하고, 결과물을 최적화 하는데 사용하기 프로덕트 디자이너와 PM으로서 함께 일할 때, 두 역할을 동시에 해야하는 날들이 많았고, 업무를 분배하는데 고민인 생겼습니다. SMART[^1] 방법으로 목표를 설정하고, 내 시간을 투자할 방법으로 사용했습니다. 어떤 목표에 시간을 더 많이 사용할 지는 다음과 같이 결정합니다. • 주 별, 분기 별 목표를 설정하자 • 목표 간 상충 관계를 파악하고 덜 중요한 요청엔 잘 거절하자 • 도중에 문제가 생겼을 때 어떤 것이 더 임팩트가 큰 지를 파악하자 [^1]: Specific, Measureable, Actionable, Relavant, Time-bound 2. 변화가 있을 때(혹은 문제가 있을 때) 적절한 태도를 취하기 지난 가을, 그로쓰 로드맵을 마무리 하고 새로운 업무를 시작하려 할 때 앱의 크리티컬 패쓰의 경험에 문제가 있는걸 발견했습니다. 이런 복잡한 상황에서 사람들은 무엇을 해야하는지에 대한 답을 찾으려고 하는게 아니라, 안정되고 긍정적인 환경을 원했습니다. 디자이너로서도 여러 사람들과 문제를 facilitating 하게 됩니다. 팀이 더 일을 잘 하도록 도우면서 리더십 스킬을 성장시키고 더 탄탄한 솔루션을 만들 수 있게 됩니다. • 인간적인 모습을 취하고, 변화의 중심에 있는 사람들의 이야기를 듣자 • 솔직한 모습을 취하지만 도움이 되지 않는 피드백이나 문제로부터 팀을 보호하자 • 답을 모르는건 괜찮다. 함께 일을 굴릴 사람들을 불러들이자. 3. 데이터를 문제 발견, 우선순위화, 평가하는데 사용하기 PM으로서 다른 사람들이 성과 지표, 상태, 사용자 행동에 대해 물어보는 일이 많았는데, 데이터 분석 코스를 수강하고 이런 질문들에 스스로 답변할 수 있게 되었습니다. 또, 내 디자인 결과에 이벤트를 추가하고 이벤트 간 비주얼 맵을 그려 여러 팀이 목표를 얼라인하고 이해하는데 도움이 되었습니다. • 프로덕트 분석과 분석 툴을 공부하는데 시간을 쓰자 • 데이터를 확인할 때 기준선(베이스라인)을 지정해, 어디에 시간을 더 써야 하는지 확인하자 • 디자인 결과물에 수집될/되는 이벤트를명시해 디자인 의사결정에 참고하고, 엔지니어들과 더 원할하게 대화할 수 있다 4. 나 혼자 뿐 만 아니라 다른 모든 사람들이 장기 계획을 바라보고 있도록 하기 현재 진행중인 일에만 집중하면, 한 Phase가 끝나고 다음 Phase로 넘어갈 때 팀원들이 예상치 못한 목표를 발견하고 놀라는 일이 생기게 됩니다. • 눈 앞만 바라보지 말고 장기적 관점을 생각하는데 시간을 쓰자 • 계속해서 팀이 나아가야 할 방향을 리마인드 하고 목표를 이해시키자 • 파트너와 이해관계자들에게 장기 계획을 이해하고 참여할 수 있도록 내 계획을 지도 삼아 이야기하자 디자이너로서 만드는 결과물들은 목표 얼라인, 협업, 영감에 도움을 줄 수 있습니다. 무언가를 만들 때 청중들이 어떻게 사용하게될 지를 고려해 만들어야 합니다.

일하는 방법

마인드셋

장승환

2022/05/04

엑셀로 데이터 쟁탈전, 파워포인트로 스토리텔링을 얼마나 잘했는지에 대한 글이 아닙니다. 모든 직업, 어떤 경우에는 삶에 적용할 수 있는 중요한 것들을 공유하고 싶습니다. 전문가가 아닌, 항상 학생으로서 문제에 접근하기. 신선하고 호기심 많은 마음으로 문제에 접근해야 합니다. 질문을 하고, 메모를 하고,더 깊이 파고들고 계속 압박하여 가설을 수정하십시오. 학생의 사고방식은 당신의 두뇌를 객관적인 환경에 놓이게 합니다. 문제를 합리적으로 분석하고, 팀원과 효과적으로 협업하고, 적절한 솔루션을 만들 수 있는 보다 개방적인 형식으로 아이디어에 접근합니다. 이 모든 것이 "모든 것을 알고" 있어야 하는 스스로 유발하는 압력을 완화하는 것입니다. ’사기꾼 증후군'의 사기꾼은 조직이 아닌, 나 자신입니다. 동료들이 나보다 더 많이 알고 더 잘 실행한다고 가정하지만, 현실은 대부분의 사람들이 진행하면서 알아가는 실행착오를 격습니다. 다른 사람들이 전문적으로 나보다 우월하다는 선입견을 가질 때, 그들(그리고 자신)을 그렇게 대하기 시작하며, 이는 큰 착각입니다. 모두가 당신과 같은 학생이라는 것을 인식해야 합니다. 실패는 일어날 수 있는 가장 좋은 일입니다. 거의 해고당할 뻔했습니다. 높은 스트레스 상황에서 까다로운 고객을 관리하면서 내 기술을 넘어 도전적인 프로젝트에 참여했지만, 비참하게 실패했습니다. 이때 스스로의 약점을 알고 실패의 핑계가 아닌 성장의 원동력이 되었습니다. 실패는 앞으로 나아갈 방향을 결정해 줍니다. 조직은 개인이 그만둘 때까지 영역에 맞춰 넣을 것입니다. 경영진은 배를 조종하는 방법에 대한 비전을 가지고 있으며, 그 비전은 더 작은 조각으로 쪼개지고, 개인은 만들어진 조작 내에서만 실행할 수 있습니다. 조직은 궁극적으로 배를 조종할 것이기 때문에 개인을 그 영역 안에 두도록 장려합니다. 하지만 조직의 방향과 영역이 배움, 흥미가 있지 않다면 스스로를 가두지 말고 다른 다른 곳을 찾는 것은 우리의 몫입니다. 마음가짐, 동기 부여, 회복력이 있다면 실행해 보세요. 모든 것에 대한 해결책이 있습니다. 침착하세요. 패닉은 해결책이 아닙니다. 한 발 물러서서 논리에서 감정을 풀고 가능한 최선의 계획에 착수하십시오. 휴식도 답이 될 수 있습니다. 좋은 의도가 사람을 움직입니다. 정치가 아닙니다. 리더가 개인적인 이득을 위해 팀원들 인형극 부리듯 조종하는 것은 단기적으로 승리할 수 있지만 장기적인 성공은 관계를 기반해서 움직입니다. 조직의 성공은 맞는 팀원들과 함께해야만 도달할 수 있습니다. 그리고 적합한 팀원이 합류되기 위해서는 리더가 팀원의 성취에 진정한 관심과 케어가 동반되어야 합니다. 만들어진 관계는 조직의 운영보다 더 깊습니다. 관계는 사건보다 오래 지속됩니다. 비록 당장 이익관계에서 틀어진다 하더라도, 함께 좋은 일을 할 수 있는 기회가 올 수도 있다는 것을 명심하세요. 긍정적인 관점에서 서로를 기억하는 것은 항상 승리할 것입니다. 그리고 서로에게 훌륭하지 않고서는 함께 위대한 일을 할 수 없습니다.

일하는 방법

마인드셋

경험 공유

2022/05/03

디자이너에서 매니저로 성장하기

PM의 시간 다루기 : 로드맵, 타임라인, 릴리즈 플랜

이 아티클은 디자인 관리라는 커리어가 적절한 선택인지에 대한 판단을 돕고, 그 여정을 시작하겠다면 성공적인 길이 무엇일지를 설명합니다. 성공을 위한 방법 결정에 도움이 되는 핵심 프레임워크와 질문을 참고해보세요. 훌륭한 매니저의 자질 전략가로서 디자인 리딩하기 팀의 목표 및 핵심 결과(OKR)을 개발하고 추적하는 일을 담당합니다. 디자인팀 OKR은 팀 내부로만 한정짓지 않고 타 팀, 회사 전체의 성과를 바라보도록 설계할 수도 있습니다. 운영자로서 팀을 원활하게 운영하고 만족스러운지 확인하기 운영자의 역할은 효과적인 프로세스를 구현하여 팀 문화와 참여를 구축하고, 우수한 디자이너를 모집 및 고용하고, 팀 성과를 관리하는 것입니다. 또한 팀에 별일이 없게끔 하고, 안정감을 느끼도록 하며 긍정적인 환경을 만들 책임이 있습니다. 코치로서 팀원을 성장시키기 마지막으로 매니저는 팀원들에게 성장과 개발 기회를 제공해야 합니다. 1 on 1은 매니저에게 가장 중요한 무기입니다. 팀원과의 관계를 구축하고, 만족하는지 확인하고, 장애물을 제거할 수 있는지 알아보고, 경력 개발을 도웁니다. 그러한 자질을 개발하기 위해 연마할 기술 매니저가 되는데 가장 큰 어려움 중 하나는 위의 3가지 역할에 적절한 비중을 두고 유연하게 대처하는 것입니다. 순간순간 회사가 무엇을 필요로 하는지에 따라 주요 책임이 달라집니다. 스킬 측면에서는 아래와 같은 기술을 익혀야 합니다. 커뮤니케이션: 팀원에게는 탑다운, 동료 매니저와는 수평적으로, 임원과는 바텀업 식으로 하는 등 실무자일 때 경험하지 못한 다양한 커뮤니케이션 전략이 필요 팀원 코칭 및 성장 지도 위임 및 기대치 설정 인재 평가, 채용 자율적으로 프로젝트를 주도: 비즈니스의 핵심 요구 사항을 해결하는 자체 프로젝트를 관리하거나 생성하여 주도권을 잡습니다. 디자이너에서 매니저로의 커리어 전환에 대한 잘못된 통념과 반박 ① 예전 직무로 되돌아갈 수 없다? 매우 일반적인 통념인데 사실이 아니며 역효과를 낳는 이야기입니다. Tech Managing 분야에는 충분한 교육, 지원에 대한 수요와 공급이 넘쳐납니다. 글쓴이는 커리어상에서 매니저와 실무 디자이너 직무를 오갔습니다. ② 매니저는 인적 자원을 서포트하는 역할이다? 다른 사람들을 지원하는 것은 매니저 업무 범위에서 빙산의 일각에 불과합니다. 운영, 관리 책임도 있습니다. 코칭이 매니저의 유일한 업무가 아닙니다. ③ 경력을 쌓으려면 매니저가 되어야 한다? 일부 회사에 해당될 수는 있지만 전부는 아닙니다. 많은 회사가 실무 디자이너의 연차가 쌓여도 개인으로서 활약하는 기여도를 유지하면서 매니저와 같은 수준에서 보상을 받고 영향력을 갖는 방법을 마련합니다. 예를 들어 Webflow라는 회사에서 수석 디자이너와 시니어 매니저는 동일한 등급이며 유사한 보상 및 영향력을 부여받습니다. ④ 디자인 매니저는 팀에서 최고의 디자이너다? 이것은 사실이 아닐 뿐더러 그렇게 되어서도 안됩니다. 직원의 작업을 평가하고 비판하기 위해 디자이너로서의 핵심 기술을 끌어내야 하지만, 그렇다고 해서 팀에서 최고의 디자이너가 되어야 하는 것은 아닙니다. NBA 역사상 최고의 코치 중 일부는 명예의 전당 선수가 아니었습니다. ⑤ 디자인 매니저는 더 이상 디자인 실무에 신경쓰지 않는다? 매니저로서 픽셀 하나하나에 덜 관여하는 것이 사실일 수도 있지만 결국 팀이 만드는 모든 산출물에 대한 책임은 매니저에게 있습니다. 디자인 매니저가 하는 일에는 팀원을 지도하고 디자이너로서 성장하도록 돕는 것입니다. 제품 설계 및 디자인에 쓰이는 프레임워크는 팀원들에게 모델 역할을 합니다.

PM/PO

마인드셋

직무 분석

달팽이

2022/04/19

PM수첩: 꼭 알아야 할 4가지 우선 순위 정하기 기법

PM의 능력은 시간을 얼마나 잘 다루느냐에 달려있습니다. PM은 단순히 시작과 끝을 지정하고 관리하는 것이 아닌 ① 시간 단위를 연결해야 하고 ② 사용자의 시간에 맞추어서 프로덕트 동작이 다채로워야 하며 ③ 고객이 원하는 시간에 딜러버리를 해야 하고 ④ 로드맵이란 큰 마일스톤에 따라 잘 분배해야 합니다. PM의 시간 - 정의 1) 로드맵 - 기업, 조직 또는 제품이 달성하고자 하는 전략을 기본으로 그 목표를 설명하는 문서입니다.(≠딜리버리 플랜) - 로드맵은 타임라인이 정해져 있지 않은, 목표를 주관적이고 정성적으로 적어놓은 것입니다. - 로드맵은 프로덕트의 성공의 기회를 만드는 시간에 생성됩니다. 2) 타임라인(≠타이밍_무언가를 결정하는 전략적 순간) - 시작 날짜와 종료 날짜가 포함된 시간순으로 정렬된 이벤트의 시각적/물리적 순서입니다. 3) 프로덕트 사이클(=프로덕트 라이프 사이클, 프로덕트 개발 사이클) - 아이디어를 내는 순간에서 릴리즈, 유지보수를 하고, 다시 새 버전을 위해 새로운 루프가 시작되는 것을 의미합니다. - 프로젝트가 끝나더라도 프로덕트 라이프 사이클이 계속되는 한 프로덕트는 존속할 수 있습니다. 4) 데드라인(=Due Date) - 프로젝트 또는 이벤트의 마감일입니다. PM의 시간 - 로드맵과 타임라인의 조화 - 로드맵은 프로덕트 전략을 기반으로 달성해야 할 목표를 우선순위를 나누어 작성한 것이며, 타임라인을 기반으로 하지 않습니다. - 하지만 사용자, 고객, 회사의 경영진은 목표의 달성 시점(시간)이 들어가야 비로소 관심을 보입니다. - 따라서 로드맵은 방향, 의도 및 의사소통의 역할을 하는 동시에 전략적 목적을 위해 충족되어야 하는 타임라인과 데드라인을 포함해야 합니다. 로드맵, 타임라인, 릴리즈 플랜의 관계 - 아무리 훌륭한 로드맵이더라도 타임 팩터가 들어가 있지 않다면, 생명력이나 전달력이 부족해집니다. - PM은 훌륭한 커뮤니케이터로써 지속적으로 투명성을 공유하는 것이 성공의 핵심입니다. - 타임라인은 그 자체로는 어떤 의미도 없습니다. - 타임라인은 우선순위 그룹과 만나야 하고 우선 순위를 정의한 로드맵은 시작일과 종료일을 제시한 타임라인과 만나야 합니다. - 로드맵에 따른 기능을 정리하고 그 우선순위를 그룹화한 후 타임라인으로 나누면, 릴리즈 플랜을 만들어 출시 계획을 경영진, 고객 또는 사용자들과 소통할 수 있습니다.

PM/PO

마인드셋

직무 분석

이근학

2022/04/07

상황에 맞게 논리적으로 우선순위를 정하는 기술은 누구에게나 필요합니다. 이 글에서 언급되는 PM은 소프트웨어 서비스 기억의 프로덕트 매니저, 프로덕트 오너 등을 지칭하고 있으나 응용하여 해석하면 타 직군에도 대부분 적용될 수 있을것입니다. 빠르고 합리적인 "우선순위 정하기"는 모든 현대인의 생존 기술 현업의 PM에게 업무 중 가장 어려운 부분이 무엇이냐고 물으면 압도적으로 차지하는 대답은 "실제 시장의 피드백이 부족한 상태에서 로드맵에 따른 백로그의 우선순위를 지정" 하는 것이라고 합니다. 백로그 작업의 우선순위를 정하는 것은 PM의 가장 중요한 업무 책임 중의 하나입니다. 가장 단순하면서 명료한 원칙은 "첫번째로 중요한 일을 가장 먼저 하는것" 입니다. 하지만 이 일을 어렵게 만드는 잠재적 변수들이 있고, 아이디어들의 우선순위를 위한 미팅과 토론은 결정에 대한 영향력과 성공가능성의 극대화라는 목적때문에 늘 치열하게 이루어집니다. 그 덕에 많은 IT기업이 우선순위를 정하기 위한 여러가지 "우선순위 지정 기법"을 사용합니다. 모스코우(MoSCoW) MoSCoW는 애자일 프로덕트 관리 방법에서 중요한 것과 그렇지 않은 것을 구별하고 이해하기 위해 일반적으로 사용되는 방법입니다. 🄼 Must Have : 이 기능을 빼고 제품 딜리버리/서비스 론칭을 생각할 수 없는 것 🅂 Should have : 높은 우선순위를 지니는 기능이 분명하지만, 그것이 없어도 프로덕트에 재앙이 닥칠 운명까지는 아닐 때 🄲 Could have : 많이 이야기하는 'Nice to have'에 해당하는 것. 충분한 자원이 있다면 할 수 있었을 것이지만 성공을 위해 꼭 필요한 것은 아닐 때 🅆 Will not have : 많은 PM들이 "다음 버전에 포함하도록 신중히 검토하겠습니다."라고 말하는 것. 주로 개발자원 부족의 이유로 이번 버전에는 포함되지 않을 것이라는 의미로 사용 워킹 스켈레톤 (Walking Skeleton) 워킹 스켈레톤은 최소화된 프로덕트의 엔드 투 엔드를 구현한 것입니다. 최소 실행 가능 제품(MVP) 기능의 우선순위를 정하는데 사용되며, 그중 어떤 것이 제품이 작동하는데 절대적으로 중요한지 정의합니다. 이 방법은 특정 카테고리에 속하는 요구사항을 뜻하는 것이 아니라 사용자 스토리에 초점을 맞추어 우선순위를 정합니다. ① 먼저 필요한 사용자 스토리에 순위를 매깁니다. ② 필수 기능의 구현에 중점을 두기 때문에 주요 기능이 완전하게 동작하는 제품의 형태를 갖고 있어야합니다. ③ 비즈니스 가치를 충분히 보여주는 형태를 갖고 있어야합니다. 여러가지 기술 제한이 있는 상태에서도 핵심 시스템 요소를 표시하기 위해 스토리맵을 잘 정리해야합니다. 워킹 스켈레톤은 딜리버리와 배포까지의 모든 과정을 포함하기 때문에 제품 기능 테스트도 과정에 포함됩니다. 라이스 (RICE: Reach, Impact, Confidence, Effort) 라이스 방법은 우선 순위를 설정하기 위해 등급점수 모델이라는 방법을 사용합니다. 🅁 Reach : 특정 기간에 이 기능을 사용할 수 있는 사용자 수. DAU, MAU 등의 실제 프로덕트 지표로 평가 🄸 Impact : 이 기능을 사용함으러써 어떤 영할을 받을지에 대한 것. 상태적인 값으로 매우 큰 임팩트의 경우 3점, 높은 경우 2점, 낮을 수록 1점, 0.5점, 0.25점을 사용해 평가 🄲 Confidence : 신뢰도 값. 이 기능이 사용자에게 얼마만큼의 혜택을 주는지에 대한 추정값. 높은 경우 100%, 중간 80%, 낮음 50% 등 객관식 척도를 사용하는 것이 좋음 🄴 Effort : 제품, 디자인 및 엔지니어링 팀이 소요한 시간. 소요 일 수나 시간 등으로 계산 ➥ RICE = (Reach*Impact*Confidence)/Effort R, I, C의 곱을 E(시간)으로 나누어 계산. RICE의 값이 클수록 우선순위가 높다는 뜻이 됨 카노 모델 (Kano) 카노 기법은 고객 기반의 우선 순위 지정 방법입니다. 프로덕트의 기능에 대해 사용자의 만족도와 행동이 다르다는 사실에서 시작합니다. Must-be : 고객이 이 기능이 포함된 경우에만 제품의 의미를 두는 반드시 구현해야하는 기능 Performance : 프로덕트가 동작하기 위해 반드시 필요한 것은 아니지만, 고객은 이 기능을 매우 갖고 싶어 하는 경우 Attractive : 만족감을 더해주는 것들. 이 기능이 없다고 해서 특별히 불만족스러워하지는 않지만 가지고 있으면 좋은 기능 Indifferent : 고객 만족에 미치는 영향이 거의 없는 것 프로덕트 백로그에서 작업의 우선 순위를 정하는것은 PM의 중요한 책임 중 하나입니다. 직감에 의존할 수도 있지만 이러한 접근방식은 대개 해당 프로젝트와 제품/서비스를 위험에 빠뜨립니다. 원글에서는 위의 각 방법의 장단점과 이를 비교해놓은 표로 글을 마무리하고 있습니다. 어떤 상황에 어떤 우선순위 지정기법을 사용하는 것이 효율적인지 파악하실 수 있으니 관심이 가신다면 아래의 원글 링크에서 자세한 내용을 확인해보세요.

PM/PO

일하는 방법

프레임워크

2022/04/14

주니어 PM에게 바라는 10가지

야근하지 않는 디자이너, 디자인 기반 PO의 첫걸음

PM은 IT분야에서 많은 사람들이 원하는 직무이면서, 경험이 없으면 매우 어려운 직무입니다. 이 아티클에서는 처음 PM이 되어 IT 매니징에 아무런 경험이 없던 작가가 지난 몇 년간 경험하며 배웠던 10가지 교훈을 얘기합니다. 1. 다음달에 유니콘을 제공하겠다고 고객과 약속하지 마세요. 첫째로 유니콘은 존재하지 않으며, 둘째로 유니콘이 존재한다 하더라도 그 가능성을 팀과 확인해야 합니다. 고객은 항상 아이디어를 가지고 있고, 그 요구사항은 사실 어제 원했던 것입니다.* 하지만 성급히 약속하지 마세요. 고객의 레거시 코드를 확인하고, 실행 가능성을 평가하는 회의를 반복하세요. (*어제 원했다 = 아주 새로운 아이디어가 아니라, 이미 여러번 요구되었던 기능일 수 있습니다. - 역자 주) 2. 데모가 필요합니다. 프로젝트 시작 단계에서 고객에게 제품/디자인의 전체 데모를 요청하고 질문하세요. 데모 중에 질문하고 내용을 녹음하세요. 질문에는 옳고 그름이 없습니다. “전문적으로 보이기 위해" 질문을 하지 않으면, 플랫폼과 요구사항을 제대로 이해하지 못한 채로 잘못된 기능을 만드는 데 몇 주를 소비하게 됩니다. 3. 고객의 언어로 이야기하세요. 고객이 가장 선호하는 커뮤니케이션 방법이 무엇인지 이해하기 위해 회의를 몇 번 해보세요. 어떤 사람은 전화를 싫어하고 다른 사람은 문자를 싫어하고 어떤 사람은 보고서를 선호하는데 다른 사람은 전혀 보고서를 원하지 않을 수 있습니다. 그리고 특히 데모를 할 때 “Lorem ipsum and etc” 대신 그들이 쓰는 데이터와 사진을 사용하세요. 4. 팀이 잘 가고 있는지 확인하세요. Covid-19 시대에 번아웃은 현실적인 문제입니다. '웰빙'은 팀원의 일과 삶, 정서적이고 육체적인 측면을 모두 의미합니다. 관리자는 업무 및 작업속도를 저해하는 요소가 있는지 알아야 합니다. 5. 고객이 디자인에 참여하게 하세요. 물론, 우리가 스스로 디자인 요소와 플로우를 결정할 수 있습니다. 하지만 3개월 뒤에 고객이 “저희가 언제 이걸 하기로 했었죠? 기억이 안나네요...” 라고 말하고, 작업을 다시 해야 하는 상황에 빠질 수 있습니다. 고객을 관리자로 두지 말고, 함께 만들어가는 참여자로 만드세요. 6. To-do list를 만드세요. 회의 중에 바로 항목을 작성하세요. 우리의 단기 기억 체계*는 간단한 액션들을 잊을 수 있습니다. 작성하고, 고객에게 확인하세요. 세심한 배려는 항상 높게 평가됩니다. (*단기 기억 체계 = 사람의 자각 시스템에서 수초에서 수분 사이의 일시적인 정보의 보유를 담당하는 기억 체계입니다. - 역자 주) 7. PM은 첫번째 방어선입니다. 어떤 일이 발생할 때 당신이 팀을 보호할 수 있는지 확인하세요. 매니저는 항상 책임을 요구받지만, 팀을 하나로 모으는 것도 당신입니다. 8. 표정도 소통의 도구입니다. 원격 회의때 카메라를 켜는게 중요합니다. 팀원들이 논의된 내용에 동의했다는 것을 PM이 이해할 수 있는 방법 중 하나이기 때문입니다. 다른 방법으로는 예/아니오로 이해를 확인하거나, 미팅 콜이 끝날 때 팀원에게 책임을 인지하도록 반복하는 것입니다. 9. 먼저 팀을 구성한 후, 프로젝트를 구성하세요. 진부하게 들릴 수 있지만 잘 구성된 팀, 그리고 팀 내 합의 없이는 아무것도 되지 않습니다. 팀은 하나의 ‘몸'처럼 느껴져야 합니다. 10. 너무 많은 책임을 한번에 지지 마세요. 경력 초기에는 모든 PM이 야망덩어리이며, 모든 것을 처리할 수 있다고 생각합니다. 동시에 3-4개의 프로젝트를 수행합니다. 하지만 경험상 너무 많은 책임을 진다면 데드라인을 놓치거나 실수할 수 있습니다. P.S. 11번째로, 과로하지마세요! 점심을 먹고, 휴가를 가세요. PM은 어메이징한* 직무이기 때문에 경력 초기에는 번아웃이 올 수 있습니다. 당신이 앞으로 배울 것들과 그 여정에 행운을 빕니다! (*느낌을 살리기 위해 그대로 썼습니다. - 역자 주)

마인드셋

PM/PO

직무 분석

정하영

2022/04/13

[성장을 위한 데일리 아티클] '야근하지 않는 디자이너' 디자이너에게 요구되는 직무적 역할이 늘어나고 있는 요즘, 나를 포함한 많은 디자이너들은 처리해야 할 업무들에 둘러쌓여 있는 상태다. 나의 일을 효율적으로 처리하기 위해서는 똑똑하게 일하는 방법을 알아야 한다. 내가 야근을 했다는 것은 내가 효율적으로 일을 처리하고 있지 못하다는 뜻이다. 구조적으로 업무량에 비해 디자이너 리소스가 부족한 경우를 제외하고, 내가 가진 리소스로 내가 맡은 업무를 처리할 수 있다면 내가 야근하게 되는 이유는 아래와 같은 이유들로 발생하게 된다(이외에도 여러 이유가 있을 수 있지만 원 글의 내용을 기반으로 합니다). 1. 내가 가진 업무에 대해 제대로 파악하지 못했다 2. 일의 우선순위를 제대로 세우지 못했다 3. 작업 방향을 잘못 잡았거나 완성도에 집착하다 마감 기한을 놓친다 4. 물리적인 업무 시간 중 이미 시간을 배정해둔 협업 시간들을 유의미하게 보내지 못했다 이 중 1, 2, 3은 업무 효율성을 높이기 위한 순서이자 방법이다. [1. 내가 가진 업무에 대해 제대로 파악하지 못했다] 나의 시간을 효율적으로 배분하고 어떤 일을 먼저 집중해서 처리해야 하는지 아는 것은 내가 가진 업무가 무엇인지, 왜 그 일을 해야하는지를 파악하는 것으로부터 시작한다. 업무를 완료하면 어떤것이 더 나아지는가? 누구를 위한 작업인가? 작업을 완료하기 위해서는 어떤 리소스가 필요한가? 작업을 완료하기 위해서는 어떤 일들을 해야 하는가? [2. 일의 우선순위를 제대로 세우지 못했다] 각 업무를 왜 해야하는지를 알면 우선순위를 세울 수 있다. 다른 팀 지원 업무, 쉽게 끝낼 수 있는 일이지만 중요하진 않은 업무, 내부 회의에서만 쓰고 실제 프로덕트로 개발되지 않을 장표들의 경우 우선순위를 낮게 가져갸야 한다. 내 업무시간은 나의 팀의 목표에 맞고, 고객에게 더 중요한 일이며, 시간이 많이 필요하더라도 꼭 달성해야하는 어떤 것이다. [3. 작업 방향을 잘못 잡았거나 완성도에 집착하다 마감 기한을 놓친다] 주로 주니어에게서 많이 발견되기도 하는 이 문제는 시간이 오래 걸리는 일이거나 아직 익숙하지 않은 일 일수록 쉽게 발생할 수 있는 문제이다. 내 상관이 원하는 방향은 이미 있는데 그것을 제대로 파악하지 못하고 잘못된 방향으로 일하고 있다거나, 중요하지 않은 디테일을 먼저 신경써서는 안된다. 전체적인 얼개를 그려 드래프트를 자주 공유해 방향을 자주 점검하고, 큰 줄기에서 작은 줄기, 마지막 디테일 순으로 작업해야 진짜 중요한 작업을 놓치지 않을 수 있다. [4. 물리적인 업무 시간 중 이미 시간을 배정해둔 협업 시간들을 유의미하게 보내지 못했다] 스크럼, 회고, 의사결정을 위한 회의 등 다른 사람들과 협업하기 위한 시간은 고정되어있고, 여러 사람의 시간을 동시에 사용하기 때문에 더욱 귀중하게 쓰여야 한다. 회의 어젠다는 참석자에게 전달하고 수렴하고 싶은 내용이 확실하게 정해져야 한다. 이를 위해 주도적으로 회의를 준비해보는 것도 도움이 되겠다.

PM/PO

마인드셋

경험 공유

일하는 방법

장승환

2022/04/12

PM을 위한 API 해설

PM과 소프트웨어 엔지니어가 레스토랑에 들어갑니다.엔지니어는 PM에게 API가 무엇이며 어떻게 작동하는지 레스토랑 일에 비유하면서 설명하기 시작합니다. 인증 (Authentication) 엔지니어: 회원 전용인 멋진 레스토랑에 간다고 상상해 보세요. 클럽 회원 자격이 있어야 레스토랑에서 식사를 할 수 있습니다. PM: API에서 이것이 의미하는 바는 무엇인가요? 엔지니어: 레스토랑에 입장하려면 요트 클럽 레스토랑에 입장할 수 있는 신분증과 유효한 멤버십 카드가 필요합니다. 기술 용어로 API 사용 인증을 받으려면 ‘API 키 또는 토큰’ 이 필요합니다. 엔드포인트/목적지(Endpoint) PM: 식당으로 가는 주소와 길을 알려주시겠습니까? 엔지니어: 주소는 '엔드포인트(http://xxx.com)'라고 부릅니다! 메소드, 요청과 응답 (Method, Request and Response) PM: 이제 레스토랑에 도착했으니 음식을 주문하죠! 엔지니어: 여기 있습니다, Method = Get GET method 는 지정된 리소스의 서버에서 데이터를 검색하는 데 사용됩니다. (‘Method’ 는 API에 수행하도록 요청하는 '동사' 또는 '동작'일 뿐입니다.) 이 시나리오에서는 웨이터에게 레스토랑에서 제공되는 메뉴를 요청했습니다. Request: 레스토랑에서 제공되는 항목 목록을 보도록 요청했습니다. Response: 응답의 결과는 레스토랑에서 제공되는 항목 목록을 보여주는 메뉴를 얻는 것입니다. Method = Post 상상의 요트 클럽 레스토랑에서는 원하는 음식을 찾지 못해 레스토랑의 주방장에게 전화를 걸어 맞춤형 “비건 버거” 새로운 요리를 요청합니다. 그리고 요리사는 이 새로운 항목을 메뉴에 추가하기로 결정했습니다! 이 시나리오에서 메뉴에 새 항목을 넣는 행위를 'Post‘ 라고 합니다. Request: 셰프가 새로운 “비건 버거” 메뉴를 추가합니다. 요청에는 메뉴에 게시할 설명 및 가격과 함께 항목 이름이 포함되어야 합니다. Response: 이 결과 '설명' 및 '가격'과 함께 “비건 버거”가 게시되고 메뉴에 표시됩니다. Method = Put “비건 버거”는 레스토랑에서 큰 인기를 얻었지만 터무니없는 가격에 요리사는 가격을 몇 달러 인하하기로 결정합니다. 이 시나리오에서 메뉴의 기존 항목을 업데이트하는 작업을 'Put'이라고 합니다. Request: 셰프가 “비건 버거” 항목의 새 가격을 입력합니다. 요청 페이로드에는 업데이트 중인 항목의 참조 및 값과 함께 업데이트가 필요한 매개변수가 포함되어야 합니다. Response: 이 결과 메뉴에서 “비건 버거”가격이 업데이트됩니다. Method = Delete “비건 버거”에 대한 수요가 급증하자 요리사는 메뉴에서 인기없는 다른 메뉴를 제거하기로 결정합니다. 아이템을 제거하는 행위를. API 용어로 ’Delete’ 라고 합니다. Request: 셰프가 메뉴에서 '캐비아'를 제거해 달라고 요청할 것입니다. 요청 페이로드에는 메뉴에서 제거할 다른 세부 정보 중에서 항목 이름이 포함되어야 합니다. Response: 이 결과 메뉴에서 '캐비아'가 더 이상 표시되지 않습니다. 상태 코드와 오류 메세지 (API Status Codes and Error Messages) PM: 와우! API가 원하는 모든 작업을 수행한다는 사실이 마음에 드는군요. 엔지니어: API가 항상 잘 작동하는 것은 아닙니다. 종종 오류도 발생합니다. 아래 '응답 코드'를 통해 API의 동작 상태를 확인할 수 있습니다. 2xx : 요청이 성공했음을 의미합니다. 3xx : 운전을 해서 상상의 요트 클럽 레스토랑으로 가서 새 주소로 이사했다는 안내판과 호텔 직원이 새 위치 방향을 알려주는 안내판을 찾았다고 상상해 보세요. API 용어로 요청이 다른 URL로 리디렉션됨을 의미합니다. 4xx: 레스토랑으로 차를 몰고 가 '캐비아'를 주문했는데 더 이상 레스토랑에서 제공되지 않는다는 사실을 알게 되었습니다! 이는 클라이언트 오류(승인되지 않음, 금지됨, 페이지를 찾을 수 없음)와 동일합니다. 5xx: 이 경우에는 레스토랑의 문제입니다! 비건 버거를 주문했지만 대기열이 길고 항목을 만드는 데 시간이 오래 걸렸습니다. API 용어로 그것은 서비스를 사용할 수 없거나 게이트웨이 시간 초과를 의미합니다.

마인드셋

직무 분석

커뮤니케이션

2022/04/11

2021년 B2B 마케팅 트렌드 15가지

2021년 B2B 디지털 마케팅 트렌드 9가지 2021년은 B2B 마케팅에서 디지털 전환이 가속화된 해였습니다. 이러한 흐름은 2022년에도 가속화될 것이기에 2021년에 일어난 주목할 만한 B2B 마케팅 15가지를 정리해보고자 합니다. (국내에서 적용하기 용이한 9개 사례만 요약했습니다. 전문은 링크에서 확인 부탁드립니다.) 1. AI의 지배력 증가 AI는 조직이 데이터 잠재력을 실현하고 다재다능한 홍보 전략을 위해 콘텐츠를 스케일업하며 고객에게 더 나은 시각과 서비스를 제시할 수 있도록 지원합니다. Ex. 챗봇은 고객들에게 더 빠른 반응성, 더 나은 서비스는 물론 24시간 대응을 제공할 수 있는 연중무휴의 에이전트입니다. 2. 진실하고 독창적인 콘텐츠 파워 진정한 콘텐츠를 홍보하는데 집중하면 높은 성과를 얻을 수 있습니다. 아래 5가지 팁을 참고하세요. (1) 키워드 리서치 기반의 콘텐츠 게재 (2) 긴 포맷과 짧은 포맷의 혼합 콘텐츠 (3) 고객, 임원, 파트너에게 콘텐츠 판매 (4) 비즈니스를 위한 구독자, 팔로워 구축 (5) 콘텐츠 상위 노출을 위한 유료 광고 집행 3. 고객 유지를 위한 타깃 마케팅(리텐션 & CRM) 하버드 비즈니스 리뷰에 따르면 고객 유지율이 5% 증가할 때 수익은 25~95% 증가합니다. 또한 새로운 고객 확보 대비 5~25배 저렴한 비용이 사용됩니다. 고객 유지 전략은 B2C, B2B 모두에게 필수입니다. 4. 옴니채널 마케팅 전략 고객이 어느 채널에서나 브랜드를 찾을 수 있게 하는 옴니 채널 마케팅은 고객과의 상호작용 촉진은 물론, 고객 유지율을 91% 상승시킵니다. 다만, 모든 채널을 사용하지만 통합되지 않는 멀티 채널 마케팅과는 구분되어야 합니다. 5. SEO & SEM 음성 검색, 검색 의도와 시맨틱 검색의 증가로 인해 기존과 같은 짧은 키워드는 물론 롱테일 키워드 및 인포그래픽 콘텐츠의 적극 활용이 필요합니다. 6. 영상 마케팅과 VR B2B 고객의 90% 이상이 온라인에서 영상을 시철할 뿐만 아리아 절반 이상이 제품 및 서비스 검색의 목적으로 영상을 이용합니다. VR이 중요성 역시 점차 증가하고 있습니다. 7. Paid 마케팅에 대한 투자 Organic과 Paid는 동전의 앙면과 같습니다. Organic이 브랜드 평판, 신뢰 등을 정의한다면 Paid는 보다 빠른 도약을 가능하게 합니다. 특히 대부분의 브랜드가 Paid 광고를 이용한다는 점에서 경쟁사의 마케팅을 고려하지 않을 수 없습니다. 8. 웹 혹은 블로그 콘텐츠 재최적화 새로운 콘텐츠는 최적화에 시간이 걸리기 때문에 보다 효율적인 운영을 위해서는 기존에 웹 혹은 블로그에 업로드된 콘텐츠를 업데이트 하는 재최적화를 통해 검색 엔진에서 높은 위치에 위치할 수 있습니다. 9. 인플루언서 마케팅 B2C 마케팅에 한정되있던 인플루언서 마케팅은 B2B 영역에도 확장되고 있습니다. 인플루언서를 통해 세분화된 고객 니즈 공략은 물론 개인화된 구매 경험을 제공할 수 있습니다. 특히 B2B 인플루언서 마케팅은 콘텐츠를 재생산하는 인플루언서 유형에 보다 초점을 맞춰야 합니다.

마케팅

마인드셋

일반 이론

이근학

2022/03/10

회사 내 단일 UXer로 살아남는 법

조직 내 단일 UXer로 살아남는 법 조직 내 단일 UXer거나 소규모의 UX팀에서 일한다는 것은 디자이너에게 큰 기회입니다. 하지만 UX조직의 규모가 작을 수록 UXer의 목소리는 작고, 사용자 경험에 포커스된 업무 문화가 조성되기 어렵습니다. 어떻게 하면 성공적으로 사용자 경험을 위한 조직 문화를 만들고, 단일 UXer로서 성공적으로 일할 수 있을까요? 먼저 프로세스 수립하세요 첫번째 단계는 명확한 UX 프로세스를 수립하는 것입니다. UX 디자인 프로세스가 없다면 디자이너는 어둠속에서 길을 걸어가는 것과 같습니다. 명확하고 간결한 UX 프로세스가 있다면 이를 통해 사용자에게 놀라운 경험을 제공할 수 있습니다. 다만, 프로세스는 조직과 제품의 환경을 고려해 만들어야합니다. 어떤 것도 완벽하게 맞을 수 없기 때문에 어떤 프로세스를 선택하든 초기 프로세스를 수립한 후 필요에 따라 문제를 해결해가며 조직에 맞는 프로세스를 만들어야합니다. 이해관계자과 UX의 이점에 대해 공유하세요 좋은 사용자 경험은 비즈니스에 분명히 좋습니다. UX의 이점은 분명하지만 UX프로세스가 왜 이해관계자들에게 중요한지도 설명할 수 있어야합니다. UXer는 비즈니스의 중심에 앉아있습니다. 우리는 비즈니스팀과 프로젝트의 요구사항에 대해 이야기하고, 기술팀과 협력해 무엇이 가능한지 파악하고 개발 작업을 지원합니다. 또한 우리는 고객의 요구와 기대를 이해하기 위해 고객과 대화합니다. 이처럼 UXer는 프로젝트의 모든 파이프라인 사이에 있기때문에 UX프로세스를 통해 각 이해관계자에게 어떤 영향을 미치는지 말할 수 있습니다. UX의 성공은 비즈니스 조직 전체의 협력과 참여에 달려 있습니다. 조직 내 이해관계자들에게 우리의 역할과 프로세스가 어떤 이점이 있는지 명확하게 설명하고, 사용자 경험 중심의 문화를 수용할 수 있도록 설득하세요. 어디서 어떻게 이야기해야할까요? 개발 싱크업 미팅 블로커가 되는 이슈에 대해 듣고 향후 개발 전후 과정에서 UX의 역할이 이를 해결해줄 수 있는 부분을 설명하세요. 비즈니스팀 미팅 비즈니스 목표 달성을 위해 고객 이해가 필요하지 않나요? UX프로세스를 통해 어떻게 고객을 이해할 수 있고, 비즈니스 목표 달성에 영향을 줄 수 있는지 이야기하세요. 스프린트 회고 이전 릴리즈의 문제를 논의하고 UX프로세스가 이 문제에 어떤 영향을 미칠지 이야기하세요. 고객과의 만남 고객은 훌륭한 UX가 시작되고 끝나는 곳입니다. 개발 중인 프로젝트에 대해 고객과 이야기하고, 고객의 요구사항과 니즈, 패인포인트를 비즈니스팀 미팅에 이를 가져가 더 좋은 제품을 만드세요. 앞으로의 긴 여정에 대비하세요 UX를 하나의 팀으로 만들어가는 과정은 힘들고 외로울 수 있습니다. 함께 일할 사람이 없는 상태에서 무리하지 않는 것이 중요합니다. 합리적인 목표 설정을 위한 상급자와의 논의 상급자와 프로세스를 수립할 시기와 방법에 대해 이야기하고, 진행상태와 블로커에 대해 정기적으로 공유하세요. 더 큰 규모의 UX커뮤니티에 참여 단일 디자이너로 고립된다면 창의적인 해결책을 내거나 전문적으로 성장하는데에 방해가 됩니다. 우리에게는 회사조직보다 더 큰 팀에서 피드백을 줄 수 있는 동료가 있습니다. UX커뮤니티나 모임, SNS에서의 업계 리더와 UX/기술 블로그 팔로우 등 적극적으로 UX업계에 참여하세요.

마인드셋

협업

스타트업이 블로그 글을 게시해야하는 3가지 이유

2022/03/03

모든 사람들은 잘 만들어진 사용자 경험을 좋아합니다. 그러나 문제는 아무도 제품의 존재를 알지 못한다면 사용할 기회조차 갖지 못한다는 것입니다. 이때, 블로그는 제품을 홍보하는 유용한 도구입니다. 블로그는 SEO(검색 엔진 최적화)에 도움을 줍니다. 여러분이 집을 산다고 상상해 보세요. TV 광고, 유튜브 광고 다음, 인터넷에 “집을 사는 법” “대출받는 법”을 찾아봅니다. 이때 우리는 수많은 블로그 글을 봅니다. 그리고 원하는 정보를 알아내기 전에 모든 신뢰할 수 있는 블로그 소스를 클릭했을 것입니다. 블로그는 회사에 목소리를 줍니다. 블로그는 사람들이 제품이 무엇인지 알기도 전에 해당 UX를 소개할 수 있는 좋은 방법입니다. 잘 된 블로그들을 보면 UX, UX Writing,블로그가 완벽히 하나의 패키지로 매끄럽게 묶여 있습니다. 플랫폼 전체 색상은 통합되어 있으며 내가 어떤 페이지에 있느냐에 따라 제품과 상호 작용하는 것처럼 느껴지게 합니다. 이런 블로그가 있는 회사는 제품을 판매할 시도할 필요 없이 소비자가 스스로 구매할 겁니다. 블로그는 가치를 제공합니다. 가치는 제품, 사용자 경험, 제품의 문제 해결 가능성 모든 것입니다. 그중 가장 중요한 것은 가치가 신뢰를 구축한다는 것입니다. 블로그를 통해 여러분이 어떤 주제에 대한 전문가로 소개할 수 있다면, 고객들은 이 주제에 대한 신뢰할 수 있는 정보원으로 보고 답을 얻기 위해 찾아올 겁니다. 대부분 회사는 Instagram에 매일 10개의 사진을 게시하고, 매시간 트윗을 게시하고, 30분마다 새로운 Facebook 게시물을 게시하면서 성과를 내고 있다고 생각합니다. 하지만 이것은 가치를 제공하는 것이 아니라 자랑입니다. 고객과 친구가 되지 마세요. 블로그는 고객을 이해하고, 고객과 관계를 맺고, 고객의 문제를 해결하는 데 도움을 주는 방법입니다.

스타트업

프로덕트 전략

비즈니스 전략

2022/02/25

어떻게 "No"라고 잘 거절할 수 있을까

어떻게 "No"라고 잘 거절할 수 있을까 "No"라고 말할 수 있는 능력은 성공적인 PM이 되기위해 중요한 것 중 하나입니다. 많은 경우 아이디어를 제안하는 사람은 회사의 중요한 이해관계자, 투자자 또는 C레벨의 임원일 수 있습니다. 그들의 제안을 어떻게하면 잘 거절하고, 올바른 방향으로 갈 수 있을까요? 잠깐! 혹시 이런 이유로 "No"라고 말하지는 않았나요? · 게으름으로 인해 "No"라고 말하는 경우 · 업무량이 많기 때문에 "No"라고 말하는 경우 · 제대로 검증하지 않고 "No"라고 말하는 경우 · 빡빡한 일정으로 인해 "No"라고 말하는 경우 · 습관적으로 "No"라고 말하는 경우 우리는 훌륭한 제품을 만들기위해 "No"라고 말해야합니다. 검증한 후 "No"라고 거절하세요. 정량적, 정성적 데이터로 의견을 뒷받침해야합니다. 제품의 성과 지표와 다양한 유입경로를 확인하세요. 사용자 인터뷰와 프로토타입을 통해 우리의 가설에 대한 피드백을 수집하세요. 이를 통해 아이디어가 가치 없는 것으로 판명된다면 회의실로 돌아가 개인적인 감정이 상하지 않도록 우리의 발견을 공유하세요. "이 아이디어는 정말 좋고 작업을 시작하고 싶지만, 데이터와 사용자는 그렇지 않은 것으로 보이네요." 우선순위에 따라 "No"라고 거절하세요. 리소스는 한정적이기 때문에 모든 아이디어를 1의 방법으로 검증할 수는 없습니다. 따라서 우선순위를 정해야합니다. 개발 소요시간을 확인하고 이 기능이 가져올 수 있는 비즈니스적인 가치를 계산한 후 진행할 가치가 있는지 최종적으로 결정하세요. 이 방법은 있으면 좋은 아이디어와 비즈니스적으로 필수적인 아이디어를 구분하는데에 효과적입니다. "이 아이디어는 정말 좋은 것 같지만 비즈니스적으로 큰 임팩트가 없어요. 따라서 우리의 리소스를 이 기능을 만드는데 사용하는 것은 좋지 않을 것 같아요." 대안을 제시하며 "No"라고 거절하세요. 1의 방법으로 검증하는 과정에서 우리는 사용자가 직면한 문제를 확인할 수 있습니다. 아이디어가 사용자의 문제를 해결하지만 해결책이 적절하지 않은 경우에 우리는 거절하는 대신 다른 대안을 찾아야합니다. "검증을 통해 이 아이디어X가 사용자의 문제를 해결할 수 있음을 확인했습니다. 다만 사용자가 작동방식을 이해하는데에 어려움이 있어 수정이 필요합니다. 우리는 아이디어Y의 방식을 적용할 수 있어요." "Yes"라고 말하면서 "No"라고 거절하세요. 위의 여러 방법에도 불구하고 회의중 이해관계자에게 "No"라고 말하는 것은 어렵습니다. 제품을 더 좋게 만들기위해 제안한 사람에게 감사하기 위해 "Yes"라고 말할 수 있습니다. 이 아이디어가 검증되지 않을 것이라는 것을 이미 알고있더라도 더 나은 장소에서 논의할 수 있도록 회의 안건에서 제외하고, 이후 후속 조치를 취하세요. "제안해주셔서 감사합니다. 그 아이디어로 제품이 지금보다 더 좋아질 수 있다는데에 동의합니다. 이것을 검증할 수 있는 방법을 찾아본 후 나중에 논의하면 좋을 것 같아요." PM은 더 나은 제품을 위해 "No"라고 말해야합니다. CEO의 아이디어였기때문에, 대화를 빨리 끝내기 위해 "Yes"라고 말하지 마세요. 우리는 그것이 제품을 더 좋게 만들것이라고 느끼는 경우에만 "Yes"라고 말해야합니다.

PM/PO

마인드셋

워크플로우

일론 머스크가 소개하는 아이들이 반드시 알아야 할 인지 편향 50가지

2022/02/16

일론 머스크는 여러 논란이 있지만 성공한 혁신가라는 점은 부인할 수 없습니다. 그는 이 성공의 주요한 요인 중 하나로 ‘제 1 원칙 사고’라고 부르는 명확하게 사고하는 법을 꼽았습니다. 급변하는 시장 상황에서 여러 상반되는 요구사항을 가지는 사용자를 상대로 올바른 결정을 내리기 위해서는 머릿 속에서 일어날 수 있는 오류나 편향을 피해야 합니다. 다음은 일론 머스크가 모든 어린이들에게 가르쳐야 하는 50가지 인지편향, 사고 오류, 인간의 비합리적 경향을 옮긴 내용입니다. 가까이에 두고 내 의사결정이 올바른 것인지 점검하는 용도로 사용해봅시다. 업무와 개인 생활에 있어 더 중요하다고 생각되는 경우엔 별도 표기했습니다 : 업무 중 의사결정 오류를 유의해야 하는 경우 : 개인 생활 중 유의해야 하는 경향 1. 근본적 귀인 오류 (Fundamental Attribution Error) : 다른 사람의 잘못은 상황보다는 성향에서 이유를 찾고, 자신의 잘못은 성향 보다는 상황에서 이유를 찾는 것 2. 자기 고양적 편견 (Self-serving Bias): 성공적인 일은 자신의 역할을 강조하고, 실패한 일에는 다른 사람이나 상황 요인을 탓하는 것 3. 내집단 편애 (In-Group Favoritism): 다른 집단에 속한 사람들에 비해 나와 같은 집단에 속한 사람들을 편애하는 것 4. 밴드웨건 효과/편승 효과(Bandwagon Effect): 대중으로 유행하고 있다는 사실이 그 선택에 더욱 힘을 실어주는 것 5. 집단 사고 (Groupthink): 의견의 일치만을 위해 갈등을 최소화 하여 비판적인 생각을 하지 않는 것 6. 후광 효과 (Halo Effect): 일부의 긍정적인 혹은 부정적인 특정에 주목해 전체의 평가에 영향을 주는 것 7. 도덕적 운 (Moral Luck): 성공한 사람은 도덕적으로도 우월할 것이라는 생각 8. 합의 착각 효과 (False Consensus): 객관적 사실 없이 다른 사람들이 나와 같은 생각을 가질 것이라고 생각하는 것 9. 지식의 저주 (Curse of Knowledge): 내가 새로운 사실을 알게 되었을 때 다른 사람도 그 사실을 알고 있을것이라는 생각 10. 스포트라이트 효과 (Spotlight Effect): 자신의 특징이나 행동에 대해 다른 사람이 생각하는 정도를 과대평가 하는 것. 다른 사람들은 생각보다 나에게 관심이 없음. 11. 가용성 휴리스틱 (Availability Heuristic): 머릿속에 더 쉽게 떠오르는 사건을 중심으로 생각하는 것. 자동차 사고가 더 빈번하지만 떠올리기 쉬운 비행기 사고에 대해 더 많이 걱정하는 것 12. 귀인 편향 (Defensive Attribution): 자신이 경험할 수도 있는 사건에 대해 더 화를 내는 것 13. 공정한 세상 가설 (Just-World Hypothesis): 세상은 공정하다고 가정하므로 공정하지 않은 일을 당한 사람은 그 사람이 잘못했다고 생각하는 것 14. 소박한 현실주의 (Naive Realism): 자신이 다른 사람 보다 더 객관적으로 바라본다고 생각하는 것 15. 순진한 냉소주의 (Naive Cynicism): 다른 사람이 실제보다 이기적일 것이라고 생각하는 것 16. 포러 효과/바넘 효과(Forer Effect (aka Barnum Effect)): 모든 사람에게 적용될 수 있는 모호한 말이지만 나에게만 해당하는 것으로 착각하는 것. 예: 점성술이나 타로, 사주 17. 더닝 크루거 효과 (Dunning Kruger Effect): 능력이 부족한 사람은 자신의 능력을 제대로 이해할 수 없기 때문에 과대평가 하고, 능력이 뛰어난 사람은 자신의 능력을 너무 잘 이해하고 있기 때문에 과소평가 하는 현상. 18. 정박 효과 (Anchoring): 첫 정보가 전체 논의에 영향을 미치거나 프레이밍 하는 것 19. 자동화 편향 (Automation Bias): 시스템이 사람보다 더 나은 결과를 제공한다고 생각하는 것 20. 구글 효과 (Google Effect (aka Digital Amnesia)): 쉽게 검색할 수 있는 것이라면 더 잊을 확률이 높다 21. 청개구리 효과 (Reactance): 선택의 여지가 없는 상황에서 주어진 것에 반대로 하고싶어 하거나, 금지된 것일수록 더욱 갖고 싶어지는 것 22. 확증 편향 (Confirmation Bias): 현재 가지고 있는 신념을 반증해주는 정보를 더 찾으려 하거나 더 잘 설득되는 것 23. 역효과 법칙 (Backfire Effect): 현재 가지고 있는 신념에 반대되는 정보와 사실이 있더라도 원래 가지고 있는 신념을 강화하려는 것 24. 제 3자 효과 (Third-Person Effect): 일반적인 현상이 자신보다 타인에게 미칠 영향을 더 크게 생각해 태도와 행동에 변화가 나타나는 것 25. 신념 편향 (Belief Bias): 주장의 타당성을 평가할 때 그 주장의 논리성이나 사실에 근거하는지와 강관 없이, 내가 현재 가지고 있는 믿음이나 가치관, 정보에 기반하여 평가하는 것 26. 가용성 폭포 (Availability Cascade): 더 많은 사람이 믿거나, 이야기할 때 그것이 사실이라고 믿게 되는 것. 집단적 믿음에 대한 자기 강화 프로세스 27. 비관론 (Declinism): 과거를 미화하고 현재를 쇠퇴하는 시기라고 생각하는 것 28. 현상 유지 편향 (Status Quo Bias): 변화가 더 도움이 되더라도 지금 현상을 유지하려고 하는 것 29. 매몰 비용 오류/몰입 상승 효과 (Sunk Cost Fallacy (AKA Escalation of Commitment)): 잘못된 결정이나 실패할 것이 확실한 일에 계속해서 투자하고 노력하는 것 30. 도박사의 오류 (Gambler's Fallacy): 사건이 일어날 확률이 결정되어 있음에도 전후에 일어난 사건에 영향을 받아 확률이 변화될 것으로 생각하는 것 31. 제로 리스크 편향 (Zero-Risk Bias): 여러 위험 요소가 공존할 때 전체 리스크의 확률을 낮추기 보다 최소한 하나의 위험 요소를 완벽히 없애는 것을 선호하는 것 32. 프레이밍 효과 (Framing Effect): 동일한 사건이나 상황도 표현 방식에 따라 판단이나 행동이 달라질 수 있는 것 33. 고정 관념 (Stereotyping): 그룹에 대해 일반적인 신념을 가지고 있으면서 그룹 내 개인도 동일할 것이라고 생각하는 것 34. 외부 그룹 동질성 효과 (Out-group Homogeneity Bias): 그룹 내부 사람들은 다양하다고 생각하고, 그룹 외부 사람들은 비슷하다고 생각하는 것 35. 권위자 편향 (Authority Bias): 이치에 맞지 않고 도덕적으로 의미가 없다고 하더라도 권위를 가진 사람의 말에 귀를 귀울이는 것 36. 플라시보 효과 (Placebo Effect): 어떤 것이 통할 것이라고 생각한다면 실제로 성공했는지 여부와 관계 없이 작은 긍정적인 효과를 경험하는 것 37. 생존자 편향 오류 (Survivorship Bias): 생존한 사람들만 생각하고, 사라진 사람들은 생각하지 못하는 것. 2차 세계대전 당시 생존한 비행기의 탄착흔이 날개에 있었다고 해서 날개를 보강해서는 안됨. 엔진에 맞은 비행기는 살아남지 못한 것이기 때문에. 38. 타키사이키아/빠른 마음 (Tachypsychia): 약, 긴박한 사건, 트라우마 등으로 시간이 느리게 느껴지는 것 39. 사소함의 법칙 (Law of Triviality (AKA Bike-Shedding)): 더 중요한 것은 무시하면서 사소한 것을 필요 이상으로 중요하게 생각하는 것 40. 미완성 효과/자이가르닉 효과 (Zeigarnik Effect): 미완성된 일을 완성할 때 까지 더 잘 기억하는 것 41. 이케아 효과 (Ikea Effect): 우리가 직접 만든 것의 가치를 과대평가 하는 것 42. 벤저민 프랭클린 효과 (Ben Franklin Effect): 우리가 호의를 베푼 상대에 대해 더 긍정적으로 생각하는 것 43. 방관자 효과 (Bystander Effect): 군중 속에 있을 때 사람들이 의무를 지려 하지 않는 것 44. 피암시성 (Suggestibility): 외부의 생각이나 영향력에 순응하고 무비판적으로 순응하는 것 45. 거짓 기억 (False Memory): 일어나지 않았던 사실을 실제 있었던 것으로 기억하는 것 46. 잠복 기억 (Cryptomnesia): 실제 기억을 상상이라고 생각하는 것 47. 클러스터 착각 (Clustering Illusion): 랜덤하게 일어난 사건에 대해 경향성을 찾으려고 하는 것 48. 염세주의 편향 (Pessimism Bias): 사건을 염세적으로만 바라보는 것 49. 낙관주의 편향 (Optimism Bias): 사건을 낙관적으로만 바라보는 것 50. 맹점 오류 (Blind Spot Bias): 다른 사람의 오류는 쉽게 눈치 채지만 자신의 오류는 깨닫지 못하는 것

PM/PO

심리학

프레임워크

장승환

2022/01/25

모든 UX 초보자가 배워야 할 7가지 주제

1. 디자인 심리학 사람들이 어떻게 생각하는지, 디자인 요소에 어떻게 반응하는지, 그리고 우리의 인지 능력과 한계를 이해하는 것입니다. 심리학은 사람들이 디자인과 상호작용하는 방법에 기초하기에, 기본적인 것을 배우는 것은 컨텐츠 구성, 작업의 흐름, 라벨링, 색상 선택, 인터렉션 디자인 등 모든 것에 대해 효과적인 결정을 내릴 수 있게 해줍니다. 모든 디자인 선택은 컨텐츠에 접근할 수 있는지 여부, 탐색방법, 명확하거나 혼란스러운 사항, 의사 결정 방법, 작업을 마치는데 걸리는 시간 및 전반적인 경험에 대한 느낌에 영향을 줍니다. 2. 연구 방법 정보에 입각한 사용자 중심의 디자인 결정을 내리는 것이 전통적인 UI 디자인과 UX 디자인을 구분하는 것입니다. 전통적인 UI 디자인은 사람들이 필요로하고 기대하는 것에 대한 디자인 지침과 가정에 기반을 두고 있었습니다. UX 설계는 증거 기반입니다. UX전문가들은 목적에 따라 다양한 사용자 및 디자인 연구방법을 수행합니다. 결과를 계획, 수행 및 분석하는 방법을 배우는 것은 UX전문가의 핵심 기술입니다. 3. 정보 구성 사용자의 기대에 부합하고 목표 달성에 도움이 되도록 컨텐츠를 구성하는 것은 매우 중요한 기술입니다. 정보 구성에는 디자인의 모든 요소를 구성, 구조화 및 레이블링하고 복사 및 그래픽 컨텐츠를 포함합니다. 사람들이 쉽게 탐색하고, 원하는 것을 찾고, 작업을 완료할 수 있도록 해야합니다. 정보 구성은 사람들이 목표를 달성하려고 할 때 도움이 될수도 방해가 될수도 있습니다. 4. 와이어프레이밍/프로토타이핑 연구에 따라 충실도가 낮고 충실도가 높은 콘텐츠 레이아웃을 만들면 다양한 디자인 컨셉을 초안하고 신속하게 변경할 수 있습니다. 와이어프레임은 미학 또는 컨텐츠 세부 사항을 포함하지 않는 아키텍쳐 설계 개념이며 프로토타입에는 세부 정보 구성 및 미학이 포합됩니다. 프로토타입은 정적 또는 대화식일 수 있으며 일반적으로 팀 내에서 그리고 사용자와 함께 다양한 디자인 아이디어를 탐색하는 데 사용됩니다. 5. 인터렉션 디자인 명확하고 시기적절하며 예측 가능한 사용자 상호작용을 촉진하는 것은 훌륭한 사용자 경험을 디자인하는데 필수적입니다. 그래픽 디자인의 목표는 메시지를 전달하거나 사람들이 행동을 취하도록 영감을 주는 것이지만, 상호작용 디자인은 발견, 의사결정 및 목표달성을 지원하는 것을 기반으로 합니다. 상호작용 피드백 제공을 위한 사람과 컴퓨터간 상호 작용, 디자인 패턴 및 모범사례의 원칙을 숙달하는 것의 중요성은 아무리 강조해도 지나치지 않습니다. 6. 포괄적인 디자인 다양한 능력, 문화, 정체성, 사용 맥락을 고려한 디자인은 종종 간과되거나 틈새 시장으로 간주되지만 실제로는 훌륭한 사용자 경험을 디자인하는데 필수적입니다. 포괄적인 디자인은 팀 내에서 다양한 대표성을 갖고, 디자인을 제공할 사람들과 협력하고, 경험에 대한 디자인의 영향에 집중함으로써 다양한 요구와 기대를 충족시키기 위한 틀입니다. 사람들은 다음과 같은 경험을 기대합니다. 접근 가능하고 사용 가능하며 평등하고 윤리적이며 이는 사용자 인터페이스 디자인과 백엔드 프로그래밍을 통해 달성됩니다. 7. 기본 UI 개발 이것은 보너스입니다. 사용자 인터페이스 마크업에 대한 기본 사항을 이해할 필요는 없지만 스타일 및 콘텐츠 프레젠테이션에 대해 개발자와 대화하는데 매우 유용합니다. 디자인 구현을 위한 절충안 및 옵션에 대해 개발자와 얼마나 자주 논의했는지 셀 수 없습니다. HTML과 CSS에 대한 기본적인 이해가 있으면 한결 수월합니다. 이것은 당신이 조사하는 마지막 주제가 될 수 있지만 장기적으로 그만한 가치가 있습니다.

마인드셋

김지유

2022/01/24

스페셜리스트 vs 제너럴리스트

많은 사람들이 진로를 결정하거나 커리어의 다음 스텝을 고려할 때 한 가지 전문성을 더 파고들지, 더 폭넓은 방향으로 성장할지에 대해 고민한 적이 있을 것입니다. 제 나름의 결론은 '스페셜리스트 먼저, 그 다음 제너럴리스트' 였는데, 글의 저자분의 생각과 어느정도 일치하는 부분이 있는 것 같습니다. 먼저 취업이라는 좁은 관문을 뚫고 안정적으로 자리잡기 위해서는 처음엔 스페셜리스트의 뾰족함이 필요할 것입니다. 그리고 퇴직할 때 까지 실무를 하는 경우는 쉽게 발견할 수 없습니다(본인이 월클 디자이너가 되지 않는다면). 이후 커리어의 방향을 결정할 수 있는 후보를 다양하게 준비해 결정할 수 있기 위해서는 좀 더 다양한 분야에 대한 지식이 도움이 될 것입니다. 일반적인 직장을 다니는 경우를 생각했을 때, 완전한 스페셜리스트나 완전한 제너럴리스트는 존재할 수 없습니다. 만약 어느 한 분야의 전문성을 가지지 못했던 사람이라면 팀장과 같은 여러 직무의 사람들을 매니징하는 관리직으로 대표할 수 있는 제너럴리스트의 역할을 맡을 수 없을 것입니다. 또, 아주 좁은 분야에 대해 연구하는 연구자라고 하더라도, 그 연구자가 본인의 연구 분야를 결정하기 까지는 더 많은 분야에 대해 학습하고, 협력했을 것입니다. 그리고 아무리 좁은 분야라도 심리학/인류학/통계학/물리학 등 다양한 인접 학문과 연계해야만 하는 지점도 존재합니다. 원 글에서는 두 사람의 다양성과 전문성의 분포를 블럭으로 표현하여 겹치는 부분이 70% 정도임을 시각적으로 보여줍니다. 만약 자신이 들고 있는 블럭의 개수가 적다면 어디에 블럭을 쌓을지 보다는 눈앞에 당장 쌓아야 할 블럭을 놓치고 있는 것일지도 모릅니다.

디자이너 성장

당신 프로덕트의 진짜 가장 큰 경쟁자

포트폴리오 작성에 가장 도움이 되는 프레임워크 : STAR

당신은 프로덕트의 가장 큰 경쟁자를 간과하고 있습니다. 만약 당신에게 가장 큰 경쟁자가 누구냐고 물어본다면 스타트업부터 대기업까지 당신이 경쟁자라고 생각하는 많은 기업들을 줄줄 읊을 수 있을지도 모릅니다. 기능 별로 누가 더 잘하고 있는지도 다 알고 있을 수 있습니다. 하지만 대부분의 경우에, 특히 세상에 없던 혁신적인 프로덕트를 만들어내는 중이라고 한다면 가장 큰 경쟁자는 어떤 '회사'가 아닙니다. 당신의 가장 큰 경쟁자는 '현상 유지' 입니다. 사람들은 다양한 이유로 다양한 결정을 합니다. 어떤 사람은 본인이 가장 잘 아는 큰 명성을 가진 회사의 프로덕트를 선택하기도 하고, 어떤 사람은 가장 저렴한 프로덕트를 구매하기도 하지만, 어떤 사람은 본인이 가장 잘 아는, 가장 저렴한 옵션을 선택합니다. 바로 아무것도 하지 않는 선택입니다. 당신이 해결하고자 하는 문제를 가진 사용자들은 그 문제를 해결하기 위해 어떤 방법이든 사용하고 있습니다. 스프레드 시트로 관리하거나, 인턴을 고용하거나, 이메일으로 대체하거나, 혹은 그냥 참고 있기도 합니다. 어느 쪽이든 '현상 유지'는 전통적인 경쟁자들보다 더 많은 시장 점유율을 가지고 있는 경우가 많습니다. Jira와 경쟁하고 있는 회사들은 Monday.com, Basecamp, Productboard, Trello 등을 꼽을 수 있습니다. 하지만 Jira의 '현상 유지' 경쟁은 다음과 같습니다. • MS 워드로 기획하고, 엑셀로 로드맵을 정리하고, 이메일로 태스크를 할당하는 것 • 데일리 미팅에서 각자 자신의 업무 진행상황을 보고하고 PM은 전달사항을 전파하는 것 • 팀의 업무 생산성을 위해 팀 사이즈를 5명 이하로 유지하고 있는것 경쟁 회사들은 눈에 잘 보이고, 비교 경쟁하기도 쉽습니다. 하지만 이 함정에 빠져 '현상 유지'중인 고객들을 빼먹는 것은 위험합니다. 당신이 프로덕트를 만들고 있는 이유는 고객의 문제를 해결하기 위함이지, 경쟁 회사를 뒤쫒는게 아니기 때문입니다.

프로덕트 전략

비즈니스 전략

세일즈

PM/PO

스타트업

마인드셋

포트폴리오 작성에 가장 도움이 되는 STAR 프레임워크 STAR 프레임워크는 내가 내린 의사결정의 배경과 이후 학습한 결과를 자연스럽게 보여줄 수 있는 프레임워크입니다. 일반적인 경우 How에 해당하는 내가 생각한 아이디어, 실행한 방법만 집중적으로 묘사하게되는 경우가 많은데, STAR 프레임워크를 사용한다면 내 포트폴리오를 읽게 될 면접관들에게 문제의 배경, 목표, 행동과 결과를 빠짐없이, 이해하기 쉬운 순서로 전달할 수 있게 됩니다. ️ STAR 프레임워크 • S(Situation | 배경): 어떤 것을 달성해야 하는 상황에 대한 설명 • T(Task | 목표): 나 혹은 팀이 달성해야 하는 목표 혹은 문제 • A(Action | 행동): 목표를 달성 혹은 문제를 해결하기 위해 취한 행동 • R(Result | 결과): 행동에 따른 결과 포트폴리오 뿐 만 아니라 인터뷰 질문에 답변할 때도 STAR 프레임워크를 사용해 본인의 이야기를 잘 정리해서 전달할 수 있습니다. 압박감이 컸던 상황에서 업무했던 경험에 대해 알려주세요 지난 직장에서, 팀원 중 한 명이 장기 휴가를 가면서 맡고 있던 프로젝트를 담당할 수 없는 상황이 있었습니다.(S) 제 팀장은 저를 그 프로젝트에 할당했고, 기존 데드라인을 수정해주지 않아 몇 주는 걸릴 일이었지만 남은 시간은 며칠밖에 없었습니다.(T) 저는 그 프로젝트에 몰입하기 위해 기존 반복 업무를 줄이는 것을 요청했고(A), 결국 데드라인을 맞추면서도 프로젝트 퀄리티를 만족시킬 수 있었습니다. 팀장은 저의 태도와 실행력에 감명을 받아 이후에도 추가 프로젝트를 맡아 진행하도록 했고 이후 승진과 연봉 상승에 긍정적인 영향을 주었습니다(R)

포트폴리오

프레임워크

디자이너 성장

디자인 분석

프로덕트 전략

직장 필살기: 질문의 기술

브랜드 이름이 일반 동사나 명사로 사용되면 안되는 이유 (feat. 제록스)

직장에서 사랑받는 주니어, 일잘러가 되는 방법: 질문의 기술 질문하는것은 매우 중요합니다. 하지만 무제한적인 호기심은 가장 먼저 스스로에게 물어야 하고, 다른 사람에게 질문을 할 때에는 그 목적이 분명해야 합니다. 질문을 하는 제 1 목적은 '모르는 것에 대한 답'을 얻기 위함입니다. 아는 것도 물어보고, 모르는 것도 물어보는것은 민폐입니다. 바쁘디 바쁜 동료의 시간을 의미없이 사용해버리기만 합니다. 책임을 회피하기 위해 질문을 이용하는것은 생각하는 머리가 없다고 고백하는것과 다름 없습니다. 책임을 져야 할 것 같은 느낌이 왔다면 누군가의 말에 그 책임을 전가시키는게 아니라 이 행동을 하지 않아야 하는 이유를 설득해야 합니다. 내가 모르는 것은 두 가지 경우가 있습니다. 1. A와 B 중에 어떤 결정을 내려야 할 지 모르겠다 (객관식) 2. 어디서부터 시작해야할 지 단초를 찾고 싶다 (주관식) 1번의 경우에서는 질문하기 전에 어떤 답을 들을지 미리 예측해보는것이 중요합니다. 나라면 어떻게 결정할까? 그리고 질문을 받게될 사람은 어떻게 결정할까? 이런 예측을 연습한다면 다음에 있을 유사한 상황에서 질문을 반복해서 해야할 지, 내가 예측하고 있는 모델이 잘못된 것인지를 확인할 수 있습니다. 2번의 경우에는 특별한 경우가 아니라면 최대한 피하는게 좋다. 먼저 내가 치열하게 고민한 다음에도 답이 나오지 않는 경우에만 유효하합니다. 그리고 질문을 습관적으로, 시간 단축용으로 하지 않아야 합니다. 시간 단축용으로 질문하는것이 습관이 될 경우, 간단하고 중요도가 낮고 반복적으로 발생하는 업무에도, 혹은 새로운 상황이 발생할 때 마다 조건 반사적으로 질문을하게 됩니다. 본인의 리소스는 줄어들 수 있지만 그 만큼 상대방의 리소스를 뺏어가게 됩니다. 이 질문을 했을 때 그 사람은 어떻게 의사결정을 할 지 예측하는 연습을 하고 묻지 말아야 할 때와 물어야 할 때를 구분하려는 노력이 필요합니다.

일하는 방법

마인드셋

SaaS 프로덕트의 종류 (PLG, SLG,…)

브랜드명을 일반명사로 사용하는것이 좋은 전략일까요? 에스컬레이터, 아스피린, 지퍼와 같은 브랜드는 일반명사로 사용되는 대표적인 케이스입니다. 하지만 이런 경우 회사에 수익을 가져다 주는것 보다 더 많은 비용을 발생시킬 수 있습니다. 이렇게 브랜드명이 일반명사로 사용되어 상표권을 상실하게 되는 경우를 'Genericide'라고 합니다. 이는 브랜드의 고유성과 구별성을 유지하기 위해 노력하는 상표권 소유자에게 좋지 않은 일입니다. 일반적으로 브랜드는 해당 제품이나 서비스를 설명하는것이 아니라, 시장에서 다른 회사의 제품이나 서비스와 구별되는 역할을 합니다. 브랜드가 브랜드 아이덴티티를 개발하고, 고객 충성도를 구축하기 위해서는 일관성이 핵심입니다. 브랜드명이 일반명사로 사용되는것을 방지하면서도 나쁜 여론을 형성하지 않기 위해서는 다음과 같은 정책이 필요합니다. • 경쟁자가 일반명사로 내 브랜드명을 사용하는것을 주시합니다 • 본인의 브랜드명을 올바르게 사용하는 방식을 구축하고 언론 등 서면 자료에서 적절하게 사용하는지 확인합니다 • 동사로 사용하지 않기 (XeroxⓇ this) • 명사로 사용하지 않고, 형용사로 사용한 뒤 설명을 위한 명사를 붙이기 (BMWⓇ 자동차) • 소유격 형태의 브랜드명인 경우에만 소유격 형태를 사용하기 (McDonald'sⓇ) • 복수형으로 사용하지 않기 (OREOS가 아닌 OREOⓇ 쿠키) • 언론이나 기타 기관에서 내 브랜드명을 잘못 사용하는것을 발견했을 때 강한 어투의 정정요구 서한을 보내는것 보다 부드럽게 컨택합니다

브랜딩

마케팅

최근 성공적으로 성장한 SaaS 프로덕트를 이야기할 때 빠질 수 없는 개념이 'Product-led' 입니다. Product-led를 간단히 설명하자면 프로덕트의 매력을 중심으로 프로덕트와 비즈니스를 성장시키는 프레임워크입니다. 하지만 모든 SaaS 비즈니스가 Product-led는 아닙니다. Product-led 가 아닌 다른 성장 방식으로는 어떤 것들이 있을까요? Sales-led • 구매자와 좋은 고객 관계를 만드는데 투자합니다. • 새로운 고객을 유치하는게 가장 어려운 부분입니다. • 전환 비용이 커서 Churn 하기 어렵고, 리뉴얼과 업셀이 핵심 수익 원천입니다. • 높은 가치를 가진 고객일 수록 기능과 커스텀을 요구할 수 있는 힘이 있습니다. Marketing-led • 퍼포먼스 마케팅, 컨텐츠, SEO에 투자합니다. • 고객 유치 비용이 높은 것은 높은 전환율과 강력한 레퍼러 프로그램으로 합리화 될 수 있습니다. • 경쟁이 심하고 전환 비용이 낮아 Paying User를 전환시키는게 중요합니다. Engineering-led • 최신 기술, R&D, 업계의 인정(특허 등), IP를 구축하는데 투자합니다. • 가진 기술을 상업화 하는 것이 중요합니다. • 기술팀과 비즈니스팀엔 지식의 차이가 있어 프로덕트의 가치를 모두 알지 못해 효과적으로 대중에게 판매하지 못하기도 합니다. Product-led • 경쟁에서 이기고 시장 파괴적인 힘을 가지기 위해 시장과 사용자 리서치, 프로덕트 개발, 분석에 투자합니다. • 성장을 유지하고 사용자를 수익화 하고 효율적으로 스케일업 하는게 중요합니다.

비즈니스 전략

프로덕트 전략

연봉협상을 위한 10계명

[Kimchihill] B2B 회사 경영진에게 우리가 하는 질문들 - 주관적 해설서

연봉협상을 위한 10계명 연봉협상은 언제나 어려운 일입니다. 내가 협상을 하는건지, 통보를 받는것인지.. 이직할 때 더 나은 연봉협상을 위한 10계명입니다. 1. 협상은 생각보다 일찍 시작한다 • 첫 만남에서 원하는 금액을 물어보는 경우가 있는데, 절대 숫자를 얘기해선 안됩니다. • 오히려 역으로 예산이 어느정도인지 물어보고 내 예상과 일치하는지 확인하세요. 2. 인터뷰에서 정보를 더 얻기 • 인터뷰할 땐 답변만 하는것이 아니라 정보도 얻어야 합니다. • 지금 팀이 가장 주요하게 생각하는것은 무엇인가요? 왜 이 포지션이 필요한가요? 3. 압박에 굴하지 않기 • 포지션에 오퍼를 받은 다음엔 리크루터의 목표는 평가에서 클로징(계약 완료)로 옮겨갑니다 • 이 때 다시금 원하는 금액을 물어보는데 이 때도 숫자를 말해서는 안됩니다. • 금액을 말씀하시면 거기에 맞춰드릴게요 = 비슷하지만 더 낮은 금액으로 계약합시다 4. 대기업에서는 리쿠르터의 발언권이 없습니다 • 대기업일수록 연봉 테이블이 단단하게 형성되어 있습니다. • 리쿠르터는 '급여 위원회'로 부터 숫자를 받고, 협상을 원할 땐 리쿠르터가 위원회로 가 재평가를 받아야 합니다. 따라서 리크루터는 위원회와 면접자를 여러 번 다녀가지 않기 위해 금액을 먼저 받고싶어 합니다. • 기존 연봉 테이블의 범위에 들어가버리게 되었다면 다른 곳에서 받은 오퍼 등으로 다시 협상의 기회를 열어야 합니다. 5. 제안의 문맥 읽기 • 제안 금액이 낮은 경우: 협상하기 전 인터뷰어에게 다른 사람들이 생각한 자신의 가치에 대해 피드백을 요청해 내가 생각하는 나의 가치와 상대가 받아들인 가치의 갭을 줄여야 합니다. • 제안 금액이 중간인 경우: 가장 일반적인 경우입니다. 인터뷰 과정에서 강한 옹호자를 만들지 못했다는 의미입니다. 매니저가 당신을 위해 금액을 배팅하기 위해 마음먹기 전에 협상하지 않아야 합니다. • 제안 금액이 테이블 꼭대기 일 경우: 더 높은 밴드 금액을 제시할 논의가 있었을 가능성이 있습니다. 이런 경우 밴드를 넘어선 금액을 제시할 수 있습니다. 6. 스타트업에선 다른 방식이 필요함 • 현재 회사의 재무적 상황, 포지션에 대한 계획, 엑싯했을 때 지분가치를 이해하고 협상해야 합니다. 7. 마음을 얻어야 함 • 의사결정권자와 팔로업 미팅을 요청해 그들의 마음을 얻어야 연봉이 나의 가치를 반영할 수 있습니다 8. 데이터를 얻기 • 다른 오퍼와 비교해 경쟁력 있는가? 이야기 나눈 내용은 어떻게 실현되고, 모두 사실인가? 등 데이터를 얻어야 합니다. 9. 오퍼 비교하기 • 오퍼는 회사별로 다양한 방식으로 구성되어 있습니다. 선금을 많이 책정할 수도, 스톡이나 보너스 등으로 나눠져 있을 수도 있습니다. • 어떤 회사가 더 유망한지, 승진은 어떻게 되는지, 매니저의 영향력은 어떠한지 등을 비교해야 합니다. 10. 미신을 딛고 제대로 요구하기 • 실제로 다른 곳에서 받은 오퍼가 있어야 한다, 리크루터에게 내가 얼마나 적합한지 이야기하는게 가장 확실한 방법이다, 오퍼와 기대가 맞지 않으면 포기할 수 있다고 강력하게 이야기 해야 한다 등은 모두 미신이고 잘못된 방법입니다. • 큰 액수로 금액을 성공적으로 올리기 위해서는 올바른 방법이 필요합니다.

디자이너 성장

일하는 방법

[채널톡] 우리 회사만의 방식으로 마케팅 하는 회사가 성공할 수 있다

알토스 벤처스의 Han Kim 대표님이 B2B 회사 경영진에게 던지는 질문에 대해 Sendbird의 Country Manager 이상희님의 주관적인 답변이 담긴 글입니다. Sendbird가 성공을 위해 달려가고 있는 과정과 생각을 엿볼 수 있으니 본인의 프로덕트/회사가 답할 수 있는 내용과 어떻게 다른지 생각해보는것도 도움이 될 것 같습니다. 6가지 질문은 다음과 같습니다. 1. 왜 이 제품을 쓰나요? 이 제품은 어떤 문제를 해결하죠? 2. 타겍 고객이 누구인지? 어떤 크기 기업들이 중심인지? 설득해야 하는 사람이 누군지? 구매자와 사용자가 다른지? 제품은 한 기업에서 몇 명이나 쓰는지? 얼마나 자주 쓰는지? 3. 어떻게 타겟 고객이 이 제품이 있다는 것을 알게 되는지? 알고, 경험하고, 구해하고, 실제로 사용하는데 어떤 프로세스를 겪는지? 처음부터 끝까지 시간이 줄었는지? 어떻게 줄었는지? (어떤 곳들은 어떤 요일 몇시에 어떤 이메일을 어떤 고객에게 보내니 응답률이 좋았다는 실험을 한 곳도 있음) 4. 고객들은 구매 이전에 내부적으로 어떻게 승인을 얻는지? 그게 고객마다 다른지? 다르다면 왜 다른지? 5. (무료에서 유료로 전환하는 모델) 한 번 쓰기 시작한 고객을 어떻게 유료로 전환시키는지? 어떤 실험을 해보았는지? 6. (유료 전환 후) 고객들에게 어떻게 추가로 가치를 줄 수 있는지? 고객 안에서 더 많은 사람들이 쓸 수 있는 것인지? 그러려면 제품 기능 중 어떤 것을 추가해야 하는지?

비즈니스 분석

비즈니스 전략

PM/PO

스타트업

경험 공유

구글 UX Design Lead가 전하는 나를 쓸모있게 만드는 세 가지 성장법

채널톡이 채널톡 마케팅에 적용하기 위해 B2B 마케팅 사례를 분석한 결과에 대한 경험을 공유했습니다. 잘 된 스타트업, 최근 SaaS 붐을 이끌고 있는 사례, 유명한 B2C 서비스까지 다양하게 살펴 본 결과, 공통점은 거의 없고, 두 가지 공통점만 발견할 수 있었다고 합니다. 1. 시장에서 두드러지게 뛰어난 제품(Outstanding Product) 2. 뛰어난 제품에 기반한 입소문(Word Of Mouth) 모두들 다른 방식을 사용했음에도 불구하고 결과적으로는 성공한 사례가 된것을 보면 어떤 성공 방정식은 없는것 같습니다. 다만 모두들 '자신다운' 마케팅을 했다는 점은 눈에 띄었습니다. 채널톡도 채널톡의 마케팅 활동을 돌아봤을 때 자신답지 않은 활동이 많이 발견되었다고 합니다. 특히 '매출이 오른다'는 점을 강조한 광고들은 대표님들의 눈과 귀를 혹하게 만들긴 하지만 결국 뻔한 '쉽게 돈 버는법' 같은 내용에 지나지 않게 될 것입니다. 채널톡은 채널톡을 사용하는 최 우선 목적이 '매출을 올리고 싶어서'가 아니라 '고객과 대화하고 싶어서'가 되면 좋겠다고 합니다. 이런 목적이 실현된 사례를 성공사례로, 광고로 만들어 다시 한번 좋은 마케팅의 Flywheel을 만들 계획이라고 합니다. 우리 프로덕트는 고객에게 어떤 말을 하고 있나요? 우리 프로덕트다운 말을 하고 있나요?

경험 공유

실 사례

케이스 스터디

마케팅

구글의 UX Design Lead인 김은주 디자이너의 스럼프에 빠진 분들을 위로할 세바시 강연입니다. 1. 나의 First 구체화 하기 - Me Fact Table 2. 내가 할 수 있는 일 하기 3. 혼자가 아니다

경험 공유

디자이너 성장

일하는 방법

B2B, 기업용 SaaS를 디자인 한다는 것

스타트업 업계에서 자주 나오는 용어를 만화로 이해하기

B2B SaaS를 디자인하는것의 특징과 감상을 표현한 글입니다. B2B를 디자인하는것은 B2C를 디자인 하는 것과 어덯게 다른지, 어떤 점을 고려해서 해야하는지 잘 표현되어 있습니다. 공감가는 글이라 공유 드립니다.

디자이너 성장

디자인 분석

스타트업 업계에 종사하다보면 다양한 용어를 만나게 됩니다. 업무나 회의 중 나만 모르는 단어를 모두가 이해하고 쓰고 있으면 대화의 흐름을 따라가기 벅찹니다. 스타트업 업계에서 자주 사용되는 용어들을 쉽게 이해할 수 있도록 만화로 풀어낸 곳입니다. 문제는 만화인데 영어로된 만화라는 점..? [지표 & 분석] A/B Testing, ARR & MRR, LTV/CAC, Cohort Analysis, ARPU & AOV, Churn and Bounce rate, Payback Period, DAU/WAU/MAU [프로덕트] Product Market Fit, MVP, Pivot, Growth Hacking, Traction, B2B vs B2C [비즈니스] Burn rate and Runway, Unit Economics, Moat, Bootstrapping vs Raising Funds, Valuation and Stages

프로덕트 전략

프로덕트 분석

비즈니스 전략

비즈니스 분석

데이터 분석

A/B테스팅

지표

KPI

웹 기본

마케팅

프로덕트 디자인 in 스타트업

구글 시트 함수로 정보 스크래이핑 하는 방법 (IMPORTXML)

식스샵 정선우님의 스타트업에서 프로덕트 디자인을 한다는것에 대한 인사이트를 담은 글입니다. 현 시대에 프로덕트 디자이너라는 직무를 많은 기업이 찾는데에는 기존 기능 중심 조직에서 제품 중심 조직으로 많은 기업이 거듭나고 있기 때문이라고 합니다. 제품 중심 조직의 구성원들은 도메인에 대한 지식을 바탕으로 본인이 맡고있는 제품에 대한 오너십을 가지고 (워터폴 방식이 아닌) 애자일하게 일하기를 기대합니다. 스타트업의 성장 과정에서 프로덕트 디자이너가 집중해야 할 일의 구분과 프로덕트 디자이너가 가져야 할 마인드셋과 업무적 역량도 정리하였습니다. 디자이너에게는 다음과 같은 역량이 필요합니다 • 사고 역량 • 끝없는 호기심과 질문 • 사용자 경험에 대한 이해 • 인터페이스 디자인 역량 이러한 역량을 기르기 위해서는 프로덕트 사고, 도메인, 제품 구현에 대한 훈련을 해야합니다.

디자이너 성장

일하는 방법

직무 분석

프로덕트 전략

비즈니스 전략

경험 공유

케이스 스터디

[Figma] Product Design Ladder

리서치 과정에서나 실 데이터를 디자인에 접목하고자 하는 경우 웹상에 존재하는 데이터를 한 곳에 모아야 하는 일이 빈번하게 있는 편입니다. 이 과정을 엑셀으로 간단하게 스크레이핑 할 수 있는 수식인 IMPORTXML 을 소개하고 있습니다. 소개하는 과정을 한번 따라하는 것 만으로도 충분히 감을 잡고 활용하실 수 있어요. 유사한 기능을 하는 다른 수식으로는 IMPORTDATA, IMPORTHTML, IMPORTRANGE 등이 있습니다.

경험 공유

웹 기본

일하는 방법

Grab 딜리버리 디자이너로 일하며 배운것들 1 | 문제 발견과 데이터로 설득하는 과정의 중요성

최근엔 대부분의 회사들이 디자인 툴으로 피그마를 사용하고 있습니다. 피그마는 프로덕트 디자이너의 레벨을 어떻게 바라보고 있을까요? 비공식이고, 2020년 1월이 마지막 업데이트지만 피그마에서 프로덕트 디자이너를 어떻게 6단계로 구분하고 있는지를 확인할 수 있습니다. 본인이 어느 단계에 있는지 가늠해보고, 다음 단계로 나아가기 위해서는 어떤 노력이 필요할 지 생각해볼 수 있습니다.

일하는 방법

디자이너 성장

로그인 후 홈 화면 개선으로 적극적인 사용자 만들기

브런치 작가님 Jina 님이 Grab 디자이너로 1년 간 일하며 배운 것들에 대한 시리즈 1편입니다. 최근 디자이너의 업무 범위가 점점 늘어나는 추세인 것 같은데요, 문제를 발견하고 이를 팀에게 설득하기 위한 과정에 대한 이야기를 중심으로 풀어냅니다. 다른 분들도 실무를 하다 보면 리서치를 충분히 하지 못하거나, 내가 생각한 문제상황을 다른 사람들에게 공감 시키는데 어려움을 느낀 적이 있나요?

경험 공유

UX 개선

일하는 방법

데이터 분석

로그인 후 홈 화면 개선으로 적극적인 사용자 만들기입니다. 위시캣 플랫폼 사용자들을 좀 더 적극적으로 만들 수 있도록 사용자의 상태를 3가지로 구분해 다음 사용 단계를 자연스럽게 유도할 수 있는 적절한 화면을 구성하는 프로세스 전반을 다룬 프로젝트 경험 공유 글입니다. 어떤 과정을 거쳐 어떤 생각으로 디자인하게 됐는지 상세히 작성된 글이라 사용자 상태 별 화면 구성을 고민하는 분들이나 프로젝트의 전체 프로세스를 간접적으로 경험하고싶은 주니어 분들에게 필요한 글입니다

경험 공유

케이스 스터디

데이터 분석

UX 개선

도그푸딩 직접 해보기

데이터 분석가를 위한 All-in-one Worksapce를 목표로 하는 Prequel.ai 에 다니시는 한지유님의 미디엄 글입니다. B2B 프로덕트를 디자인 할 때 가장 힘든점 중 하나가 사용자의 워크플로우를 알기 어렵다는 점입니다. 프로덕트 디자이너가 개발자가 사용하는 SQL을 사용하면서 겪을 수 있는 문제에 공감하기 어려움을 극복하기 위해 직접 SQL을 배우고 실습하는 과정을 경험하였습니다. 이렇게 본인이 고객이 되어 직접 워크플로우를 체험하는 것을 도그푸딩이라고 하는데요, 이렇게 도그푸딩 과정을 통해 고객이 필요한 것을 알아내는 경험을 풀어내었습니다.

경험 공유

실 사례

케이스 스터디

불만을 없앤다고 만족이 생기는게 아니다