2022/04/12開催の地味PM meetupの登壇資料です。 https://mercari.connpass.com/event/243373/
![プロダクトのための地味な動き - 地味PM meetup](https://cdn-ak-scissors.b.st-hatena.com/image/square/ae3c824dd31a31faf403ac6956fd9156c96e5536/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F1177613015cb4b88af021266bb3aa70a%2Fslide_0.jpg%3F21068784)
「シューマイ」は、“世界をテックリードする日本人エンジニアを多く輩出する”をビジョンに、 日本のエンジニアのレベルの底上げを目指すコミュニティです。今回は、普段CTOやリードエンジニアクラスとして活躍している方々が、SaaSについて熱く語りました。ここで登壇したのはascend株式会社の丹羽氏。フルサイクルエンジニアとしての働き方について話しました。 ビジョンは運送業界の価値最大化 丹羽健氏(以下、丹羽):ascend株式会社の丹羽と申します。本日は「Vertical SaaS開発におけるフルサイクルエンジニアという向き合い方」と題してお話しします。 最初に自己紹介をします。丹羽健と申します。ascend株式会社のCTOを務めています。ascendをご存じない方も多いと思いますが、設立1年半ほどでシード期を超えるか超えないかくらいのスタートアップの会社です。本日は、エンジニアのキャリア形成
このnoteについて2020年1月、株式会社SmartHRに転職しました(とても幸せです)。 転職活動にあたり様々な情報を集めましたが、「そういえば、あんまり経験談って見ないな?」と感じていたため、あくまでn=1として誰かの参考になればと思い、転職活動を始めた経緯から入社2ヵ月までを記録に残します。 Titleの通りPdMとしての職務期間は比較的短く、どの程度かはこのすぐ後にご紹介します。 活動期間は2019年7月末〜2019年11月初旬。約3.5ヵ月での出来事です。 活動開始時の経歴「参考になるもならないも、あなた何者?」 はい。おっしゃるとおりです。 PdMは掛け算スキル職種なので、背景は重要ですよね。まずは簡単に、転職活動時までの経験内容を挙げます。なお、経験社数は2社(ブライダル6年 → 自社WEBサービス5年半)ですが、特にPdMに関連するものとして2社目に絞ります。 ・経験業務
プロダクトマネージャーを目指す人にとって指針となるようなマニフェストを、日本語で作りたいと思っている。 僕自身も修行中の身だが、僕がプロダクトマネジメントを行う際に気をつけていることをマニフェスト風にざっと書き出してみた。 まだ粗々なのでここからブラッシュアップして行きたい。 私たちは、ユーザーに愛されるプロダクトによって利益を生み出すことに情熱を持っています 私たちは、プロダクトの力で難しい問題を解決できると信じています 私たちは、問題の定義が最初の仕事であることを知っています。 私たちは、ターゲットとその課題を定義すること無しに良いプロダクトを作れないことを知っています 私たちは、要件定義はゴールではなく出発点であることを知っています 実現可能性のあるアイデアを選定するのは私たちの仕事です。 私たちは、自分の考察に盲点があることを知っています。 私たちは、多数決ではイノベーションが生ま
自分の方針としてもう一つ。値下げに応じないというのがある。 製品を売っていれば一度はかならず顧客から「料金交渉をお願いしたい」という名の値下げ交渉をされることがあるだろう。その場合は値下げは一切しないことを伝える。 もし値下げを粘られた場合は取引をしないほうが良い。また、値下げを一度でもしてしまうと、交渉さえすれば値下げをしてくれる会社と勝手に認識されてしまう。 顧客ごとの料金表は提供しないほうが良い。なぜなら世間は狭い。あの会社にはこの料金でだしているのに、なんてめんどくさい話も出てくる。 そのため、自分はすべての顧客に同一な料金表の提示。そして大量購入による割引。これ以上のことは一切やらない。顧客は相談はできず選択しかできない。 自分の会社の料金体系に合わない顧客とは取引をしないという方針を取っている。無理に値引きするのはその製品の寿命を縮めてしまう上に、会社の寿命も縮めてしまうと思う
Inspired: 顧客の心を捉える製品の創り方を読み返していて、「第7章: プロダクトマネージャーを管理する」の一節 エンジニアリング部門というのは、基本的に、正しい製品を作ることではなく、製品を正しく作ることに専念することになっているからだ。 というところが引っかかったので、思うところを書いてみる。ちなみに「第5章: プロダクトマネジメントとエンジニアリング(実装)」にも「正しい製品を作るのか、それとも、製品を正しく作るのか」というタイトルの章がある。 エンジニアは製品を正しく作る エンジニアは製品をリリースする責任があるので、不確定要素を減らして正しいスケジュールでリリースすることにモチベーションがある。このために、開発が進むほどにエンジニアは保守的になっていく。企画段階では和気藹々とブレストしてアイデアを出していても、最後のリリース前にはしぶい顔で実装を拒んだりする。 エンジニアと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く