フィードバックから考える、プロダクト改善サイクル

10月の中旬あたりから開発の業務委託で仕事探しを開始して、ようやく案件が決まった。一生決まらないんじゃないかとドキドキしてたんだけれど。

せっかく独立しているわけなので、業務委託ばかりではなく、少しずつ自分のサービスも増やしていきたい。

これまでだって、散々プロトタイプ作ってきたけれどうまくいかなかったのは

とかでも書いてきた。

うまくいかなかった理由には色々あるけれど、「フィードバックがない」というのが一番どうしようもない状態だったと感じている。反応がなければ、どうしていいのか判断できないし、改善方法が導けない。

個別のプロダクトのコンセプトや機能云々を決める前に、フィードバックをもらいやすい領域で始めるってのが、もしかしたらコツなのかなと最近感じ始めている(比較的レッドオーシャンであろうことは承知の上で)。

フィードバック内容が良かろうが悪かろうが、とりあえず反応があることが大事。

そのようにサービスの戦略を制約すると、それなりにアクティブなアプリやWebサービスのジャンルで始めるのが良いということになる。

その中で自分が興味を持てる領域をできるだけたくさん見つけて、プロトタイプを投下していくのが良いのかもしれない。

それと、フィードバックの量と合わせて、フィードバック頻度も大事だと考えている。

なので、できるだけ手早くリリースできないといけない。

この意味だと、これまでのプロトタイプはちょっと作り込みすぎてた。もっと機能を絞って、もっとアーキテクチャもシンプルにしないとダメだなと反省している。

やってみて分かったけれど、プロトタイプでバックエンドとフロントエンドを切り離してAPI作って、なおかつ楽観的UIを実現しようとすると相当な実装や運用管理コストが必要で、やりすぎたかなと感じている。

今までに作ってきたサービスから考えて、作ろうとしているサービス程度ならフルスタック可能なウェブフレームワークで作るので十分。例えばNext.js + Vercel + BaaSのような構成でバンバン作って出すみたいなのじゃないと、売れるものまでサービスを持っていけないのではないだろうか。

反応が希薄なのは潔く捨て去る。ひたすらアイデア出して作ってリリース。反応出るまでこれを繰り返す。このイテレーションが素早くできないとダメじゃないかと。

バックエンドのインフラだって簡単とはいっても、かなりあれこれ調整することになるので、売れるのかわからない状態でそれをするのは心理的にちょっとしんどい。個人的に、作る時間が長すぎてリリースされない状態が続きすぎるとモチベが維持できないし。

と、こんなことを考えながらも新しい仕事準備に忙殺されているので、しばらくは個人開発はお預け。アイデアくらいは考え続けるけれど。