From 47636bd890b1d0a26b4807d419401b416097a1de Mon Sep 17 00:00:00 2001
From: Sean Yu <sean.yu@boostdraft.com>
Date: Thu, 14 Nov 2024 18:12:46 +0900
Subject: [PATCH] Updated best practice

Examples to each behaviour guideline
---
 .DS_Store  | Bin 0 -> 6148 bytes
 Team/PM.md |  63 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 63 insertions(+)
 create mode 100644 .DS_Store

diff --git a/.DS_Store b/.DS_Store
new file mode 100644
index 0000000000000000000000000000000000000000..bdff5dea468e004f342d9b2620a93e761f40bfc9
GIT binary patch
literal 6148
zcmeHKO;6iE5S<O7*g{A-P>D;Wm3ob63iM08xF!ho&<jRzpjB#Pt5|isC{D;BisUo=
z7_R)1{vG;ecY_K^Z>Xx!jx_t$v-8IGTifd;A`y<#*F-HM^5BdOAI$>earQZD*vK+a
z=o%N4lcE9b(`YW+1^!0`c<$CIq>Roera$K|rxeiwGg<;SsZZ(WLY*dsO2FX<<`aDL
zRvUUmYqYCpKcgemD)0<sR4rs)KVbTFKzpdyr7yq*=Mpa-Fq(9T>M`|`admF5=_WZZ
z@@m-W{1T0&=JK-@Z^c{nzC~wh91Y{)s0!o32_GFQRV1^1oE+uZxYt_WRpl_w%WR+t
zd72^R>v3MDY8<LjnO2$`nE}uD{9bEgGTD0frY*PMccyJQ`LNY#%bo4F)2Z)0fBEX;
zLGNeLFV!WBgI5Iah_*G0Gq^(M?tU(!L0PEs2V%4QS)N0ufK$LJ@K_4i?~AwkSOr}j
zr+`!7$tb|z2MK2kEY=3~rvr`N0sxx`YeS!Z4Vfb?1{Q0B7=Z~x1sbZbTMS|7h)bIn
zSgZ{iItjb^5cbT%?ofn2JL*fFP9iYqTBm?h;JyM&=CH-<|K8vC|MyAm$SL3ycv1?8
zW;g1FxFx%`&fOfZwG#dv&c=DQ!8-~%dMQROFU1>hZHP<m00WD)K}2BgM?lNq8mGWN
GRp2)pUv)bG

literal 0
HcmV?d00001

diff --git a/Team/PM.md b/Team/PM.md
index 8b13789..dea1bfd 100644
--- a/Team/PM.md
+++ b/Team/PM.md
@@ -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?
+