#프로덕트 #마인드셋
💬 실수 그거.. 어떻게 줄이는 건데?

아래의 글은 ‘팁스터 뉴스레터 - 메이커들의 커피챗’에 포함, 발행된 글입니다. 전체 뉴스레터를 보시려면 오른쪽 링크를 클릭해주세요! 뉴스레터 보러가기 

'메이커들의 커피챗'은 서비스 기획, 프로덕트 관리, 프로덕트 디자인 등 제품을 만드는 일을 하면서 생기는 여러 문제에 대해 질문하고, 좋은 해결 방법을 탐구하는 뉴스레터입니다. 질문에 대한 메이커들의 생각은 물론, 함께 읽어 볼 만한 글, 써 볼 만한 도구를 함께 담았어요. 출근길 커피 한 잔 하면서 편하게 읽어 주세요!

 

실수를 통한 배움이 우리에게 더없이 소중한 이유

얼마 전, 저의 첫 부사수를 만나 밥을 먹었어요. 주문 후, 가장 먼저 한 이야기는 최근 실수가 많아져 자신감, 자존감이 모두 떨어진 상태라는 내용이었죠. 실수한 것들을 들어보니 한 번씩 더 확인했다면 하지 않았을 실수가 많았습니다. 저도 여전히 실수를 많이 하고 있는데요. 이런 실수를 줄이는 방법은 사람마다 다르지만, 제게 가장 효과적인 방법은 '기록'이었어요. 실수 노트와 같은 것을 만들어 업무의 상황과 단계에 따라 실수한 내용, 배운 것, 다음에는? 과 같은 내용을 정리하는 방법입니다. 그리고 같은 업무를 하기 전, 노트를 보며 이전의 실수와 배움을 확인하고 있어요. 적어도 같은 실수를 하지 않고, 이전의 실수에서 배운 걸 계속 써먹을 수 있어요. 이처럼 오늘은 다섯 명의 메이커를 통해 실수를 어떻게 대하고 있는지, 우리가 참고할만한 방법에는 어떤 것들이 있는지 자세히 살펴보려 합니다.
 

프로젝트 매니저 H : 실수를 배움으로 전환하기 위한 기록의 중요성

창업을 했을 때, 중소기업에서 만드는 품질 좋은 제품을 가져오기 위해 가장 먼저 선택한 방법은 메일을 보내는 일이었어요. 제안서를 만들고 메일 문구를 여러 번 가다듬어 100여 개가 넘는 곳에 메일을 보냈는데 일주일이 넘도록 답장을 하나도 받지 못했습니다. 얼마 뒤, 코엑스에서 열리는 중소기업대전 같은 행사에 팀원들과 함께 찾아갔고 그곳에서 만난 한 업체의 홍보담당자를 통해 이유를 알 수 있었어요. ‘생산'에 초점이 맞춰진 업체는 대부분 홍보담당자가 없거나 있어도 우리가 아는 홍보가 아니라 경리 업무를 함께 보는 분들이 많다는 이야기였습니다. 그래서 메일보다는 전화가, 전화보다는 직접 방문을 하는 편이 피드백을 빨리 받을 수 있을 거란 내용도 함께 들을 수 있었어요. 우리에게 익숙하다는 이유로 받는 사람의 상황과 입장을 전혀 고려하지 못했다는 생각이 든 순간이었습니다.

이후 메일을 보내고 다시 전화를 돌려 몇 곳과 미팅을 할 수 있었는데요. 평택의 한 공장을 방문, 안내를 받아 담당자 두 분과 미팅을 시작했는데, 인사 후 첫 번째 말은 저를 다시 당황하게 했어요. 어떤 서비스인지, 뭘 원하는지 설명해달라는 요청을 들었기 때문입니다. 미팅 일정이 잡혀 들어오긴 했는데, 어떤 미팅인지 정확히 알지 못한다는 내용도 포함되어 있었어요. 제안서가 문제였는데요. 30페이지는 1분 1초가 바쁜 그들에게 꼭 읽어봐야 할 내용이 아니라 귀찮은 존재였고, 슬라이드에 작성된 폰트 사이즈가 크지 않아 자리에 앉아 집중해서 봐야 하기에 읽지 못한거죠.

두 번째 미팅을 했던 팀원 역시 비슷한 경험을 했고, 우린 연달아 세 번에 가까운 경험이 반복되지 않길 바라는 마음으로 이야기를 나눴는데 몇 가지 문제점을 발견할 수 있었어요. (1) 각자가 처음 겪은, 실수에 가까운 경험은 스스로 삼키는 경우가 많다는 것 (2) 첫 실수이기에 업무와 관련된 회고 시간엔 잘 공유되지 않는다는 것 (3) 시간 순으로 정렬하면 팀과 조직에게는 반복되는 실수인 경우가 된다는 것. 첫 번째 미팅에서 겪은 경험을 먼저 공유하지 않았다면, 두 번째 미팅을 진행한 팀원은 다음엔 그렇게 하지 않아야겠다.라는 생각으로 넘어갔을 가능성이 높다는 사실을 알게 된 시간이었어요.

각자가 이런 생각과 과정을 겪고 있었고, 팀 관점에서는 큰 손실을 보고 있다는 생각에 저는 회고 시간을 활용, 처음의 실수를 모두의 배움으로 녹여낼 수 있는 이야기를 함께 진행하기로 했습니다. 지금도 저는 ‘오늘/매일의 배움'이라는 이름으로 작성 중인 이 내용은 그리 어렵지 않게 정리할 수 있는데요. (1) 매일 배운 점을 작성한다 (2) 배운 점을 다음에 어떻게 활용할 수 있을지 의견을 덧붙인다 (3)업무 관점이라면, 팀원들과 공유 후 피드백을 함께 덧붙인다.

예를 들어 생산업체에 첫 연락을 할 땐 이메일보다 전화가 더 효율적이다. 가 오늘의 배운 점이라면, 전화를 언제 하면 연결될 확률이 높아질 수 있는지, 전화 시 짧은 시간에 집중적으로 전달해야 할 정보가 무엇인지 등 다음에 전화할 때 개선 또는 생각해볼 수 있는 내용을 작성하는 방법입니다. 또 나와 같은 업무를 한 번 이상 경험한 팀원들과 간략하게 논의한 내용까지 더해지면 메일을 보내 답장을 하나도 받지 못한 우리의 실수가 전화로 미팅까지 연결되는 확률을 높이는 배움으로 연결될 수 있다고 생각해요.

 

메이커의 꿀팁

  • 개인과 팀의 실수를 ‘배움’이라는 이름으로 기록한다.
  • 실수를 하지 않기 위해, 다음에는 어떻게 할 것인지를 함께 작성한다.
  • 회고 시간을 활용해 실수를 통한 배움에 대한 내용을 확인하고 실행한다.

 

배움의 기록을 위해 읽어보면 좋은 글

사실 위 내용은 에디터🐳의 이야기예요. ‘한 번의 실수는 배움이, 두 번의 실수는 실력이 된다’에 정리된 내용이기도 한데요. 위 내용과 더불어 눈에 띄었던 내용은 ‘창업의 끝에 작성한 실패노트’였어요. ‘사무실을 정리하며 팀원들과 틈틈이 작성한 ‘배움' 노트를 다시 펼쳤다. 빼곡히 적힌 우리의 배움이 꽤 많다는 생각이 들었다. 나는 펜을 들어 다음장 첫 줄에 ‘만약에'로 시작되는 가정들을 하나씩 적고, 다시 다른 색으로 ‘다음에는'이라는 말을 이어 붙였다. 배움을 적고, 개선할 점을 함께 적었던 기존의 방식과 크게 다르지 않았다.’

다음에는(같은 상황을 마주한다면), 그때는 이렇게 해보자.라는 내용으로 작성한 또 하나의 노트에 에디터는 ‘실패 노트'라는 이름을 붙였다고 해요. 첫 번째 이유는 작고 큼에 상관없이 실패와 실수에 대한 경각심을 갖기 위해서이고 두 번째 이유는 실패를 통한 배움을 잊지 않고 계속 유지하기 위해서였다고 하네요. 실수라는 기록이 많아지는 건 마냥 좋진 않지만, 그 기록이 잘 정리되어 있다면 업무를 하기 전 한 번씩 우리 스스로를 되돌아보고 두 번의 실수로 연결되지 않는 중요한 역할을 하지 않을까요?
 

 

서비스기획자 Y : 나만의 업무 QA 도입하기

 


제가 자주 저지르는 하찮은 실수가 하나 있어요. 피그마나 노션으로 작성한 기획 문서를 공유할 때 링크의 접근 권한을 공개로 설정하는 것을 깜빡하는 거예요. 사람들이 저에게 접근 금지 페이지가 나와서 안 보이니까 권한을 풀어달라는 DM이 오면 죄송하다고 말씀드리면서 뒤늦게 권한을 수정하는 경우가 종종 있었어요. 비록 작은 실수지만 여러 번 반복되니 어느 순간 ‘이건 실수가 아니고 실력이다. 내가 프로답지 못하게 일하고 있구나.’ 하는 생각이 들었어요. 지금까지는 실수의 상대가 내부 팀원이었지만, 만약 중요한 고객사인 경우에는 제 실수로 인해 전화나 이메일이 한두 번 더 오가는 등 커뮤니케이션 비용을 낭비하게 되고, 회사에 대한 신뢰에도 영향을 미칠 수 있었어요.

그렇지만 단순히 실수를 할 때마다 자책하거나, 다음부터 실수를 하지 말아야지! 하고 다짐하는 것에서 그치고 싶지 않았어요. 의지를 다잡는 것은 그때뿐, 실제로는 별로 효과가 없다고 생각해요. 막상 업무 마감일이 돌아오면 더 중요하게 챙겨야 할 것들이 많아서 사소한 다짐은 기억할 수 없다는 것을 경험상으로 알고 있었어요. UX 디자인 원칙 중에는 ‘포카요케’라는 용어가 있는데요, 사용자의 실수를 미리 예상해서 설계할 때부터 오류가 발생하지 않도록 만드는 것을 의미해요. 저희가 제품을 만들 때 실수를 저지르지 않는 사용자는 없다고 가정하는 것처럼, 저도 같은 가정을 염두에 두고 실수를 시스템적으로 방지해야겠다고 생각했어요.

그래서 저는 문서 공유 권한처럼 반복된 실수가 눈에 띌 때마다 적어놓는 리스트를 만들고, 마감일 전에 이 리스트를 검토하는 시간을 가지고 있어요. 마치 QA팀이 테스트케이스를 만드는 거랑 비슷한 느낌이 들어서 저만의 업무 QA라고 부르고, 캘린더에 아예 날짜와 시간도 등록해 놨어요. 여기서 중요한 것은 반드시 시간을 확보하는 거예요. 검토하는 과정을 보조적인 것으로 생각하고 과소평가하면 또 다른 실수가 나오더라고요. 마치 개발할 때 보이지 않았던 버그를 테스트 기간에 잡아내듯이, 지금 보이지 않는 실수가 반드시 한두 개는 숨어있다는 생각을 가지고 업무를 대하는 것이 결과적으로는 제가 하는 일의 퀄리티를 프로에 가깝게 만들어준다고 생각해요.

 

메이커의 꿀팁

  • 실수를 하지 않겠다는 다짐보다 실수를 방지하는 시스템 만들기
  • 실수를 줄이기 위한 업무 QA, 체크리스트를 만들어 활용하기 

 

업무 QA 도입을 고려할 때 읽어보면 좋은 글

잔실수를 줄이려면 어떻게 해야 할까요?라는 글에도 실수를 반복하지 않기 위한 방법으로 실수 노트를 만들어 내 실수에 대한 데이터를 먼저 모으고, 모수가 쌓이면 가장 많이 한 실수부터 체크리스트에 정리하는 방법을 추천하고 있어요. 체크리스트를 도입했던 미군 육군항공대 사례를 소개한 부분을 재미있게 읽었는데요, 1935년 미군은 조종사의 실수로 인해 차세대 비행기를 소개하는 행사에서 그만 비행기가 폭파되는 사건을 겪는데요, 해결책으로 조종사가 비행 전 확인해야 할 체크리스트를 도입한 결과 이후에 있었던 수많은 비행에서 단 한번의 사고도 내지 않았다고 해요. 미군은 비행기 조종을 이륙, 비행, 착륙, 지상 이동의 4가지 파트로 나누어서 리스트를 만들어 실수의 가능성을 낮추었다고 하는데, 우리도 반복되는 업무 단계를 나누고 각 단계에서 어떤 실수가 자주 일어나는지 떠올려보면 어떨까요?

한편, 작은 실수를 줄이는 방법에서는 실수하는 사람의 마인드셋에 대해 이야기하고 있어요. 실수를 반복하는 이유는 그것을 작게 여기는 태도 때문이고, 이 태도는 곧 습관으로 이어져 나의 이미지를 안좋게 만드는 나비효과가 될 수 있다는 부분에서 공감이 됐어요. 특히 에디터는 예전에 업무를 완벽하게 해서 넘긴다는 욕심 때문에 데드라인을 1분, 2분 지각하는 실수를 종종 저질렀던 때가 있어요. 생각해보면 반복된 실수 이면에는 시간약속을 어겨도 된다는 가벼운 마음이 있었고, 이것이 업무평가로 이어졌던것 같아서 이 글을 읽고 뼈아픈 반성을 하게 됐어요. 절차를 통해 실수를 방지하는 것도 좋지만 내가 업무를 대하는 근본적인 태도가 어떤지 점검하는 것도 중요하다고 생각해요.

 

마케터 L : 업무집중시간을 최대한 활용하기

스타트업은 우리가 하나의 업무에 집중할 시간과 환경을 넉넉하게 제공하지 않아요. 사실 일반 회사에서도 마찬가지라고 생각하는데요. 동시다발적으로 업무를 진행하다 보면 우리도 모르게 실수를 하게 되는 경우가 많아요. 예를 들어 다음에 만들 기능에 대한 정책을 확인하며 활용 방안을 정리하고 있는데, 다른 팀에서 지난 기능에 대한 광고 집행 결과를 공유해 달라고 하는 등 업무가 갑자기 들이칠 때가 있어요. 그럼, 어떤 업무를 먼저 해야 하지?라는 생각을 하게 되고, 우선순위가 갑자기 변경되어 다른 업무를 먼저 진행하게 될 때도 있어요. 동시에 여러 업무를 요청받게 되는 상황도 많고요.

저도 이런 경험이 많았고, 그때마다 우선순위를 나름의 기준에 따라 조정하며 일을 했지만 시간은 매일 정해져 있기에 하나의 업무에 집중하지 못하는 상황이 많아지고 자연스레 실수로 이어지는 경우가 많았어요. 그래서 가장 먼저 집중업무시간을 활용하기로 했습니다. 재택과 출근이 병행되는 특성 상, 슬랙 상태표시에 매일 집중업무 시간을 설정하고 다른 팀에게도 그 시간은 제 기준 우선순위가 높은 일에 집중하고 싶다는 의견을 공유드렸어요. 저는 주로 10시부터 12시까지를 정했는데, 그 시간에 미팅이 자주 없고 (8시 - 11시 사이에 출근하기 때문) 개인적으로 집중이 가장 잘 되기 때문이었어요. 이 시간에는 다른 업무가 치고 들어와도 일단 제가 해야겠다! 생각한 업무에 집중했고, 이후에 요청이 오거나 다음에 진행해야겠다고 생각한 업무를 다시 한번 확인해서 진행했어요.

집중업무시간은 하루에 일정시간 우선순위에 따른 업무를 처리하고, 실수를 줄이는데 많은 도움이 되었는데요. 여전히 아쉬웠던 점은, 개인의 업무 우선순위가 계속 바뀐다는 점이었어요. 우선순위는 바뀔 수 있지만, 변경으로 인해 제가 업무 일정이나 업무 자체를 놓치는 등의 실수로 이어지는 경우가 많아, 관리가 필요하다고 생각했어요. 저는 회사의 유일한 마케터라 업무를 하나, 둘 놓치면 팀에게 영향을 주는 상황이 발생하기도 했는데요.

그래서 매일의 해야 할 일을 정리해서 슬랙 채널에 공유하고, 집중해서 처리할 일을 따로 표기했어요. 우선순위가 변경되면 변경된 이유와 이에 따라 영향을 주는 다른 업무에 대해서도 공유해 모두가 확인할 수 있도록 했죠. 제가 이 두 가지 방법을 쓰면서 느낀 건, 실수가 어디에서 시작되는지 그 환경을 먼저 생각해봐야 한다는 것이었어요. 제게는 업무 환경이 가장 컸고(홀로 일하며, 요청을 많이 받는 입장) 그 과정에서 실수를 줄일 수 있는 방법을 많이 생각하게 되었습니다.

 

메이커의 꿀팁

  • 업무 환경, 과정에서 실수가 많이 발생하는 지점 찾기
  • 업무집중시간을 활용해 온전히 일에 집중할 수 있는 환경 만들기
  • 해야할 일과 변경사항 등을 반영해 업무 진행상황 공유하기

 

업무집중시간을 갖고자 할 때 읽어보면 좋은 글

시간 관리가 무엇보다 중요한 이유'에서도 업무의 순서와 시간을 할당하는 방법에 대해 정리하고 있어요. 매일 할 일을 정해놔도 중간중간 치고 들어오는 업무로 인해 순서나 시간이 변경되면 팀과 개인에게 영향을 줄 수밖에 없고, 그런 상황에 우리가 어떻게 대처해야 하는지가 주요 내용인데요. (1) 업무와 업무, 즉 시간과 시간 사이에 10-15분 정도의 여유 주기 (2) 정해진 업무와 시간에 다른 업무가 끼어들어야 하는 경우 우선순위를 위한 기준 만들기(3) 끼어든 업무가 먼저라면, 해당 업무를 진행한 시간만큼 기존 업무를 재구성하기 (4) 필요하다면 나머지 업무 일정도 다시 한번 확인, 다음날 일정까지 함께 고려하기 등의 방법이 잘 정리되어 있습니다.

이어서 (1) A 업무에 할당되는 시간을 계산, B 업무를 마지막 10분 정도 포함시킨다. (2) 정해진 만큼 재충전의 시간을 갖는다. (3) B 업무를 다시 이어서 진행한다. 다음 쉬는 시간 전, C 업무를 일부 진행한다. (4) 이 과정을 반복한다. 등의 내용을 확인할 수 있어요. 제가 인상 깊었던 건, 쉬는 시간에 대한 내용이었는데요. 우리가 업무를 하면서 중간중간 쉬는 시간을 잘 활용하지 않으면 업무와 업무 사이의 연결이 잘 되지 않고, 집중력을 유지하기 어려워 실수로 이어질 수 있기 때문이에요.

 

서비스 기획자 A : 검토를 별도의 업무로 활용해야 하는 이유

저는 기획 업무가 익숙하지 않은 시기에 검토를 업무 전체의 일부라고 생각했어요. 당시에는 기획 업무의 핵심이 ‘와이어프레임’과 ‘스토리보드’ 제작이었는데요. 그때 작성한 업무 리스트를 보면, A 기능 스토리보드 제작이라고 쓴 뒤, 바로 다음 업무로 ‘리뷰’가 이어졌어요. 스토리보드를 만들고, 리뷰 전 확인까지 하나의 큰 업무로 생각했다는 사실을 알 수 있는 내용인데요. 검토는 중요한 과정이지만, 스토리보드 등을 계속 만지며 내용에 익숙해진 상태에서 검토를 하기에 잘못되거나 바로 잡아야 하는 것을 제대로 보지 못한다는 문제가 발생했어요. 실제로 리뷰를 하면 제가 스스로 봤을 땐 보지 못했던 내용이 피드백으로 여럿 언급되는 경우가 생겼죠.

이렇게 검토를 하나의 업무 속 마무리로 진행하면 놓치는 내용 등 실수가 계속 일어날 것 같다는 생각에 검토를 별도 업무로 구분해 보기로 했어요. 기존에는 ‘스토리보드 제작’이 하나의 업무였다면, ‘스토리보드 제작’과 ‘스토리보드 검토’를 두 개로 나누고, 각각의 일정을 산정해 업무를 진행하게 된 것이죠. 물론 일정은 동일하게 가져가되 검토에 필요한 시간을 더 할당하는 방법으로 시작했어요. 그리고 검토를 시작할 땐, 같은 업무를 진행하는 팀원들에게도 공유한 뒤 피드백을 요청했어요. (지난 뉴스레터 ‘업무 리뷰’에도 비슷한 내용이 있더라고요!)

검토를 하나의 별도 업무로 분리하고, 함께 하는 사람을 추가한 결과는 생각보다 좋았어요. 무엇보다 이제 곧 끝이다!라는 생각으로, 집중력이 떨어진 상태에서 업무 검토를 했을 때보다 집중도가 높아졌다는 게 느껴졌어요. 제작을 마친 뒤, 잠시 다른 일을 하거나 쉬는 시간을 갖는 등 억지로 잠시 멀어졌다가 다음 업무로 검토를 진행하니 놓치는 내용이 많이 줄어들었고, 함께 참여해 주는 동료들 덕분에 리뷰 전 꼼꼼하게 내용을 확인할 수 있었죠. 이후로는 모든 업무 검토를 별도로 진행하고 있고, 여전히 제게는 중요한 업무 루틴 중 하나로 자리 잡고 있어요.

 

메이커의 꿀팁

  • 업무의 끝에 검토를 두지 않고, 별도 업무로 활용하기
  • 검토 업무 시, 함께 참여할 수 있는 동료 고려하기
  • 주요 업무로 시작해, 모든 업무에 검토를 분리해 진행하기

 

검토를 분리해 실수를 줄이고 싶을 때 읽어보면 좋은 글

내가 결정한 일이 주는 영향 고려하기’에서는 우리의 결정이 주는 ‘영향’을 깊게 고려하지 않았던 실수에 대해 이야기하고 있어요. 신규 기능으로 인해 영향을 받는 기존 기능은? 신규 기능으로 인해 영향을 받을 핵심 지표는? 신규 기능으로 인해 영향을 받는 기타 요소는? 등을 미리 확인하고 준비했어야 하는데, 새롭게 추가될 기능에 초점을 맞춘 나머지 개발 과정에서야 충돌이 발생하는 부분을 확인하게 된 것이죠. 때문에, 이전까지의 서비스 상황을 잘 파악하고 있어야 하며, 우리가 준비하는 개발 과정에서 받는 영향을 미리 분석할 수 있어야 한다는 내용도 포함되어 있습니다.

이 글을 읽으며, 검토를 별도의 업무로 활용하는 과정에 진행한 업무는 물론이고 이 업무가 주게될 영향도 함께 확인하면 좋겠다는 생각이 들었어요. 검토의 범위를 조금씩 확장해보는 것이죠. 검토에 드는 시간은 조금 추가될 수 있지만, 이를 통해 영향을 받을 수 있는(하지만 발견하지 못한) 대상을 찾을 수 있다면 오히려 시간을 절약할 수 있지 않을까 생각합니다.

 

프로덕트 오너 S : 나의 직책에 따라 집중해야 할 역할을 돌아보기


저는 큰 실패를 경험한 뒤 그 실패가 귀한 경험이 될 수 있도록 자신을 돌이켜본 뒤에서야 제 실수가 뭔지 알게 된 적이 있습니다. 하나의 프로덕트를 총괄하는 PO로 일하며 미래의 먹거리로 새로운 BM을 적용한 신규 플랫폼을 이끌게 되었죠. 팀을 리딩하며, 세부 기획을 진행하는 등 치열하게 준비한 끝에 6개월 후 베타 버전을 오픈 할 수 있었습니다. 하지만 1년 6개월 후 회사의 상황으로 인해 페이드 아웃(종료) 대상이 되어, 서비스와 팀이 해산되는 결과를 맞이하게 되었어요.

이끌던 서비스가 꽃 피우지 못한 채 종료되는 경험으로 초기에는 스스로 자책하고 자신감이 많이 떨어졌어요. 시간이 조금 흐른 뒤 냉정하게 1년 6개월 동안 서비스가 왜 안정적인 반열에 오르지 못했는지 돌이켜봤습니다. 여러 환경적 아쉬움과 사업적 지연이 일어났던 영향도 분명 있었지만, 저는 외부 요인보다 스스로가 바뀔 수 있었던 부분이 뭐가 있었는지 고민했어요. PO로 빠른 의사결정보다 세부 기획에 더 집중하다 보니 성장할 기회를 놓쳤던 순간들이 떠올랐습니다. 완성도 보다 성장에 초점을 맞춰 의사결정을 했다면 좋은 기회가 있었을 텐데, 저는 사용자 경험과 개발 안정성에 우선순위에 뒀던 것이죠. 

경력이 늘어날수록 커버해야 할 영역은 늘어나고, 디테일한 실무보다 팀 관리 혹은 서비스 전체적인 관리 업무가 더 늘어나는데요. 직군마다 역할이 있듯, 사람마다 팀과 서비스에서 어느 쪽에 더 중심을 두어야 하는지가 중요하다는 사실을 이번 경험으로 알게 되었습니다. 그래서 저는 지난 경험을 통해 현재 내가 속한 조직, 업무 과정에서 나란 사람이 어디에 더 중점을 두어야 하는지를 고민하게 되었습니다. 그 결과 새롭게 꾸려진 팀에서는 세부 기획과 디테일은 그 업무를 좀 더 깊게 고민할 수 있는 담당자에게 맡기고, 저는 다음 업무를 미리 준비하고 성과를 위한 더 큰 사업 목표를 신경 쓰고 있습니다.

 

메이커의 꿀팁

  • 직책, 직무에 따라 어느 역할에 더 중점을 두어야 하는지 고려하기
  • 환경과 목표에 따라 빠르게 의사결정 하기
  • 팀과 충분히 업무를 분담하여 전체적인 밸런스 맞추기

 

실패를 어떻게 대해야 할지 모를 때 읽으면 좋은 글

지난 6월 한 창업자의 사이드 프로젝트 회고록이 굉장히 뜨거웠습니다. [Skrr 회고]🦄 퇴사하고 사이드프로젝트로 창업했는데 실패했다. 누구나 실수는 물론 작고 큰 실패를 끊임없이 경험하는데요. 그 경험을 얼만큼 받아들이고 왜인지 이유를 분석하는 것은 앞으로 나아가기에 큰 도움이 될 거에요! 특히 Skrr 회고 글에서 감명 깊었던 부분은 애정 깊었던 아이템에 대해 냉정하게 성장 가능성을 돌이켜보는 점과 창업자이자 팀 리더의 관점에서 팀원이 끝까지 흥미를 가지고 도전적으로 일할 수 있는 환경을 구축하지 못한 점을 회고한 것이 흥미로웠습니다. 앞서 메이커로서 제 경험 또한 환경을 구축하고 의사 결정할 수 있는 자리에 있는 ‘내’가 무엇을 더 깊게 고민해야 하는 지 생각하는 점에 공감도 했습니다.

 

같은 주제에 대한 더 많은 메이커 이야기는 뉴스레터를 통해 자세히 확인하실 수 있어요.
전체 뉴스레터를 보시려면 오른쪽 링크를 클릭해주세요! ‘뉴스레터 보러가기 

팁스터 뉴스레터에서는 프로덕트와 관련된 다양한 주제의 콘텐츠를 발행합니다.
(1) 서비스의 업데이트 전/후와 실무자의 코멘트가 담긴 '업데이트 소식'
(2) 다양한 메이커의 실무에 대한 노하우가 담긴 '메이커들의 커피챗'
(3) 서비스의 문제해결 방법을 산업을 중심으로 살펴보는 '멤버십'

링크 복사

팁스터 뉴스레터 · 에디터

프로덕트와 관련된 다양한 주제의 콘텐츠를 발행합니다.

댓글 1
팁스터 님의 글이 EO 뉴스레터에 실렸습니다. 이번 주 이오레터를 확인해보세요!

👉https://stib.ee/Z8v9
추천 아티클
팁스터 뉴스레터 · 에디터

프로덕트와 관련된 다양한 주제의 콘텐츠를 발행합니다.

1