As a product manager, you know everything about your product, customers, and competition. You know what the pain points are and have likely identified areas of opportunity to improve the product.
But how do you go about actually getting approval to work on a project you know will be extremely valuable? This is where your project proposal is key!
The steps for product development are quite simple: start with discovery, identify the problem you want to solve, do the research, validate the solution, build it, and ship it.
But any product manager knows those “simple” steps are quite involved — they take a lot of communication before anything is added to the roadmap, let alone get shipped. The good news is if you thoroughly lay the groundwork for your key stakeholders early and set the right expectations, the risk of building something your customers do not want or need is virtually eliminated.
So how can you achieve that? Through writing a darn good, highly-detailed project proposal.
The proposal aims at answering all those burning questions on stakeholders’ minds like “Why should we build this?” or “How does it benefit our customers or our company?” or “Does it differentiate us from our competitors?” Even more so, it gets leadership and teams aligned on the project and how it ladders up to the company’s key objectives or OKRs.
Having a project proposal is like having a blueprint of the house you are going to build so that the buyers know what it will look like before investing in it.
Think back to the times you wrote all those long papers back in school. There was a structure to them — a clear beginning, middle, and end. You should treat your proposal the same. Just remember, keep it simple and direct using research, facts, and data.
The format of a good proposal lists these elements:
Let’s go over each of section of a project proposal in-depth below.
The executive summary is one of the most important elements of your proposal. It summarizes the project in a digestible format so that anyone reading it understands what the project is and its benefits right out of the gate.
The next section in your proposal should dive into the details of the project. Why is this project important? Why should we invest in it now and what are the benefits to customers and the company?
This is a great place to include any data you have or customer feedback about the value of the project. You should also list out what personas this is for and any use cases you have identified that further support the project.
Having insight into the market and your competition is one of the most important jobs for product managers. This section offers you an opportunity to show you’ve done the research and know your product and the market. Include details on who the competitors are and if they offer something similar.
Make sure to document how this project differentiates your product in the market from the rest. Including any screenshots, videos, or documentation around similar features with both direct and indirect competitors in this section of the document helps strengthen your pitch.
It would be great if we lived in a world where building products is free. However, that is not the case and how your project may affect the company’s bottom line is super important.
This section details any costs associated with the project. These costs could be in the form of data storage, headcount required to build the product or feature, any third-party integration costs, etc.
If what you intend to build is something you plan to charge for, what does that pricing structure look like? How does this pricing fit in with the larger company pricing structure? You can also include information about how other companies price and sell similar products as a comparison.
Break down how you are thinking about delivering to customers and turn these into milestones. Clearly document the release phases, all the way from MVP and having something beta ready for customers to full general availability. Add details of what the deliverables fall under each phase and beyond.
It is very important when creating this proposal to have the right conversations with the right people that may be impacted by your project. This section highlights either constraints for the project — like a deadline or limited resources — as well as any risks involved.
Lastly, how will you know this project is a success? Use this section to get very specific on your success metrics — whether they are qualitative or quantitative.
For example, success metrics could be increased utilization, increased revenue, decreased number of calls to support, or decreased customer complaints. If you have specific values to commit to, that is even better.
Based on everything we outlined above, here is a free, basic project proposal template that you can use and customize for your projects:
Remember that you can add any additional information or sections if it would be helpful for the stakeholders you are presenting to. A project proposal should highlight all of the important elements of a project, so it may make sense to customize it based on the needs of your own organization.
Okay, you have your proposal down, now for (gulp) perhaps the most nerve-wracking part — delivering it to stakeholders. Relax, you have prepared your research and have outlined all the details in your proposal! Now you just need to share all those findings with your stakeholders.
A few tips I recommend from pitching many proposals over the years would be:
Chances are your stakeholders are very busy people. So getting them away from their responsibilities for even 20 minutes is tough.
This is where you will need to understand who your audience is and what pieces of your project they will care about the most. Once you identify this then you can prioritize the order in which you want to go through the proposal.
I know you want to get this over with and out the door, but you have a mission here to make sure you take time to acknowledge questions and jot down follow-ups.
Listen carefully to what is being suggested and asked. It is OK if you do not have all the answers and don’t be afraid to admit that just take a note to follow up post-meeting once you’ve had a chance to figure out the answer.
After the meeting, either later that day or latest the next day, send out a follow-up. Thank those for attending, attach the recording if you recorded the meeting, link to your proposal, and add a high-level summary of what was discussed during the meeting. This double confirms alignment, acts as a paper trail, and reduces the chance of miscommunication amongst the group.
Proposal writing for product management can seem like a daunting task, but the positives far outweigh the negatives in devoting time to creating one. Being able to create a document that clearly outlines the scope of the project for stakeholders is a vital step toward the success of the overall project.
And remember, communicating with the right stakeholders is a huge part of the success of the project. So, while it is extremely important to prepare for delivering your proposal realistically, your communication with stakeholders should be a constant feedback cycle even before the project proposal is written.
Keeping your stakeholders close to the project and constantly in the loop ensures no wires get crossed or unrealistic expectations get set which ultimately means smoother execution and less stress on your end!
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Phil Freo shares his experience scaling Close from its founding team to more than 100 people and transition to being a fully remote company.
Nick Fisk shares his experience leading transformations and transitioning companies to a product ownership model.
It’s easy to hide behind charts and justify decisions with shallow metrics. But great product teams resist that urge.
Tony Schumacher shares important lessons he learned and has taken with him from working under his former boss and mentor.
Learn more →
