Getting Serious about Product Process
Product management is hard. Tight deadlines, unlimited demands on your time, and complex technical requirements make Product Management a challenging but impactful role.
That’s why, for this year’s Denver Startup Week, I decided to ask experts about something I’ve always been interested in, their PM process. Fortunately for all of us, this is a topic all PM’s have strong opinions on😉. Check out the session description for more details, here.
To kick off the event, I asked about their product processes—each PM utilizes a very different one at their company. They each took a couple minutes to walk through their process, why they use it and some of the pro’s and con’s associated with the process. If you’re curious on that check out the links below.
The Experts and Their Processes
Insights on Product Management Process from the Panel
I know not everyone wants to watch the full panel, so I’ve distilled 6 key takeaways below. Whether you’re looking to improve product process on your team, move into product or are simply curious how our 4 panelists run their product teams these takeaways will be useful for you.
#1 Process should serve the product, not lead it
Deviating from the established process is often the cause of failure in projects.“It went off the rails.” Interestingly, the fit of the process to the situation is rarely considered.
Sometimes the process is the problem.
“If people are constantly frustrated with the process or you’re getting slow velocity, you may need to review your process,” – Scott
#2 Process should reflect the needs of the project & the team
This seems straightforward but it’s not. Teams routinely mimic processes developed for and by other teams in different situations. Your process, while not necessarily totally original, should fit your situation.
“4 companies on the panel 4 totally different processes.” – Michael
That’s not a coincidence, these companies are all very different, making products for different audiences, on different scales. Bigger teams benefit from a robust process to communicate status, prioritization, and budgets to the larger organization.
#3 Processes must be clear and transparent
A process is describing an agreed upon way to manage work, be it building a digital product, a new toy for children, or a Tesla everyone is hoping drive. It’s useful to keep people on the same page but Michael also pointed out that “process helps prioritization”.
That’s not all, “The process helps leadership see the impact a change will cause to outcomes” – Taylor
As groups get larger the importance and challenge of communicating process increases. In general, it should be clearly written out, with clear justification for why this process makes the most sense for this organization and situation.
“You need to share the guardrails on the process that keep prioritization and direction on path”- Christine
Without an understanding of what is and isn’t acceptable in terms of changes to the default process, there are no common ground rules for everyone to play by. Inevitably in a scarcity situation, which is always the case on product teams with limited resources, people will get frustrated when the resources they were hoping for are used on some other project. This is unavoidable but frustration is limited when a process is in place to make these decisions fair and transparent.
#4 Process needs to be review regularly with all stakeholders
With #2 in mind, it’s clear that the process needs to change to reflect a change in the organization. As the organization changes so should the process it’s using.
“In general, smaller teams can adjust monthly, larger teams only adjust bi-annually” – Scott
#5 Process is essential to manage and prioritize feedback
We’re in a great era for digital product creation—users are often a click away. With video interviews, screen captures, survey, and app analytics, we have an overabundance of data on the needs of users. An effective feedback system starts with collecting the right type of feedback.
As Scott from SendGrid shares, “Get it into problem focused not feature focused language” thus no more arguing about the specific sending feature another company has, but instead focusing on solving the actual problem the user is complaining about (ex. they need to send an email while asleep so it arrives during business hours in another time zone). that you are or are not currently solving. Once you train your team and customers to share feedback in problem-focused language you can go even deeper as Taylor from GoSpotCheck explains “Ideally, you can explain the tradeoffs solving the problem they’re having will incur” and then have them decide if the trade-off would be worth it to them.
#6 Process specific knowledge isn’t a prerequisite to becoming a PM
Knowledge is definitely power but all of our panelists agreed that learning a specific process isn’t the route to becoming a Product Manager.
“Every company uses a different process, so learning a single process is unlikely to help you. Whenever I’m asked how to become a product manager I tell people to go build something for a client” – Taylor
Michael from Clique suggests “Learning sequencing is much more important” than learning a process. Scott says Sendgrid is really focused on finding people who are “really customer focused and are really able to work a problem”.
Tools to Consider
Insight Gathering and Mgmt