1. MVP(Minimum Value Product)

- 이전 시리즈 -

2019/12/02 - [만들기/린스타트업(실전편)] - 0. Design Thinking : 천천히, 하지만 착실하게

Intro

[그림 1-1]

MVP(Minimum Value Product)

MVP를 이용한 개발 방법의 포인트는 피드백을 기반으로 한 기민성 입니다.

“다른 곳으로 편리하게 이동한다”

라는 가치를 제공하려 한다고 할때, 그림 1-1의 윗부분의 과정에서는 4번의 과정이 되기 전 까지 사용자는 우리가 제공하려고 하는 가치를 체험해보지 못하고, 피드백을 전달하지도 못합니다. 제품 출시 전까지 중간에 피드백이 없기 때문에 최종 제품이 나온 이후에 그 가치가 제대로 제공되지 않는다면 피해가 적지 않을 것입니다.

반면, 그림 아랫부분은 모든 과정에서 퀄리티의 차이는 있지만, “다른 곳으로 편리하게 이동한다” 라는 가치를 제공합니다. 각 과정에서 유저들에게 피드백을 받으면서 점점 발전된 형태의 제품을 만들어낼 수 있고, 최종제품이 실패할 확률은 점점 낮아집니다.

1. MVP는 빠르지 않다!

기존의 방식, 그러니까 ‘자동차’라는 결과물을 처음부터 설계하고 제작을 하는 방식(1-1의 위쪽)이 자동차를 빨리 만들어서 고객에게 제공할 수 있습니다. 반면, MVP를 중심으로 한 개발(1-1의 아래쪽)에서는 1 -> 2 단계를 제외하면 프로젝트를 완전히 엎고 다시 만들어야 합니다. 당연히 훨씬 오랜 시간을 투자해야 자동차라는 결과물을 만들 수 있을 것입니다. 기존 방식의 프로세스가 견고하다면 시간적 차이는 더욱 벌어지겠죠.

2. 그럼 이걸 왜 하는 거지?

다행히도 그림 1-1에서는 고객이 원하는 가치를 제공했습니다.. 하지만 실제로는 아래와 같은 일들이 많이 발생합니다.

[그림 2-1]

그림 2-1에서 제일 큰 문제는 고객이 완성품을 받아보기 전까지 문제를 바로잡아줄 사람이 없다는 것입니다. 속도는 빠르겠지만 빠른 속도로 잘못되고 있는 것이죠.

MVP는 이런 문제를 해결하는 좋은 방법 중 하나입니다.

비록 고객이 처음 받아볼 제품은 원하는 수준에는 전혀 미치지 못할 테지만 당장은 고객의 문제를 해결할 수 있습니다. 이 부분이 중요합니다.

“MVP는 Minimum Value를 반드시 구현해야 한다.”

3. Minimum Value

모든 서비스는 고객의 어떠한 문제를 해결하기 위해서 존재합니다(설령 고객이 그걸 문제라고 생각하지 않더라도!). 그림 1-1의 경우, 고객은 원하는 곳으로 편하게 이동하지 못하는 문제를 가지고 있습니다. 우리의 MVP인 ‘바퀴가 달린 판때기’는 최소한 걷는 것보다는 편하게 이동한다는 Minimum Value를 제공하게 됩니다.

 

 

여기서 중요한 것은 고객의 문제가 무엇인지 잘 파악하는 것입니다.

 

그림 2-1 첫 번째 칸에서 고객은 자신이 무엇을 원하는지 잘 설명하지 못한것 같습니다. 예상 해보자면, 이렇게 이야기하지 않았을까요?

고객 : “나무에 두꺼운 밧줄을 걸고, 판자로 연결해서 앉을 수 있으면 좋겠어요!”

여기서 제작자가 

”고객이 이걸 왜 필요로 하지?”,

”이것으로 어떤 가치를 얻기를 원하는 거지?”

같은 질문을 하지 않고, 

“나무, 두꺼운 밧줄, 판자, 연결하고, 앉을 수 있음”

같은 기능(Function)에만 집중해서 기획서를 쓰게 됩니다. 그 결과가 2번째 칸이죠.

고객이 요구하는 기능은 모두 구현 했지만 본연의 가치는 제공하지 못합니다.

 

이 경우는 원하는 제품 자체가 워낙 심플해서 MVP를 만들기 힘들지만, 억지로 그 과정을 시뮬레이션 해보려고 합니다.

우선, 고객과 프로젝트 매니저 사이에선 이런 대화들이 오가야 할 것입니다.

매니저: “왜 나무에 밧줄을 걸기를 원하시죠”?,
고객: ”그래야 앞뒤로 왔다 갔다 하죠!”
매니저: “앞뒤로 왔다 갔다 하면 어떤 점이 좋은 건가요?”
고객: “재밌잖아요!”
매니저: “그렇군요! 그렇다면 연결은 왜 해야 하는 거죠?”
고객: “그래야 연결한 부분에 몸을 의지해서 공중에 매달릴 수 있죠!”
(이런 식으로 계속…)

엄청 바보 같아 보이지만 이 부분을 충실히 수행하면서 고객이 이 제품을 통해서 얻기 원하는 가치가 공중에 매달린 상태로 앞뒤로 왔다 갔다 하면서 얻는 재미라는 것을 알 수 있게 되었습니다.

최대한 빨리 이 가치를 제공해 줄 수 있는 방법을 생각해보니

이런 결과물이 그려졌습니다. 물론 타는 사람은 힘도 많이 들고, 앉을 수도 없으며 밧줄이 두껍지도 않고, 판자로 연결되어 있지도 않지만, 고객이 가장 원하는 가치인 공중에 매달린 상태로 앞뒤로 왔다갔다는 할 수 있습니다.

반나절 만에 밧줄을 나무에 묶어놓고 고객을 부릅니다(중요).

당연히 아직 제품이 완전 초기 버전이고 많이 부족할 것이라고 밑밥을 깔고요.

나 : “매달려보시죠!”
고객: (매달려서 몇 번 왔다 갔다 한다)
나 : “어떤 부분이 불편하신가요?”
고객 : “우선 팔이 너무 아프네요. 앉을 수 있으면 좋겠어요. 그리고 밧줄이 너무 얇아서 불안하네요…. (블라블라)”
이런 식으로 피드백을 받으면서 제품을 발전시켜 나간다.

만약에 이렇게 안 하고 프로젝트 매니저가 생각한 대로 기획하여 완성된 제품을 만들었다고 해봅시다.

고객이 처음 제품을 만나는 시간은 MVP를 만들었을 때보다는 훨씬 오래 걸릴 것입니다 .

그렇다면 오랜 시간 끝에 야심 차게 고객을 불러서 제품을 보여준다면 과연 고객은 만족할까요?

매니저가 생각한 제품의 가치와 고객이 필요로하는 가치가 일치 하지 않는다면 고객은 절대 만족하지 못할 것입니다.

Warning: Not TODO

하지만, 그림 1-1의 상황에서 아래와 같이 접근 하는 것을 많이 경험하게 됩니다.

“우리는 앞으로 여기 있는 기획을 따라 자동차를 만들 거야! 근데, 요즘 MVP라는 게 유행이라지? 그럼 이 기획안에서 1달 안에 최소한으로 구현할 수 있는 기능이 어떤 거야?!”

이 문장 안에서 MVP를 사용한 제품 개발에 적합하지 않은 점들을 뽑아보자면

1. 이미 기획이 완성되어 있다
   • 최종 목적지가 정해져 있기 때문에 고객의 요청사항을 적극적으로 반영할 수 없습니다.
   • 오히려 고객들의 피드백은 "우리가 피땀흘려가며 오랜시간 연구 끝에 개발한 기획서를 이해 못한 어리석음의 산물" 로 전락하게 됩니다.
2. “최소한으로 구현할 수 있는 기능이 어떤 거야?!”
   • 위에서도 말한것 처럼 우리가 구현해야 하는 Minimum 은 Value이지 Function 이 아닙니다!
   • 완성된 자동차 제작 기획에서 Function을 최소화하면 당연히 타이어 한 짝 밖에 나오지 못하죠...
   • 타이어 한 짝을 MVP라고 만들어서 고객에게 제공하게 된다면, 고객은 타이어를 들고 이동을 해야 합니다. 풀고자 했던 문제가 더 심각해진 것이지요.

이런 경험이 쌓이면, MVP 는 쓸모가 없어지겠지요. ㅠ_ㅠ

마무리하자면...

위의 내용들로 확인할 수 있는 것처럼 MVP는 속도보다는 방향에 초점이 맞춰진 개발 방법입니다.

그리고 제대로만 하면 고객 입장에서도 당장 해결하길 원하는 문제의 해법을 빠르게 제시한다는 점에서 속도의 이점역시 가질 수 있습니다.

 

완벽하게 기획이 완성되지 않았기 때문에 자연스럽게 짧은 호흡으로 제품을 개선시켜야 하고 이는 Agile, Lean Start-up 등과 좋은 호환성가집니다.

 

이어지는 글

2019/11/19 - [만들기/린스타트업(실전편)] - 2. 디자인 씽킹 ToolKit - Contextual Inquiry