What is your advice for creating and/or improving the product management process when joining a small but growing team? Particularly for a small company with no or little structure?

Be adaptable to change - don't be afraid to try different things or change a process that is no longer working for the team. For a team that is growing quickly oftentimes process gets ignored because the team is so focused on delivering/executing that they feel process may slow them down. In some cases little to no process can be a good thing, but for a team that is scaling it can be detrimental. What I try to do is understand how they are using product management processes today and then try to understand where product can add the most impact short term and demonstrate early wins to help build trust. Getting buy-in from the team is essential, and typically I try to message that I am adaptable and my goal is to help the team's ability to execute and focus on the right things rather than add more things to their plate.

I entered a team that was doing well from a revenue standpoint but was constantly putting out fires and as a result didn't have much time to focus on feature development to improve and grow the product - it was just maintaining with a bit of decline. I focused first on root cause analysis of the fires/incidents from the previous 60 days and found most of them could have been avoided by introducing a lightweight process before a content release. We piloted it for 1 team for couple sprints and found it reduced incidents by about 50%, so we rolled it out to other teams and got similar results. This in turn freed up engineers from firefighting, and also helped me build trust with the team. In general my motto was "what we have now isn't working, let's try X for a few sprints and if it's not working we'll try something else." The general pushback I usually got was from engineers who wanted to avoid meetings or unnecessary overhead - however, I found that if I could show that I was flexible and what I was doing would ultimately save them time/effort, I found most to be amenable to change. 

Another tool that helped me was retrospectives and post-mortems, and advocating for better processes during these times. Oftentimes in these situations people are open to discussing improvements, and if you can clearly tie in how a product process can help avoid/solve a problem you can get buy in easily, particularly if you are offering to drive it. Better yet, if you can circle back with results and outcomes that show how this benefited the team (fewer CS tickets, better velocity, etc) you can help demonstrate the value that product can provide. 

I'm a strong believer in "just enough" process, so my answer to questions like this is always some version of "it depends"!

The one piece of process that every team must have is a way to reflect on, and incrementally improve, they way they work together. You can call this process whatever you like - "reflection", "retrospective", "after-action review", "post-mortem" - but it is imperative to building an effective team. 

This practice will inform the way you introduce and evolve processes as your team grows.

Here's the lightest-weight retro format I've ever used, which is a great way to get started:

Format: individual stickies brainstrom (one idea per sticky)

Time: 30 minutes to one hour

Frequency: Every one to two weeks

Method: 

• Each person responds to the "I like" and "I wish" categories on individual stickies - timebox to 3-5 minutes
• Each person shares their stickies
• Affinity mapping: cluster similar ideas together
• If needed: dot vote on the things that are most important. Be careful not to always prioritize the concerns of one group, though (eg, if there are more engineers than any other role, how will you ensure you also address concerns from other roles?)
• Discuss your highest priority topics, with a focus on understanding the cause and generating ideas to make it better. Retro isn't a venting session!
• Agree on the things you'll try, and if appropriate, who's responsible for making it happen.

Categories:

• I like - the things that worked well in the preceding week or two
• I wish - the things that you wish were different
• We will - the group's commitment to change over the next week or two

There is literally an entire book on this topic: Agile Retrospectives, by Esther Derby, Diana Larsen, Ken Schwaber.

When joining a small company with no or little structure or joining a small but growing product team, it is essential to understand the current state of the product management process before establishing new processes. Rushing to make changes and establish processes that have worked for you in the past is not ideal. What worked in one company may not work here due to differences in the culture and how teams have been set up.  

In your first few days, you should set up a meet and greet meeting with stakeholders from product, engineering, customer success, sales, and marketing. Use this time to introduce yourself, understand their working style, and get a clear understanding of what is working, what is not working, and what are their expectations from your product management. Once you have collected all the information, synthesize it to form an opinion on the operating procedures you want to put in place that will help meet the objectives. Share your plans, collect feedback, and iterate and formalize the process. By using this shared way to drive change, you are bringing everyone along instead of dictating how things should be done. Keep in mind more is less and there is no shame in iterating if a certain process does not work the way you expected or you have outgrown the process. Processes are there to help establish structure and make things painless and repeatable for everyone. 

Based on my experience working at a small company with little to no structure, here are some areas where you will need to establish operating principles.

1. Define clear roles and responsibilities - Having clear ownership defined within the team prevents duplicated effort and stepping on each other's toes. Every product manager on the team knows what their charter is and has the needed space to operate.
2. Articulate clear product vision and strategy - This is extremely important to align and rally the team towards common goals and objectives. 
3. Create product roadmap - A roadmap is important to drive the team towards common outcomes and provide a reference point for decision-making. Without a roadmap, no one knows where we are headed and everyone makes their own assumptions.
4. Outline the product development process - This is critical to ensure the team is working efficiently and effectively and has a common understanding of what it takes to take a product from inception to launch.
5. Establish effective collaboration and communication - The product team works with stakeholders across the company and setting up collaboration and communication processes and tools in place will allow keeping engineering, marketing, customer success, sales, and support on the same page.

As someone who has recently joined a small and growing team, I can relate to the challenge of creating and improving the product management process in a company with little structure. When joining such a team, it's essential to take the time to learn about the existing product management process. Observe how the team operates and identify what works well and what needs improvement. Additionally, familiarize yourself with the product, strategy, and vision to determine whether the current team is equipped to achieve success or if there are gaps that need to be addressed. If there are existing product management processes in place, evaluate their effectiveness and productivity. Once you have a clear understanding of the current state, prioritize areas that are causing pain, consuming too much time, or providing little value.

Based on your assessment, work with the team to define clear product management goals and processes that will help the team achieve those goals. This could involve creating a product roadmap, establishing a product backlog, and defining product release criteria. Once you have defined your product management processes, identify tools and frameworks that can help you implement those processes efficiently. For example, you might use a project management tool to track progress on product development or an agile framework to manage sprints.

Remember that effective product management requires collaboration and communication across the team. Make sure to involve all relevant stakeholders in the process and ensure that everyone understands the product management goals and processes. Product management is an iterative process, so it's important to continuously review and improve your processes over time. Solicit feedback from the team and stakeholders, track key metrics to assess the effectiveness of your processes, and make adjustments as needed.

By taking a proactive approach to creating or improving the product management process and prioritizing areas of improvement, you can help drive success for the company as a whole.

You can spend too much time setting up "product management processes" and covering a lot of ground. Instead of focusing on creating a product management process, focus on diagnosing what's going well and what isn't in your current team and product output.

1. Do teams have confidence that they are building the right thing? If not, focus on sensing mechanisms and processes to gather more input during problem and solution validation.

2. Are teams effectively collaborating with UX and Engineering to come up with great product solutions? If not, why? Consider clarifying roles and responsibilities, helping the teams better collaborate by creating PRD or UX intake templates, working to ensure that engineering is present during solution validation, improving UXR, etc.

3. Is the team building product to spec and relatively bug free? If not, focus on quality processes -- beef up QA, add bugbashes to your releases, etc.

4. Is the rest of the organization (execs, sales, support, marketing) excited and ready to properly support new product launches? If not, work on upfront alignment with other groups around priorities, cross-functional project staffing, field and support enablement as part of product launches.

5. Are product managers showing the right competencies as PMs? Are they able to properly validate customer pain points, use sensing mechanisms to prioritize, come up with great solutions, iterate and deliver those? If not, focus on team competencies development via coaching, learning/development, hiring, etc.

There's a lot more that you could do, but this gives you a gist. I'm a fan of iterating on process changes. Find a problem, then only add the smallest process necessary to fix the problem. And as you add process always ask yourself whether there's other process that needs to be removed. if you just accumulate processes over time you'll stifle the organization and your best PMs will leave.