Atlassian

Ideally you have the right market insights before you start building. However, if you have open questions, I encourage you to break down the project into smaller milestones you can ship that help you answer those questions. This way, you are continually shipping, but they are smaller in scope, but also helps you de-risk when there's a lack of clarity in market insights. 

Don't think there's a "right" ratio, but I would say 1 PM to 6-12 engineers is a good ratio. I think beyond 12 engineers, it gets a little difficult for a PM to stay on top of projects and the PM could become a bottlenect to project progress. I would also say 1 designer to 6-12 engineers is a good rule of thumb. 

Generally, the engineering manager (EM) is more involved than the individual contributor (IC) engineers. First, before planning of individual features happen, I make sure the EM is involved and aligned when we are creating the product strategy of our team. Doing this makes getting alignment on individual features much easier because the engineering team knows what the higher level goals are and why we are going after those goals. I've found that in order to get buy in with engineering, I have to make sure the team understands why the work they are doing is important - how it ladders up to a...

At the beginning of the project. Before we start implementation, I make sure to define:  * What problem are we trying to solve and for whom? * Why is this problem important to solve? * What is the business impact?  * How does this project ladder up to the broader product/company strategy? * How will we measure success? 

For a visible project that has the attention of upper leadership, I think of 3 checkpoints with leadership: 1. Showcasing the vision at the beginning of the project Once I have nailed down the problem to solve, why it's important to solve, how it contributes to broader business goals, and you have an idea of how you want to solve it i.e. conceptual mocks - I present the vision for the project to get alignment with upper leaderships. While I'm getting this ready, I will make sure to keep my manager and other key stakeholders in the loop to get their feedback and refine the vision.  2....

This is a continual process! It is important to have regular syncs with the engineering team to discuss progress, open product questions, and review next steps. I don't think this can be done in stand ups, but rather having a weekly 30 min sync has worked for me.  I don't think it's possible to spec out every single detail of a product up front. It's important that you have ~70-80% of the details defined before engineering starts work, but as you start to define the rest of the 20%, sync with the engineering team regulary so that you can clarify the scope. 

* In terms of KPI's shared between product and engineering, I would say "Effective Resource Utilization" can be missed primarily because it can be hard to track and measure across projects/teams. * "Internal team satisfaction" is another one that PM's may not include but this is an extremely important metric that provides a good idea of the health of the team and organization. This should not be missed.

Here is a rough process I would follow but it really varies a lot depending upon each business: * Understand Company Objectives and Goals * Have a clear Product Vision and Strategy that aligns with these goals/objectives * Create higher level OKR's that can map to KPI's * Determine the top KPI's the company is interested in driving/moving. Examples are: Business Performance KPIs: Customer counts, Customer / user acquisition, Retention Rate, Churn Rate, Revenue etc. * Make a prioritized list of these KPI's you can measure. Example Revenue would map to MRR and so on * Pick ...

Some of the worst KPI's in my opinion are: * KPI's that cannot be measured correctly * KPI's that do not give a sense for the goal you are tracking. You can use the AARRR (Acquisition, Activation, Retention, Revenue, Referral) framework to understand the best metrics you can choose to align with your outcome/goal. * KPI's that are not achievable in a desired timeframe. Yes there could be exceptions here but generally these are not the best ones in my opinion. * Any KPI's that do not really tell you the health of the business unless a holistic picture is presented. e.g. numb...

* Congratulations to you! There are a lot of ways you can pave the path for KPI's at your company as the first hire * The KPI's should be directly based on the business outcome you plan to achieve. * Even before that though, I would highly recommend having a solid Product Vision and Strategy in place for your company/product * Who are your customers? What is the benefit you are trying to provide them? * After that you can use the AARRR (Acquisition, Activation, Retention, Revenue, Referral) framework to understand the best metrics you can choose to align with this outcom...