より価値を届けていくためにどのようにプロダクトマネジメントをすればよいのか？をまとめてみました。
プロダクトマネジメントプロセス概要
より価値を届けていくためにどのようにプロダクトマネジメントをすればよいのか？をまとめてみました。
BtoBプロダクトをシンプルに保つ「名前をつけない」UXライティング｜hikaru-takase /Loglass
🐳この記事は「ログラスサマーアドベントカレンダー2023」の29日目の記事です。明日は一人目のマーケ、盛川君です！ こんにちは、ログラスでデザインマネージャーをしている高瀬です。 この記事では、名前をつけないUXライティングのアプローチについて考察し、なぜ名前をつけない決断が必要なのかを記載していきたいと思います。 プロダクトが複雑になる問題昨今のデジタルプロダクトは時間の経過とともに成長していき、どんどん便利な機能がリリースされていきます。はじめはシンプルで使いやすかったけど気がつけば複雑になっていき「使いにくい…」となることも珍しくありません。 私が所属しているログラスは「BtoB」 で「経営管理」という領域のプロダクトを提供しているため、専門用語や複雑な業務フローを扱うことがよくあります。 例えば経営管理の業務ワードを軽くピックアップするとこんな感じのものがいくつも出てきます。 予
ChatGPTで業務フローが自動的に書けた｜Yuji Inagaki
こんにちは。ユアマイスターでプロダクトマネージャーをしています、稲垣といいます。 最近、業務でChatGPTを使いまくっているのですが、ちょっと個人的に感動する使い方を見つけたので紹介します（既に知ってるぞ！という方、すいません）。 プロダクト開発において、業務フローって必要になること多いですよね。でも書くの大変。Draw.ioとかFigmaとか便利なツールも出てるけど、それでも大変。 さあ、下記のようにプロンプトを書いてみましょう。 一般的な受注業務の業務フロー図を作りたいです。Mermaid Markdown形式で出力してください。 # 制約条件 - 「・」「?」は使用しないでください ChatGPTの出力結果のこれをコピーして、 Notionに貼りましょう（「コードブロック」を選択してください）。 「コード」を選ぶこの領域にペーストするすると・・・。 うおおおおお。 業務フローが自動
なぜ雑談が重要か - stmn tech blog
これはなに？ こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 コミュニケーションには会議体やテキストベースなど様々な手段があります。 その中で雑談がなぜ重要であるかについて、私の考えを記したものです。 大事な前提 〜目的と手段の関係〜 人々の活動には目的があります。そして目的を満たすための手段を追い求めています（ここでいう手段とはシステムであったり情報であったり、「目的の役に立つもの」と考えてください）。 目的と手段の関係性を次の図で表現します。目的と手段それぞれの円の重なりが大きいほど、目的に対して相応しい手段である、ということをここでは表します。 この図を使った例を出します。 今の時期、だんだん暑くなってきましたね。「暑さを解消したい」という目的に対して、「扇風機を点ける」「エアコンを点ける」「かき氷を食べる」「南極に送り込む」
主観と客観を切り替える鍛錬｜Miwa Kuramitsu
突然ですが、ここに一つのプロダクトがあるとします。 そのプロダクトを見つめる視線には様々な種類があります。 そのプロダクトを利用しているユーザーの視点、利用していないが存在は知っているという人の視点、それをつくるデザイナーの視点、プロダクトを運営している会社経営者の視点… もしあなたがデザイナーであれば、デザイナーの視点だけが唯一自分で体感できる「主観」で、それ以外はすべて「客観」となります。 主観と客観のスイッチング プロダクトデザイナーはユーザーの期待通りに正しく動くしくみを設計し、「このプロダクトを利用した時に、ユーザーの生活はどう変化していくのだろうか？」と問いを立てながらアウトプットを評価していきます。 自らの考える理想像をデザインしながら、一方でそれに触れるユーザーの様子を想像する…プロダクトデザイナーは主観と客観を電気のスイッチのように瞬時に切り替えることに長けた人が多いイメ
スクラムマスターは「スクラムチーム改善」のプロダクトオーナー - maru source
今年からスクラムマスター(SM)を始めた。1ヶ月ほどたったので、「やってみて気づいたこと」や「具体的に取り組んだこと」を残しておく。 ただし、僕はスクラムマスター研修は受けてない野良SM（？）である。なので、間違いとか超基本すぎることなどがあるかもしれない。 やってみて気づいたこと スクラムマスターの仕事は「スクラムチームを改善する」ことに尽きると思った。その観点で次の事が特に大事だと気づいた。 「スクラムチームの改善」は「プロダクトの改善」と同じ スクラムチームを一種のプロダクトだと考えて、課題見つける→PBIにする→解決する SMはスクラムチームの改善において、いわゆるプロダクトオーナー的な役割である 司会・議事録係・ミーティング調整役ではない まずはとにかく透明性をあげる プロダクトオーナー(PO)、BizDev、エンジニア、デザイナー、ドメインエキスパート、SM、etcのやってるこ
GoogleのProduct Managerになりました｜natsumi.kondo
要約: 日本で文系営業職からキャリアをスタートし、アメリカに渡ったのちにGoogleのエンジニア系職種であるProduct Managerになった人の話です。 このnoteは、へぇそんなキャリアもあるんだ〜という一つの参考に、また、現状打破のために何かしたいけど何をすればいいのと思っている方へ、なにかシェアできたらと思いいろいろと書きました。長いです。 まずかんたんに私の経歴を。 慶應義塾大学環境情報学部卒業 →リクルートキャリアで法人向け転職支援事業の営業 (n年) →Google日本法人で大手法人向け広告営業 (4年) →Google日本法人で大手法人向け広告プロダクトスペシャリスト (2年) →Google米国本社でGlobal Product Lead (4年) 福島県で高校時代までを過ごし、留学経験もなく、リクルートキャリアで営業として楽しく働いていましたが、頑張っていたら運よく
多機能すぎるプロダクトはなぜダメなのかをプロダクトマネージャーが考えてみた｜Shin
プロダクトがPMF（プロダクト・マーケット・フィット）し、成長してくるとつい機能を盛り込みたくなるのが人間の性というもの。しかしプロダクトの品質を任されているプロダクトマネージャーにとってこれは大敵です。 つい先日こんなツイートをしたところ、色々な方からご意見をいただきました。賛否両論いろいろありつつ、そもそも「機能」の認識が違っていそうだなと思ったので、今回より具体的に解説してみます。 多くの人が誤解しているのは「プロダクトは多機能であるほど良い」と思っていること。これは実は逆で、多機能であるほどユーザーは学習コストが高いため使いにくくなる。たとえ少ない機能でも組み合わせで「え、実はこんなことできるの？」というプロダクトが圧倒的に強い💪 NotionしかりSlackしかり。 — Shin Sasaki (@shin_sasaki19) February 17, 2022 多機能すぎるプ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フロントエンド開発のための Figma
