AMA: Barracuda VP, Product Management, Mike Flouton on Product Development Process

This is a classic conundrum. The good news is it’s a lot less costly when it happens in today’s agile world than it was when I started my PM career in the days of 18 month waterfall development cycles. First, apply your PM skills and dig in and explore the problem and its root causes. Is this an isolated issue specific to a single engineer, or more of a systemic cultural issue? If it’s the former, the fix is a bit easier. Make sure you have a rock solid relationship with your engineering managers and address it with them. Any EM worth their salt knows the cost of unplanned work, and it’s especially frustrating when it’s work that could have been avoided. Sometimes you have to drop everything and fix a production issue - it happens. But when it’s an engineer’s pet project it’s avoidable. Learn how to diplomatically “name and shame.” When I was a PM I’d do a release scorecard for management - if we missed a deadline (or opportunity to come in early), we made sure to clearly highlight the unplanned feature that slipped its way in. You don’t need to throw the engineer under the bus (and probably shouldn’t), but it’s not going to take long for the exec team to start asking questions about what the highlighted unplanned feature is and why it made it in. If it’s a cultural issue, I’m afraid the fix is much harder. Figure out how high it goes. You may need to enlist help from your head of product if it’s systemic. If it goes as high as the founders, you might need to make the fundamental case for product management. Or find a new job.

Job number one is ensuring you have the right market insights to prioritize the roadmap correctly. Engineering managers and scrum masters can pick up the slack and keep the trains running on time when you’re falling behind on customer research. Never shortchange market insights!

The biggest mistake companies make is treating product management a junior, technical function. A good PM is a strategic thinker who is market oriented. A big part in making that transition to the strategic is learning to speak in terms of business outcomes, and learning how to sell internally. If you’re not getting the resources you need, put together a model for the business benefit you could drive with more resources. Don’t talk about story points, or feature velocity, or any of that. Executives and finance people don’t understand it and don’t care. Talk about revenue growth acceleration or COGS reduction. Put specific numbers to your proposals. Your numbers will be wrong. That’s ok, forecasting is hard. But putting a line in the sand gives you a place to begin the debate. And that debate is going to go a lot better if your executive team sees you as a strategic collaborator rather than as an out of touch techie who doesn’t understand the business.

I’m a huge believer in transparency. Make your roadmap and decision process transparent. We use a weighted scoring algorithm where roadmap items (and ultimately supporting tickets) roll up into a prioritization rubrik. That prioritization methodology should be available to anyone in your company, including engineers. Make grooming a collaborative activity - let them weigh in on the scores you are giving to specific tickets. Argue with fact, not opinion. If you’re doing your job you will have the best market insight and can fall back and cite your customer research. Generally that’s going to win out over internally generated engineering ideas, but not always! Sometimes engineers will have great contributions you can take away and validate with the market, and ultimately prioritize if the market agrees.

Metrics work best when they are continuously embedded into the process. We use OKRs, and cascade them down from top level corporate goals into product line metrics, product team metrics and sprint metrics. Use them in a regular cadence to assess progress towards high level strategic objectives. We continually refer to them, in quarterly business reviews, sprint retrospectives, grooming and planning.

Product management is accountable and responsible for assessing which problems to tackle. But I strongly believe it works best when it’s a process where everyone can provide input, there’s transparency on how decisions are being made (see question on feature planning), and where decisions are made based on market fact - not opinion. Any debate should be decided by data and market (customer) signal. As a PM, your market intelligence should come from as many sources as possible. Customers, partners, analysts, customer success, sales reps, sales engineers and even engineers. Entertain as many ideas as possible. But work diligently to validate ideas with market data. Never make a decision based on someone’s opinion.