앱을 만들기 전에 MVP를 만들어야 하나요?

앱에 대한 아이디어나 소비자가 앱에 어떻게 반응할지에 대해 도박을 할 여유가 있습니까? 특히 고객의 돈과 평판이 문제인 경우 고객도 그렇게 하는 것이 편하지 않을 것입니다.

주의 깊게 접근하지 않으면 앱은 비즈니스에 위험한 투자가 될 수 있습니다. 그럼에도 불구하고 가장 잘 연구된 앱 개념은 실망스러운 사용자 다운로드 및 유지율로 이어질 수 있습니다.

모바일 앱을 구축하든 SaaS 제품을 구축하든 관계없이 MVP(Minimum Viable Product)를 사용하여 고객의 투자를 보호하는 것에 대해 생각해 본 적이 있습니까?

MVP를 사용하면 파이프라인을 통해 프로젝트를 더 빨리 가져올 수 있을 뿐만 아니라 개발자가 클라이언트를 위해 전반적으로 더 강력한 제품을 만들 수 있습니다.

알아야 할 사항이 있습니다.

앱 개발에서 MVP의 가치

Frank Robinson은 2001년에 처음으로 MVP가 무엇인지 정의했습니다. 그 뿌리에서 MVP는 제품의 개념과 시장에서 실행 가능성을 테스트하고 검증할 목적으로 대중에게 출시되는 축소된 버전의 제품입니다. .

린 스타트업(Lean Startup)의 저자인 에릭 리스(Eric Ries)는 초기에 MVP를 옹호한 사람 중 한 명이었으며 2013년에 MVP를 사용해야 하는 이유와 방법에 대해 흥미로운 이야기를 했습니다.

요점은 더 얇은 제품을 만드는 것이 아닙니다. 앱의 가장 기본적인 버전이나 개념을 채택자와 전도자의 손에 전달하는 것입니다. 그런 식으로 개발자는 초기에 사용자 피드백을 수집하고, 결과적으로 제품을 최종 버전으로 적절하게 형성하는 데 사용됩니다.

예를 들어 Dropbox를 사용하십시오. 2009년 제품의 방문 페이지는 다음과 같습니다.

회사 이름, 소프트웨어 설명, 데스크톱 또는 모바일 앱을 다운로드할 수 있는 링크가 포함된 간단한 페이지입니다. 그들이 얻는 것에 대해 더 알고 싶은 사용자를 위해 "둘러보기"는 더 많은 정보가 있는 미니 사이트로 안내했습니다.

이는 오늘날 소비자와 기업이 모두 사용하는 강력한 스토리지, 콘텐츠 제작 및 협업 서비스와는 거리가 멀습니다.

하지만 그것이 MVP의 매력입니다. 기본적으로 개발자 는 최소한의(그러나 절대적으로 필수적인) 기능 세트만 사용하여 제품을 빌드해야 합니다 .

Dropbox는 클라우드 스토리지 서비스의 힘을 예측하거나 당시 시장에 적합하지 않은 것을 만들 필요가 없었습니다. 사용자가 필요로 하는 간단한 솔루션을 그때그때 출시하기만 하면 됩니다. 그런 다음 사용자는 제품을 검증하고 회사에 제품을 가져가는 데 필요한 방향을 제공할 수 있습니다.

MVP를 만들면 다음과 같은 다른 이점이 있습니다.

• 전체 앱이 개발될 때까지 기다리는 것보다 훨씬 빠르게 제품을 출시할 수 있습니다.
• 작업에 너무 많은 인력을 투입하기 전에 개념의 실행 가능성을 테스트할 기회를 얻습니다.
• 최종 제품의 꼬임을 해결할 수 있는 더 많은 공간(그리고 약간의 용서도 가능)을 제공합니다.
• MVP로 비용을 절약할 수 있습니다. 첫째, 절대적으로 필요한 기능만 구축하는 데 시간을 할애하기 때문입니다. 둘째, 사용자가 축소된 버전에 만족하고 제품을 완성하기 위해 더 많은 작업을 수행할 필요가 없다는 것을 알 수 있기 때문입니다.
• 사용자가 수용한 테스트된 아이디어를 통해 나머지 개발 프로세스를 훨씬 더 원활하게 진행할 수 있는 투자자에게 가져올 수 있는 것이 있습니다.

동영상에서 Eric이 말했듯이 MVP는 완전한 제품 개발이 허용하는 것보다 훨씬 짧은 시간 내에 성공 가능성 을 극대화하는 가장 좋은 방법입니다.

사용자가 테스트하고 싶은 가치 있는 MVP를 구축하는 방법

MVP의 성공은 얼리 어답터가 제공한 통찰력과 피드백을 활용하는 능력에 달려 있습니다. 즉, 100% 귀하의 편이며 제품을 믿고 귀하가 부족한 부분을 채우도록 도우려는 사람들입니다. 그러니 놓치지 마세요.

MVP는 함께 던진 반쪽짜리 앱이 아닙니다. 여전히 가치가 있어야 합니다.

MVP를 구축하고 실행하기 전에 수행해야 할 몇 가지 작업은 다음과 같습니다.

1. 제품의 목적 결정

앱이 성공하려면 많은 소비자 기반의 문제를 고유하게 해결해야 합니다. 즉, MVP는 제품의 기능과 사용자에게 필요한 이유를 명확하게 분석해야 합니다.

예를 들어 Uber(당시 UberCab)는 2010년 베타 기간 동안 다음과 같이 판매했습니다.

앞의 Dropbox 예와 마찬가지로 개념이 매우 간단하고 그것이 무엇인지 또는 왜 그렇게 가치가 있는지 설명하는 측면에서 군더더기 없습니다. 하지만 여전히 아이디어를 얻을 수 있습니다. 사람들이 휴대전화로 자동차를 주문하고 결제할 수 있는 앱입니다. 기본적으로 택시를 편리하게 대체할 수 있습니다.

1년 후 Uber가 공식 제품 출시를 통해 정체성과 가치 제안을 확고히 하기 시작했음을 알 수 있습니다.

2011년 Uber가 "Cab"을 내리고 온콜 개인 운전 서비스라는 레이블을 붙였을 때였습니다. 소비자가 다른 방법으로는 감당할 수 없는 특정 호화로운 특권을 경험할 수 있는 방법이었습니다.

그것이 Uber가 최종적으로 취한 형태는 아니지만 초기 사용자 피드백이 제품 개발자가 플랫폼의 어떤 부분을 강조하고 구축할 가치가 있는지 결정하는 데 얼마나 도움이 되었는지 알 수 있습니다.

이것은 MVP를 구축하고 사용자가 원하는 것과 필요한 기능에 대한 귀중한 통찰력을 수집하기 시작할 때 발생하는 일입니다. 그러나 먼저 일반적인 목적과 가치를 명확히 하는 것부터 시작해야 합니다. 나중에 다듬을 수 있습니다.

2. 이상적인 사용자 찾기

당신은 당신의 개념을 가지고 있습니다. 이제 소비자들이 그것을 원할지 알아낼 때입니다. MVP가 더 저렴하고 빠르게 구축할 수 있다고 해서 결국 시간과 리소스가 완전히 낭비되는 것은 아닙니다. 최소한 관심이 있는지 확인한 다음 타겟 사용자가 누구인지 명확하게 정의해야 합니다.

특히 위치에 대해 생각해야 합니다.

위의 Uber 예시에서 베타 제품이 샌프란시스코에서만 테스트되었음을 ​​알 수 있습니다.

에어비앤비의 초기 버전도 비슷한 일을 했습니다. Airbnb의 공동 설립자인 Joe Gebbia는 How I Build This의 2017년 에피소드에서 자신의 MVP에 대한 이야기를 들려줍니다.

기본적으로 그는 현금이 부족하여 다가오는 회의를 위해 샌프란시스코 아파트에서 에어 매트리스를 임대하기로 결정했습니다. 그는 호텔에 객실이 부족할 것이라는 사실을 알고 있었기 때문에 이를 통해 돈을 벌 수 있다고 생각했습니다. 그러나 그가 번 돈은 단지 임대 돈이 아니 었습니다. 그는 많은 사람들이 자신의 아파트에 공간을 임대하는 데 관심을 보인 후 새로운 사업에 대한 아이디어를 얻었습니다.

그래서 그와 그의 파트너는 "AirBed & Breakfast"라는 웹사이트를 만들었습니다. 그러나 일단 실행되면 원래 샌프란시스코 테스트 지역을 훨씬 넘어서 퍼졌습니다.

2009년에는 72개국에서 AirBnB를 임대했습니다. 오늘날, 당신은 사실상 전 세계 어느 도시에서나 쓰레기를 선택할 수 있습니다. 그러나 모든 것은 샌프란시스코에서 시작되었습니다.

따라서 제품 빌드를 시작할 때 전체 릴리스를 수행하기 전에 앱을 테스트하고 피드백을 얻을 수 있는 최적의 장소를 생각하세요. 목표로 하는 인구 및 인구 통계를 잘 나타내는 지역이 되기를 원합니다. 또한 제품에 대한 수요가 있고 대상 사용자가 해당 제품을 사용할 수 있는지 확인해야 합니다(수익 창출을 시작하면).

3. MVP 형식 선택

MVP의 형식은 건물을 짓기 전에 고려해야 할 또 다른 중요한 사항입니다.

어떤 경우에는 실행 가능한 제품을 만들어야 합니다. 예를 들어 새로운 데이트 앱을 만드는 것이 목표라고 가정해 보겠습니다. 시장에는 수많은 데이트 앱이 있습니다. 특히 지속적으로 팩을 지배하는 두 개의 앱이 있습니다. 기능을 아무리 줄여도 모바일 데이트 앱을 구축하는 것은 거대하고 비용이 많이 드는 도박이라는 것을 알고 있습니다. 그래서, 당신은 무엇을합니까?

대신 PWA 데이트 앱을 만들 수 있습니다. 비용은 더 낮고 출시 시간은 훨씬 더 빨라질 것이며 앱 스토어에 무언가를 올릴 때보다 사용자에게 MVP를 알리는 것이 훨씬 더 쉬울 것입니다. 결국 PWA가 제품 형식 측면에서 충분하다는 것을 알 수도 있습니다.

다른 경우에는 MVP가 실제 제품일 필요조차 없습니다. 제품을 발표하거나 개념의 와이어프레임/프로토타입을 제공하는 웹사이트일 수 있습니다.

2018년 Rand Fishkin은 2004년에 공동 설립한 Moz를 떠나겠다고 발표했습니다. 동시에 그는 SparkToro라는 신제품을 발표했습니다.

이제 Rand는 MVP로 개념 을 시작하고 여전히 성공할 수 있는 사람입니다. 그는 이 공간에서 오랜 역사와 탄탄한 평판을 가지고 있기 때문에 당연히 사용자들은 소비할 수 없는 이 신제품에 끌릴 것입니다.

새로운 브랜드에 대한 MVP를 구축하는 사람들에게는 아마도 그렇게 운이 좋지 않을 것입니다. 그러나 실제로 구축하려는 제품 유형에 따라 다릅니다.

축소 버전으로 제품을 생성할 방법이 전혀 없다면 탐색할 가치가 있는 옵션이 될 수 있습니다. 귀하 또는 귀하의 고객에게 자금이 전혀 없고 투자자에게 개념의 실행 가능성을 증명하기 위해 검증된 피드백이 필요한 경우에도 좋은 생각이 될 것입니다. 이것이 내가 Joe Schmoes가 이 문제를 해결하는 것을 볼 수 있는 유일한 방법입니다.

만약 당신이 이 길을 간다면, 당신도 정말 좋은 설명 섹션이 필요할 것입니다. 이것은 우리가 만들고 있는 것 페이지에 있는 SparkToro의 내용입니다.

이런 종류의 제품에 끌리는 사용자, 즉 이러한 종류의 솔루션이 실제로 필요한 고급 마케터에게는 기능의 개념과 실행 가능성을 테스트하는 이러한 방식이 좋다고 생각합니다. 그들의 언어와 그들이 이해할 수 있는 시각 자료로 작성되었습니다.

그러나 귀하의 브랜드에 익숙하지 않거나 Rand의 청중만큼 잘 훈련되지 않은 사용자의 경우 제품 대시보드의 와이어프레임 또는 프로토타입이 더 나은 아이디어일 것입니다. 설립자의 설명 동영상도 잘 작동합니다. 사용자가 가입하고 가능한 한 빨리 피드백을 제공하도록 설득하는 것이어야 합니다.

4. 실제 최소값 찾기

Eric Ries의 비디오를 보면 MVP의 최소 기능을 정의하는 공식을 제공한다는 것을 알 수 있습니다. 다음과 같이 진행됩니다.

필요하다고 생각하는 최소 기능 수 / 8 = 진정한 최소값

그 공식이 당신을 불안하게 만든다면 의미가 있습니다. 그러나 다음과 같이 생각해 보십시오.

당신은 쓸모없게 되지 않고 가능한 한 단순한 MVP를 구축합니다. 사용자에게 발송하고 피드백을 제공할 수 있는 기회를 제공합니다.

결과적으로 몇 가지 일이 발생할 수 있습니다.

그들은 그것을 절대적으로 싫어합니다.

그들은 기능 A가 얼마나 형편없었는지, 어떻게 다른 일을 하기를 바라는지, 또는 기능 B가 거의 거기에 있었는지에 대해 불평하지만 기대에 미치지 못합니다. 저건 완벽 해! 테스트 사용자는 제품에서 원하는 것을 정확히 알려줄 것입니다. 일관된 피드백을 충분히 받으면 앱의 다음 버전에 나타나야 하는 필수 기능 목록을 갖게 됩니다.

그들은 괜찮지만 그것을 사랑하지 않습니다 ... 아직.

다시 말하지만 사용자가 100% 만족하지 않아도 괜찮습니다. 당신은 그들에게 멋진 제품을 시험해 볼 기회를 주었고 그들은 그 안에 담긴 약속을 보았습니다. 그들에게 자신의 생각을 말할 기회를 주고 그들이 무엇을 사랑했고 무엇을 좋아하지 않았는지 알려주세요. 그런 다음 이러한 약점을 강화하고 진정한 게임 체인저가 될 기능을 포함하는 데 중점을 둡니다.

그들은 있는 그대로 그것을 좋아할 것입니다.

솔직히 말해서, 이것은 일어날 가능성이 없습니다. 하지만 피드백이 너무 적어서 MVP를 있는 그대로 굴릴 수 있다면 좋지 않을까요? 또한 제품을 너무 많이 줄여서 자신과 고객을 절약 한 모든 시간을 생각해보십시오. 때로는 단순한 것이 더 좋습니다.

제품에 대한 피드백과 지원에 대해 이 사용자들에게 감사하는 것을 잊지 마십시오. 그들의 통찰력 없이는 그들이 필요로 하는 솔루션을 만들 수 있는 방법이 없으므로 이 분야에서 그들이 수행하는 역할을 인식하는 것이 가장 좋습니다. 그 대가로 그들은 출시 후에도 오랫동안 계속해서 제품의 전도사로 남을 것입니다.

5. 랜딩 페이지를 일찍 디자인하라

비록 위에서 언급한 이유로 MVP 역할만 하는 랜딩 페이지나 미니 웹사이트에 그다지 관심이 없지만 MVP가 작업 중인 동안 모바일 우선 랜딩 페이지를 만드는 것이 좋은 생각이라고 생각합니다. .

게임 앱과 SaaS는 베타 등록 페이지를 일찍 시작하는 데 특히 좋은 선택입니다. 다음은 Hytale의 예입니다.

MVP가 성공하기를 바란다면 지금 남은 시간을 강력한 랜딩 페이지를 구축하는 데 투자해야 합니다. 이 게시물에 소개된 회사의 초기 웹 사이트를 조사하는 것으로 시작하십시오. 그들은 모두 성공적으로 개념을 설명하고 제품을 소프트 마케팅했으며 초기 사용자가 테스트에 등록하도록 설득했습니다.

거기에 있는 동안 블로그, 소셜 미디어 계정 및 커뮤니티 기능(활성화된 뉴스레터 포함)도 설정해야 합니다. 당신은 절대 모릅니다. 누군가 Google 검색이 아닌 다른 곳에서 귀하의 MVP 발표를 발견하고 사이트를 북마크에 추가하거나 베타 테스터가 되기 위해 조기에 등록하기로 결정할 수 있습니다.

귀하의 사용자 세트로부터 동의를 얻기 시작하기에 너무 이른 때는 없습니다!

6. 성공 기준 정의

마지막으로 MVP의 성공을 어떻게 측정할 것인지 결정해야 합니다. 피드백의 품질에 관한 것만이 아니기 때문입니다.

다음을 고려하세요:

• 얼마나 많은 방문자가 귀하의 방문 페이지를 방문했습니까?
• 그 중 몇 명이 베타에 가입했습니까?
• 일정 기간(1개월, 3개월 등) 동안 몇 명의 사용자를 유지했습니까?
• 얼마나 많은 사람들이 피드백을 제공했으며 앞으로 제품 디자인과 기능에 대한 확실한 결정을 내릴 수 있을 만큼 충분히 중요합니까?
• 사용자 집합의 인구 통계가 앱을 디자인한 대상과 일치했습니까? 왜 그랬다고 생각하세요?
• 평균적으로 사용자가 앱 내에서 보낸 시간은 얼마입니까?
• 어떤 기능에 가장 많은 시간을 보냈습니까? 최소한?
• 어떤 기능이 가장 좋은 피드백을 받았습니까? 최소한?
• 제품에 대해 긍정적인 경험을 한 특정 사용자가 있었습니까? 무엇이 그들을 다르게 만들었을까?

원래 랜딩 페이지, 베타 테스터, 사용 데이터 등에서 수집한 모든 정보를 가져 와서 실제로 모두 살펴보십시오. 당신이 디자인한 MVP에 대해 무엇을 말해주는가? 그리고 지금, 당신은 그것으로 무엇을 할 것입니까?

그대로 둘 것인가 아니면 사용자가 원하는 완전한 제품으로 만들 것인가?

수집한 사용 데이터를 기반으로 고객을 유치하고 확보하기가 쉽습니까? 또한 이러한 사용자를 유지할 수 있습니까? 아니면 기본 앱 형식 대신 브라우저 측에서 앱을 유지하는 것이 더 비용 효율적입니까?

그리고 마지막으로, 제품에 대한 액세스를 위해 얼마를 청구할 수 있고 또 청구해야 합니까? 그것이 궁극적으로 회사를 수익성 있게 만들 것인가, 아니면 이것을 가치 있는 벤처로 만들기에 충분한 관심(적어도 사물의 수익화 측면에서)이 없을 것인가?

많은 질문을 남기고 있지만 테스트가 시작되면 해결해야 할 문제가 많습니다. 게다가 처음부터 MVP를 만든 이유입니다. 이 사용자 피드백은 프로세스에 매우 중요하며 시장에 출시할 가치가 있는 제품인지 또는 다시 검토할 가치가 있는 제품인지 알 수 있는 유일한 방법입니다.