トラッキングとかが制限されてきて もしかしたら良いプロダクトを作るのに 取り敢えずリリースしてから改善しますではなくて ちゃんと生み出すプロセスをちゃんとやれって話かな

休むことでなんかスッキリした 定期的に休もう

方針立てるのって簡単 実行するほうが100倍むずい

事業向けの説明ではビジネスサイドを強調して ユーザ向けにはユーザファーストでやりたいことをやる姿勢 ほんとは合わせる必要があるんだろうけど

リリース前にどこか触ってもらって その外したくない指標なら体験が絶対に達成できるのかを考える もしくはユーザテストする

資料の体裁が整ってないと 中身を読んでもらえないことがあるようだ 気をつけよう

コストをかけるか 品質を取るか どっちも取れれば良いのに

だいたい資料ができたあと 詰めるのが後回しになってしまう ここをやりきらないと

発散型で出した後に収束させるのが苦手 ちゃんとまとまらないと気持ち悪いと思ってしまうが 他の企画とか見るとそこまでちゃんとまとまってるわけではなくて それっぽく見えればいいんだなーって

なんか図示が必要になったとき その説明って複雑になりすぎてないかを疑った方が良い

気を抜くとビジネス課題を解決しようとしていて 無理やりユーザ価値に近づけて進めている気がする やっぱりユーザ課題にちゃんとフォーカスしてやっていかないと ペイン解消もKPIにヒットしなくても進めるべきだな

何か買い物をするときにお試しをする これで自分の生活での使用イメージがつけば それを選択する後押しになる

ある程度時間をおいて自分の職種の領域を学び直すのはいいね 情報が更新されていたり 初心を思い出させてくれたり

進めば何か見えてくるので まずは一歩ずつ進んでいくこと

キャリアにおいて何かしら強みを持ちたい

政治にたけてる人は使うことが最も望ましい

ユーザに何もさせずに利益を与える まずはそこを目指すことにしよう

何かを継続するのはまあできるが それで積み上げができるかと言うとそれはまた違う話 目標持って継続しないと積み上がり方が緩くなってしまうみたい ちゅういしよう

プロダクトで割るかKPIで割るか 関係部署で割るか 多分正解はないから 流動性高く動かせるようにしておいたほうが良い

アーキテクチャにこだわりたいが 目的に合ってるかどうかとか 結局その作りもいつか負債になるかもしれないと思うと 何も決められなくなる 今最善の選択を取り運用をしっかり組むことが必要そう

後に来る施策と開発領域が被った時 後の施策はどの程度前の施策を考慮するべきか 後の施策が前の施策を前提に作った時 前の施策は負けてもそのままで後続をやるべきと思ったがそうでもないのか？ 前の案件が勝つまで後ろの案件ができないことになってしまう…

新規機能や画面をリリースする場合 ABテストではなく全展開リリースとなる 効果を精緻に見ることができないので一体諦める必要があるが その時の効果の見積もりと結果はどうやって折り合いをつけるのだろう

ドキュメント上から主観的な表現を全て削除 残すとしてもエビデンスかエクスキューズと一緒に

ホワイトボードでもノートでも良いから完成形を早めに共有することで 余計な議論を減らすことができそう

なんか詰まったら 無理やり追加したり あんまり自信がないところを一旦切ってみて うまくいくかを考える そのあと直すようにその部分を追加すると良いことあるかも

スタート管理って難しい やっぱりちゃんと理解してないと予期せぬエラーが起きる 治して早くリリースしたい

導線を整備するだけだと思ったような効果はあげられない いや、意欲の低いユーザ向けに限定されるか これは金言として心に刻もう

モニタリングでKPIが大きく動いた場合に その原因がブラックボックスのままにしていてはいけなくて 必ず原因を突き止めないといけない 再現性を持たないといけない

ドキュメントベースで仕事することで 途中から始めた人でもそのまま引き継げるようにするって出来たら良いのでは？ ツールが多岐に渡り一元化できない現状は人間の柔軟性に依存している気がする

課題の方向性から任されることがあった場合 しらみつぶしに全ての課題を拾いにいくのも良いが 課題を解決することを考えると 最終的にプロダクトでコントロール可能な指標を改善する施策に落ち着くので その指標を先に考え その改善幅がどれくらいあるかを確…