바오밥나무

기술에 대해 "충분히 아는" PM이 되는 길

In Web Posted Mar 23, 2017
Extra Form
저작자 Lulu Cheng (Instagram Product Manager)
출처 http://www.lulucheng.com/2015/11/28/gett...t-manager/
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

당신은 기술에 대해 잘 알지도 못하면서 왜 검색 파트의 PM 인가요?

위 질문은 실리콘 벨리에 있다 보면 자주 맞닥뜨리는 무심한 질문입니다. 만난 지 5분밖에 되지 않는 사람에게 던질 법한 질문은 아니지만, 합리적인 질문이라고 생각됩니다.

 

전통적으로 제품 관리자(Product Manager, 이하 PM)에게 요구되는 조건 "컴퓨터 과학이나 관련된 분야에의 학사 학위, 혹은 이에 준할만한 실제적 경험" 입니다. 후자는 보통 "제가 만든 거에요." 라고 말한 만한 사이드 프로젝트가 있을 때를 의미하죠. 몇몇의 예외는 있지만, 기술에 대한 이해가 깊은 것(Being technical)은 "있으면 좋은 것"이라기보단 "무조건 있어야 하는 것" 입니다.

 

최근 기업들은 이러한 요구 조건을 "PM은 기술에 대해 충분히 알아야 한다." 로 다시 쓰고 있습니다. 요구 조건에 적힌 단어의 선택에 집중해 다음을 읽어 보세요. (링크를 클릭하시면 각 기업을 확인해보실 수 있습니다.*) 

 

 

제가 조금 편향적이긴 하지만, 일반적으로 이러한 움직임은 좋은 방향이라고 생각합니다. 또한 PM 의 역할과 수요가 늘어날 수록 이런 움직임은 가속화될 것입니다. 제품 관리(Product Management)는 과학인 만큼 인문학이며, 통계학인 만큼 심리학입니다. 또 작은 디테일에 집중하는 만큼 큰 그림을 보는 것도 중요하죠. 여러분이 어떤 산업의 회사에 속해 있으며, 어떤 제품의 무슨 기능을 담당하고 있는지에 따라 요구되는 기술적인 수준과 일상 업무는 매우 달라집니다. 더불어, 존경 받는 PM 이 되기 위한 자질에는 기술적 전문성이 거의 포함되지 않습니다. ("그건 훌륭한 엔지니어를 낭비하는 방법입니다." 라고 누군가 말하기도 했죠.)

 

하지만 궁금증은 풀리지 않습니다. 기술에 대해 "충분히 안다." 는 것이 정확히 어떤 의미일까요? 어떻게 성취될 수 있을까요? 또한 그러는 와중 어떻게 팀 내에서 신뢰를 쌓을 수 있을까요?

 

제가 마케팅에서 PM 으로 직무 전환을 했을 때, 저는 이러한 궁금증을 풀어줄 만한 대답이 인터넷에 거의 없다는 사실에 놀랐습니다. 그래서 제가 Pinterest 검색 파트에서 겪은 첫 90일간의 PM 경험을 통해 나름대로 대답해 보려 합니다. 제 글이 비 기술 분야의 배경을 가진 PM 들에게 도움이 되었으면 하는 바이며, 이를 통해 더욱 더 많은 대화들이 오고갔으면 좋겠습니다.

 

글은 제가 좋은 PM 이 되기 위해 시도한 경험이 녹아든 두 가지 파트로 나뉘어 있습니다.

  1. 기술에 대한 이해의 베이스라인을 구축하고, 시간이 지남에 따라 더 투자한다.
  2. 어떻게 즉각적인 가치를 더할 수 있는 지 파악해 신뢰를 쌓는다. 

 

기술에 대한 이해의 베이스라인을 구축하고, 시간이 지남에 따라 더 투자한다.

첫 번째로, PM 으로서 "충분히 기술적" 이 된다는 것은 어떤 의미일까요? 다양한 의견들이 있지만, 저는 다음과 같은 능력이라고 생각합니다.

  1. 사용자 이슈를 따라가 잠재된 문제를 파악할 수 있다.
  2. A 기능과 B 기능을 만들 때 어떤 것이 더 오래걸리는지 대략 추정할 수 있다.
  3. 특정한 기획이나 제안을 적용할 때 있을만한 문제들을 예측할 수 있다.
  4. 기술적인 문제들에 대한 잠재적 해결 방안을 브레인스토밍할 수 있다.
  5. 새로운 기술들로 인해 생기는 기회 요소들을 발견할 수 있다. 

 

각 능력의 상대적인 중요도는 여러분의 제품에 따라 달라질 것입니다. B2C 앱이라면 새로운 기술을 활용하는 것이 중요할 것이고, B2B 소프트웨어라면 정해진 스케쥴에 맞추어 프로젝트 범위를 정하는 것이 중요하겠죠. PM 은 이러한 이슈들의 중요도를 가늠해야 합니다.

 

이제 어디로 가야할 지는 조금 알았으니, 다음 질문은 어떻게 가야 하는가? 일테죠. 제가 발견한 방법들은 다음과 같습니다.

 

호기심으로부터 시작한다.

앞으로 있을 리스트 중, 이것만은 무조건 지켜야 합니다. 기술적인 문제들에 대한 진정성 있는 호기심은 여러분들의 든든한 동반자가 될 것입니다. 호기심이 없다면, 다음 말씀드릴 일들은 그저 '해야할 일' 일 뿐이겠지요. 특정한 지점까지는 이런 호기심을 일부러 길러내는 것이 가능은 하지만, 저라면 PM 인터뷰 도중 이러한 신호들을 찾아낼 것입니다. Ellen Chisa 가 이와 관련된 훌륭한 포스트를 썼으니, 더 관심이 있다면 읽어보시면 좋을 겁니다.

 

엔지니어링에 내재된 창의성을 존중한다.

바로 전 이야기와 이어지는 포인트입니다. 엔지니어링이란 무에서 유를 창조하는 행위로서, 그 안에 엔지니어의 창의성이 내재되어 있다는 사실을 잊지 말아야 합니다. 또한 엔지니어링은 복잡성을 필연적으로 동반합니다. 구현된 모든 기능의 뒷면에서 엔지니어는 항상 수 많은 결정들을 내리고 있습니다. 내리게 될 결정 사이에 섬세하고 장 단점을 비교하며 디테일을 적용하고, 특이 케이스들을 고려해가면서 말이죠. PM으로서 이러한 절차와 역학들을 이해하는 데 실패한다면, 엔지니어들은 최선의 퍼포먼스를 내기 위해 필요한 "제품에 대한 주인의식" 을 잃게 됩니다.

 

엔지니어들을 괴롭힐(?) 시간을 초기에 만들어 둔다.

첫 며칠 간 여러분들이 읽을 수 있는 것은 모두 읽고, 끊임 없는 질문 리스트들을 만들어 두세요. 그리고 화이트보드 하나를 잡고, 엔지니어 한 분을 초대해 질문들을 같이 검토해 보세요. 현명한 질문을 위해선 사전에 충분한 이해도를 쌓아 두어야 합니다. 같이 질문을 검토하는 부분은 너무 미루지 마세요. 스크린을 쳐다보는 것만으로 배울 수 있는 것에는 한계가 있으며, 팀원과 함께 보내는 시간은 큰 도움이 될 것이니까요.

 

배운 것을 공유할 수 있는 형태로 갈무리한다.

이 지점에서 여러분들은 온갖 약어와 끄적거린 다이어그램들 속에서 허우적대고 있을 겁니다. 새로운 정보들을 전부 문서 형태로 갈무리 하세요. 갈무리한 문서를 신입 직원들과 공유하세요. 그들이 적응을 위한 리소스로서 활용할 수 있도록이요. 다른 분야 매니저들에게 여러분이 맡고 있는 분야의 소개 발표를 해 본다면 더 좋을 겁니다. 이렇게 공유하고, 발표하는 것은 여러분이 어떤 것을 알고 있으며 어떤 것을 더 파봐야 할 지 잘 알게 해줍니다.

 

피드백과 버그 리포트를 활용해 다양한 이슈에서 패턴을 찾아본다.

"충분히 기술적" 이라는 것이 무슨 의미인지에 대한 첫 번째 이야기로 돌아가 봅시다. "사용자 이슈들을 통해 기저에 있는 문제를 파악할 수 있다." 는 것이 첫 번째 기준이었습니다. 이를 위한 방법 중 하나는 피드백과 버그 리포트들을 짜맞춰 패턴을 파악해보는 것입니다.

 

PM 으로서 여러분들은 제품에 대한 피드백에 대해 첫 번째로 대응할 수 있는 영광을 가지게 됩니다. 예를 들어 보죠. 어떤 날 여러분들은 다수의 혼란스러운 버그 리포트를 받았습니다. 동료가 슬랙을 통해 "검색 내용에 작은 따옴표를 붙이면 연관검색어가 나오지 않아요." 라고 말했고, 어머님이 이메일을 통해 "'윌리엄-소노마'를 찾았는데, 결과가 나오지 않는구나. :(" 라고 말씀하셨습니다.

 

여러분들이 이슈를 트래킹할 수 있는 충분한 준비가 되어있다면, 다음과 같은 일들이 일어나게 됩니다.

  1. 특정 버그에 대해 엔지니어들이 쓰는 단어들을 알아들을 수 있게 됩니다.
  2. 다양한 이슈들이 공통적인 문제에서 나올 경우, 관련된 이슈들을 연결지을 수 있게 됩니다. 

따라서 동료와 어머님으로부터 받은 리포트가 한 가지 이슈에서 생긴 것이라는 것을 알 수 있겠죠. "표준화된 자동완성 기능이 구두점들을 적절히 통제하지 못하다." 라는 기술적인 문제를요. 또한 이러한 과정을 통해 다양한 이슈들의 크기나 중요도에 대해 가늠해볼 수 있는 능력을 키울 수 있게 됩니다.

 

코딩과 친숙해 진다.

당황하실 필요 없습니다. "코딩과 친숙해 지는 것" 의 목표는 코드 내 언제 어디서 특정 변수들을 선언하는지 정도에 대해 답할 정도면 됩니다. 엔지니어들을 괴롭힐 필요 없이요.

 

핵심 개념에 집중한다.

모든 분야에는 항상 등장하는 개념들이 있습니다. 검색 분야에서의 정확도 vs 재현율이라던가, 데이터 모델링에서의 카디널리티(Cardinality) 등이죠. 컴퓨터 과학 내에서 그러한 개념들을 파악해보고, 구체적으로는 여러분들의 제품 분야에서도 알아보세요. 이러한 작업들은 학습의 우선순위를 파악할 수 있게 해 줍니다.

 

철면피가 된다.

커닝햄의 법칙에 따르면, "인터넷에서 정답을 얻는 가장 좋은 방법은 질문을 올리는 것이 아니라, 잘못된 대답을 올리는 것이다." 라고 합니다. 여러 관점에서 이 말은 PM 의 역할에 대한 완벽한 비유로 볼 수 있죠. 제품의 기능이나 스펙에 관한 초안, 낙서 등을 만들어 다른 사람들이 씹고 뜯고 맛보고 즐길 수 있게 하는 것이 여러분들의 일입니다. 못생긴 빨대 인간들을 그려놓는 것이 중요한 게 아니고, 이러한 일이 대화 자체를 시작되게 만든다는 것이 중요합니다.

 

어떻게 즉각적인 가치를 더할 수 있는 지 파악해 신뢰를 쌓는다.

새로운 기술을 배우는 것은 시간이 걸립니다. 하지만 일과 함께라면 풀타임으로 학생이 될 수 있는 사치 같은 건 없습니다. 여러분들이 즉각적으로 영향을 미치고 기여를 시작할 수 있는 분야를 찾아내야 합니다. 하지만 이건 그렇게 어렵진 않습니다. 애초에 여러분들이 고용 된 이유 자체가 여러분들이 가진 기술과 능력 덕분이니까요.

 

데이터를 파고든다.

팀 내 각 역할은, 다른 사람들이 함께 일하고 싶도록 만드는 슈퍼 파워들이 있습니다. 디자이너라면 고해상도 프로토타입 등을 빠르게 만들 수 있는 능력이라던지, 엔지니어라면 빠르게 프로토타입을 구현하고 언제 코드들을 가다듬을 지 판단하는 능력 등이죠.

 

제가 생각하기에 PM 의 슈퍼 파워는 데이터에 대한 능숙함입니다. "ABC 라는 기능이 얼마나 쓰이죠?" 라는 질문이 튀어나왔을 때, "대충 123 정도요." 라고 바로 대답할 수 있는 능력이죠. 그러면 여러분들은 신뢰를 쌓게 됩니다. 제품 분석 쪽에 있는 사람들이 PM 으로 많이 가는 이유도 이에 있다고 생각됩니다.

 

실제적으로는, 데이터에 대한 능숙함이란 것은 다음과 같은 일들을 할 수 있는 것입니다.

 

  1. 어떤 프론트 엔드와 백 엔드 데이터들이 어떻게 로깅되는 지 알고 있다.
  2. 데이터가 어디에 저장되는지 알고 있다.
  3. 데이터들을 쿼리하는 방법을 알고 있다.
  4. 실험의 결과를 분석하는 방법을 알고 있다.     
  5. 가장 좋은 디자인 사례들을 찾아 실험할 수 있다.

 

프로젝트가 진행될 수 있도록 장애 요소를 치운다.

효율적인 미팅을 진행하세요. 이는 다음과 같은 것들입니다.

 

  1. 미팅의 목적이 참가자들에게 전달되었다.
  2. 의사결정에 필요한 사람들이 모두 참가한다.    
  3. 미팅의 시작에 적절한 정도의 맥락이 공유된다.    
  4. 미팅이 끝날 때 분명한 액션 아이템들과 소유자들이 있다.   
  5. 회의록을 작성하고 지체 없이 공유 한다.    

  

지나치다 싶을 정도로 커뮤니케이션하고, 기록하세요. 언제 이메일을 쓰거나 쓰지 않는게 좋을 지 잘 파악하세요. 다른 팀에게서 자주 받는 질문들은 답변들을 모아 스스로 답변을 찾아볼 수 있는 장소를 만들어 주세요.

엔지니어들에게 질문하세요 : "지금 하고 있는 일 중에 하지 않았으면 하는 일은 뭐가 있나요?" 버그 리포팅, 로그 상세 요구 기술, 데이터 뽑기, 다른 팀으로부터의 요청 처리 등, 엔지니어들이 하고 있는 일 중에 여러분이 할 수 있는 일을 찾아 덜어 주세요.

 

경험과 강점에 기댄다.

일을 막 시작했을때, 전 다른 사람들에게 제가 기술 백그라운드를 가지지 않았다는 것을 알리고 싶지 않아 제 마케팅 배경에 사람들이 주목하는 것을 피하려 했습니다. 바보같은 짓이었죠. 제가 가진 백그라운드가 제가 PM 이 된 이유 중 하나이기도 했을 테니까요. 이메일 캠페인을 진행하는 것이든, 빠른 설문을 하는 것이든, 사용자 인터뷰를 진행하는 것이든, 작은 성취들을 쌓아 나가 모멘텀을 형성하세요.

 

의사결정 과정에 활용될 수 있는 프레임워크를 제공한다.

이전의 슈퍼파워 비유를 기억하시나요? 이번 것은 데이터에 대해 아는 것만큼 중요합니다. 좋은 PM 은 그들이 참여하는 모든 대화를 명료하게 만들어 줍니다. 날카로운 질문을 던질 줄 알죠. 당신이 어떤 문제를 왜 풀고 있으며, 어떻게 그것을 측정할 것인지, 그리고 어떤 순서로 문제를 풀어갈 것인지 말해 줄 수 있습니다. 더 중요한 것은, 좋은 PM 이 만들어 공유한 "생각의 프레임워크" 를 통해 PM 이 자리에 없더라도 팀의 모든 사람들이 최선의 결정을 할 수 있게 만드는 것입니다.

 

팀에게 큰 맥락을 공유하는 시간을 가진다.

PM 으로서 여러분들은 종종 팀의 대표로 어떤 미팅에 참여한다거나, 이메일 참조를 혼자 받게 됩니다. 팀 외부와의 상호작용을 팀 내 모두에게 항상 공유하세요. 이렇게 공유하는 데에 즉각적인 장점은 없겠지만, 지속적인 공유를 통해 누적된 맥락에 대한 이해도는 팀원들끼리 논쟁거리가 될 만한 사안을 직접적으로 이야기하는 것을 쉽게 만들어 줍니다. 시간이 지남에 따라 팀원들은 여러분들에게 질문과 고민거리들을 안고 찾아오게 되겠죠.

 

 

Getting to “technical enough” as a product manager

 

“Why are you the product manager for search if you’re not technical?”

 

The question was posed with the blunt earnestness you come to expect of social interactions in the Valley. And it was a fair one, to the asker’s credit, though maybe not something I would have fired off within the first five minutes of meeting someone.

 

Conventional wisdom, and most job descriptions for product managers, say that candidates should have a “BA/BS in Computer Science or related technical field, or equivalent practical experience.” The latter usually means a side project you can point to and say “I built that.” There are notable exceptions to the rule, but being technical is still more of a must-have than a nice-to-have.

 

Recently, companies have started to reframe this requirement as “Product managers should be technical enough.” Note the language in these job descriptions (kinda fun to try to guess the company):

 


Though I’m a bit biased, I think this shift is generally a good thing, and will only accelerate as awareness of and demand for the role grows. Product management is as much art as it is science, psychology as it is statistics, big picture as it is the smallest of details. The day-to-day responsibilities, and technical bar, varies widely depending on the industry and size of the company, as well as the part of the product you work on. At the same time, the qualities that make someone a universally respected PM rarely have to do with technical expertise (“That’s a waste of a good engineer,” as some would say).

 

But the question remains?what does it mean exactly to be “technical enough”? How do you get there? And how do you build credibility with your team in the meantime?

 

When I transitioned from marketing to product management three months ago, I realized the internet had surprisingly little to offer on this subject. I want to share my experience trying to answer these questions while navigating the first 90 days as a PM at Pinterest, focused primarily on search. Hopefully it’s helpful to other product managers coming from a non-technical background, and kickstarts more conversation.

 

The rest of this post is broken out into two parts, reflecting my general onboarding approach:

 

  1. Establish a baseline of technical understanding and invest more over time.
  2. Build trust and credibility by figuring out how you can add immediate value.

 

Establish a baseline of technical understanding and invest more over time

First, what does it mean to be “technical enough” as a PM? There will be many opinions here, but I think of it as the ability to do the following, in order of difficulty:

  1. Trace a user issue (or set of issues) back to the underlying problem.
  2. Estimate how long it will take to build A vs. B.
  3. Anticipate implementation challenges with a particular proposal.
  4. Brainstorm potential solutions to technical problems.
  5. Identify opportunities that arise from new technologies.

The relative importance of these criteria will vary depending on your product?it might be more critical for a consumer app to stay on top of new technology, for instance, while B2B companies should be extra mindful of project scope to hit scheduled release dates?but it’s reasonable to expect a PM to be able to weigh in on all these issues.

 

With a better understanding of where we need to go, the next question becomes how do you get there? Some steps that I’ve found helpful, roughly in order of importance:

 

Start from a place of curiosity

This is the only must-do on the list. A genuine curiosity about technical problems will take you a long way; without it, things are a non-starter. It’s possible to cultivate this curiosity to a certain extent, but I’d try and get signal here during the interview process. Ellen Chisa has a great post on this topic if you’d like to read more.

 

Appreciate the creativity inherent in engineering

This point flows directly from the one before. You don’t have to poke far below the surface to realize that, at its core, engineering is about creating something from nothing, and comes with all the messiness that’s part of any subjective process. Behind every effort to bring a feature to life, there’s an engineer making dozens of judgment calls, weighing subtle tradeoffs, and thinking through implementation details and edge cases. Failing to understand this dynamic deprives engineers of the autonomy and ownership needed to do their best work.

 

Set aside time early on to pick an engineer’s brain

Read everything you can get your hands on in the first few days, keep a running list of questions, and then grab a whiteboard and time with an engineer to run through them. Get enough of a baseline understanding to ask intelligent questions, but don’t put off the last part for too long. There’s only so much you can absorb from staring at a screen, and the initial investment of a team member’s time will go a long way.

 

Synthesize what you’ve learned into a shareable format

At this point you’re probably swimming in a sea of acronyms and scribbled diagrams. Synthesize all this new information by writing it up in a doc. Share it with new hires as an onboarding resource. Even better, find an opportunity to present the information to another team, e.g., give a Search 101 presentation to partner managers. This is a great way to test your understanding and highlight areas where you need to dig in more.

 

Use feedback and bug reports to pattern match different issues

Returning to our definition of what it means to be “technical enough,” the first criteria is being able to trace a set of user issues back to the underlying problem. One way to do this is by pattern matching feedback and bug reports.

 

As a PM, you have the honor of being first responder for product feedback. On any given day you might field multiple reports about things that are confusing or broken. A coworker slacks you, “Including apostrophes in my search doesn’t return any suggestions.” Then your mom emails, “Tried searching for ‘williams-sonoma’. Can’t find it :(”

 

If you’re organized with your issue tracking, two things happen over time:

 

  1. You pick up on the vocabulary that engineers use to discuss certain bugs.
  2. You start to link issues together as symptoms of the same root problem.

So the reports from your coworker and mom would get rolled up under the parent issue: “Autocomplete normalization logic doesn’t handle punctuation.” Through this process you’ll also develop a sense for the relative magnitude and priority of different issues.

 

Familiarize yourself with bits of the code base

No need to go crazy here; the goal is to be able to answer simple questions like where and how we’ve defined a particular variable, without having to bother an engineer.

 

Focus on core concepts

Every field has a set of concepts that crop up again and again, e.g., recall vs. precision in search, cardinality in data modeling, etc. Identify what these are for computer science generally and your product area specifically, to help prioritize your learning.

 

Develop a thick skin

Cunningham’s Law states, “The best way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer.” In many ways this is the perfect metaphor for the role of a PM?it’s your job to come up with the initial spec or Google Drawings mock that everyone else then picks apart. The point isn’t that you proposed a crappy strawman (most first drafts are), but that this gets the conversation started.

 

Build credibility by figuring out how you can add immediate value

Learning any new skill takes time, but when it’s happening on the job, you don’t have the luxury of being a full-time student. You have to identify areas where you can make an immediate impact and start contributing, while you’re ramping up. Hopefully this isn’t too difficult, as part of the reason you were hired in the first place is because of the complementary skill set you bring to the table. Some things to consider:

 

Dig into the data

There’s this idea that each function has a superpower; some quality that, when wielded, makes other people jump to work with you. For designers, it might be the ability to quickly produce a range of high fidelity explorations. For engineers, maybe it’s the ability to hack together a prototype but also know when to invest in clean, extensible code.

 

For product managers, I think the closest equivalent is data fluency. Any time someone asks, “Do we know how many people use ABC feature?” and you can say, “Yeah, it’s roughly 123,” you build credibility. This is probably why product analyst positions have become one of the more common feeder roles into product management.

 

Practically speaking, being data fluent means knowing:

 

  • Which frontend and backend events are logged, and how
  • Where this data is stored
  • How to query the data
  • How to analyze experiment results
  • Experiment design best practices

Do the blocking and tackling work that keeps trains moving

Run efficient meetings. This usually means:

 

  • The purpose of the meeting is clear to everyone invited.
  • All necessary decision-makers are present.
  • You’ve set the right level of context at the beginning of the meeting.
  • There are clear action items and owners at the end of the meeting.
  • You take notes and share them promptly.

Err on the side of over-communicating and over-documenting. Know when email is the best communication channel and when it’s not. Keep track of common questions you get from other teams and centralize the answers in a self-serve resource.

 

Ask your engineers: What are you doing now that you’d rather not do? Anything you’re able to take off their plate?filing bugs, specifying logging requirements, pulling data, responding to requests from other teams?do.

 

Lean into your experiences and strengths

Early on, I tried to avoid drawing attention to my marketing background because I didn’t want to remind people that I wasn’t technical. In retrospect this was pretty silly, as my unique set of experiences was partly why I was hired. Whether it’s shipping an email campaign, running a quick survey, or setting up user interviews, build momentum by accumulating small wins.

 

Provide a shared framework for decision-making

Remember the superpower metaphor from before? This one’s a close second to knowing your data. Good PMs bring clarity to every conversation they’re involved in. They have a knack for asking incisive questions. They can tell you what problem we’re solving and why, how we measure success, and the order of operations to get from here to there. More importantly, everyone on their team can apply this shared framework to make the best call even when the PM isn’t there.

 

Take the time to give your team broader context

As a product manager, you’re often the only representative from your team sitting in on a certain meeting or cc’d on an email exchange. Keep everyone updated on these interactions with other parts of the company. There’s often no immediate benefit to doing so, but the cumulative context makes it easier to discuss controversial decisions down the road. Over time, your team will start to proactively come to you with questions and concerns.

 

---

I’d love to hear from you if you’ve made it this far, especially folks who’ve transitioned (or are thinking about transitioning) into product management from a non-technical role. As I noted at the beginning, there aren’t a lot of resources on this subject, and it’s hard to learn best practices beyond the narrow slice of your personal experience. Let’s change that!


  1. [번역] 빵조각 메뉴: 무엇, 언제, 어떻게

    Read More
  2. [번역] 고통없는 계정 UX에 대한 3가지 법칙 : 로그인

    #UI/UX 읽기
    Read More
  3. [번역] 이 이메일에 회신하지 마시오

    #UI/UX 읽기
    Read More
  4. Survivorship Bias (생존자 편향의 오류)

    #Mkt 읽기
    Read More
  5. Top 25 Free Mobile Friendly & Responsive HTML Email Templates 2017

    #Web 읽기
    Read More
  6. Mobile Application Frameworks (HTML, CSS & JavaScript)

    #UI/UX 읽기
    Read More
  7. 여러 도메인 추적하기(Cross Domain Tracking)

    #GA 읽기
    Read More
  8. Envato Market의 Standard 라이센스(Regular 라이선스 vs. Extended 라이선스)

    #Web 읽기
    Read More
  9. 코딩이 필요 없는 웹사이트 제작 툴 & 사이트 10선

    #Web 읽기
    Read More
  10. 기술에 대해 "충분히 아는" PM이 되는 길

    #Web 읽기
    Read More
  11. 주목해야할 5개의 엔터프라이즈 오픈 소스 위키

    #Web 읽기
    Read More
  12. 어플리케이션 생명주기 관리를 위한 무료 소프트웨어

    #Web 읽기
    Read More
  13. TOP5 오픈 소스 프로젝트 관리 도구

    #Web 읽기
    Read More
  14. [번역] 이메일 마케팅: 고객의 참여를 높이기 위한 7가지 이메일 디자인과 문구 비법

    #UI/UX 읽기
    Read More
  15. [번역] 면적 과잉 : 사이드바 내비게이션을 단순화하기

    #UI/UX 읽기
    Read More
  16. [번역] 상단 내비게이션 vs 왼쪽 내비게이션 : 어떤 것이 더 적합한가?

    #UI/UX 읽기
    Read More
  17. NRE (Non-recurring engineering)

    #Web 읽기
    Read More
  18. IT용어중 POC, Pilot, BMT의 업계에서 통용되는 의미에 대한 정리

    #Web 읽기
    Read More
  19. 프로젝트 라이프 사이클의 이해

    #Web 읽기
    Read More
  20. 모바일 터치 제스쳐 정의

    #UI/UX 읽기
    Read More
목록
Board Pagination Prev 1 2 3 4 Next
/ 4