AMA: HubSpot Product Lead, CRM Platform, Katherine Man on Product Development Process

Product managers should partner closely with engineers on building a product roadmap so that everyone is bought into the roadmap and avoids the need for slipping in rogue features. I would say this sounds like a lack of trust between product and engineering. Here are a few suggestions of how to rebuild trust: * Collaborate early and often on a roadmap with engineers and UX to make sure the entire team is bought into the plan. Encourage suggestions from engineers so that they have a voice. * Establish a clear prioritization framework when deciding what to work on. This should be product-led but still involve the whole team. You can consider things like customer value, time to build, alignment with overall business priorities. That way when there are conflicts between you and engineers over what to prioritize, you can use the prioritization framework to resolve disagreements without much conflict. * Share customer feedback so engineers can see the impact of their work and understand why you chose to prioritize certain features over others. * If the engineer still insists on working on a "rogue" feature and assuming it won't damage the product, you can discuss with your tech lead if every sprint your team should reserve 20% for engineers to work on whatever they want. This allows engineers to prioritize issues they want to work on but would never be considered high priority (reliability, design bugs, etc.)

The ideal product manager to engineer ratio can vary from company to company and even team to team, but it usually depends on the company size, product complexity, the skill level of the engineers, and the role scope of the product manager. A general rule of thumb is 1 product manager for every 5-10 engineers. * 1:5 - This is common in startups or small teams where the product manager may need to be in the details. * 1:10 - As the team and company grows, a product manager may manage larger engineering teams. Sometimes it's one large team or multiple engineering teams. Since product managers don't have time to be in the details for every project, they are expected to work at a higher level on setting product vision and direction rather than detailed product requirements. It is common for senior product managers to manage multiple teams. * 1:7 - This is the sweet spot where a product manager can still get into the details of a project while also having a lot of impact with a team of this size.

Having a QA team ranges from company to company, but I personally believe it's important for engineers to test their own features so they feel more ownership over the quality of what they've built. Often engineers test continuously while building so they can fix bugs as they arise and not be overwhelmed by how much they have to test at the end. Once they feel good about the product quality and have double checked that what they've built meets product requirements, they can organize a "bug bashing" session with the entire team, UX designer, and product manager. It's the product manager's role to make everything is working as intended before engineers ship the product.

Success metrics should be discussed early with engineers to ensure alignment with the product or feature's goals. By setting these metrics early, it helps prioritize what features to build and define how success will be measured. While it's fine for the metrics to change as new learnings come up, it's important to involve engineers early and often. Many times engineers will also help pull the success metrics data so they need to understand why it's important.

I would describe my product development philosophy as "agile lite," meaning there is some structure but the order of operations can change based on new learnings that arise. The entire product team (product manager, UX designer, and engineers) should be involved at every stage, but different roles will play a leading role depending on the stage. Here are the stages I go through: * Identify the problem: Product manager identifies the top customer problems to solve. * Conduct user research: Product manager schedules customer calls to validate how large of a problem it really is. They collect use cases and get feedback on any initial design concepts, which can be lightweight wireframes and not full, clickable prototypes. UX designer and engineers should be invited to the calls to hear feedback directly from customers. * Ideate: Product manager organizes a brainstorming session with the UX designer and engineers. Product manager identifies the top user stories to solve for and the entire team workshops ideas for a MVP. * Create prototypes and do user testing: UX designer takes on the lead role and creates a prototype based on the brainstorm session. They then schedule customer calls to get feedback on a clickable prototype to test ease of use and whether it solves customers' pain point. * Define product requirements: Product manager creates a document to capture product requirements once designs are finalized. While this doc can be started earlier, even as early as the "identify the problem" stage, requirements should not be finalized until you've validated what you're building with user testing. Here is a sample product requirements doc. * Build MVP: Engineers take on a lead role once requirements are finalized. It is critical that you involve engineers all the way from the start and not just at the build stage. That way by the time you're ready to start engineering work, you've aligned on requirements and expectations and have their buy-in on the project. This collaborative process should reduce any risk of being surprised by what they've built. * Release: Engineers release the product and product managers monitor customer feedback. * Continue to iterate based on feedback: Even after releasing a product, it's important to continue to iterate based on feedback. * Sunset the product [optional] : At the end of a product's lifecycle, product managers should consider sunsetting a product. While this is not a required part of the cycle for every feature release, it's important for product managers to think critically about when they need to sunset a feature to reduce clutter in their product. It's more important to have a product with helpful features rather than a product riddled with less helpful features.

When you lack resourcing whether it's engineering, design, or even product, it's critical to practice ruthless prioritization and managing expectations. Realistically there is only so much you can get done given the resources you have, so you need to work with your team to define what is within scope for a certain timeline. Once you have that, you need to align and set expectations with stakeholders and leadership. If they push you to do more, you can ask what they're willing to trade off to do what they ask. If they're in charge of resourcing you could ask for more resources and explain how much further the additional resources would get you.