Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file added .DS_Store
Binary file not shown.
63 changes: 63 additions & 0 deletions Team/PM.md
Original file line number Diff line number Diff line change
@@ -1 +1,64 @@
# COMMUNICATION

# Extra effort to align assumption 前提のずれをなくすために努力しよう

As a best practice, we should have a kickoff meeting and doc to clarify why and iron out the assumptions. 

why? this take more time initially but help us work more efficiently and avoid us going down the wrong path


# Direct communication and positive intent listening 直接的に伝え、聞く側は「いい意味で」を無意識に補間しよう

- Avoid using advanced words, if you have to, explain them in simpler English
- Ask for clarification if you dont understand what someones trying to say
- Provide clear points in written form of what you just discussed in a call or meeting

# Explicity show respect

Fail: 
Jan. shares the negative feedback on the new iteration Feb. created for Popup feature, on a command tone, and Feb. feels demotivated and scared to share the design thinking and defend the solution.

Success: 
Jan. learned from the failure in communication and share the negative feedback with empathy by explicitly tell there is some negative comments come out, plusing the logics behind. Feb. is encouraged by the new relaxing communication and have better ways to learn and discuss.

# Logic over experience 経験を言語化して伝えよう

Always backup with you experiences with the context and rationale
Encourage to discuss or even debate
Try to rationalize the logic from scratch


# WORK PROCESS

# Distributed-autonomy and self-drive 自律分散・自走主義

# Ownership over management
- Your craftsmanship makes the difference: Even if you are an associate, your role is not a step in an assembly line. You are an independent contributor with support from your peers. Your work will be the finality that our customers experience, and you should be proud of your deliverables.

- Be the coach, not the general: If you are a manager, instead of taking the all things on, if there is someone who is very motivated to work on something, it’s worth giving that person the ownership to see that work from beginning to end.

Everyone in PM/Design is a manager. We’re supposed to work as both contributor and also manager for the task of other team members.


# Ownership for product and organization 「自分が」会社・プロダクトを作っているとして行動しよう

As a best practice, everyone is an owner for the product and organization. 

1. If you see something not working. Feel free to propose change you think will make it better. This is a startup, there are no rules, if you want to do something you can always propose it.

Feel free to express your opinions so we can get diverse opinions. Even if its not in your day to day job.

why? entropy mean things will eventually be broken unless we actively maintain it

# Ask users before half-complete 作り込む前にユーザーに問おう
- Internal dogfooding whenever somethings developed
- Ship to pilot users and ask for feedback


# Codify and update guideline ガイドラインを言語化・アップデートしよう

Fail: 
Feb. just joined in and is excited to take the first task on Popup feature. But there lacks any document about how this feature was created and evolved, so the questions are raised towards Jan., the expert of this feature. And later Mar. joined the team, similar friction occurred and the communication for alignment takes efforts from both Jan. and Feb.

Success: 
Since then the design team starts to document and update the design decisions when an iteration gets ready for dev. Now our new star Apr. joins and ready to address a customer request from users. By learning the document there is good confidence on understanding the feature and who to reach out when some unclarity comes out.

# Transparency by default 公開がデフォルト。DMを避けよう

Minimize using DM in Slack
Share the progress, status, risks with teams openly
Use open documentation tools shared with teams by default
Make all the status up-to-date in Github and ADO

# Creativity for Speed 最速を実現するためにクリエイティビティ

If you are NOT fully convicted about your improvement/change, what is the fastest way to validate that with the customer? Would doing a quick user test with 5 customers be better for validation then coding a MVP?

If you are very convicted, what is the fastest way to get positive feedback from users (either in quant data or written feedback) through engineering means? Can we deploy a beta quickly to several customers? Can we sacrifice the robustness/scalability of the system to get a MVP released earlier?