유용한 피드백과 실제로 앱을 쓸 사람의 의견은 어떻게 구분할까?

AI 요약

작성자는 사업 조언을 해주는 사람과 앱을 실제로 쓸 사람을 구분하려고 합니다. 조언이 쓸모없다는 뜻은 아니며, 조언이 어떤 정보를 주는지 파악해야 한다고 봅니다. 기능을 설명하기는 쉽지만 업주가 기존 업무 방식을 바꿀 이유를 알아내기는 어렵다고 말합니다.

아이디어보다 최근의 실제 업무를 묻기

댓글에서 제안한 방법은 앱을 보여주기 전에 상대가 마지막으로 문제를 겪었던 때를 묻는 것입니다. 당시 무엇을 했는지, 시간이 오래 걸린 곳은 어디였는지, 나중에 무엇을 고쳤는지 확인합니다. 작성자는 상대가 설명을 마치기 전에 앱 기능을 끼워 넣지 않도록 주의해야 한다고 말합니다.

TradeQuote에서는 견적 하나를 준비하고 확인하는 과정까지 함께 살펴볼 계획입니다. 완성된 견적만 보여주기보다 설정부터 확인까지 진행하며, 실제 견적 업무를 맡는 사람이 현재 방식과 비교해 어디서 편리하고 어디서 기존 방식이 나은지 말하도록 하려 합니다. 아직 이 테스트를 진행하지는 않았습니다.

말보다 실제 행동을 신호로 보기

댓글에서는 실제 견적, 구체적인 가격 질문, 설정에 관한 질문처럼 상대가 자신의 업무에 앱을 대입하는 행동을 신호로 꼽습니다. 현재 쓰는 스프레드시트나 수기 절차를 보여달라는 제안도 나왔습니다. 기존 방식의 편리한 지점과 불편한 지점을 직접 보면 무엇을 바꿔야 하는지 파악하기 쉽다는 의견입니다.

한 댓글 작성자는 비공개 테스트에서 가입 수는 괜찮았지만 스스로 세션을 완료한 사용자는 거의 없었다고 말합니다. 그 경험을 바탕으로 안내 없이 두 번째 방문을 하는 행동을 가장 믿을 만한 신호로 봅니다. 다만 원글 작성자는 일주일을 고정 기준으로 삼기보다 다음 견적 업무가 생겼을 때 다시 TradeQuote를 선택하는지 확인하고 싶다고 답합니다.

실제 업무를 함께하는 테스트에도 조건이 따릅니다. 고객 정보가 포함된 실제 견적을 공유하기 부담스러울 수 있으므로, 원글 작성자는 정보를 가린 사례로 먼저 진행하는 방법을 언급합니다. 또 사용자가 앱을 한 번 써보는 데서 끝내지 않고 다음 견적에서도 다시 선택하는지 살피려 합니다.

Indie Hackers 반응

• @Tether — 실제로 마지막 견적을 어떻게 작성했는지 보여달라고 요청하면 좋겠습니다. 실제 업무를 설명하다 보면 어려웠던 지점이 자연스럽게 드러납니다.
• @Anatolii Yukhymovych — 가장 좋은 신호는 사람들이 말하는 내용보다 실제 행동인 것 같습니다. 다시 돌아오거나, 업무 흐름을 다시 시도하거나, 구체적인 기능을 요청하는 행동 말입니다. 지금까지 어떤 신호가 가장 유용했는지 궁금합니다.
  • @B Dunfee — 아는 사람들의 격려가 실제 사용으로 이어지지는 않는다는 점을 배웠습니다. 현재 업무를 설명하거나, 특정 상황을 앱이 어떻게 처리하는지 묻거나, 다음 업무 때 다시 쓰는 행동을 살펴보려 합니다. 아직 어떤 신호가 가장 중요한지는 알아가는 중이지만 "좋아 보인다"는 말보다는 더 많은 정보를 줍니다.
• @Ahmed ZNOUDA — 비공개 테스트에서 가입은 잘 됐지만 혼자서 세션을 끝낸 사람은 거의 없었습니다. "좋아 보인다"고 말한 사람과 실제로 쓴 사람도 대부분 달랐습니다. 이후로는 아무도 요청하지 않았는데 두 번째로 방문하는 행동을 신뢰합니다. 함께 처음부터 끝까지 진행하면 설정의 어려움을 찾을 수 있지만, 일주일 뒤 실제 견적에 앱을 다시 여는지 확인하면 업무에 들어맞는지 알 수 있습니다.
  • @B Dunfee — 안내 없이 돌아오는 행동은 함께 진행하는 테스트만으로 알 수 없는 점을 보여주겠습니다. 일주일을 엄격한 마감으로 정하기보다 실제로 다음 견적을 준비할 때 다시 선택하는지 보고 싶습니다.
• @Tether — 상대가 현재 견적을 스프레드시트나 노트로 처리하는 방식처럼 기존의 임시 해결책을 자세히 설명하기 시작하는 것이 신호일 수 있습니다. 친절한 사람은 기능에 반응하지만, 바꿀 가능성이 있는 사람은 자기 업무와 그로 인한 비용을 이야기합니다.
  • @B Dunfee — 아는 사람들과의 대화는 "유용해 보인다"에서 끝나는 경우가 더 많았습니다. 현재 견적을 어떻게 준비하고 무엇이 여전히 불편한지 알아야 바꿀 이유가 있는지 이해할 수 있습니다.
• @sk_learns — 호흡 앱을 실제로 쓴 사람이 광고를 세션 뒤로 옮기고 월간 요금제를 추가하라고 한 것처럼 구체적이고 소소한 의견을 줬습니다. 앱이 깔끔하다는 칭찬보다 실제 흐름에서 불편했던 순간에 대한 지적에 더 귀를 기울입니다.
  • @B Dunfee — 광고를 세션 뒤로 옮기라는 의견은 좋은 사례입니다. 새 기능을 요구한 게 아니라 방해 요소를 없애달라는 요청이었습니다. 칭찬도 고맙지만 무엇이 불편했는지도 편하게 말할 수 있어야 합니다.
• @daiwik_builds — 실제 견적을 보여주거나 가격과 설정을 묻거나 언제 써볼 수 있는지 묻는 등 먼저 행동하는 사람을 살펴보겠습니다. TradeQuote 테스트는 샘플 견적보다 이번 주에 처리해야 하는 실제 견적으로 진행하라고 제안합니다.
  • @B Dunfee — 실제로 처리해야 하는 견적을 함께 진행하면 더 많이 배울 수 있습니다. 고객 정보를 먼저 지우고 업무 자체를 살펴보는 방법도 괜찮습니다.
• @Zane Berg — 대화가 끝날 때 다음에 준비할 실제 견적을 가져와 BubbaCode로 처음부터 끝까지 진행하자고 제안해보세요. 조언만 하는 사람은 "언젠가"라고 답하겠지만, 실제 사용 가능성이 있는 사람은 견적을 보내거나 날짜를 알려줄 것입니다. 다섯 번 대화한 뒤에도 아무도 내놓지 않는다면 피드백만으로는 알 수 없는 점을 알게 됩니다.
  • @B Dunfee — 구체적인 예정 업무를 물으면 막연한 사용 의향보다 생각하기 쉽습니다. 다만 고객 정보를 공유하지 않고 시도할 방법도 마련하고 싶습니다. 실제 업무를 공유하기 망설인다고 관심이 없다고 단정할 수는 없으며, 정보를 가린 사례로 함께 진행하는 것도 좋은 첫 단계입니다.
• @Rana Muzamil — 견적 하나를 처음부터 끝까지 보여주는 테스트가 좋습니다. 도구를 쓰다 이탈하는 곳은 완성된 결과보다 설정과 확인 단계인 경우가 많습니다. 가능하다면 상대가 먼저 자기 화면으로 현재 절차를 보여주게 하세요. 지름길과 임시 해결책은 말로 설명하지 않는 경우가 많고, TradeQuote가 넘어야 할 부분이 바로 그런 지점입니다.
  • @B Dunfee — 현재 과정을 먼저 보면 도움이 됩니다. 임시 해결책을 보고 없애야 한다고 생각할 수 있지만, 실제로는 빠른 업무 처리에 꼭 필요한 방식일 수도 있습니다. 제 견적 업무 경험만으로 다른 사람의 절차까지 안다고 볼 수 없으니 공정한 비교에 도움이 되겠습니다.
• @Bullpicks — 지난 업무를 구체적으로 말하는지가 신호입니다. 실제 사용 가능성이 있는 사람은 마지막 견적과 걸린 시간, 나중에 고친 불편한 점을 대개 먼저 이야기합니다. TradeQuote 시연에서는 키보드를 넘기고 첫 견적 동안 조용히 지켜보세요. 어디서 멈추고 스프레드시트를 찾는지 보면 시연 후 말보다 더 많은 것을 알 수 있습니다.
  • @B Dunfee — 조용히 있는 게 쉽지는 않겠지만, 다음 단계를 설명하지 않고 사용자가 직접 찾는지 보고 싶습니다. 스프레드시트를 찾으면 거기서 무엇을 하려 했는지 물어보겠습니다. 앱이 마음에 들어도 소유주나 동료가 변경에 동의해야 할 수 있으니 누가 결정에 참여하는지 묻는 것도 유용합니다.

원문: Indie Hackers / 번역·요약: Trawling