Tips for managing stakeholder input: are there any templates or best practices for when to gather input and how to incorporate (i.e. whose feedback to incorporate vs. ignore, etc.), especially as it relates to a timeline?

This is a bit tricky, especially if the feedback provider is an exec. One of the tactics that has helped me in the past is to outline what is in scope versus what is not. Be clear on this and have your approvers align to it. When suggestions that are out of scope and could impact your timelines, reference that initial proposal/project brief, “great suggestion, we would love to incorporate that in the next phase, edition, general availability, etc. but it is not in scope for this phase of the project”.

Thinking of this through a project lens, I have seen DACI or RAPID frameworks help by assigning clearer roles and decision-making responsibilities. The project owner then knows who they need to involve to gather input from, who they need to keep informed, who can contribute to the decision, and who can block it. I've seen this approach work well with a product launch, for example, which is a huge cross-functional effort. It allows demand gen teams, product marketers, content teams, PR and others to be clearer about their role, provide input, and share the dependencies and deadlines that need to be adhered to in order to execute their part of the project.

My second tip is to avoid decisions by committee -- it's paralysing! I would try to limit the number of people who approve/sign off on a project.

Finally, to manage stakeholder input, be conscious of people's time - it's a finite resource. Large group meetings going through status updates are generally not valuable to anyone. Gather the updates in advance and use the time together to review blockers and agree on the next steps.

From the beginning of a project, set clearly defined objectives and goals. I believe the key to managing stakeholder input is to lay the foundation from the beginning. It’s much harder to manage stakeholders and their feedback if the structure is not set from day 1. If each interaction anchors to this then your stakeholders won’t experience surprises.

Clear communication is going to be necessary as well. My preference is to get ahead of the questions. Define how you are going to communicate progress and measure performance. You’ll find it is much easier to manage timelines if your stakeholders have an expected cadence for communication. This also helps manage the opinions that are received from multiple channels at multiple times (which makes project management difficult).

Lastly, documentation is important. Will everyone read it? No, but it serves as a point of reference for stakeholder management. As input is gathered and documented, you should also define if it is in scope or part of a future phase. Acknowledge the input and show it as captured and not forgotten, but also reinforce what will be incorporated now versus what will be part of the backlog for prioritization.

In my experience, the RASCI matrix/model has been incredibly helpful for determining whose feedback to incorporate vs. ignore. The people who need to be consulted and informed are usually the most significant stakeholders and tend to be senior leaders in the organization attached to the project who will sign off on shipping it once it's done. It's integral in getting their feedback early on to help set the direction of the project.

With that being said, it is not required to incorporate all of their feedback if it's not going to help the project reach its objective. This question is incredibly tricky to answer, as there are many nuances to incorporating feedback. Ultimately, I feel strongly it is the project leaders call to make on what feedback to incorporate or ignore, as they know the project goals, medium, and message best and should take ownership over the direction of the work.

When it comes to timelines and a project is in its final stages, I would keep feedback to a minimum and between the most integral people on the project. Opening up a project for wider critique or further feedback from more teams/people towards the end is bound to cause delays and unnecessary roadblocks. The reality is that in order to do good, fast work, the number of people providing ownership and feedback on a project should be the bare minimum.

This is where alignment with Sales leadership goes a long way. Depending on your company size and complexity, you could encounter a scenario where you are getting various input from multiple reps that may conflict / create too many priorities.

With that said, gathering input and processing that input should be a regular practice. Certainly when you start - but also as a recurring thing. One thing I recommend is to use your calendar here - literally schedule time on your calendar to check-in with sales. Create a standardized approach to getting information. Create bi-directional discussions.

Beyond that though, listen to their sales calls. And even more so, talk to customers! You'll build a ton of credibility if you are actually getting real-time insights from customers.

As it relates to what feedback to use / ignore - I'll go back to the alignment with Sales Leadership piece. Ultimately good leadership knows you can only do so much. So distill your feedback down into something you can discuss with leadership, and agree on what should be prioritized. That MUST then be communicated back to the rep so nobody simply thinks you are just ignoring their input.

My rule of thumb - you can't ever make everyone happy. But if you create alignment and manage expectations through over-communication and then doing what you say you will do - you'll make a lot more people happy!

For each cross-functional project, I build a clear RACI with one ultimate decision-maker for each milestone. This defines who has the power to green-light the project, and it is shared during the introduction phase of the project. It’s important to make clear who has decision-making power vs. consultative power early on in the project and get buy-in from leadership. 

Likewise, it’s important to provide a strong workback schedule with go-no-go dates that have to be met and be clear on when deadlines will push and which teams will be impacted. If needed, this work can be up-leveled to managers if too many projects are impacting downstream teams.

“A camel is a horse that was designed by committee.” - Sir Alec Issigonis

Marketoonist Tom Fishburne has a fantastic cartoon on this as well.

When determining stakeholder involvement in a project, it’s important to understand who should actually have input if you show a campaign or design to 20 people, chances are that they could all give you some suggestion for improvement, but the question is, how much of that is meaningful?

When dealing with timelines and deadlines, clearly communicate with your stakeholder group on the deadline you are trying to meet as well as their level of participation when planning your project timeline, take into account schedules and reasonable review times, but communicate clearly when deadlines to make changes are

Revisions can quickly get out of hand, and if you feel your project is in danger falling prey to this suggest an A/B test to get data to back future decisions.

Ship. Learn. Iterate.