Roadmap Planning

The answer lies in the breakdown of how the organisation intends to hit it's goals. See this answer for context - https://sharebird.com/h/product-management/q/how-do-you-handle-exec-input-in-the-roadmap-and-convey-a-point-of-view-while-also-accommodating-1 To take an extreme example, if 70% of the organisations revenue target is based on the acquisition of new customers then that's a good guideline for your investment levels, eg 65% - Prospects 25% - Existing customers 10% - Tech debt

I typically start from what are the annual business targets set by the company to answer this question. Oftentimes, the sales organization, CEO, and professional services organizations have targets around expansion, new logo acquisition, and win rate which will help portion out what the backlog needs to be to support the business goals.  In absence of these targets set by leadership, I would use a RICE framework (https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/) to establish what is the highest value driver for the business. That way I am not really focused on driving whitespace or greenfield, rather on what will drive the most business results in total. 

I find that this type of division can be misleading. In many industries, there is little difference between what an existing customer would want vs what a prospect would want. Many times, the two would like to see the same kinds of capabilities built (but their priorities might be different). I think more about the buying centers I’m targeting, the use cases they have that my product can solve, and prioritize the roadmap based on the importance of those.

Great question! This is something most product teams wrestle with when only looking at the roadmap from a features perspective to balance what to build for existing vs prospective customers. What I’ve found very useful to address this is to revisit the product strategy and business drivers for the product and align the roadmap accordingly. For example, if you assess your product strategy and look at the data for your business drivers, you may see a trend that customers really start adopting your product in years 2-3 with 10x revenue from their initial purchase, what decisions would you make? One decision could be to build more features to get more prospects because you know it will pay off in years 2-3. OR, you could decide to focus on existing customers but learn from your customers why adoption is lagging and then focus on solving your customers needs to speed up adoption so they get value earlier from onboarding or within the first year and shift that 10x revenue earlier in the cycle for your business. In short, I found it best to revisit the product strategy, and leverage data from customers and business drivers to make an informed decision on how to position the roadmap for existing vs prospective customers. Once you identify the customer or business outcome you want to drive, use the roadmap to deliver that outcome.

In a perfect world, you want at least 80% of your roadmap to be applicable to both! But, we don't live in a perfect world, do we?  Some startups focus on a small number of customers and really customize the product to the desired features of those early users, but I like to first go broad in appeal, and then deep into a few features that are highly impactful to as many users as possible. If you want to reach a new type of user, solve a new use case, or enter a new market, you will have enough of a reason to build something exclusively for prospects. This is a strategic decision to expand your business or market footprint.  A great way to determine if your roadmap is mostly applicable to both prospects and existing customers is to build a way for existing customers to submit ideas for the roadmap, and let your entire customer base upvote their favorite ideas. The more votes, the more likely both existing and new customers will benefit from the roadmap idea. Sometimes, however, you'll have a big customer needing something specific, and there will be many reasons to build something unique, often influenced by the size/revenue impact of the customer. I don't usually let more than 5-10% of the roadmapa focus on one-off, custom features.

Who to focus on often depends on the maturity of the product. At the beginning stages of the product, we focus heavily on prospective users. When the product is mature, we focus heavily on existing customers (the thinking is -- if you can deliver impact to existing customers then prospective customers will likely find the same features useful). Additionally, who to focus on can depend on whether your company is driving to satisfy existing customers vs working to attract new customers. 

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’m wishing you a successful product pivot! You got this! In this situation, you have your internal stakeholders (sales, marketing, GTM, etc) and you have your customers you need to reset expectations with (mostly for B2B products, less so for B2C) For your internal stakeholders, the best thing you can do is be transparent and bring them as close as possible to what’s happening. For example, share the challenges, the tough trade off considerations, data you are using to drive your decisions, etc. This builds trust and partnership. Once you do that, sharing a short term roadmap will be more understandable and you can always provide a DFAD (date for a date) on when you expect to know more or have more things planned (milestones). For your customers, also be transparent about the pivot and why you are making this change. Hopefully this pivot is ultimately for the best interest of your customers. Also, what works really well is if you take the opportunity to solicit feedback from your customers about the pivot and get some insights from them. This builds trust and a stronger partnership with your customers. And since you can’t share plans too far out, a DFAD is also good to manage expectations with your customers.

I think you say exactly that! "We're pivoting our product. There are a lot of unknowns. It's hard to plan our roadmap too far out. We're resetting expectations on how much we can communicate..." THEN, I would add this... "We are focusing on these 3 themes in this priority - 1... 2... 3...Our goal is to deliver these X, Y, and Z customer outcomes by pivoting our product. We plan to have an update on these themes in ABC timeframe." It's ok not to have all the answers in times of big change and ambiguity. If you did, you'd probably be guessing at best! And that's the fun - figuring it out.

Say exactly that "We're pivoting our product. There are a lot of unknowns and it's difficult to plan too far out." It's perfectly fine to communicate honestly. If there's a good reason for the pivot, no one will fault you for it.  If you're able to have direct conversations with customers, it's important that you set up these conversations. Having open and honest conversations is important to build trust despite the pivot. It is also an opportunity to solicit feedback and listen to your customers. Resetting expectations internally within your company will be much easier if you have already held conversations with customers. You can leverage these conversations to prove that the new direction has been validated by your customers. In any case, pivoting a feature or a product can be stressful. But it's also fun.  

The balance/percentage should be agreed upon by the EM and the PM and shared with the broader org for visibility. For example, in a team of 5 engineers, one engineer's time could be set aside for 'must do' work and the rest will continue to focus on goal strategic efforts. Similar approach can be applied if the organization is big - eg. one pod assigned for maintenance work and 2 pods working on strategic efforts.  In the end, key is alignment with the broader organization and stakeholders so right expectations are set!

The main risk is constantly deprioritizing the Compliance and maintenance work and building a tech debt at such a level that it will take forever to pay it back.  There are two kinds of situations: 1- you do not have a vast tech debt, and you can manage compliance and maintenance work by allocating a fraction (10 to 30%, depending on the amount of work)of your capacity to this work. The remaining capacity work on development-related work. Alternatively, whenever a developer touches a part of the code, you impose that he improves (or maintains) a part related to what he just changed. 2- You have let the tech debt grow out of control: you will have no more choice. You will need to allocate your capacity to pay the tech debt before you go "tech bankrupt."  When the tech debt is back under control, you can apply the rules stated in 1st paragraph.

Before jumping into the "must do" work, it's best to understand the reason for doing the work.  Sometimes the "must do" work is warranted. For example, compliance could have high customer impact which naturally means that it'll get prioritized anyways. Sometimes the "must do" work is not impactful. For example, there might be a set of maintenance tasks that is necessary but it's highly manual and repetitive. While it needs to be done, it's more exciting for the team to reduce/eliminate this work through automation than continue doing it over and over again. At the end of the day, there will always be some level of "must do" work. The key is to reduce the unimpactful/repetitive tasks. Once those things are eliminated, the team is often happy to take the more impactful (even if mildly annoying) "must do" work.   

Let’s say that a product team and an executive team are aligned on the goal of improving customer satisfaction with the product (measured by a CSAT survey). The product team will then do research and perform experiments to validate the best way to impact customer satisfaction. Including executives in the research process via stakeholder interviews is a great way to get input early - executives are viewing things from a much different perspective than team ICs and often have great ideas. When the team prioritizes opportunities to pursue, the framework they use for prioritization can also be used to convey their point of view on the best way to impact customer satisfaction. If an exec suggests making an adjustment to the roadmap during the team’s roadmap review, seek to understand why and dig into their thought process. Then, seek the truth. Is there a quick way to validate or invalidate the feedback? What does the objective evidence point towards as the best opportunity to impact the goals? For more on this topic, I recommend “Cracking the PM Career” by Jackie Bavaro which has a chapter on working with executives.

Exec input is key so that you're aligned on the company goals. First get a breakdown from the Execs and finace on which levers the company intends to pull so that it achieves it's goals, and then categorise, eg, X% from new customers acquired , Y% from existing customers , Z% from cost savings. Then map the biggest customer problems to each of these categories - this gives you your key themes. Now that you have this mapped out 1. First playback your understanding of the importance and priority of each category / lever 2. Second highlight the customer problems that align to each category 3. Finally flag high level features that map to the each customer problem. - Ideally you don't even need to show this as the feature level conversation becomes far less relevan once 1 and 2 are understood You should now be getting useful feedback at the appropriate level and steering clear of the feature level discussion which will likely be a distraction.

This is certainly a tricky one! I like to think of a roadmap being made up of four sensing mechanisms:  1. External stakeholders - investors, board members  2. Market landscape - competitors, analyst reviews or reports, and prospects 3. Internal stakeholders - CEO, leadership, cross-functional teams  4. Customers - install base or existing paying and free users  When you are able to attribute the sources of your roadmap features transparently, it becomes a trade-off conversation with executives - rather than a top-down mandate. Being able to show that certain bodies of work have been sourced from competitors or analyst reports which show that you may be lagging behind, for example, is a great dialogue to have when it comes to prioritizing the input from the executives. If the feature request should get done because you have applied a RICE score or some other type of validation, sequencing behind the most impactful items will be a great way to accommodate the request while delivering the most impact. 

The most helpful way to maintain alignment with the exec team is to align early and often on the product vision and strategy. Those conversations will likely surface gaps or areas of misalignment that you can address or close at the strategy level before you ever get into a roadmap discussion. If however, you find yourself at the receiving end of some exec input that isn’t aligned with a strategy you have socialized, there are several ways to handle it. 1. Pull the suggestion into your input process and work the idea through your product development lifecycle to see if it will make it through your process fairly and as intended. Many suggestions will likely fall into this bucket and will eventually land on the roadmap, but the tricky part will be keeping the exec in the loop about the progress. 2. Sometimes, the suggestions are fantastic, but the team is occupied with a longer-term project that is sequential in nature and it would be extremely disruptive to their progress or their morale to reprioritize something else. In this case, I’d raise this concern to the exec in question. Compliment the value of the idea, and mention that the team is not quite in a good place to take it on, but that you will explore it with them as soon as they complete their current work stream. 3. The suggestions could be coming quickly and often, and way too frequently for your team to be able to accommodate them. In this case, I’d leverage tradeoff conversations. If this new idea is going to be prioritized on the roadmap, what item (of equal or greater effort) comes off? 4. There are scenarios in which the suggestions are not aligned with the product strategy and vision the team has agreed to. If that’s the case, it’s important to surface it so that either the strategy can be adjusted to accommodate more of what the broader team was expecting or to stop investments like these from distracting the team.

Executive alignment on your roadmap is pretty key to getting funding and resources to deliver on your roadmap. Your executive team probably cares about customer success, growth, and potentially things like margin/security/compliance. Tie your roadmap to these outcomes very clearly. If you can communicate very clearly HOW your roadmap item helps achieve more than one of these outcomes / benefits, you are more likely to get buy-in.  What happens when you disagree with the executive? Well, that depends on whether the exec is challenging your roadmap prioritization to understand where you're coming from as a mechanism for providing feedback OR if the exec is communicating a mandate to accommodate a strategic initiative. There's a difference. For the former, you can make sure to communicate how your roadmap helps achieve those desired outcomes. If the latter, accommodate away.

It's always good to review roadmaps with leadership on an ongoing basis. These touchpoints allow you to keep your leadership informed and give you the opportunity to solicit feedback.  At the end of the day, gaining alignment is key to getting funding and resources. The leadership team is often looking to understand how your product is doing (e.g., usage, adoption, success stories) and how your roadmap can deliver additional impact (e.g., growth in usage, adoption, customer happiness). Clearly communicating how the roadmap can deliver outcomes will help you get buy-in.    While unlikely, your leadership can use their power to overrule and change your roadmap. When this happens, kindly ask your leadership to help you understand why they are asking for the change. If the rationale isn't sound, it's ok to push back. If the rationale makes sense, use their line of thinking to help your team understand why the roadmap has changed.

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 a two-part question. Let me first articulate how I like coming up with ideas for new opportunities, followed by how I like to make decisions about what to build. Hopefully, you don’t mind that I’m thinking about “opportunities” because it might not always be a feature that’s the right solution. I should start by saying that there isn’t one right approach to coming up with ideas. In my experience, I’ve had success ensuring that there are: 1. Insights from the four lenses: Customer, Business, Market, Technology 2. Effective methods to facilitate ideation At the core, you have to have a deep understanding of the underlying user pain point you’re trying to solve through a thorough investigation of the Customer by talking to customers and product usage. You might actually learn very quickly that the user problem is around discoverability or activation, not necessarily a feature gap. Ideally, the customer impact is so deep that it translates effectively into Business impact. The Market context is critical to help understand how your user will experience the product within the broader competitive landscape and the direction an industry is headed. Finally, the Technology lens offers insight into what capabilities could be used as part of a solution. Preferably, these four lenses come together through cross-functional ideation that has the right participants (e.g. PM, UX, Eng, and even folks go-to-market teams). In a hybrid world where we’re working across time zones, I’ve enjoyed having the opportunity to ideate together synchronously and asynchronously. In terms of decision-making, the ideation process should lend itself to initial layers of prioritization. I won’t go into prioritization frameworks here, but there are many out there. They do tend to distill back to impact and effort and sequencing. At HubSpot, depending on the type of decision we are trying to make, we may use a “driver, approver, contributor, informed” DACI model used by other companies we admire like Atlassian.

Ideas can come from many places. They include customer feedback calls, customer troubleshooting sessions, customer submitted ideas (at Splunk, we have an idea submission portal called ideas.splunk.com), conferences (at Splunk, we host .conf where we have the opportunity to meet many customers in person), ideas from your engineering team (they generate some of the best ideas), and ideas you dream up yourself.   Once there’s a list of ideas, we typically do a full re-prioritization at annual planning. Throughout the year, we also slot in new ideas and do minor re-prioritization as things change. 

When I prioritize or stack rank a list of items, I typically find it helpful to understand how each item can (a) deliver customer impact and (b) increase engineering happiness. Additionally, I also find it helpful to understand each item's level of (c) feasibility, (d) urgency and (e) effort.  I weigh customer impact and engineering happiness at 50:50 -- after all, you need to make your customers happy while also keeping your team excited. Things that are less feasible are often pulled down the list. Whereas things that are higher urgency or less effort might be pulled up the list. At the end of the day, prioritization is an art. 

At Momentive there are several stakeholders that have input into our roadmap, a few main partners and collaborators are listed below: * Other Product & Design Teams * Sales/CS teams * Marketing & Growth * Research * And more… Most cross-functional partners just want to be heard and want to understand whether their requests will be addressed or not. This is why transparency is a key element in all 3 of the following tips to help you maintain the balance between influence and control: 1.  Give your cross-functional partners an acceptable avenue to advocate for customer requests and surface themes they are hearing from the market. We have a very specific process for capturing requests. All requests get routed through a feature request or feature feedback form that is centralized for our product team to analyze and address. We look at the data coming through those channels monthly and roll up the insights quarterly. The expectation is set that we will evaluate all requests but that there is no commitment to addressing any specific requests. An important aside is - As a product leader, be grateful for the feedback that you receive, there are many organizations that aren’t benefiting from the insights you are getting straight from the customer-facing teams. 2.  Help your cross-functional teams feel heard; be transparent about realistic outcomes they can expect. In all of the organizations I’ve had the privilege of working with, the friction between cross-functional product requests and roadmap prioritization was anchored on a misunderstanding of the product management function. Helping your cross-functional partners understand your process, their input’s role in it, and the outcomes that result should help alleviate some of the pressure to “just put it in the roadmap”. 3.  Close the loop - even internally. My team has a quarterly meeting with our cross-functional partners to give them an update on 1) the requests we’ve received, 2) which items have been delivered, 3) which items are in progress, 4) what our current expectations of delivery are, and 5) which ones we’ve recently received. We also address the items they have requested that we will not be delivering and do our best to explain why (e.g. not aligned to our current strategy, not a point of differentiation, we don’t have resource capacity for another large initiative right now, etc). This meeting alone has had an incredible impact on our ability to keep our team aligned with our cross-functional partners.

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 appreciate this question! Generally speaking, we get inputs mostly from sales, customers and product/engineering. I’ve used the approach of building partnerships with stakeholders and that takes care of the influence vs control dilemma. When you have a strong partnership with your stakeholders, they trust you that you’ll make the right product decisions and in turn, you show that you value their inputs. So I would encourage you to think more about building stronger partnerships so you don’t have to struggle with influence and control.

Prioritization is more art than science. My goal is to actively listen to all stakeholders and help communicate how I make tradeoffs and how that impacts timeline to deliver a requested feature. But as a rule... Customers have the most impact on roadmap. Then engineering (especially on tech debt, architecture, compliance, and quality improvements needed). Then, I weigh any influence from market trends and changing competitive landscapes. Here, I consult with analyst relations, product marketing, and competitive intelligence. Then sales/CSM/support to learn trends/issues they're experiencing directly with customers or issues selling.  And sometimes, executive input will trump everything else - but that doesn't happen as often as you'd think unless you work in very top-down work culture. Ultimately, as the product manager, it is your job to make the final call on the roadmap prioritization. It is your primary responsibility!  

In my mind, several groups of stakeholders often influence the roadmap. They include your customers (both internal and external), your product team (e.g., engineering, design, data science), your internal non-product stakeholders (e.g., legal, compliance, sales) and your leadership.  From these stakeholders, it's important to put most of your focus on the ideas coming from your customers and ideas generated by your team. While we all like to work on things that benefit the customer, it is equally important to make sure that your engineering team has the opportunity to work on technically challenging projects even if these things don't always directly benefit the customer.  Then, there are times when your leadership would trump everything. Believe it or not, this doesn’t happen often. 

Good framing is essential for effective prioritization, especially in cases where departments have different perspectives on what to prioritize. In many companies, including my own, the sales team is an important stakeholder in the product roadmap. When working with other departments or teams, you want to ensure that there’s a common language in which to communicate. For example, are both departments aligned on the prioritization of high level business goals? Is there a clear ownership model? Once there's tentative alignment on these topics, it's much easier to have an objective discussion about the opportunities to influence a goal. At Braze, feedback and observations from Sales and Sales leadership is one of the many inputs that we incorporate into forming a perspective on the best way to achieve high level business objectives.

What are your company goals for the year, and how much is dependent on new sales vs retaining exist customers and growing customers? It's important to know, as It can cost five times as much to attract a new customer, than to keep an existing one. But if there is no clarity on this, ask the execs - What % should we allocate to new sales? An effective leadership team should be representiative of other voices too , like marketing, customer success, support etc. Make sure you reflect that voice back effectively. Bring your data to the table so that you can share your perspective on the risk to losing existing customer as well as the oppotunities to upsell or cross sell to them. Bear in mind that sales typically drive incremental growth not exponential growth, so manage expectations accordingly The Roadmap is a reflection of your leadership's priorities, and it's your role to help them make informed decision on investment priorities.

Well, I often incorporate multiple sensing mechanisms into the roadmap - the field and sales team are definitely an important lever to drive revenue, which really is why product managers exist.  So, a tactic I use is to show how much of my engineering capacity is dedicated to enabling revenue, technical debt, and long-term vision. The long-term vision is often a "big bet" that is about making a splash in the market or analyst review. Oftentimes, sales and the field are supportive of carving out time for long-term bets because analyst ratings, whitepapers, and affirmations of the product in the market are great supports for the sales cycle. 

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 like this question because it is such a classic situation. I’ve seen this played out at companies and it’s likely a culture issue that it’s very hard to change unless the Product and Sales leadership teams get together and have a heart to heart about it and come to an agreement on the best path forward. Getting the autonomy you are looking for starts at the top and it has to be a coordinated effort to address the culture and behavior. On the other hand, it’s great to get sales input into your roadmap because they are out there daily with customers. If you are looking for a grassroots approach to autonomy, one suggestion would be to ask sales for a prioritized list of their requests (with a business case) and agree on a number of requests you’ll directly add to your roadmap each quarter. This provides sales a window to your roadmap while providing a balance for you.

When departments have different opinions on prioritization, the product manager needs even more to have a transparent and data-driven prioritization method. Sales is a very important source of prioritization, and the art of product management is to find the right balance between supplying features that will unlock further sales, features that will please existing users, and resolving bugs and tech debt. The old say "it is less expensive to keep an existing user than to acquire a new one" remains true and needs to be embedded in the method. But a good product manager is one who knows how to stay firm with his prioritization in front of all stakeholders without confronting them.

Thanks for the question! You, my friend, are in a coveted position. I would encourage you to shift your mindset and look at it as an opportunity to influence and educate your leadership team on what you know about your customers and create a vision and strategy for your product to share with them. Since the leadership team is new, you have the opportunity to show them that you are proactively thinking about the product direction and execution versus waiting for direction. So take a shot and give it your best.

This is the role of the product managers to bring up what the users want to see built. This is usually not good practice to have the executive giving too much guidance. The executive should give the vision, and the product managers should determine the features on the roadmap based on the prioritization they determined with the users to achieve the vision. It could be an advantage when the leadership doesn't provide guidance as it prevents the bad top-down approach of product management. The executives keep an open-minded approach and fairly evaluate the proposals made by the product management.

Our product development lifecycle process looks very similar to a double diamond design process but with an adapted approach for our organization. While there are best practices for a product development processes, I've found that there is a decent amount of adaptation and adjustment that needs to happen to customize an approach for the needs of the organization. I've not seen 2 product lifecycles that are the same.  At a minimum, a product development process should help reduce friction for the R&D teams, create clarity around what we need to know before we invest, and insight into the variables that influence those decisions. The most mature and refined PDLC programs also create consistant expectations of each role that participated in the product development process, sets criteria for high quality output, and provides clarity on what to do next through each stage. This is extremely benefitial when you think about onboarding new PMs to the team, as well as supporting the growth of PMs new to the role.  Depending on the needs and maturity of your organization, you can chooste to implement a light version of this process that focuses solely on alignment and rescource allocation, or lean more into a more detailed process that provides more clarity on activities you expect the teams to execture for each stage.  A good process provides time and space for the team to engage in activities focused on discovery, exploration, and time in a particular problem space. In this stage. you should avoid solutioning at all costs.  There should be a stage for concept exploration, and I strongly encourage my teams to explore more than 1 concept. Sometimes the first concept we surface is not the best for the job, but inertia and time constraints prevent us from exploring more. I recommend my teams take the time, because it saves us on the rework later.  Once a concept has been validated, there should be a stage that allows you to define the high level requirements and start thinking about an experience that would make it as easy as possible for customers to realize value from your chosen solution for the problem space. For me, customer validation of the specific execution is critical, because we are very rescource constraigned on the engineering side. If I can prevent rolling out soemthing that needs major rework, I will. Some organizations are more constraigned on the research or PM side in which case you may use the experience itself for validation.  There are many types of product development lifecycles, and you should choose an execution that solves the most prevalent R&D problems your organization is facing. 

I don’t believe in a universal end-to-end product development process. I believe there are key rituals and elements that should be present on every team to ensure great outcomes, but each team needs to tailor the development process to their unique situation. My must-have product development elements & rituals: 1. Common Language - Your company should have a common language for the product development process. This is not a prescribed way to do product development for every team at the company (this needs to vary team by team for good reason). At Shopify, we call it GSD (get sh*t done). The base elements are a common language around Product Development stages: 1) Proposal 2) Prototype 3) Build. We have an internal system at the company where you can look at all development projects and the stage that they’re in, how long they’ve been in that stage, when they’re expected to go to the next stage. We also have a common calendar of 6 weeks sprints that is used by the company wide. This helps when you’re having a discussion around when do you think you will have x? This transparency and common language is key. 2. “Agile Research” - This is a term I coined to describe the act of always conducting user interviews. The problem with well-designed research projects is that they take too long and tend to deliver the insights after you’ve started building the thing. Advocate for a “rolling recruit” of your key personas so that you can tap into talking to users *every week.* This ensures you have feedback and insight in the moment you need it most before the product is built and decisions are made. Alternatively, you can create a type of Customer Advisory Board where members opt into research questions, providing feedback, etc on an ongoing basis. 3. Continuous Product Discovery - A common misconception around PMs is once a project is kicked off and being prototyped their discovery work is done. Discovery is a never-ending job. There is a lot of work to be done up front to define the problem and opportunity more broadly, but throughout the development lifecycle there are endless sub-problems that need to be found, defined and shaped. 4. Unstructured Live time with the Product Squad - At Shopify, we refer to this as "Jamming." This is the schedule I tend to implement on my teams: Monday - Problem Shaping, Wednesday - Live Prototyping, Thursday - Fresh Eyes, Friday - Demo. Monday and Wednesday sessions are unstructured live time with the Product Squad. PM, Eng, UX, and Data get on a call and stare at the Problem or Prototype together. PM guides the Problem Shaping meeting and UX guides the Live Prototyping meeting, but the purpose is to tap into all the brains on the team to get to the best outcomes. It can be terrifying for a lot of people. It’s like getting in the car without a destination in mind. You need to create a culture on your team where it’s ok to not have all the answers. To prepare, the PM can have “intended outcomes”, “problem definition” or “options” prepared. During the meeting, the PM facilitates getting insights from the group around what else to consider, what’s missing, etc. 5. Progress every week - Another cultural thing - you need to have rituals on your team to encourage and ensure progress is made in some way, shape or form every week. My favorite way to do this is the weekly demo AND ensure that not only eng presents, but also folks from PM, UX, etc.