🌓 갑자기 저보고 앱을 만들라고요? 요즘 (PM도 기획자도 아닌) 친구들이 난데없이 앱 만들기, 웹사이트 개편 등의 일을 맡게 되더라고요. 정도는 없겠지만 여러 차례 0에서 1을 만들어 보면서

🌓 갑자기 저보고 앱을 만들라고요? 요즘 (PM도 기획자도 아닌) 친구들이 난데없이 앱 만들기, 웹사이트 개편 등의 일을 맡게 되더라고요. 정도는 없겠지만 여러 차례 0에서 1을 만들어 보면서 제가 따라갔던 방법을 소개합니다. 이것만 따라가면 여러분도 기획자..! 문제를 정의하는 단계는 (가장 중요하지만) 생략하고 솔루션을 찾아야 할 때를 염두에 두고 적어봤어요. 하지만, 문제가 뾰족할수록 더 가볍게 MVP를 만들 수 있습니다. 0️⃣ 문제를 발견합니다. 이 부분은 아주 길게 설명해도 다 담기 어렵기 때문에 패-스 하겠습니다! 1️⃣ 레퍼런스를 찾습니다. 내가 만들려는 서비스가 세상에 처음으로 존재하는 서비스일 경우는 아주 적습니다. 보통 비슷한 문제를 해결하려고 하는 서비스들이 있고, 대체재가 존재합니다. 최대한 많이 그런 대체재를 찾습니다. 앱스토어에서 검색해도 좋고, 예전에 사용해봤던 기억을 돌이켜보아도 좋은데요. 앱의 레퍼런스를 찾을 때는 아래 두 사이트를 가장 많이 활용했습니다. - https://mobbin.design/ 외국 앱들의 유저 플로우를 모두 캡처해놓은 사이트 - https://wwit.design/ 모빈의 한국 버전, 한국 서비스의 유저 플로우를 모두 캡처해놓은 사이트 레퍼런스를 보다 보면 어떤 방향의 서비스를 만들고 싶은지, 어느 수준으로 만들면 좋을지 조금 감이 잡히는데요. 여기서 주의할 점은 레퍼런스들은 대부분 완성도가 높은 제품이라는 것! 따라서 기대 수준을 조정할 필요가 있어요. 그렇지 않으면 MVP와 아주 머나먼 길을 떠나게 될 거예요. 2️⃣ 페르소나를 몇 개 만들어서 사용자 여정을 그립니다. 잘 모르겠는 도메인의 잘 모르겠는 제품을 잘 모르겠는 사람들을 위해 만들 때 가장 유용한 방법이에요. 그 제품을 사용할 수 있는 사용자를 가능한 구체적으로 상정합니다. (페르소나 만들기) 한 가지 케이스가 아니라 타깃 하는 여러 사용자 케이스를 포함하면 좋습니다. 예를 들어, 버블리라는 회사의 채용 사이트를 기획한다면 1. 버블리에 관심 있는 주니어 프론트엔드 개발자, 2. 버블리 리크루터에게 이직 제안을 받은 시니어 PM, 3. 버블리에서 도와줄 사람 없이 혼자 일하는 리크루터. 그런 다음에 그들이 하고자 하는 일 (JTBD)을 해결하기 위해 어떤 행동을 하게 될지를 처음부터 그려봅니다. 1은 버블리라는 회사에서 일하고 싶어합니다. 그러기 위해서 1이 경험하는 과정을 차례대로 나열합니다. 1은 원래 버블리라는 서비스를 사용하는 사람이다. > 버블리 서비스를 사용하던 중 버블리가 채용을 한다는 사실을 알게 된다. > 버블리가 주니어 프론트엔드 개발자도 뽑는지 궁금하다. > (…) > 버블리에 지원한다. 마찬가지 과정을 다른 페르소나에서도 반복합니다. 3️⃣ 사용자 여정을 늘어놓고 필요한 기능을 나열합니다. 페이지(페이지에서 보여주어야 하는 것)와 사용자의 액션으로 나누면 명확해지는데요. 예를 들어 주니어 프론트엔드 개발자를 뽑는지 알 수 있으려면 채용공고 페이지가 필요하겠죠? 사용자가 편하게 알 수 있으려면 채용공고 페이지에서 직무명을 포함시키면 좋고요. 연차 정보도 있다면 더 쉽게 찾을 수 있을 거예요. 이런 것들을 나열시키고 나면 어떤 페이지들이 필요한지 사용자가 어떤 행위를 할 수 있어야 하는지가 명확해집니다. - 2&3을 위해 제가 주로 사용했던 템플릿: https://miro.com/app/dashboard/?tpTemplate=3074457345769008393&isCustom=false&share_link_id=974714502074 4️⃣ 목표에 따라 필요한 기능만 추립니다. 이제 지금까지 했던 것을 하나씩 잘라낼 시간✂️. 제약조건이 필요해지는 순간인데요. 적어도 이런 경험은 할 수 있도록 한다, 한 달 안에 만들어서 출시한다 같은 제약조건을 바탕으로 의사결정을 합니다. 문제 정의와 제약 조건이 뾰족할수록 쉽게 필요 없는 기능을 잘라낼 수 있고요. 그렇지 않다면 하나하나 자를 때마다 의사결정을 해야 해서 시간과 에너지가 많이 소모됩니다. 이때는 반드시 협업하는 사람들의 인풋을 받아야 합니다. 이전 단계에서는 인풋이 도움이 되었다면 이제는 인풋 없이는 의사결정이 어려워요. 이때 사용하는 여러 가지 프레임워크가 있을 텐데요. 저는 MoSCoW 와 KANO를 자주 활용했습니다. - MoSCoW에 대한 정보: https://www.productplan.com/glossary/moscow-prioritization/ - KANO에 대한 정보: https://www.productplan.com/glossary/kano-model/ (둘 다 영어 자료인데 읽기 귀찮으시면…. 댓글로 알려주세요. 나중에 요약해 드릴게요!) 5️⃣ 여기까지 했다면, 이제 만들면 됩니다! 위에 말씀드렸던 것처럼 하나의 정도가 있지는 않아요. 매번 이 모든 것을 그리고 있을 필요도 없고요. 그리고 익숙해지면 유저스토리를 만들어내고 기능을 정의하는 데 드는 시간도 훨씬 짧아집니다. 하지만 갑자기 저보고 서비스를 만들라고요? 싶어 막막했던 분들께 도움이 되길 바라요. 더 궁금한 점이 있다면 댓글로 물어보세요 🧚🏽