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.
- 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.
- Articulate clear product vision and strategy - This is extremely important to align and rally the team towards common goals and objectives.
- 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.
- 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.
- 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.
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.
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.
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.
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.
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.
In these situations, I hope you've aligned with leadership on the reasons for them to hire a PM (sometimes their first PM) before you join the team, whether that's as an internal transfer or an external hire. If you aren't on the same page about the problems they are trying to solve by hiring you, and also how much autonomy/decision-making they are going to let you have once you get there, it's going to be a bad time: leadership is going to be frustrated when you start asking a lot of questions about both execution and strategy, and trying to make changes. This alignment before you get on board is going to be the biggest determinant of your success.
Assuming your leadership team understands why they are hiring you, and they agree and are willing to (in theory) give you the latitude to introduce some better product management practices, the first thing to do is to observe how things are working for a little while and take private notes on current condition vs. target condition (your opinion). Then see where you can immediately lean in to make some basic changes that will help the team save time, money, toil, etc. For example, can you kill some meetings that aren't delivering value and replace them with something else (or maybe just get rid of them entirely)? Can you start meeting with customers or sales teams and bringing insights to the engineering team that they haven't heard before, and give more direction and meaning to what engineering is working on? Can you take a "yes, and" approach to ideas that engineering has, to explain to lead engineers that you believe in their technical ideas (if you do) but that success will arise from a whole bunch of other factors rather than just the coolness of their mousetrap? etc.
Don't try to change too many things at a time. Focus on a couple of areas where you can get a win, and calibrate that to how resistant the team (including leadership) is to change. Good luck!
Id say the main key things to do is to focus on agility and results over rigid frameworks.
1. Start with outcomes, not inputs. Align the team around clear measurable outcomes. Ask “What does success look like in 6 months? Instead of introducing detailed roadmaps and lengthy planning cycles, get everyone obsessed with the end goals. This will naturally drive focus on the most impactful tasks.
2. Small companies can’t afford to get bogged down in bureaucracy and formal structures like sprint cycles or massive backlogs. So start with lightweight methods like a simple Kanban board or use OKRs to keep things organized but flexible. The key is to introduce enough structure to avoid chaos but not so much that it stifles agility. No need to complicate things from the get-go.
3. Focus on customer feedback and product iteration based on that when possible if it makes sense. You should focus on power users first. Ship fast.
Also, involve your key team leaders around decision making like lead eng, design, marketing, etc because they all play a role in the GTM process. Better be aligned now than risking silos later. You dont need to control everything. so focus on facilitating collaboration between those folks.
Good luck :)
Top Product Management Mentors
