read

Lean

지금 가지고 있는 가정은 다음과 같다.

  1. Problem#1 이 존재한다.
  2. 이것을 Solution#1 으로 해결할 수 있다.
  3. Customer#1 이 Solution#1 에 Cost#1을 지불할 것이다.

이 중에서 가장 먼저 검증되어야 하는 것은 Problem#1 이 존재하는 가 하는 것이다. 두번째로 검증해야 하는 것은 Customer#1 이 존재하는가 하는 것이다. 이 둘을 검증한다음, Cost#1 을 지불하도록 Solution#1 을 빌드해가는 것이 Lean approach 이다.

반성

나도 지금은 Solution#1 을 빌드하는 것부터 시작하고 있다. Problem#1 에 대하여 대화를 통해 어느 정도 진행한 바가 있지만, 이것을 구체적인 형태의 인터뷰 폼으로 남기지는 못했다.(숨은 가정 : Problem#1 의 존재에 대해 검증했다고 생각한다.) 그 다음은 Customer#1 을 찾는 일인데, 고객을 찾으려면, Cost#1 이 결정되지 않으면 안된다. Customer#1 를 찾고, Cost#1 을 내도록 설득하는 과정에서 Solution#1 에 대한 설명이 필요할 수도 있다. 이때 유창한 말과 잘 만든 프레젠테이션으로 설명할 수도 있겠지만, 그것보다는 실제 돌아가는 형태의 프로토타입이 보다 효과적이다. (숨은 가정 : 프레젠테이션으로 Solution#1 을 Potential Customer#1 에게 설명하기 힘들다.)

그래서 지금 내가 하는 일은 Customer#1 을 찾기 위한 MVP#1 을 만드는 것이다. 목표는 핵심 개념 설명과 Problem#1 이 어떤식으로 쉽게 풀리는지 보여주는 것이다. 이 과정을 페이퍼 프로토타이핑이나 와이어프레임으로 대체할 수도 있겠지만, 둘다 비숙련자인 내가 하기에 개발만큼 시간이 걸릴 것이라 판단했다.(숨은 가정 : 페이퍼 프로토타입이나 와이어프레임은 시간이 많이 걸린다.)

Call to actions

  • 고객 인터뷰 최소 20명 진행하기
  • Cost Structure 정해보기
  • MVP#1 가 달성할 목표를 S.M.A.R.T 하게 정하기
  • 주간 회고 때 이번 주를 보다 Lean 하게 보내려면 어떻게 했어야 했는지 반성하기
Blog Logo

Ki Sung Bae


Published

Image

Gsong's Blog

Developer + Entrepreneur = Entreveloper

Back to Overview