AMA: ezCater Director of Product, Fulfillment, Brandon Green on Product Roadmap & Prioritization

Autonomy is certainly a desirable aspect of product work, but it comes with time. To gain autonomy, you need to first build trust. Start by not assuming your sales team is wrong (I realize this is blunt, but worth saying). They spend their days talking to users and prospective users and probably have a good idea of their pain points. They may not always be thinking about creative solutions to those pain points, or have a good product sense, but it's unwise to assume those ideas are fundamentally wrong - they may just not be ideal, or quick to market, or they may be a red herring for a different underlying problem. Engage with your sales team and really invest in learning their perspective, offering your own fresh insight and perspective and working together on the solution. This helps build camaraderie and trust, builds your understanding of the customer problems you need to solve, and potentially gives you some quick early wins to work with. If the roadmap that results is not 100% "yours" and involves a lot of heavy input from sales, that's okay. It's important to note that no PM is truly fully autonomous - you lead and support a team of different people in different functions, and inputs from those folks are invaluable. Over time, you'll have a more confident understanding of your users, and your sales team will trust you with that confident understanding.

I could give a really detailed answer about my process, but I don't really have one. I've found that my "prioritization process" is actually pretty simple and is about attempting to answer the questions I listed out below (will repeat them here): 1. What, fundamentally is the problem this idea is meant to solve? How worth it is solving that problem vs. others I know about? Does solving this problem create opportunities or risks in any form that I should think about? 2. Is this a problem I need to solve now, in 6 months, in 2 years, etc.? What's the risk of just putting it off? 3. Has this idea been validated in some form already (even without product development)? What's the "why" behind this being an idea? Is there a good hypothesis around it? 4. If it hasn't been tested yet, is there a low-cost iteration of this idea that my team could build and test quickly? What (rough swag) impact or learnings could a low-cost iteration yield? Then, it's a matter of developing a sequence that makes sense based on the answers to those questions. You could tackle this with 2 final questions: 5. Do any of these ideas directly depend on another, or would my perspective significantly change based on the learnings gathered from any particular idea? 6. Are there any irreversible decisions (business or technical) involved to ship any of these features? If so, do any of the features make sense to build and learn from to help make that decision? If I can answer those questions effectively for the features on my list, the roadmap starts to write itself :) 

It depends on the role and problem space, but I try to invite (1) virtually everyone I collaborate with on a regular basis, (2) their management/leadership, and (3) fellow PMs as partners in the roadmapping process. I think it's important to think of stakeholders more as partners in the roadmap creation process, since their ideas and input really shape my POV on what's important there. Influence vs control is interesting. I've been in situations where stakeholders are pushing for specific features on the roadmap, which isn't necessary bad in itself - but it's important to (1) make sure it's clear *why* those things need inclusion, and (2) that if they are not included in a roadmap, you have a clear justification as to why. That could be for a lot of different reasons (eg. sequencing, technical effort, lack of certainty/understanding of impact, etc.) but it's important to clarify why you, as the PM, have decided to deprioritize thing A instead of thing B. A helpful tactic here to suggest influence without losing control is to propose an alternative placement for the given thing on the roadmap. For example, if it's risky to tackle thing A in Q1, don't just explain why, but also provide some rough guidance as to where thing A may end up as a result. Lastly, I think word choice matters here, and commnunication tactics help. I've found success in "proposing" a roadmap, alternative prioritizations, alternative framing; giving stakeholders a deadline by which to provide feedback; expressing support for ideas even if they are not the most important ones at the moment. 

I've found that there are basically 2 levels of detail that matter, with the goal of each being somewhat different: 1. Executive summary (Director/VP/C-suite audience) - which focuses much more on the problem areas to focus on, why, and a high level outlook on the features or impact you aim to ship in that quarter/half/year. Goal is to provide guidance to the exec team on where your product domain is going, make clear where you need support or have cross-functional dependencies or risks. 2. Stakeholder-facing roadmap - higher level of detail than the exec summary, with more focus on a sequence of features/initiatives to ship but still with a heavy focus on the why and goals. Goal is to ensure (a) shared understanding of the goals of Product in the given quarter/half/year and (b) coordination with partner and stakeholder teams, calling out dependencies and risks. There is likely a 3rd roadmap that makes sense in most cases, which is much more in the weeds and meant for your immediate squad - but for me, that has over time become more of the focus of an engineering lead/manager partner (ie. that person owns this 3rd document and it's focused on execution of the stakeholder-facing roadmap).

I've had to manage a couple different pivots like in my product career. What's worked best in terms of communicating is the following: * Making clear the "why" behind the pivot, and the risk associated with not pivoting * Stating clearly the underlying first principles or vision for the pivot that exists today (it doesn't have to be super detailed - but this more about acknowledging what you do know or what you believe should be true) * Acknowledging clearly that the roadmap will be in flux for some time, and the short-term is around building learnings and certainty around a long-term strategy * Committing to some series of regular updates (I like every 2 weeks - if you're not learning enough worth sharing in 2 weeks, you're not pivoting fast enough) * Following through on those updates, and keeping them as crisp and simple to understand as possible. Bulleted lists usually work well for me.

I consider product marketing managers (PMM) part of the core partner group working with Product in roadmap creation (also including engineers, design, analytics, research, and other key functions based on the role). We aim to loop in product marketing as soon as roadmapping begins, and make sure they're aligned with product on objectives for the given quarter/half - this usually involves PMM sharing insights to help pressure-test the objectives, ensure we have a good understanding of customer sentiment, etc. PMM also takes part in the feature prioritization process, both to help validate the potential impact of those features and for awareness as they build marketing plans. We also typically include PMMs in kickoffs for individual initiatives and especially the product design process - often, the thing that is marketed becomes clear during this process (eg. what it looks like, how it specifically will solve the given user's problem, how we want to communicate this), and gives PMM a good sense of what their work will look like. In my current role, we're often having discussions at this stage about "whether the thing needs to be marketed at all" - we may be working on a behind-the-scenes change, or a very minimal feature requiring experimentation before we're confident in our approach, and that may have significant implications on the product marketing plan as a result.

I don't have a specific framework I use for determining build vs buy, but I've typically used a series of questions to help evaluate the decision: - What is the problem you're trying to solve by building or buying? - How strategically critical is that solution to your business? Is it something that could create a competitive advantage, help build moat against competitors? (If so, there is probably some risk in relying on a 3rd party.) - What benefits come from buying? Does it significantly speed up your time to market? Are there long-term benefits or capabilities that a 3rd party vendor can provide beyond what you're immediately trying to solve for? (If either is yes, that may increase the value of buying a 3rd party solution.) More importantly, look at other examples of companies having built vs bought and how they evaluated those decisions. One thing I love about the Internet is that there are tons of examples of companies having gone through this decisioning process, and how it worked out for them. I recommend checking out things like Ben Thompson's Stratechery blog, the Acquired podcast, blogs of companies you know have bought vs built in-house, etc.

I deal with this a fair emount in my current role - Delivery at ezCater to some degree touches all possible users of our multi-sided marketplace (customers, supply & fulfillment partners, internal staff), and each of those major user buckets contains multiple segments. Here are some things I've found useful in dealing with all these different user segments at once: * First, acknowledging to yourself, your team and your stakeholders that there are A LOT of potential problems to solve, and complex effects of focusing on one segment over another - but trying to serve all at once runs the risk of slowing down progress. Simply put, acknowledging the challenge itself helps me because I've often found that folks underestimate the challenge of having to build for many users at once. * Deepen your knowledge on the relative value (current and opportunistic) of each segment, and possible network effects that occur by affecting change on one or several of them. For instance: improving the experience for a non-revenue-generating user (eg. internal staff) may not drive money directly, but may provide better experiences for revenue-generating users or save costs to fund other initiatives elsewhere. * Look for opportunities to solve many problems for different segments or user types at once. This may be via network effects (eg. improving the experience for power users allows you to charge them more, enabling you to lower prices for new customers or invest elsewhere), or by building with multiple users' in mind (eg. building a tool for new customers that, with a small addition to scope, also helps power users). * All the while, look for opportunities for quick wins or learnings to keep pace up and iteratively create value. * All the while, working with leadership to understand the current or potential value of each segment to help steer you in the right direction.

Everywhere! Users themselves, colleagues, market research, competitors, randomly in the shower. Generally, I like to consider each idea seriously and work through a few questions to help decide if they are worth building: 1. What, fundamentally is the problem this idea is meant to solve? How worth it is solving that problem vs. others I know about? Does solving this problem create opportunities or risks in any form that I should think about? 2. Is this a problem I need to solve now, in 6 months, in 2 years, etc.? What's the risk of just putting it off? 3. Has this idea been validated in some form already? What's the "why" behind this being an idea? Is there a good hypothesis around it? 4. If it hasn't been tested yet, is there a low-cost iteration of this idea that my team could build and test quickly? What (rough swag) impact or learnings could a low-cost iteration yield? This feels like a lot of questions, but I've gotten good at answering them quickly with a few driving assumptions to help keep myself moving. This is really hard early in one's product career, and potentially when you're working in a very new job or problem space - but as you ramp up, you start to be able to answer them faster.

This is an interesting question, because I think it highly depends on the leadership and culture of the company you work in. I've seen leadership figures have very strong opinions on how much they want to publicly share about the roadmap, and it's anyone's guess as to whether it's to their benefit or detriment. Here's how I've thought about this before: - Your customers benefit from knowing your priorities and what you're building towards. Therefore, being public about mission, vision (to an extent), and the priorities of product is valuable. - I've been burned countless times by promising specific features in specific timeframes, so I no longer do this until either the feature is shipped, or (better yet), after we've learned about the impact of that feature and how effectively it's helping my users. - If you work in a SaaS business, especially leaning more toward SMB and enterprise as your main customers, I do think there is value in communicating a rough sense of priorities or goals for the product on some recurring basis (usually quarterly). Given my last point, I think it's important to carefully decide how much you're willing to share - and that's usually based on your confidence in a given item. For instance, if you have something about to ship that you know will solve a major customer problem, that may be worth sharing - but things that have a lot of open questions or risks you may want to withhold specifics on.

A PM's job is to take in a lot of inputs (including the 3 listed in this question) and articulate a compelling strategy and roadmap around achieving the best outcomes for your business. Within those are assumptions, risks, opportunities, etc. that are worth digging into and questioning, and from there you can usually start to get a sense of where to focus. To a certain extent, you'll need to at least focus a little on all of these inputs, just to get a sense of whether they're worth digging deeper on. I think the answer around "where to focus" will differ highly based on the context you find yourself in, but I think you can start by asking yourself what the biggest immediate problem or opportunity is, based on what you know. Oftentimes the inputs themselves will help provide that direction. For instance: in my current role, I have a wide scope with a lot of users to consider, stakeholders to partner with, and problems to be solved. Some of the problems that appear impactful on the surface I realized were not very actionable as is for a number of reasons, so I chose to shift focus to an area that was immediately actionable, had resourcing focused on it, and I had prior experience to help guide me on potential solutions. I was able to then demonstrate some short-term impact and hire a PM to drive value in that space, allowing me to shift over to another problem area. I also realized that one of the business goals related to that space had some assumptions built into it that we began to question as a result of the work we did, allowing us to shift the priority of that business goal a bit.