서비스 기획 특강

- ui 전에 서비스에 대한 본질을 생각하기

- 기획은 화면을 구성하는 것이 아니라 가치에 대한 고민을 하는 것

- mece하다

파괴적 혁신

파괴적 혁신을 추구하는 기업은 특정한 고객군을 타깃으로 해서 그들의 니즈를 정확히 충족해서 발전해 나가겠다는 이상향을 가진다.

Jobs-to-be-done (할 일 이론)

• 사용자는 자신만의 특정한 목적을 위해서 이 문제를 잘 해결할 수 있는 서비스를 '고용'한다.
• 사용자는 앱을 해결책으로 사용한다.
• 고객은 자신이 인식했을 때 자기의 문제를 제일 잘 해결할 수 있는 기업을 선택한다.
• winner takes it all
• USP(Unique Selling Point) 가 굉장히 구체적으로 있어야 한다. (고객에게 각인 되서 받는 포인트)

IT 스타트업은 이렇게 일한다.

• 사용자의 문제에 집착한다.
• 작고 어설프게 시작하더라도 딱 사용자에게 필요한 수준으로 업그레이드 해가지고 결국 시장에서 '로켓'이 될 수 있다고 믿는다.

'문제'가 무엇일까?

Ex) A가 10년전으로 돌아가고 싶다. -> 왜 돌아가고 싶은데? -> 가족이 다 함께 있었고 젤 행복했어. -> 이 문제를 해결하기 위해선 그 사람이 행복해져야 한다. -> But, 타임 머신은 못 만듦.(기술적 제약) -> 따라서 그 사람의 가족을 모을 수 있는 방법을 생각해내는 것이 문제 해결력이다.

• 사용자의 문제 정의 - 기존의 pain point(부족한 점, 불편함, 가격 등)
• IT 개발 프로젝트의 문제 정의 - 기업의 규모에 따라 달라짐

- 프로덕트 매니저는 기능 개발 없이 해결할 수 있다면 없이 해결할 수 있도록 도와준다.

- 문제 해결은 누가 하나?

문제 해결력 = 문제 정의력, 문제 해결은 다 같이 해야 한다.

즉, 기획의 과정은 구체적으로 해결해야 하는 문제를 정의하는 과정이다.

전통적인 기능 조직

오래되었다 라고 생각하는 조직은 대부분 기능 조직이다. Ex) 회장님 옆에 기획, 전략팀이 있다. -> 앞으로 어떤 시장이 잘 나갈 거라서 이 분야에 투자해야돼요.

Ex) 우리은행의 '위비톡' -> 우리도 이제 IT, 플랫폼 산업을 시작해야겠지? -> 해외에는 금융 기술이 들어간 ~이 엄청 큰 플랫폼이 되고 있습니다. -> 전략 기획팀은 IT를 모름 -> 외부 조직에게 넘김 ~기능을 만들고 싶습니다. -> 서비스 기획팀은 이건 또 모야? 생각 -> 디자인/개발팀에게 넘김 -> 봉황을 그려놨는데 닭을 가지고 온 경우가 많음.

----> 전통적인 기능 조직의 폭포수 단점

- 장점 : 내부 인원을 효율적으로 변경 가능

- 단점 : IT 조직에서는 수행에만 집중해서 자신들이 만들고 있는 것이 정확히 어떤 용도를 위한 것인지를 모른채 만들 수도 있다, 오픈 후에는 조직이 해체됨으로 유지 보수 힘들 수 있다.

진짜 큰 문제 !! : '마음의 문제'

- 평가 기준 때문에 두려움이 커지고 무엇을 만드는지 모른채로 만들기 때문에 힘들 것

기존 조직의 문제에 대한 대안 사상 : 애자일(Agile)

- 마음의 문제를 해결하는 사상

- 개발자가 진짜 만들고 싶어서 만들 수 있도록 의견을 낼 수 있도록 해줘라

- 고객이 기획자로 있어서 고객과의 협력을 꾀하라. (고객이 옆에서 이게 사실 조류에요~ 처럼 계속된 설명을 해줘야 한다.)

- 계획 준수를 넘어서 변화에의 대응 / 프로젝트가 늘어지면 내가 뭘 하고 있는지 까먹게 됨. 따라서 몇 주 단위로 계획을 해서 아 효과 봤어 털어버리고(반복) 해야 한다.

크로스펑셔널팀으로서의 목적조직의 구성방식

- 크로스펑셔널팀 : 하나의 목적을 가지고 움직이는 하나의 조직

- 모든 사람들이 함께 협동

- 단점 : 한 회사에 프로덕트팀이 너무 많으면 협동이 잘 안 됌. MSA하면 니가 할래 내가 할래 서로 안 하려고 함

 

- 목적조직의 성공사례 : 구글, 네카라쿠배당토 등 많은 조직들이 선택하고 있다.

- 기능조직의 성공사례 : 애플

 

스크럼 조직

- 비전 제시(~ 가치를 준다. 되게 추상적일 수도 있다.(가치는 명확해야 한다.) Ex) 쿠팡 : 쿠팡이 없으면 힘들도록 만들겠다. 아마존 : 최대한 많은 상품을 들여와서 없는 상품이 없도록 하겠어.)

- 로드맵

- MVP 정의

- 프로덕트 백로그 : 무엇을 개발할지 더 쪼개서 정의를 해준다.

- 출시 계획 (롤아웃 플랜) 

이 서비스를 출시하는 시점에 그 가치를 극대화 할 수 있는 방식을 찾는다.

- 스프린트 플래닝, 2주 단위로

- 스프린트 백로그

PRD에 이 모든 것을 작성함 (프로덕트 백로그를 어떻게 구현할 수 있는지, 프로덕트의 형태가 있는 프로젝트로 만들어낼 것인가?)

- 2주 단위로 휙휙휙휙 넘어가고 털어지는 경향이 많다. 텐션이 높거나 압박이 있거나

- 일의 의미를 찾아가면서 일하도록 만들자

 

- PRD : 고객이 원하는 대로 해결이 되었는지를 기준으로 판단, 정말 의미있는 서비스를 만들었는가

- 폭포수 방식 : 기능이 없는지 있는지를 기준으로 판단, 개발자들의 자유가 없어짐

PRD의 구성 요소

배경

- 어떻게든 표준화 시켜서 명확한 배경을 공유

- 친구 설문조사를 할 때는 ~문제점이 있을 때는 어떻게 해결해? 이렇게 물어보기

목적, 목표

- 비전에 미션을 내놓기 Ex) 쿠팡의 비전에 대해서는 미션이 배송 서비스를 굉장히 빠르게 하는 것이 될 수 있다.

- 목적에 대한 부분도 고객의 사용성에 편의성을 높인다.

- 그 편의성을 높이기 위한 목표로는 새벽배송이 있다. (조금 더 구체화, 수치화 하기)

- 이 때 레퍼런스를 사용하면 더 구체적으로 설득할 수 있다.

우리의 고객은 누구인가

- 프로덕트에서 타겟팅하는 구체적인 서비스 사용자 그룹(고객) 이 누구인지를 잘 파악해야 한다.

- 헷갈릴 때는 PRD를 다시 꺼내보기, 이래야 과잉 개발을 막을 수 있다.

- usecase와 프로세스를 잘 정리하기 위해서는 고객이 누구인지를 잘 파악해야 한다.

- 페르소나에서 20대 여대생, 고양이를 좋아하고 ~ 이런 내 서비스와 아무 상관 없는 인류학적 페르소나를 들지 않았으면 좋겠다. 단, 마이크로소프트의 페르소나 스펙트럼은 참고하면 좋다. 상황에 맞는 고객군을 정의하는 것이 중요. 2~30대 여성이라는 타깃은 전국민이라고 생각하면 됨. X

- 제일 좋은 것은 사전 신청을 받아놓고 그 사람들의 관심분야를 뽑아놓는 것

대안 설정 및 선택 이유

- 프로젝트화 하기 위해 대안을 설정하고 만약 거부된 대안은 왜 거절되었는지 이유까지 기록해야 나중에 헷갈리지 않고 시간의 낭비를 방지할 수 있음

- "동의할 순 없지만 그렇게 하시죠" -> 프로덕트는 정답이 없기 때문에 일단 팀원들의 말대로 해보고 나중에 고치면 된다. (단 처음에 설정한 objective에 벗어나지 않는 한)

가설과 검증 매트릭

- 이를 잘 해야 우리가 정말 이 서비스를 이해하고 만들었는지를 파악할 수 있다.

- 만약 틀렸어도 괜춘 -> 가설을 바꾸면 됌

- 유저 플로우에 영향을 준다.

구현원칙(Guiding Principle)

- 기능을 늘리는 것에 대한 자유도를 어디까지 줄 것인지, 구조 설계를 할 때 이 프로젝트를 어디까지 확장시킬지 등 개발자, 디자이너 모두가 모여 합의해야 한다.

- 기능을 추가해 갈 때 오바인 것들은 구현원칙을 바탕으로 reject할 수 있다.

- 정말 우리가 목적한대로 흘러갈 수 있도록