質問者さん
スタートアップで1人PMをしています。
ジュニア的な仕事（企画を具体的な要件や仕様としてまとめる）から、シニア的な仕事（事業成長のためのあれこれ）までやる必要があるのですが、どうしてもジュニア・ミドル的な仕事に時間を奪われ、中長期的な視点での検討に時間を割くことができずにいます。
目の前のことしか見えておらず、このままではビルドトラップな状況に陥ってしまうのではという懸念があるものの、稼働時間を増やす以外に現状を打開する方法が思いつかないです。
akiさんならどのように対応されますか？（もっと働け！というご意見も受け入れます）
10月15日
Akiさん
近しい話をNewbeeのインタビューでしているのでそちらもぜひ見てください。
https://youtu.be/NhAz3a4Hexo?si=SKyI08ARhzpxRzXJ
で、それを見ていただいた上で追加のアドバイスなんですが、「逆じゃない？」って疑ってみてください。考える時間を確保していないから時間が足りないのでは？ひとまずスケジュール上だけでも考える時間をブロックしましょう。
あとは例えば仕事を棚卸してみるとか、自分がいなくても回る仕組みをつくるとか、日々の仕事に中長期の視点を組み込むとか。「もっと働け」は言いませんよ、今どれぐらい働いているか知らないので。
Akiさんに 質問してみましょう！
Aki
アイダホバーガーがハワイからアイダホに帰還することを望む人のアカウントです。発言内容は個人の見解であり所属組織を代表するものではありません。
何でもどうぞ。私のツイートのあの感じで回答します。難しいことははぐらかす癖があります。 非公開質問でプロダクト関連の相談も受け付けています。（もちろん公開でもいいんですが、非公開のほうがお互いいろいろ気にせず発言できると思うので。）
Tips質問回答方針
Tipsがあるものから優先的に、且つなるべく文字数多めで回答します。なくても回答します。 回答が役に立ったと思ったら、よろしければTips付きでその旨教えていただけるとその後のやる気に繋がります。
Tips報酬金額を選択する
(Tips質問者は回答全文をメール受領できます)
¥0(無料質問)
関連する質問
¥500
10月21日
続き質問
追加の質問です。
うちの組織では「エンジニアは開発に集中、デザイナーはデザインに集中」という前提があり、それ以外の業務をすべてPMが担う形になっています。
リリースは1〜2週間に1度のペースで、常に仕様書を先回りで準備しておかないと開発の手が止まってしまう状況です。
セールス側も「毎回リリースがある」ことを前提に顧客コミュニケーションをしており、開発サイクルを止めづらい空気があります。
質問1
軸が定まりきっていないことは自覚しており、まずそこを明確にすることに時間を使うべきだと理解しました。
ただ、そのためにいったん開発を止める（＝リリースを止める）ことは現実的でしょうか？
もし止めるとしたら、エンジニアだけでなくセールスやマーケにも説明が必要になりますが、「軸を定めることの重要性」をどう伝えれば理解してもらえるでしょうか？
質問2
「他の人を巻き込む力が必要」という点もまさにだと感じています。
とはいえ社内では「PMがやって然るべき」と思われている業務が多く、他の人に振ることが難しいのが現状です。
上司もPdM出身ではないため、PMの仕事範囲を誤解している節があります。
こうした状況で、巻き込みや役割の再設計を進めるにはどんなアプローチが現実的でしょうか？
Akiさんが
回答したTips質問
¥500
01月29日
先日、採用について面接について下記のようなポストされているのを拝見しました。
> 「あなたは何を大切にしどのような考え方をするのか」「あなたはどのように振る舞うのか」「あなたはどの程度の経験があるのか」しか聞いていないよ。ただ深く聞くだけ。
私は去年事業責任者になり、採用の最終意思決定者になることが増えました。まさにAkiさんが書かれていたようなことを聞きたいと思ってはいるのですが、どのように深く聞いていくのか、わかっているようで恐らくわかっていません。そのため、実践できていません。よろしければ、Akiさんがどのようなことに気をつけて、どのような対話をされているのか、教えていただけないでしょうか。来週、面接があるので勉強と準備をして臨みたいと思っています。
¥500
12月28日
続き質問
乗っかりでいくつか質問です。
>ちなみに、「この機能便利そう」レベルで意思決定ができる組織においては仮説検証と実プロダクトリリースの境目は曖昧になります。（いわゆる、出してみて確かめるというやつです）
1. このタイプのチーム・組織である場合でも、最低限事前に確認しておいた方が良いことはあるのでしょうか？
例えば、既存データからわりと簡単に類推可能な想定ユーザー数とか、既存ユーザーからの意見など。
2. 出してみて確かめる場合、仮説検証と確認する項目に違いはあるのでしょうか？
事前の場合、定性でしか取れなかったデータが定量でも分析可能になるようなイメージはあるのですが、具体的なケースが描けていないからか考えがはっきりしません。
3. 事前に仮説検証する場合と、出してから考える場合のどちらが好みですか？
¥500
10月21日
続き質問
追加の質問です。
うちの組織では「エンジニアは開発に集中、デザイナーはデザインに集中」という前提があり、それ以外の業務をすべてPMが担う形になっています。
リリースは1〜2週間に1度のペースで、常に仕様書を先回りで準備しておかないと開発の手が止まってしまう状況です。
セールス側も「毎回リリースがある」ことを前提に顧客コミュニケーションをしており、開発サイクルを止めづらい空気があります。
質問1
軸が定まりきっていないことは自覚しており、まずそこを明確にすることに時間を使うべきだと理解しました。
ただ、そのためにいったん開発を止める（＝リリースを止める）ことは現実的でしょうか？
もし止めるとしたら、エンジニアだけでなくセールスやマーケにも説明が必要になりますが、「軸を定めることの重要性」をどう伝えれば理解してもらえるでしょうか？
質問2
「他の人を巻き込む力が必要」という点もまさにだと感じています。
とはいえ社内では「PMがやって然るべき」と思われている業務が多く、他の人に振ることが難しいのが現状です。
上司もPdM出身ではないため、PMの仕事範囲を誤解している節があります。
こうした状況で、巻き込みや役割の再設計を進めるにはどんなアプローチが現実的でしょうか？
Akiさんが
最近答えた質問
02月02日
最近気になっているもの、はまっていることはありますか？
02月02日
仕事の家庭をどう両立してこられたのか教えてほしいです。
¥500
01月29日
先日、採用について面接について下記のようなポストされているのを拝見しました。
> 「あなたは何を大切にしどのような考え方をするのか」「あなたはどのように振る舞うのか」「あなたはどの程度の経験があるのか」しか聞いていないよ。ただ深く聞くだけ。
私は去年事業責任者になり、採用の最終意思決定者になることが増えました。まさにAkiさんが書かれていたようなことを聞きたいと思ってはいるのですが、どのように深く聞いていくのか、わかっているようで恐らくわかっていません。そのため、実践できていません。よろしければ、Akiさんがどのようなことに気をつけて、どのような対話をされているのか、教えていただけないでしょうか。来週、面接があるので勉強と準備をして臨みたいと思っています。