인스파이어드

p66  제품 디자이너

요즘 제품 디자이너들은 제품 발견부터 제품 실행까지의 전 과정에서 제품 관리자 및 엔지니어와 계속 협업을 해나간다. 마찬가지로 예전에는 디자이너 동료들끼리 함께 근무했다면, 요즘의 제품 디자이너는 제품 관리자의 옆에 앉아서 제품 발견 단계의 파트너로서 업무를 수행한다.

제품 디자이너는 디자인 작업의 산출물을 가지고 평가받지 않고, 제품의 성공 여부로 평가 받는다. 이러한 이유로 제품 디자이너도 제품 관리자와 비슷한 고민을 한다.

p73 제품 팀에 전담 디자이너가 있는 경우 다음의 다섯 가지 가이드를 따르면 디자이너와 성공적이고 건강한 관계를 만들어나갈 수 있을 것이다.

1. 무슨 수를 써서라도 디자이너가 당신(PM) 옆에 앉아서 일하도록 하라.

2. 아이디어 초기 단계부터 디자이너를 개입시켜라.

3. 가능한 한 많은 기회를 통해 사용자 및 고객과의 상호작용에 대해 경험하게 하라. 사용자와 고객에 대해 함께 학습하라.

4. 디자인 아이디어가 있더라고 웬만하면 참고 디자이너에게 이야기하지 마라. 스스로 디자인 문제를 해결할 수 있는 충분한 여유와 기회를 제공하라.

5. 디자이너가 이른 시점부터 가능한 한 자주 이터레이션에 참여할 수 있도록 하라. 초기 이터레이션부터 디자인 세부적인 사항에 대한 사소한 트집을 늘어놓지 않는 것이 최선이다. 디자이너가 단순히 일상적인 디자인 접근 방법에서 벗어나서 문제에 대해 창의적인 해결 방법을 마음 놓고 탐색해 볼 수 있도록 지원하라.

제품 관리자와 디자이너는 진정한 파트너라는 것이 요점이다. 둘은 함께 제품을 발견하고, 적절한 솔루션을 찾으면서 각자 다른 핵심 역량을 팀에 채워 준다.

p115 큰 기업에서는 일반적으로 다른 팀에 공통 서비스를 제공하는 한 개 이상의 팀이 존재한다. 이런 팀은 보통 공통 서비스(common service)팀, 핵심 서비스(core service)팀, 또는 플랫폼(platform)팀이라고 불리며, 주로 아키텍처의 특성이 반영된다.

매우 높은 수준으로 서비스가 활용되는 이유로, 많은 회사에서 확장 단계에 이러한 팀을 갖추게 된다. 하지만 적합한 사람을 갖추기 어려운 팀이기도 하다. 다른 팀의 업무를 가능하게 하므로 모튼 팀이 의존하는 팀이기 때문이다.

이러한 공통 서비스팀에는 유능하면서도 기술적인 이해가 뛰어난 제품 관리자(platform product manager)가 있어야 한다.

p118 팀의 역량 수준

대략 세 단계의 팀 역량 수준이 있다.

1. A팀 : 올바른 의사결정이 필요한 임무를 맡을 수 있는 경험이 풍부한 팀

2. B팀 : 좋은 의도를 가지고는 있지만, 훌륭한 의사결정을 하는 데 필요한 경험의 수준을 아직 갖추지 못해서 일정 수준의 도움이 필요한 사람들

3. C팀 : 심지어 그들이 무엇을 모르는지도 잘 모르는 주니어팀. 이 팀은 상당 수준의 코치가 없으면 의도치 않게 엄청난 이슈들을 만들어 낼 수 있다.

p119 속도의 중요성

팀은 동료와 함께 협업하며 제품을 만들 수 있어야 하고, 이미 있는 것을 만드는 데 시간을 쓰면 안 된다는 것이 기본적인 원리이다. 하지만 때로는 자율성이라는 이름으로 팀의 잠재적인 중복 작업이 발생하거나 느려지는 상황이 발생하기도 한다. 이는 단순한 용인된 권한 부여의 비용을 발생시킨다.

p141 높은 신뢰 수준의 약속

아이디어가 유효하다고 하더라도 성공적인 성과라고 할만큼 충분히 의미 있는 수준이 되려면 보통 몇 변의 이터레이션이 더 있어야 한다.

약속에 대한 모든 근심의 근본적인 원인은 약속이 발생하는 '시점'이라는 점을 이해하는 것이 핵심이다. (...)

절충점은 꽤 분명하다. 제품팀은 약속이 발생하기 전에 제품 발견을 위한 일부 시간을 요청한다. 그리고 제품 발견 단계 후에는 이해 관계자들이 효과적으로 그들의 업무를 준비하고 진행할 수 있게 일정과 결과물에 대해 기꺼이 약속한다.

p243 맥락질문법(contextual inquiry)

p254 프로토타이핑 기법

• 실현 가능성 프로토타입

  • 엔지니어가 제작. 제품 발견 기간 동안 기술적인 실현 가능성의 위험에 대응하기 위함

  • 가끔 새로운 기술을 실험 (새로운 알고리즘 등)

  • 성능을 평가

  • 실현 가능성의 위험을 파악할 수 있도록 개발자에게 충분히 코드를 작성하게 해보는 것이 기본

• 사용자 프로토타입

  • 모의실험

  • 와이어프레임처럼 보이는 형태(lo-fi)부터 실제 제품과 비슷하게 보이고 느껴져서 단지 모의실험이라고 하기 어려울 정도의 형태(hi-fi)를 가진 범위까지 존재

• 라이브 데이터 프로토타입

  • 실제 데이터 소스에 접근할 수 있는 프로토타입이 필요할 때

  • 일부 유용한 정보를 얻기 위해 충분한 양의 실제 트래픽을 프로토타입으로 전송할 수 있어야 함

  • 실제 데이터를 수집하여 우리가 무언가를 증명할 수 있게 하거나 최소한 일부 증거라도 수집하기 위함

  • 기능, 디자인, 업무 프로세스와 같은 아이디어가 실제로 유효한 것이 맞는지 알아채기 위함

• 혼합 프로토타입

  • 서로 다른 프로토타입 유형의 부분을 조합한, 다양한 혼합 형태들 또한 존재

  제품 발견은 가장 빠르고 적은 비용으로 우리의 아이디어를 테스트하는 것임을 다시금 명심하라. 그래서 특정 아이디어나 상황에 따라 당신의 필요에 가장 부합하는 프로토타입을 선택하고 싶어할 것이다.

p258 어떤 형태의 프로토타입이건 가장 중요한 목적은 실제 제품을 만드는 것보다 시간과 노력의 측면에서 훨씬 더 적은 비용으로 학습하는 것이다. 모든 형태의 프로토타입은 최소한 최종 제품보다는 작은 규모의 시간과 노력을 해야 한다.

p259 의도한 목적에 맞는 올바른 수준의 충실도를 만드는 것이 원칙이다. 그리고 낮은 충실도는 높은 충실도보다 빠르고 저렴하다는 것을 알고 있다. 그래서 높은 충실도의 프로토타입은 꼭 필요한 경우만 진행해야 한다.

프로토타입의 주요한 목적은 제품 발견 단계에서 하나 혹은 그 이상의 제품 위험(가치, 사용성, 실현 가능성, 유효성)을 해결하기 위해서다. 또 다른 효익은, 엔지니어와 그 외 조직 전체에 무엇이 만들어져야 하는지 효과적으로 커뮤니케이션할 수 있다는 것이다. 이는 흔히 **기능 명세만큼의 프로토타입(as prototype as spec)**으로 언급된다.

p349 안티 패턴(anti pattern, 자주 사용되지만 지양해야할 행동)

처음부터 리더에 대한 기대사항을 명확히 하지 않으면 문제가 발생한다. (다른 큰 기업에서 온)

이들이 일하는 방법에 대한 시각을 그대로 들고 온다. 더 심각한 문제는 그들이 보통 이전에 했던 업무 방식을 따르는 사람을 채용하는 것이다. 나는 이러한 안티 패턴이 엔지니어부터 CEO까지 회사의 모든 레벨에서 발생하는 것을 보았다.

방어법

• 매우 강력하고 목적의식이 강한 제품 문화를 만들고 확실히 자리 잡도록 하는 것

• 면접 과정이나 입사 과정에서 명확히 밝힐 것

p359 좋은 팀은 그들의 엔지니어가 매일 제품 발견을 위한 프로토타입을 만들어 볼 수 있는 시간이 있는지 확인한다. 그래서 더 나은 제품을 만드는 방법에 대한 그들의 생각을 실행해 볼 수 있다. 나쁜 팀은 스프린트 미팅에서 엔지니어에게 프로토타입을 보여 주고 추정을 하려고 한다.