마티 케이건

발언은 출처 원문에 있는 문장 그대로예요. 한국어는 저희가 옮겼고, 원문 보기를 누르면 영어 원문이 나와요.

• 프로세스보다 원칙

  “저희가 오랫동안 주장해 왔듯이, 강한 기업 뒤에 단 하나의 프로세스나 방법론이 있다고 믿지 않아요. 대신 저희는 원칙과 기술, 그리고 사고방식에 집중해요.”

  원문 보기원문 접기

  As we've long argued, we don't believe there is any single process or method behind strong companies. We instead focus on the principles, the techniques and the mindset.

  저희 풀이마티는 강한 제품 기업을 만들기 위한 SVPG 접근 방식의 핵심 철학을 설명해요.

• 고객 전문가의 필요성

  “제품 조직은 반드시 고객에 대한 전문가가 되어야 해요. 그렇지 않으면 제품을 정의하거나 디자인하는 일에서 성공할 가능성이 전혀 없거든요.”

  원문 보기원문 접기

  the product organization absolutely must become the expert on your customers, or you've got no real chance to do either of the first two (defining or designing

  저희 풀이왜 고객에 대한 깊은 이해가 제품 정의와 디자인의 전제 조건인지 설명해요.

• 요구사항 정의의 함정

  “저에게 있어 요구사항을 정의한다는 말은 잘못된 방향일 뿐만 아니라 오만하게 느껴졌어요.”

  원문 보기원문 접기

  To me, talking about defining requirements was not only misguided, but arrogant.

  저희 풀이마티는 제품 매니저가 요구 사항을 지시하는 전통적인 방식을 비판해요.

• 로드맵의 정의

  “로드맵은 사양서가 되어서는 안 되며, 기능들을 단순히 나열한 목록도 아니에요.”

  원문 보기원문 접기

  The roadmap is not intended to be a spec, and it¹s not a laundry list of features.

  저희 풀이제품 로드맵에 무엇이 포함되어야 하는지에 대한 흔한 오해를 바로잡아요.

• 적응형 조직 설계

  “핵심은 조직이 문제를 해결하기 위해 설계되었다는 점을 이해하는 거예요. 회사가 직면한 문제나 과제가 변하면 조직도 그에 맞춰 변해야 해요.”

  원문 보기원문 접기

  The key is to understand that organizations are designed to solve problems. As the problems or challenges the company faces change, the organization needs to change accordingly.

  저희 풀이그는 조직 구조가 회사의 과제에 맞춰 진화해야 한다고 강조해요.

• 지능의 핵심

  “저는 확률을 지능의 대안이 아니라 지능의 핵심으로 보고 있어요.”

  원문 보기원문 접기

  I view probability as central to intelligence, not an alternative.

  저희 풀이확률 모델이 규칙 기반 모델보다 타당성이 떨어진다는 주장에 반박해요.

• 요구사항 수집 그 이상

  “제가 제품 팀과 협업을 시작할 때 가장 먼저 하는 일 중 하나는, 그들이 자신의 업무를 요구사항을 수집하고 문서화하는 것이라고 생각하지 않도록 만드는 거예요.”

  원문 보기원문 접기

  When I start working with product teams, one of the first things I try to do is to get them to stop thinking of their job as one of gathering and documenting requirements.

  저희 풀이케이건은 제품 관리자가 왜 전통적인 요구사항 수집 사고방식에서 벗어나야 하는지 설명해요.

• 목적이 된 프로세스

  “프로세스를 따르는 것 자체가 목적이 되어버리는 경우가 있어요.”

  원문 보기원문 접기

  Following the process becomes an end in itself.

  저희 풀이그는 팀이 실제 결과보다 규칙을 우선시할 때 발생하는 실패 양상을 묘사해요.

• 신규 인재 온보딩

  “저는 그들에게 회사가 그들의 지성과 재능에 관심이 있는 것이지, 이전 회사의 나쁜 관행을 가져오길 원하는 게 아니라는 점을 강조해요.”

  원문 보기원문 접기

  I'll emphasize to them that the new company is interested in them because of their mind and their talents, and of course they wouldn't want to bring with them the bad practices

  저희 풀이신규 입사자가 이전 대기업에서의 나쁜 습관을 가져오지 않도록 방지하는 방법이에요.

• 조직 문화의 변화

  “기능 팀, 로드맵, 수동적인 관리자로 구성된 기존 조직에 완전히 다른 문화의 기법을 덧씌우고 그것이 작동하기를 기대할 수는 없어요.”

  원문 보기원문 접기

  You can't take your old organization based on feature teams, roadmaps and passive managers, then overlay a technique from a radically different culture, and expect that will work

  저희 풀이기본적인 구조를 바꾸지 않고 단순히 OKR을 도입하는 것이 왜 실패하는지 설명해요.

• 핵심 역량으로서의 기술

  “보잉의 근본적인 실수는 기술을 가장 안전하고 연료 효율적이며 비용 효율적인 비행기를 제공할 수 있게 해주는 핵심 역량이 아니라, 그저 필요한 비용으로만 간주했다는 점이에요.”

  원문 보기원문 접기

  Boeing's fundamental mistake was to consider this technology as just a necessary cost, rather than the core competency that enables them to provide the safest, most fuel-efficient, and most cost-effective airplanes available.

  저희 풀이케이건은 보잉이 737 MAX 소프트웨어에서 실패한 이유를 설명해요.

• 고충실도 프로토타입

  “제 생각에 이러한 요구사항을 충족할 수 있는 사양서 형태는 단 하나뿐이에요. 바로 고충실도 프로토타입이죠.”

  원문 보기원문 접기

  In my mind, there's only one form of spec that can deliver on these requirements, and that is the high-fidelity prototype.

  저희 풀이그는 현실적인 프로토타입이 제품을 정의하는 가장 좋은 방법이라고 주장해요.

• 업무의 본질

  “직함은 중요하지 않아요. 그들이 하는 일이 중요해요.”

  원문 보기원문 접기

  The title is not important; the work they do is.

  저희 풀이마티나는 제품 관리자가 CEO나 공동 창업자와 같은 다양한 직함을 가질 수 있다는 점을 이야기했어요.

• 자연스러운 지식 공유

  “스타트업에서 배운 것을 공유하는 일은 보통 자연스럽게 일어나요. 제품 팀과 회사 전체가 거의 하나나 다름없기 때문이에요.”

  원문 보기원문 접기

  Sharing what we learn in a startup typically happens naturally because the product team and the company are pretty much the same thing.

  저희 풀이케이건은 기업의 초기 단계에서 소통이 왜 더 쉬운지 설명해요.

• 수익을 위한 구축

  “제품 인도 단계에서 우리는 수익을 내기 위해 만듭니다. 판매, 서비스, 지원이 가능하고 고객이 비즈니스를 운영할 수 있는 상용 수준의 제품을 만드는 거예요.”

  원문 보기원문 접기

  In product delivery we are building to earn . We are building a commercial quality product that we can sell, service and support, and that our customers can run their business on.

  저희 풀이제품 모델에서 인도 단계의 목적을 정의해요.

• 제품 감각 기르기

  “어려운 부분은 학습 내용을 평가하고 방향을 안내하는 데 필요한 제품 감각을 기르는 거예요.”

  원문 보기원문 접기

  The hard part is building the product sense necessary to evaluate the learnings and guide the direction.

  저희 풀이현대 시대에 제품 관리자가 마스터하기 가장 어려운 기술이에요.

• 선언문의 정의

  “선언문은 원칙, 신념, 의도를 공개적으로 밝히는 거예요. 잘 만들어진 선언문은 제품의 비전과 전략을 보완하는 간결한 도구가 될 수 있어서 좋아해요.”

  원문 보기원문 접기

  A Manifesto is a public declaration of principles, beliefs and intentions. I like them because if they're done well, they can serve as a concise complement to the product vision and strategy.

  저희 풀이케이건은 제품 팀을 위한 전략적 도구로서 선언문을 가치 있게 여기는 이유를 설명해요.

• 팀 생산성 요소

  “핵심은 모든 것이 팀에 달려 있다는 점을 깨닫는 거예요. 많은 관리자가 이를 잘 이해하지 못하며, 생산성 차이가 20배까지 날 수 있다는 사실에 놀라곤 해요.”

  원문 보기원문 접기

  The key is to realize that it's all about the team. Many managers don't quite get this, and they are stunned to learn that there can be as much as a 20X factor in productivity

  저희 풀이케이건은 평균적인 인재와 최상위 인재 사이의 거대한 성과 차이를 강조해요.

• 비용 대비 가치

  “이러한 생산성 요소는 겉으로 보이는 비용 절감 효과를 쉽게 압도할 수 있어요. 마찬가지로, 물가가 비싼 스톡홀름에 사는 일류 엔지니어도 가성비 좋은 인재로 만들 수 있죠.”

  원문 보기원문 접기

  This productivity factor can easily dwarf perceived financial savings. Similarly, it can turn a top engineer living in very expensive Stockholm into a bargain.

  저희 풀이높은 생산성은 비싼 인재를 저렴하고 숙련도가 낮은 대안보다 더 비용 효율적으로 만들어요.

• 낭비 방지

  “제품 관리자가 고객이 원하거나 필요로 하는 솔루션인지 확신하지 못한 상태에서 이 모든 작업을 진행하는 것은 엄청난 낭비의 지름길이에요.”

  원문 보기원문 접기

  Doing all this work when the product manager isn't even sure this is the solution the customer wants or needs is a recipe for big waste.

  저희 풀이잘못된 문제를 해결하기 위해 고품질의 소프트웨어를 만드는 위험성에 대해 이야기해요.

• 확장 가능한 솔루션

  “우리는 일련의 특수 제작품이 아니라, 많은 고객에게 통용되는 단일 솔루션을 만들어내야 해요.”

  원문 보기원문 접기

  we need to make sure we come up with a single solution that works for many customers, and not a series of specials.

  저희 풀이개인이 아닌 시장에 기여하는 제품을 만드는 것의 어려움이에요.

• 유연한 코칭 방법

  “훌륭한 제품 코치는 다양한 방법과 도구, 기술을 알고 있으며, 특정 상황에 가장 적합하다고 믿는 것을 추천해요.”

  원문 보기원문 접기

  Good product coaches know many different methods, tools and techniques, and they recommend what they believe is best suited to the particular situation.

  저희 풀이마티는 훌륭한 코치가 모든 문제에 하나의 프레임워크를 강요하는 것을 피한다고 설명해요.

• 평화 시의 전쟁 준비

  “전쟁을 준비해야 할 시기는, 아직 준비되지 않았다면 바로 평화로운 때예요.”

  원문 보기원문 접기

  The time to prepare for war, if you're not already, is when you are at peace.

  저희 풀이케이건은 기업들이 혁신 역량을 쌓기 위해 위기가 닥칠 때까지 기다리지 말라고 경고해요.

• 해결책 발견하기

  “제가 제품 팀들에게 설명하려고 노력하는 점은, 그들의 목적이 단순히 들어오는 요청을 검증하는 문지기 역할이 아니라는 거예요. 그들의 진짜 목적은 실제로 작동하는 해결책을 발견하는 것이에요.”

  원문 보기원문 접기

  What I try to explain to the product teams is that their purpose is not to serve as gatekeeper and just validate the requests that come in; their purpose is to discover solutions that work .

  저희 풀이케이건은 제품 팀이 이해관계자들에게 단순히 안 된다고 말하기보다 해답을 찾는 데 집중해야 한다고 설명해요.

• 조직 개편의 함정

  “조직 개편이 회사의 문제를 해결해 줄 거라 생각하기 쉽지만, 대부분의 경우 그건 그저 타이타닉호의 갑판 의자를 재배치하는 것일 뿐이에요.”

  원문 보기원문 접기

  it's tempting to think that a reorganization will fix their company's issues, but in most cases, it's simply rearranging the deck chairs on the Titanic.

  저희 풀이그는 보고 체계를 바꾸는 것만으로는 뿌리 깊은 문화나 기술 문제를 해결하기 어렵다고 리더들에게 경고해요.

• 엔지니어 권한 부여의 정의

  “엔지니어의 권한 부여란 해결해야 할 문제와 전략적 맥락을 제공하고, 그들이 기술을 활용해 문제에 대한 최선의 해결책을 스스로 찾아낼 수 있도록 하는 것을 의미해요.”

  원문 보기원문 접기

  Empowerment of an engineer means that you provide the engineers with the problem to solve , and the strategic context , and they are able to leverage technology to figure out the best solution to the problem .

  저희 풀이그는 권한 부여가 단순히 코딩 방식을 선택하는 것이 아니라 문제를 해결하는 것에 관한 것임을 명확히 해요.

• 혁신의 원천

  “사실 고객은 진정한 가치 창출과 혁신의 원천이 되는 경우가 거의 없어요.”

  원문 보기원문 접기

  The truth is that customers are consistently not the source of true value creation and innovation.

  저희 풀이고객의 말만 듣는 것이 왜 파괴적인 제품으로 이어지기 어려운지 설명해요.

• 고객의 한계

  “고객은 무엇이 가능한지 모르고, 직접 보기 전까지는 자신이 무엇을 원하는지도 몰라요.”

  원문 보기원문 접기

  customers don't know what's possible; and b) customers don't know what they want until after they see it.

  저희 풀이기술 제품에 왜 단순한 고객 피드백 이상의 것이 필요한지 설명해요.

• 제품 리더의 역량

  “제품 리더가 각 분야의 사내 전문가가 될 필요는 없지만, 각 분석 도구를 사용할 수 있는 역량을 갖추고 권한을 가지고 있어야 해요.”

  원문 보기원문 접기

  The product leader does not have to be the company expert in each of these areas, however, he should be capable (trained and granted access) to use each of these.

  저희 풀이케이건은 데이터 도구와 관련하여 제품 관리자에게 기대되는 기술적 수준을 논의해요.

• 제품 경제학의 이해

  “제 경험상 대부분의 제품 관리자들, 특히 기술 배경을 가진 제품 관리자들은 자신의 제품이나 회사가 어떻게 돈을 버는지에 대해 아주 얕은 이해만 가지고 있어요.”

  원문 보기원문 접기

  In my experience, most product managers, especially technical product managers, have only a very shallow understanding of how their product (or their company) makes money.

  저희 풀이케이건은 많은 제품 관리자들이 자신의 제품에 대한 깊은 재무 지식이 부족하다고 관찰해요.