마티 케이건

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

• 조기 채용의 위험성

  “흔한 문제 중 하나는 창업자가 너무 일찍 프로덕트 리더를 영입하는 것인데, 그 사람은 창업자만큼의 제품이나 고객 지식이 없어요.”

  원문 보기원문 접기

  one of the common problems is when a founder brings in a product leader prematurely , and that person simply does not have the product or customer knowledge that the founder has

  저희 풀이마티는 창업자가 확장할 준비가 되기 전에 외부 제품 리더를 고용하는 것에 대해 경고해요.

• 반복의 속도

  “제품이 실제로 작동하는 지점에 도달하려면 여러 번의 반복이 필요하다는 걸 알고 있어요. 그래서 그 반복 과정을 최대한 빨리 거치고 싶은 거죠.”

  원문 보기원문 접기

  We know we'll need several iterations to get to where the product actually works for us, so we want to work through those iterations as fast as we can.

  저희 풀이새로운 제품 아이디어를 테스트할 때 속도가 왜 필수적인지 설명해요.

• 전략과 지표

  “비즈니스 전략과 포트폴리오 계획은 예산과 일련의 비즈니스 지표를 제공해요.”

  원문 보기원문 접기

  The business strategy and business portfolio planning provides a budget and a set of business metrics.

  저희 풀이마티는 고수준 비즈니스 전략의 결과물을 설명해요.

• 리더십의 기준

  “제품 리더는 자신이 보유한 가장 역량이 부족한 제품 매니저에 의해 평가받는다는 사실을 꼭 기억하세요.”

  원문 보기원문 접기

  Please remember that the product leader will be judged by her weakest product manager.

  저희 풀이제품 관리 팀 전체에 걸쳐 높은 수준의 표준을 유지하는 것의 중요성이에요.

• 파일럿 팀의 이점

  “파일럿 팀은 기본적으로 리스크 완화 기법이에요. 회사가 제품 모델로 운영되는 권한 위임 팀으로 전환하는 것이 무엇을 의미하는지 안전하고 빠르고 저렴하게 배울 수 있게 해 주죠.”

  원문 보기원문 접기

  Pilot teams are primarily a risk mitigation technique. It lets the company learn safely, quickly, and inexpensively just what it means to move to empowered product teams operating in the product model.

  저희 풀이새로운 작업 모델을 테스트하기 위해 소규모 파일럿 팀을 활용하는 것의 전략적 가치를 설명해요.

• 제품에 대한 겸손

  “태도: 과거에는 자신의 아이디어가 훌륭하다고 믿었지만, 현재는 아이디어의 최소 절반은 실패할 것임을 알고 있어요.”

  원문 보기원문 접기

  Attitude: Old: Believes His Ideas Are Great New: Knows At Least Half of Ideas Won't Work

  저희 풀이마티는 과거의 자아 중심적 접근 방식과 현대 제품 관리의 데이터 기반 겸손함을 대조해요.

• 제품 관리자 권한 부여

  “진정한 제품 관리자를 식별하고, 그들이 높은 수준의 전략부터 세부 사항까지 제품 정의를 완전히 소유할 수 있도록 권한을 부여하세요. 명확한 소유권과 책임이 중요해요.”

  원문 보기원문 접기

  Identify the true product managers, and empower them to own product definition completely, from the high-level to the details. Clear ownership and clear accountability.

  저희 풀이케이건은 PM과 BA 사이의 역할 혼란을 해결하는 방법에 대해 조직에 조언해요.

• 자율성의 이점

  “팀이 스스로의 운명을 통제하고 있다고 느낄 때 생기는 동기 부여 수준의 향상과 진정한 주인의식이 대부분의 이점을 만들어낸다고 생각해요.”

  원문 보기원문 접기

  I attribute most of the benefits to the increased level of motivation, and true sense of ownership, when teams feel more in control of their own destiny.

  저희 풀이마티는 권한이 부여된 제품 팀이 왜 과거의 모델보다 더 나은 성과를 내는지 설명해요.

• 조력자로서의 기술

  “가장 심각하고 뿌리 깊은 문제 중 하나는 기술을 비즈니스의 핵심 동력이 아니라 비용 센터로 생각하는 것이에요.”

  원문 보기원문 접기

  One of the most serious and deeply rooted problems is thinking of technology as a cost center , rather than the core enabler of the business.

  저희 풀이케이건은 엔지니어링과 디자인을 관리 대상인 하위 자원으로 취급하는 사고방식을 비판해요.

• 엔지니어링 조기 참여

  “제품 관리자들이 저지르는 가장 흔한 실수 중 하나는 엔지니어링 팀을 충분히 일찍 참여시키지 않아 변화를 만들 기회를 놓치는 것이에요.”

  원문 보기원문 접기

  One of the most common mistakes that product managers make is to not include engineering early enough to make a difference.

  저희 풀이케이건은 제품 발견 단계에서 빈번하게 발생하는 실패를 설명해요.

• 산출물 대 결과물

  “요즘 결과물(outcomes)에 집중하라는 이야기가 많지만, 여기 산출물(output)과 결과물(outcomes)의 차이를 아주 명확하게 볼 수 있는 기회가 있어요.”

  원문 보기원문 접기

  There's a lot of talk today about focusing on outcomes, but here's a chance for people to see quite clearly the difference between output and outcomes.

  저희 풀이마티는 비즈니스 성공과 단순한 프로세스 실행의 차이를 설명해요.

• 대상 고객

  “엔지니어 팀과 함께 새로운 것을 만들고 있는 게 아니라면, 이 모델은 당신을 위한 게 아니에요.”

  원문 보기원문 접기

  If you're not working with a team of engineers to build something new, it's not for you.

  저희 풀이제품 모델을 사용하기 위한 근본적인 요구 사항은 능동적인 엔지니어링과 창조예요.

• 프로토타입의 목적

  “사용자 프로토타입은 통계적으로 유의미한 결과를 얻기 위한 것이 아니라, 큰 통찰력과 빠른 학습을 위한 것이에요.”

  원문 보기원문 접기

  A user prototype is not about statistically significant results; it's about big insights and rapid learning.

  저희 풀이정성적인 프로토타입은 데이터 검증이 아니라 통찰력을 얻기 위한 것임을 명확히 해요.

• 규모에 따른 자율성

  “아주 작은 스타트업을 제외한 대부분의 기업에서 제품 팀은 임파워먼트는 되어 있을지 몰라도 완전한 자율성을 갖지는 못해요.”

  원문 보기원문 접기

  In most companies beyond very small startups, a product team may have empowerment, but they don't have full autonomy.

  저희 풀이마티 케이건은 기업이 성장함에 따라 의존성이 종종 자율성을 방해한다는 점을 언급해요.

• 애자일 역할의 혼란

  “애자일은 수십 년 동안 소프트웨어 팀을 괴롭혀온 몇 가지 핵심 문제들을 실제로 해결해 줘요. 하지만 많은 제품 관리자와 디자이너, 그리고 어느 정도는 QA 담당자들까지도 처음에는 애자일에 혼란을 느끼고 이 방식에서 자신의 역할이 무엇인지 확신하지 못하곤 해요.”

  원문 보기원문 접기

  Agile really does attack some key problems that have plagued software teams for decades. But many product managers and designers, and to a lesser extent QA staff, are initially confused by Agile, unsure of their role in these methods.

  저희 풀이마티 케이건은 애자일 방식을 처음 도입할 때 왜 제품 관련 역할들이 어색하게 느껴지는지 설명해요.

• 주문 제작 소프트웨어의 난제

  “특정 고객을 위한 특수 목적 소프트웨어를 만드는 주문 제작 소프트웨어 세계는 오랫동안 잔혹할 정도로 어려운 분야였어요. 이는 부분적으로 고객이 자신이 무엇을 원하는지 잘 모른다는 점 때문이에요.”

  원문 보기원문 접기

  The custom software world - building special purpose software for specific customers - has long been a brutally difficult type of software. This is partly because customers notoriously don't know what they want

  저희 풀이단 한 명의 특정 고객만을 위해 소프트웨어를 개발하는 것의 본질적인 어려움을 논의해요.

• 빈번한 출시 주기

  “지속적 배포를 하고 있지 않다면, 최소한 2주에 한 번은 실제 출시를 진행해야 해요.”

  원문 보기원문 접기

  If you're not doing continuous delivery, then at the very least you should be doing true releases no less than every two weeks.

  저희 풀이그는 분기별 대규모 출시 방식에서 벗어나는 것의 중요성을 강조해요.

• 협력적인 이해관계자 관계

  “제품 팀은 종속적인 관계에서 벗어나, 고객이 사랑하면서도 비즈니스에 도움이 되는 해결책을 찾아내는 협력적 관계로 이동해요.”

  원문 보기원문 접기

  the product team moves from a subservient relationship, to a collaborative relationship where the product team must discover a solution that the customers love yet works for the business.

  저희 풀이케이건은 제품 팀이 회사 리더십과 상호작용하는 방식에서 필요한 변화를 설명해요.

• CEO가 제품에 미치는 영향

  “조직 구성원들은 CEO가 무엇을 중요하게 여기는지 주의 깊게 살펴봐요. 그래서 고객에게 훌륭한 제품을 제공하고 싶다면, CEO가 제품에 대해 정말 많이 신경 써야만 해요.”

  원문 보기원문 접기

  people in an organization pay attention to what the CEO thinks is important. So if you want to deliver great products to your customers, the CEO has to care...a lot.

  저희 풀이케이건과 대니 셰이더는 왜 제품에 대한 CEO의 개인적인 열정이 회사의 근간이 되는지 논의해요.

• 실패의 재정의

  “우리는 실패라는 개념을 되찾아 부적절하게 생략된 절차, 잘못된 결정, 그리고 예방 가능한 실수들을 지칭하는 데 다시 사용해야 해요.”

  원문 보기원문 접기

  We need to reclaim the concept of failure and redeploy it to cover our inappropriately cut corners, bad decisions, and preventable mistakes.

  저희 풀이저자는 실패가 실험 결과가 아니라 예방 가능한 실수를 의미해야 한다고 주장해요.

• 실험과 태만의 차이

  “사용자 테스트에서 반응이 없는 프로토타입은 실패가 아니지만, 예측 가능한 보안 결함이 있는 제품을 출시하는 것은 실패예요.”

  원문 보기원문 접기

  A prototype that falls flat in user testing is not failure, but releasing a product with a foreseeable security flaw is.

  저희 풀이테스트를 통한 학습과 부실한 실행으로 인한 실패를 구분해요.

• 일과 삶의 통합

  “핵심은 일과 개인의 삶이 그렇게 분리될 필요가 없으며, 사실 분리되어서도 안 된다는 것이에요.”

  원문 보기원문 접기

  The key is that work and personal life don't actually need to be so separate, and in fact shouldn't be.

  저희 풀이마티는 전문적인 영역과 개인적인 영역을 조화시키는 것에 대한 브루스 윌리엄스의 철학을 설명해요.

• 사용성보다 중요한 욕구

  “가장 어려운 질문은 사용자가 제품 사용법을 알아낼 수 있느냐가 아니라, 그들이 제품을 정말로 사용하고 싶어 하느냐예요.”

  원문 보기원문 접기

  But the most difficult question is not really whether or not the user can figure out how to use the product, it is whether they even want to use the product.

  저희 풀이케이건은 가치를 창출하는 것이 제품을 사용하기 쉽게 만드는 것보다 더 어렵다고 설명해요.

• 행동을 만드는 가치

  “진실은 보상이 충분히 크다면 사용자는 그 보상을 얻기 위해 온갖 장애물을 기꺼이 뛰어넘을 것이라는 점이에요.”

  원문 보기원문 접기

  The truth is, if the carrot is big enough, users will jump though all kinds of hoops to get to the prize.

  저희 풀이그는 성공적인 제품에서 높은 가치가 부족한 사용성을 극복할 수 있다고 언급해요.

• 실패의 리스크

  “리스크 분류 체계를 사용하지 않는 것과 제품 개발의 실패 사이에는 직접적인 연관이 있어요. 특히 실패한 MVP들이 그렇죠.”

  원문 보기원문 접기

  And there's a straight line between not using one of the risk taxonomies, and failed product efforts. Especially failed MVPs.

  저희 풀이마티는 왜 리스크 분류 체계를 사용하는 것이 제품의 성공에 필수적인지 설명해요.

• 리더십의 책임

  “권한이 부여된 제품 조직에서 제품 리더의 책임에는 코칭, 인력 배치, 제품 비전, 팀 구조, 제품 전략, 팀 목표 설정, 그리고 경영진과의 협업이 포함돼요.”

  원문 보기원문 접기

  In an empowered product organization, product leadership responsibilities include coaching and staffing, product vision, team topology, product strategy, team objectives, and working with the extended executive team

  저희 풀이저자는 현대 기술 조직에서 제품 리더의 핵심 직무를 나열해요.

• GPM 역할의 정의

  “GPM은 하이브리드 역할이에요. 일부는 개별 기여자이고, 일부는 첫 번째 단계의 피플 매니저예요.”

  원문 보기원문 접기

  The GPM is a hybrid role. Part individual contributor, and part first level people manager.

  저희 풀이케이건은 그룹 프로덕트 매니저 역할을 실무와 관리의 혼합으로 정의해요.

• 팀 간 결합 촉진

  “GPM 모델은 밀접하게 연결된 제품 팀들 간의 협업을 용이하게 하도록 설계되었어요.”

  원문 보기원문 접기

  the GPM model is designed to facilitate tightly coupled product teams.

  저희 풀이관련된 제품 영역을 관리하기 위해 GPM을 활용할 때의 구조적 이점을 다뤄요.

• 권한이 부여된 제품 팀

  “궁극적으로 권한을 부여받은 제품 팀이란 팀에게 해결하기 어려운 문제를 맡기고, 그 문제를 해결할 수 있는 공간을 제공하는 것이에요.”

  원문 보기원문 접기

  Ultimately, empowered product teams are all about giving teams hard problems to solve, and then giving them the space to solve them.

  저희 풀이케이건은 조직 내에서 제품 팀에 권한을 부여하는 핵심 목적을 정의해요.

• 전략 대 전술

  “전략은 세부 사항을 다루지 않아요. 세부 사항은 목표를 달성하기 위해 사용하는 전술일 뿐이에요. 전략은 전반적인 접근 방식이며 그 방식에 대한 근거예요.”

  원문 보기원문 접기

  Strategy doesn't cover the details; those are the tactics we'll use to achieve the goal. Strategy is the overall approach, and the rationale for that approach.

  저희 풀이케이건은 높은 수준의 전략과 실행의 전술적 세부 사항 사이의 차이점을 명확히 해요.