Crafting compelling proposal outlines is one of the most underrated product management skills out there. It’s often though of as “shallow work” or just another type of documentation to maintain, which couldn’t be further from the truth.
There are great product ideas out there that don’t get the necessary buy-in just because a product manager couldn’t pitch it well enough. There are also poor ideas that make it on the roadmap just because someone could tell a compelling story around them.
The better you are at making proposals, the higher the chance you’ll get resources and support to execute your ideas. Crafting product proposals is one of the key career-boosting skills in product management.
In this article, you will learn what proposal outlines are, how to best craft them, and how to leverage them within your role as a product manager.
Although proposal outlines can take various forms depending on the type of organization you work for, they all usually serve a single purpose — to get a buy-in from stakeholders for a particular initiative.
This is why I tend to use the terms “proposal” and “pitch” almost interchangeably. In reality, when crafting a proposal, you are pitching an idea.
Although there are endless scenarios in which you might want to pitch something, most of the time, product managers pitch one of two things:
Later in this article, I’ll cover the differences between these two with sample proposal structures.
There are a few things to consider when writing a proposal outline. Keep in mind, though, that there’s no silver bullet, and the best approach will depend heavily on your organizational context and the type of stakeholders you work with.
Resist your urge to add an executive summary to your proposal. Unless you are pitching a C-suite-level business model change, aim for specificity and simplicity.
I prefer bullet point structure; it keeps the document well-organized and easily scannable.
The proposal aims just to kickstart and ground the conversation on the topic. There’s no need to put all the details upfront.
The quality of your proposal will set expectations for the quality of your idea. You want to avoid having your idea killed just because the way you described it didn’t spark people’s imagination.
Revise the proposal at least twice before sending it further. Make sure each sentence helps strengthen your pitch and can be understood by people without the same context as you have.
If you pitch numerous proposals every month, it’s essential to keep them in the same format. It makes them easily comparable and allows for better prioritization.
While it’s perfectly okay to evolve the structure of your pitches as you learn more about what works and what doesn’t, do it only every now and then. Otherwise, you are pushing too much of a cognitive load onto your stakeholders.
You should be able to back up every claim you make in your proposal.
If you have solid evidence, attach relevant links and references to strengthen your proposal. If you don’t yet have enough evidence to back up some claim, consider spending some extra time gathering it before submitting the final proposal.
The objective of a product discovery proposal is to generate buy-in for investing resources into research of the new direction.
At this stage, you usually don’t have a specific idea of what to build and are more interested in exploratory research around a particular theme.
To maximize the chances of getting a buy-in, you need to prove that:
I tend to structure discovery proposals in the following manner
Let’s dig deeper into this format.
Briefly introduce the problem you’d like to explore. Include the reason why you believe the problem is severe enough to focus on it right now.
Example
Include any proof and evidence that supports the earlier statement.
Example
Sometimes, it’s not worth solving even the most painful user problems if they only impact a small percentage of users or if solving the problem doesn’t lead to meaningful business outcomes.
My go-to approach to opportunity sizing is usually:
Example
Briefly describe what you want to pitch. I usually include methods I want to use, the timeline for the initiative to give the sense of effort, and the resources I’d need to make that happen.
Example
It’s easy to say, “we want to learn something about X,” but try to get specific. Developing specific research questions will:
Example
Delivery proposals are usually more specific than discovery proposals. After all, if you pitch to build something, you better have solid evidence that it’s the right thing to do.
They also tend to be more expensive, thus requiring stronger justification and evidence.
I usually approach my delivery pitches in the following manner:
Describe briefly what problem you are trying to solve and why the problem is worth solving. If you previously pitched a discovery phase for the initiative, include a hyperlink in the proposal.
Example
Introduce a proposed solution for the problem. Although it might be tempting to go into details, don’t. Stakeholders rarely need it.
I usually add only one or two sentences describing the solution and then add relevant hyperlinks for any extra details. I learned that most of the time, stakeholders aren’t interested in specific user stories and design and just need a high-level overview.
Instead, I recommend focusing more on the hypothesis itself (what makes you think the proposed solution is the right one?) and the underlying assumptions (what must happen for this hypothesis to be true?).
It shows stakeholders that you really thought through the initiative. It also helps ground the discussion around specific assumptions rather than stakeholders’ opinions and gut feelings.
Example
Very few stakeholders are interested in how exactly you will develop a particular feature. Instead, focus on the effort (cost) and timelines. The former helps assess the ROI of the investment. The latter helps in planning it alongside other company initiatives.
Example
What are your target metrics for the pitched MVP?
If you pitch an idea requiring months of investment, you should go as far as to bring evidence-backed forecasts and projections. Luckily, our ideas are usually smaller and can be done within a couple of weeks.
I tried semi-scientific approaches in the past, but I learned that those are not only time-consuming but also very inaccurate.
However, I also discovered that a well-reasoned gut feeling is often enough for most stakeholders. After all, you usually don’t need complex calculations to assess if you are discussing a 5 percent lift or a 300 percent lift idea.
Make your best guesses based on the knowledge you have and move on.
Example
Proposal outlines are much more than just another piece of documentation.
By crafting well-thought, well-structured proposals, you maximize the chances of getting stakeholders’ buy-in. These extra resources lead to a bigger impact and a bigger impact leads to faster career growth.
There’s no silver-bullet approach to crafting proposals, but the structure depends on:
However, there are a few universal rules you can apply in almost any context:
Fingers crossed for your next proposal outline, and leave a comment in case I can help you in any way!
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.
A well written PRD is one of the most concrete ways you can crystallize your work and provide value for your team.
Active listening is the act of listening to what someone is saying while observing their non-verbal cues, intonations, and intent.
Payton White talks about how to create a consistent experience by maintaining the feeling that the brand wants to evoke in the customer.
A product specialist (PS) is a person with extensive knowledge about a specific product or product management-related responsibility.
Learn more →
