小さなチームで最速でアウトプットをするために実践してたこと

こんにちは。スマート書記というBtoB SasSを開発しているエピックベースで取締役 & プロダクト全般を担当してます、@marioです。

10月にクローズドβ版をリリース。セールスメンバーの頑張りで使ってくれる顧客が増えていき、ありがたいことに要望もたくさんいただくようになりました。少ないメンバーでも、顧客へ価値提供できるように意識・実践を行ってきました。実際に顧客の皆さまから「改善がどんどんされる」「期待できる」などの声もいただけるようになりました。

ただ早ければいいってものではない

• 的はずれな改善をしたとしても、顧客は「改善がどんどんされる」とは思わない

• きちんと顧客の課題を解決し、価値が提供できるものを素早く提供する必要がある

この記事ではただ早く作る、ではなく一定ちゃんと価値提供をできるためにやってきたことを書いていきたいと思います。当たり前のことも多いですが、誰かの参考になると嬉しいです。

受ける要望から本当の課題を理解する

• 〜機能が欲しい、と言った要望を受けてそのまま何も考えず実装すると、いらなかった機能を作ってしまったり、ソリューションがあってなくて失敗することがある。手戻りが発生することも。

• 「なぜ」「どういうフローや背景があってその要望が出たのか」など明確にし、理解をすること

→　適切に課題を理解し、適切なソリューションを提供することで無駄な打ち手を減らす

あれもこれも一緒にやろうとしない

• 議論をしていると、「このケースでは十分だけど、こういうケースの場合はこれがいい」などいろんな意見が出てくる

• それを全部吸い上げようとすると、仕様がどんどん複雑に、膨大になっていく

• 結局、何のためにやっているんだっけ？ってなりがち

→ どうやったら仕様を削れるか？を意識し、シンプルな仕様にできるよう意識する

議論の際はたたき台のモックを作る

• 何もない状態で議論を始めると、メンバーの頭の中で考えていることがバラバラで論点がずれることがある

• 論点を合わせるところから始めると、時間がかかってしまう

→　目線を合わせられるようにイメージができるモックのたたき台を用意し、本質の議論をできるようにする

できるだけ、車輪の再発明をしない

• 世の中に参考になるものが山ほどある場合が多い

• 0から考えてしまうと時間がもったいない。先人の知恵を生かした方がいい

• 必要なところだけ独自性を出して、それ以外はできるだけ汎用的に

→ 取り入れられるところは取り入れることで、品質を保ってスピードを上げることができる

選択と集中

• 要望が来ていると「あれもやりたい」「これもやりたい」となる

• 「みんな」からきているように思えてしまうけど、データを分析すると「みんな」ではないこともあるので、データもちゃんと見よう

• 何かをやることで何かが遅れることを忘れずに

→ 目先だけでなく、中長期的にトレードオフを意識してやることを決める

まとめ

以上がクローズドβ版リリースから、今まで意識して実践してきたことでした！どうしても要望が多かったり、課題が多かったりすると、忘れがちですが意識する指針を持っておくと立ち戻れるので自分が大事にすることを明文化しておくのは大事ですね。

• ただ早ければいいってものではない

• 受ける要望から本当の課題を理解する

• あれもこれも一緒にやろうとしない

• 議論の際はたたき台のモックを作る

• できるだけ、車輪の再発明をしない

• 選択と集中

今回書いたのは、「作る」ときに意識していたことですが、今度は「届ける」ときに意識してきたことも記事に書こうと思います！