プロダクトインタビューをしよう

プロダクト開発は、ゴールが見えない中で、長い時間をかけてとにかく前をめざして歩いていくようなものです。ユーザーに一度も見せないままリリースしてしまうと、ユーザーからの期待と違っていたときに修正するコストが大きくなってしまいます。また、一度信頼を失ったユーザーは二度とつかってくれないかもしれません。

このことを防ぐために、開発と並行してユーザーにインタビューをします。こうすれば、たとえゴールへの道を外れてしまってもその都度修正することができ、ゴールにはやくたどり着くことができます。

では、プロダクトインタビューではなにをするのでしょうか。基本的には新しい機能を使ってもらってフィードバックをもらいます。もらったフィードバックをもとに新しい計画を立てて、改善に取り組みます。この繰り返しをひたすら続けます。

ゴールをめざしながらインタビューを繰り返し、ユーザーストーリーマップを見直す。必要に応じてリーンキャンバスやフックモデル、グロースサイクルといったドキュメントを修正する。これによって、最短距離でプロダクトを完成させることができるのです。

まとめ

プロダクトインタビューは、構築中のプロダクトを用いて行うインタビューです。フィードバックをもらう目的で行います。リリースまで、またリリース後も継続的に実施します。

やってみよう

プロダクトをつくりはじめたら、週に1人以上の方を相手にプロダクトインタビューを実施しましょう。インタビューを終えたら結果をまとめ、ユーザーストーリーマップやリーンキャンバスなどを更新しましょう。

関連記事

ユーザーインタビューについては、「ユーザーインタビューのやり方」で詳しく解説しています。あわせてご覧ください。

例:tsukuri

tsukuriをつくりはじめたその週から、毎週プロダクトインタビューを行いました。毎週インタビューをすると決めたので、つまり毎週新しい機能をユーザーに届けなければいけません。これがいいプレッシャーになりました。

ここまでで課題や解決策、MVPの仮説検証を行ってきたので、根本的な手戻りはありませんでした。画面の構成やページ遷移の導線などについてもポジティブな意見をもらえました。

ただ、文字の大きさや色といったユーザー体験の部分で、使いづらいといったネガティブな意見をたくさんもらいました。このため、機能を追加しつつも文字を大きくしたり色を改善したほか、ユーザービリティに関するガイドラインもつくることで、ユーザー体験を高めました。

インタビューを行うことでの副次効果として、インタビュー以外のときでもユーザーの方がフォームなどをとおして積極的にフィードバックをくれるようになりました。また、SNSで広めてくれたりもしました。こうして、つくりはじめて3ヶ月でtsukuriはひとまずのリリースを無事迎えることができました。

著者
Hiroki Zenigami

テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。

スポンサーリンク

ブログをはじめよう

技術ブログの始め方を、たくさんの画像で分かりやすく解説しました。これまでブログをやったことがない人でも、エンジニアにとって重要なブログを今日から始められます。

ブログをはじめる