MVP를 구축한 후 기능 개발의 우선 순위를 지정하는 방법

게시 됨: 2021-10-05

[ 표지 : 유나잇 모바일 앱 ]

많은 사람들이 말하듯이 가장 먼저 해야 할 일이 있습니다. 신생 제품 개발의 맥락에서 MVP는 꿈과 같은 제품의 첫 번째 대상 버전입니다. 그러나 MVP는 시간과 비용이 적게 드는 것으로 알려져 있습니다. 프로젝트 개발이 막바지에 다다랐고 mvp 이후의 다음 단계는 무엇입니까?

MVP를 구축하는 데 눈덩이 효과가 있다는 것을 눈치채지 못 하셨나요?

눈덩이 생성 과정을 상상해보십시오. 당신은 눈송이를 공으로 모아 작은 눈송이로 시작합니다. MVP 생성에도 동일한 비유가 적용됩니다. 제품에 반드시 있어야 하는 기능을 정의하고 작게 시작합니다. 앱 개발 프로세스 동안 팀과 귀하는 제품을 개선하는 방법에 대한 새로운 아이디어를 생각해내고 그 결과 새로운 작업이 나타납니다. 물론 이로 인해 예산 한도도 늘어납니다.

그러나 이미 MVP를 구축하는 데 동의했으며 이는 개발 단계를 연장해서는 안 된다는 의미입니다. 먼저 최소 실행 가능 제품(Minimum Viable Product)의 도움을 받아 제품이 시장에서 필요한 것과 정확히 일치하는지 확인해야 합니다. 그러나 타이밍이 완벽하지 않다고 해서 귀중한 아이디어 보석을 잃어버릴 수는 없습니다. 따라서 항상 하던 대로 행동하여 이러한 아이디어를 수집하고 작업 백로그에 넣는 것이 좋습니다. MVP 이후에 추가할 기능을 연기하면 나중에 기능 개발의 우선 순위를 정하고 빌드하려는 순서대로 배치할 수 있습니다.

고객을 5가지 유형으로 분류하는 Kano 모델 이론에 따르면 이것은 사용자가 갈망하는 세 번째 유형입니다. 그러나 MVP의 주요 목적은 다른 종류입니다. 최소한의 실행 가능한 제품은 개념을 테스트하기 위해 만들어집니다. MVP는 “ 시장이 내 제품에 정말로 관심이 있습니까?라는 질문에 답해야 합니다 . "; 따라서 풍부한 기능을 갖춘 MVP의 다음 단계로 이 제품을 더 빠르고 저렴하게 개발하는 것이 현명합니다.

MVP가 완료되면 MVP를 만든 후 다음 단계는 무엇입니까?

1. 베타 테스트를 먼저 합니다.

잘 알려진 것은 개발 프로세스가 끝난 직후 제품 소유자가 베타 테스팅 그룹을 내놓는 것입니다. 베타 테스터는 클라이언트 측(또는 고객 요청에 따라 찾아냄)에서 제품을 사용하기 시작한 다른 사람들입니다. 잠시 후 실제 사용자의 기대치를 볼 수 있도록 피드백을 제공합니다. 이후 중요한 것은 기능 아이디어를 작업으로 전환하고 백로그에 넣어 수신된 결과를 처리하는 것입니다. 이렇게 하면 사용자의 목소리가 들리고 주목된다는 명확한 메시지를 사용자에게 전송합니다.

2. 3, 2, 시작.

MVP 제품의 출시는 길고 재미있는 제품 개발 프로세스의 또 다른 반복일 뿐입니다. 개발 스프린트를 마칠 때마다 같은 일이 발생합니다. 먼저 테스트한 다음 수정하고 다시 테스트하고 릴리스합니다. 그러나 이 단계에서는 아웃바운드 마케팅이라는 구성 요소를 하나 더 포함해야 합니다. 다음을 포함하여 새로운 앱이나 웹사이트를 홍보하는 방법에는 여러 가지가 있습니다.

  • SEO/ASO 서비스
  • 블로그 포스팅
  • 보도 자료 및 잡지 광고
  • 대회 및 대회

추가 애플리케이션 마케팅에 관심이 있으십니까? 애플리케이션 마케팅에 대한 최근 기사 를 읽으실 수 있습니다 .

마케팅에 대해 자세히 알아보는 것 외에도 제품에 대한 참여도를 계속 주시해야 합니다. 모든 것이 올바르게 작동하면 기술 지원 및 모니터링에만 집중하면 됩니다.

최소한의 실행 가능한 제품 뒤에 오는 것은 무엇입니까?

지금부터 미래의 모든 제품 개발은 귀하가 수신하기 시작하는 데이터에 달려 있습니다. 다음을 기반으로 결론 및 조치를 취하십시오.

  1. 수신된 메트릭 - 유지율, 세션 기간, 사용자 참여 매개변수, 사용자 획득 및 평생 가치는 추적하고 분석해야 하는 KPI입니다. 앱이 어떻게든 수익을 창출하는 경우 - 다양한 수익 창출 방법의 성능에 주의하세요. 놀랍게도 KPI를 측정하는 가장 잘 알려진 9개의 앱 성능이 있습니다. 전체 목록은 여기에서 찾을 수 있습니다.

  2. 사용자 피드백이 제공되었습니다. Google Play 및 App Store는 피드백 섹션을 살펴보는 것만으로 모니터링할 수 있는 편리한 방법을 제공합니다. 그럼에도 불구하고 소셜 네트워크, 포럼 및 웹 플랫폼에서 브랜드에 대한 언급을 찾으십시오. 사용을 권장하는 도구는 평가에서 브랜드가 언급된 불만 사항에 이르기까지 무엇이든 찾을 수 있는 YouScan입니다.

  3. 3차 MVP 단계는 1번과 2번 데이터를 분석하고 이 두 가지를 기반으로 기능 구현 결정을 내리는 것입니다. 이렇게 하려면 작업 백로그를 다시 열어야 하며 각 기능에 대해 어떤 필수 메트릭에 영향을 미치는지에 따라 특정 표시(0에서 10까지)를 지정합니다(아래 그림 참조).

기능 평가

아직 확신이 서지 않습니까? 음, 위의 이미지에서 인앱 측정항목을 정확하게 측정했으며 사용자 참여가 나머지 항목보다 현저히 낮은 것을 확인했다고 가정해 보겠습니다. 작업 백로그에 나열된 기능 아이디어에 도달하고 수평선에 넣을 기능을 선택할 시간입니다(이미지에 표시됨). 우리가 다음에 할 일은 비즈니스 및 마케팅 분석가의 도움을 받아 이 특정 기능이 개선에 도움이 되는 메트릭을 분석하는 것입니다. 이 기능이 얼마나 도움이 되는지에 따라 특정 표시(0에서 10까지)를 표시합니다. 기능 평가 프로세스는 "푸시 알림" 요소가 사용자 참여 라인에서 10이라는 확신을 갖고 있음을 보여줍니다. 일단 배포되면 사용자는 앱을 더 자주 떠올리게 되어 앱을 더 자주 방문하고 활동이 증가하며 결국 참여율이 높아집니다. 따라서 우리는 이 기능을 개발하기로 결정했습니다.

고려해야 할 또 다른 필수 사항은 변경 비용입니다. 경험에 따르면 표준 푸시 알림 기능은 개발하는 데 약 20시간이 걸립니다. 이 요소에 투자할 준비가 되셨습니까? 이것에 더하여 미래에 당신에게 어떤 이익을 가져다 줄 것입니까? 신중한 선택과 분석은 MVP 이후 기능 요약을 우선 순위로 지정하는 데 매우 중요합니다.

DIBB 접근법.

또한 DIBB의 제품 접근 방식(Data, Insight, Bet and Believe)을 강조하고 이 4단계는 제품 내에서 발생하는 모든 프로세스를 설명합니다. 먼저 데이터를 분석한 다음 통찰력을 살펴보고 특정 기능에 베팅하고 마지막으로 필요한 것이 실현되었다고 믿습니다. 전체 DIBB 개념은 최대의 수익성 있는 변화를 만들기 위해 확인해야 하는 데이터 기반 예측의 주기입니다.

중요 사항

분석할 사용자의 피드백이 항상 긍정적인 제품 리뷰로 만족스러운 것은 아닙니다. 때때로 당신은 부정적인 리뷰와 의견을 다룰 것입니다. 하지만 세상이 서 있는 모든 것을 저주하기 전에 - 기억하세요. 당신이 여기를 지배합니다. 모든 것은 특정 상황에서 어떻게 행동하느냐에 달려 있습니다. 가장 충성도가 높은 고객과의 관계는 종종 나쁜 App Store 리뷰로 시작된다는 것을 기억하십시오.

부정적인 고객 리뷰 작업에 관심이 있으십니까? "사용자 피드백으로 작업하는 방법"에 대한 기사 곧 출시될 예정입니다/ 계속 업데이트됩니다!

MVP에서 MLP로.

MVP에서 MLP로

Wikipedia에서도 Agile MVP의 주요 목표는 추가 제품 개발에 대한 피드백을 제공하는 것이라고 말합니다. 따라서 일단 가지고 있으면 리소스와 관점을 고려하여 가장 필요한 기술 업데이트를 제공하십시오. 분석, 비판적 사고 능력은 여기에서 도움이 되는 요소입니다. 그러나 위험에 처한 것이 더 있습니다. 또한 공감 요소를 켜야 합니다. 사용자가 원하는 변경 사항을 구현하여 사용자의 말을 들을 수 있음을 보여 주는 것에 주의를 기울여야 합니다. 기능 추가를 시작하기 전에 잠시 생각해 보십시오. 우리는 항상 기존 시장에 우리의 제품을 채택합니다 . 그래서 당신 의 제품을 채택하지 않겠습니까?

Ivan Dyshuk & Elina Bessarabova 작성