I’m assuming the question is about setting a ‘team’ vision/mission and one doesn’t exist yet. The mission statement is the “What” and the vision statement is an ambitious future state of what the world might look like when you accomplish your mission. A crisp vision/mission statement serves as a strong identity for your team and guides them during critical moments of decision making, gaining alignment, prioritizing resources etc. Here is a framework that I’ve leveraged in the past to arrive at a vision/mission statement for my teams, collaborating with our cross-functional partners. Have each person in the working group articulate the following in once sentence.
Next, create the vision and mission statements based on common themes and ensure it aligns with the company’s vision & mission. These statements should typically be short, start with a verb, strive to be aspirational and endure the test of time. Once the working group of cross functional partners align, socialize with key stakeholders and the broader org. You might want to consider doing a branding splash (new logo, ordering swags) to get people excited about the new vision & mission.
“Rushing to prove value” is one of the common pitfalls of starting in a new role. Having said that, you want to make steady and incremental progress in delivering value. See my response to the question "What's your best product management 30-60-90 day plan to make a big impact at a new company?" for the framework you can adopt for a 30-60-90 day ramp up plan. Here I’ll outline some quick wins you can aim for but I can’t stress enough on not coming across as ‘rushed’.
The listening tour is what I love most while taking on a new role. I’m a social person and I love meeting people. What better than getting to know the people you are going to work closely with? I typically have a ledger that I carry with me into these 1:1 conversations with my cross functional team members and take notes diligently. This also helps me to organize those into themes. Towards the end of my 30-60-90 day ramp up, I do a share out of my perspective on what works, what doesnt and where we could do better. Here is how my 1:1 conversations during the listening tour are structured -
I’ll apply the framework outlined above to this question and talk about setting up a Technical PM function for the first time. 30 days of LEARNING: I’ll start with a listening tour, meeting with all cross-functional leaders (Engineering, Data Science, Design, Marketing, Operations etc) and trying to understand where the Technical PMs can add value. I usually get a list of all the areas where help is needed. I ensure that the expectations from the team aligns with the Technical PM job profile and career expectations defined for that job profile. Next I get a deeper understanding of the following - 1) Overall org growth plans (hiring, site strategy etc) 2) Long term strategy for the Product/Platform along with current priorities 30 to 60 days of ALIGNING: Once I have consumed all the information, I typically create a plan to build the Technical PM function and scale out for the next 1 to 2 years. I’ll prioritize roles I’m going to fill based on where the Technical PMs can have the most impact in relation to the org priorities. I’ll ensure I have alignment with the cross functional leaders on that plan. I advocate for hiring strong leaders in advance and not waiting for the team to grow to a certain size. This is because - 1) Strong Product leads think big picture and know how to design orgs for the future 2) Coming in early gives them the opportunity to grow product expertise better. They get to be a part of the evolution of the product which is critical 3)They are good at hiring too.60 to 90 days of EXECUTING: The next order of business is to partner with recruiting and kickoff hiring. I’d also recommend getting hands on as a leader, by taking ownership of a critical product or platform area before you staff your team. This provides the opportunity to understand the space and the challenges your team might face in their roles. Now is the time to also build some of the key processes to help your incoming team be successful. I’ve addressed some of these in my previous AMA
I worked at Microsoft for about a decade and then moved to Meta to take on a new role, a few years back. That was the most unsettling period of my professional life. I’ve gotten accustomed to a certain culture, way of work life, people, tools & processes etc at one company and the thought of having to do it all over again was intimidating. I decided to build a 30-60-90-day plan in my new role at Meta to provide clarity to my team (and to my manager, myself) about how I’m going to ramp up. Deborah Liu, currently CEO at Ancestry, who was at Meta at that time, pioneered a template that is widely used at Meta. She also wrote a blog post about it linking to the template which I highly encourage you all to read and leverage. Her framing resonated well with me and I’ll share my personal take on it.
First 30 days of LEARNING: One of the common pitfalls that n00bs (aka new employees) do is rushing to prove their value. I took the time to understand the new company’s culture, vision, mission, top priorities. I took the time to know the people (teams, stakeholders, partners) and began to build trust. Understanding how you and your team fit into the bigger puzzle is important. The listening tour, sitting in customer feedback sessions or taking a bootcamp class (if your company offers one for your role) are great avenues of learning during this time. Have a clear understanding of what is expected of your role and publish the 30-60-90 day plan to provide transparency into how you’ll ramp up.
30 to 60 days of ALIGNING: Having an opinion is important for any strong leader. Based on my 30 days of learning, I began to form opinions about what is working well and what isn’t and validated my POVs. Aligned with key stakeholders on what a forward looking plan for your product or team might look like. You are also getting comfortable by getting hands on (if you are an IC) or making small decisions (if you are a leader), continuing to build trust. 60 to 90 days of EXECUTING: This is when the rubber hits the road and the time when you are about to lose your ‘n00b card’ (or honeymoon period). I clearly articulated the execution plan for the updated vision, roadmap and began to lead the team down that path. At this point, I’ve gained my team’s trust and I am one with the team. This is also the time I wrote my own performance goals for the next quarter or half and shared it out. Getting feedback continuously allowed me to adjust quickly. Taking on a challenging product feature or solving for a crisis situation has always allowed me to ramp up and gain expertise quickly. I recall Sheryl Sandberg saying once “Never waste a good crisis”.
Expanding the team from 1 to multiple people comes with a set of pitfalls that I’ve learned the hard way. And many other factors such as Org culture, line of business, product lifecycle etc, have a telling effect on the type of pitfalls you’ll encounter, so take this with a grain of salt. Here are a few things worth considering -
Prioritization is key. I don’t believe in dividing ‘all’ available work across my team. I believe in ensuring my team focuses on the top business priorities and are having the most impact. I typically encourage my team to do a few things but do those really well and not ‘peanut butter’ themselves across many different areas. A Technical PM on my team might be taking on multiple product areas (typically not more than 2), but they set clear expectations in terms of what their roles will be and how they’ll spend their time across those. A few things to pay attention to -
I talked a lot about evaluating the success of a program, measuring the success of a Technical PM etc in my last AMA on the topic of "Technical Product Management".
Building with intent is key. As a first PM or TPM, you are often running a one-person show. You wear multiple hats and you tend to be scrappy, flexing to what the business needs you to do. That approach works wonders up to a certain scale but soon exposes its flaws. When you think about scaling out from there, here are a few things to consider -
Finally be open to updating your org/team design as business and people grow.
I love this question. Typically one does not boot strap their career as a Technical PM, at least not until recently (Some companies including Meta are hiring Technical PM interns now who start their career as a TPMs which is great). So the most common TPM career progression stems from Engineering, Data Science, Product Operations, Partner Solutions Engineering etc. I’ve seen so many people from those backgrounds be immensely successful as a Technical PM. And there are people with many more backgrounds who could be equally successful too.I never look at job titles. You might even be surprised to hear that I never look at an interviewee’s resume. I do a lot of Solutions design (which is all about hypothetical problem solving anyway), partnership and leadership focused interviews, so what’s on the resume hardly matters in terms of the signals I want to gather during the interview. I focus on behaviors such as Strategic influence, Collaboration, Conflict resolution, Motivation, Product Intuition, Program Management etc. and I want to see examples rooted in tech as much as possible. In technical deep dive interviews is where past work matters (therefore resume) and I want to see candidates demonstrating strong E2E technical understanding, and the ability to deep dive into a few areas of their past work.