乗っかりでいくつか質問です。 >ちなみに、「この機能便利そう」レベルで意思決定ができる組織においては仮説検証と実プロダクトリリースの境目は曖昧になります。（いわゆる、出してみて確かめるというやつです） 1. このタイプのチーム・組織である場合でも、最低限事前に確認しておいた方が良いことはあるのでしょうか？ 例えば、既存データからわりと簡単に類推可能な想定ユーザー数とか、既存ユーザーからの意見など。 2. 出してみて確かめる場合、仮説検証と確認する項目に違いはあるのでしょうか？ 事前の場合、定性でしか取れなかったデータが定量でも分析可能になるようなイメージはあるのですが、具体的なケースが描けていないからか考えがはっきりしません。 3. 事前に仮説検証する場合と、出してから考える場合のどちらが好みですか？

追加の質問です。 うちの組織では「エンジニアは開発に集中、デザイナーはデザインに集中」という前提があり、それ以外の業務をすべてPMが担う形になっています。 リリースは1〜2週間に1度のペースで、常に仕様書を先回りで準備しておかないと開発の手が止まってしまう状況です。 セールス側も「毎回リリースがある」ことを前提に顧客コミュニケーションをしており、開発サイクルを止めづらい空気があります。 質問1 軸が定まりきっていないことは自覚しており、まずそこを明確にすることに時間を使うべきだと理解しました。 ただ、そのためにいったん開発を止める（＝リリースを止める）ことは現実的でしょうか？ もし止めるとしたら、エンジニアだけでなくセールスやマーケにも説明が必要になりますが、「軸を定めることの重要性」をどう伝えれば理解してもらえるでしょうか？ 質問2 「他の人を巻き込む力が必要」という点もまさにだと感じています。 とはいえ社内では「PMがやって然るべき」と思われている業務が多く、他の人に振ることが難しいのが現状です。 上司もPdM出身ではないため、PMの仕事範囲を誤解している節があります。 こうした状況で、巻き込みや役割の再設計を進めるにはどんなアプローチが現実的でしょうか？

こんにちは。いつも楽しく読ませていただいています。 ドキュメントと会議について質問させていただきたいです。 スタートアップで1人PMを行っていますが、MTGが増えがちになります。 特にUIデザイン開始後の会議が多くなります。仕様の合意にあたって営業やエンジニアにとってやはりUIデザインがあったほうがわかりやすく、フィードバックと修正が繰り返されるからです。 会議の頻繁な調整はコストになっているのと、何より会議が開かれるまでが待ちになってしまう点を課題に感じています。 テキストコミュニケーションと会議の使い分け、はどのように考えていらっしゃいますか？

ここ数年、KPIというキーワードはよく聞くようになりましたが、セットであるはずのKGIをあまり目にしなくなりました。 これはKGIが、「OKR」や「パーパス」に置き換えられたからなのでしょうか？ Akiさんのお考えを聞かせていただけると幸いです。

乗っかりでいくつか質問です。 >ちなみに、「この機能便利そう」レベルで意思決定ができる組織においては仮説検証と実プロダクトリリースの境目は曖昧になります。（いわゆる、出してみて確かめるというやつです） 1. このタイプのチーム・組織である場合でも、最低限事前に確認しておいた方が良いことはあるのでしょうか？ 例えば、既存データからわりと簡単に類推可能な想定ユーザー数とか、既存ユーザーからの意見など。 2. 出してみて確かめる場合、仮説検証と確認する項目に違いはあるのでしょうか？ 事前の場合、定性でしか取れなかったデータが定量でも分析可能になるようなイメージはあるのですが、具体的なケースが描けていないからか考えがはっきりしません。 3. 事前に仮説検証する場合と、出してから考える場合のどちらが好みですか？

仮説検証って具体的には何をすることなんでしょうか？ 煽る意図ではなく、かこにちゃんと仮設検証する環境に身を置いたことがなく、本当に何をすべきかわからないのです。