An artfully presented board with moveable letters that reads “Turn ideas into reality”
An artfully presented board with moveable letters that reads “Turn ideas into reality”
Photo by Mika Baumeister on Unsplash

How to pitch feature ideas to a product manager

Here’s the scenario: You are a non-product person working at a SaaS company. You’re in customer success and you spend your days building relationships with clients, teaching them how to use your product to meet their business goals. You receive a steady stream of product feedback from your clients, and between that feedback and your own thoughts, you’ve got a long list of feature requests that you want to share with your product team.

Because you care about your clients and your product, your goal is to get your feature request ideas picked up by your product managers — how can you make that happen? Giving you a framework to accomplish this is the goal of this article.

Before we begin, it is important to know that there are always many more ideas coming in then there are resources to implement all of those ideas.

Your ideas, even the ones that seem easy or obvious, are competing against dozens or hundreds of other ideas for attention. Your ideas will have the best chance to break through if you invest in building a case each idea so that others can understand the why as well as you do.

In this article, we’re going to dive into how to structure your feature pitch by example, working through the details of a fictional pitch and explaining each element in depth. By the end of this article, you should have the framework you need to structure a compelling pitch for building a new feature — this framework will work as a starting point for pitching entirely new products, but the focus of this article is a bit more narrow.

Let’s get started — what is the first step to writing your pitch?

What’s the problem?

Start by clearly defining the problem that needs to be solved.

Let’s say our feature idea is to add a new column to an existing report in our make-believe app. The problem is not that the column is missing in the report. Instead, the missing column is a potential solution to a yet-to-be-defined problem. Most product people thrive on solving problems — if you want to make an impact with your idea, focus on the problem first, not a solution.

So — how do we get from a potential solution to a well-defined problem? Let’s dive into our missing column idea to walk through the process step-by-step.

Problem statements, by example

Let’s look at two possible ways to frame our missing column feature idea:

Example 1:

A client wants to add a column to the widgets report that tells them the average time it takes for a space widget to move from design to development.

Example 2:

Yesterday, I spoke with Janet, a user on the Passenger Service To Mars account. Janet called in because PSTM is working on an initiative to make their team more data driven. One of the key data points they are interested in measuring is how long it takes, on average, for a space widget to move from design to development. Average space widget cycle time is not an available column in our existing reporting. I believe that we should make this metric accessible for PSTM and others accounts through our widgets report.

You can probably guess that the second example is the better approach — but what makes it better? Let’s walk through it piece-by-piece and try to understand what purpose each section serves.

Telling a story

Yesterday, I spoke with Janet, a user on the Passenger Service To Mars account. Janet called in because PSTM is working on an initiative to make their team more data driven.

We start by introducing our problem with a real world example that provides context and color to help the reader place themselves into the user’s shoes. We learn the name of the person who called, the account they belong to and, most importantly, we learn about the business context that the problem we are surfacing lives in. Janet and her team want to be more data driven and they want us to help them do that.

Getting specific

One of the key data points they are interested in measuring is how long it takes, on average, for a space widget to move from design to development.

Now, we learn precisely what the user wants. We haven’t suggested a solution, but we’ve identified the problem and, since we’ve already set the business context, three sentences into the writeup, we already have a lot of insight into how we can help this user and why helping them might be valuable.

Clarifying the current state and offering a solution

Average space widget cycle time is not an available column on our existing reporting and I believe that we should make this metric accessible for PSTM and others accounts.

Finally, we wrap up by stating that we’ve done some research into the user’s problem, thought about a potential solution, and have been unable to identify a way to implement that solution. This additional context helps answer an obvious question for your product team (do we already have a way to do this?) and starts the gears churning on ways to solve the problem.

Revisiting the bad example, briefly

Now that we understand a little bit about why the good example is more effective, let’s revisit the bad example and talk about what it is missing.

A client wants to add a column to the widgets report that tells them the average time it takes for a space widget to move from design to development.

Instead of starting with an illustrative example that provides context for the problem and an anchor to the real world, we’re talking about “a client”. Who is the client? What does this client care about?

Next, we jump right to a solution to an undefined problem. “[they] want to…” doesn’t help us understand why this is a need, or what value it would provide to the user — offering a solution without a problem puts the onus on your reader to invent a problem solved by the proposed solution. This is a great way to end up on the fast track to the “will not implement” pile.

Taking the good example further

We’ve established that telling a story, providing business context, and clearly identifying the problem are all good things. If I do those things am I guaranteed that my idea is going to get picked up? Probably not!

While the “good” example above is probably sufficient to get someone to read your idea and give it a few moments of consideration, it does not do a very good job of advocating for the value of the idea. If we call our above idea finished, we’re not likely to stand out from the crowd.

A well-stated problem and a potential solution is pretty easy to come up with and if you work at it you can come up with dozens of paragraph long descriptions of problems your product should solve. There are always lots of good ideas, and the work of building a great product is sorting through the ideas and making bets on the ones that feel most likely to produce the outcomes you’re seeking (more revenue, higher engagement, more MAUs, etc.).

If you want to have influence on the process as a non-product person, remember that your ideas don’t exist in a vacuum and that your ideas are competing with many, many other ideas for space on the product roadmap. That means that a clear write up of a problem is only step one. Once you’ve defined your problem, next you need to explain the value that solving your problem will bring to the business. Your product team should be interested in outcomes — help them understand the outcome solving your problem will produce.

Let’s go back to our example idea from before and talk about what supporting evidence we should compile to build our case.

Building the case: Who the idea impacts

Our example used Janet to tell our story. This is a great way to frame the problem, but it introduces a question we should address: Does anyone else have this problem?

If we have 1,000 users, and we only have evidence that a single user is affected by a problem, our first step should be looking for other users who have the same problem. If only one person has the problem, your product team is not going to solve it.

It can sometimes be difficult to think about how to build this part of the case, especially if you are in a role where you are used to talking with people as your primary role — do I have to talk to all of my users and ask them if they have this problem?

Good news — you do not have to talk to every single user every time you have an idea for a new feature! How you build the case will change based on the information you can access, but often you can start by asking yourself if you should build the case : “Have I ever heard anyone else talk about something like this?” If the answer to that question is no, the best thing to do is to file away the problem for now — don’t take the time to write a proposal up if you’ve never heard the problem before.

If you have heard the problem before, or if you want to dig deeper to see if other people have heard the problem, how you dig deeper depends on what data you have access to.

Good places to look as you start your research might include:

  • Your notes from previous conversations
  • NPS or other survey feedback
  • Support cases
  • Client-facing idea portals, if your company has one

As you work through this part of the exercise, it is important to keep in mind that you want to find other people who have a similar problem, not necessarily people who want the exact same solution. In our data driven example, you may be looking for other people who have talked about working on data initiatives for their teams or people who have contacted your support team asking how to access similar data points.

We’re looking for general trends that help support the value of making data more accessible and that might end up being a pretty broad bucket!

Building the case: What impact the idea could have

Knowing that other people care about the problem you’re working on is a good start, but going further, you should project the business impact that solving the problem will have.

This section can take a variety of forms and how you approach it will often be driven by what role you play in the process. If you work in sales, you may focus on the projected revenue solving a problem might bring in. If you work in customer success, identifying revenue that is at risk of churning if the problem isn’t addressed may be your focus. Other times, you might identify an internal metric that solving the problem will improve, such as an anticipated reduction in support case volume, an increase in NPS, or hours of manual work saved by internal team members who are tasked with implementing workarounds for the problem.

The key thing to keep in mind as you work through the business impact is that your goal is to help the reader understand why they should prioritize the problem you are surfacing over all of the other problems and solutions that they have in front of them. The more detail you can provide and the more compelling you can make your case, the more likely it is that your idea will rise to the top.

Updating our example

Now that we know what other information we should provide to build our case, let’s go back to our example idea one more time and see how we can expand it to give it a better chance of making it onto the roadmap.

Let’s imagine that we’ve talked to other people about similar issues in the recent past, and that we have access to NPS data from the last few months that helps us write up a case for the broader applicability of our idea.

In the past 3 months, 6 other users have mentioned that they are leading their team on initiatives to be more data driven. Three of those users specifically mentioned that they are interested in driving down cycle time from design to development. Those 6 users belong to accounts like Journey To Saturn ($5,000 MRR), Flight To The Sun ($15,000 MRR), and Jump Across The Room ($50 MRR).

Now our reader has a lot more information to use to consider the problem more broadly and they have a better picture of who might be interested in solutions to this problem.

Let’s wrap up by taking some time to work on the potential impact to round out our idea.

The users that I’ve talked to have each indicated that lack of access to data around their recruiting process is a major blocker for their business. Of the 6 NPS responses I reviewed, 5 of the 6 were detractors who indicated that access to data was a factor in their rating. In total, these accounts are worth $25,000 in MRR.

Based on my conversations with these accounts, I estimate that if we do not address these data access needs, we could lose $5,000 or more in MRR within the next 6–9 months.

Bringing it all together

Let’s take a moment to read through the entire example, so we can reflect on it as we wrap up this exercise.

Yesterday, I spoke with Janet, a user on the Passenger Service To Mars account. Janet called in because PSTM is working on an initiative to make their team more data driven. One of the key data points they are interested in measuring is how long it takes, on average, for a space widget to move from design to development. Average space widget cycle time is not an available column on our existing reporting and I believe that we should make this metric accessible for PSTM and others accounts.

In the past 3 months, 6 other users have mentioned that they are leading their team on initiatives to be more data driven. Three of those users specifically mentioned that they are interested in driving down cycle time from design to development. Those 6 users belong to accounts like Journey To Saturn ($5,000 MRR), Flight To The Sun ($15,000 MRR), and Jump Across The Room ($50 MRR).

The users that I’ve talked to have each indicated that lack of access to data around their recruiting process is a major blocker for their business. Of the 6 NPS responses I reviewed, 5 of the 6 were detractors who indicated that access to data was a factor in their rating. In total, these accounts are worth $25,000 in MRR.

Based on my conversations with these accounts, I estimate that if we do not address these data access needs, we could lose $5,000 or more in MRR within the next 6–9 months.

One important thing that happened as we developed this idea is that it grew from suggesting a very specific solution — adding a column to a report — into the identification of a more general problem related to data accessibility in our product.

Our proposal for a new column might be part of the solution that gets implemented, but if we had stopped at just asking for a column without the extra context 1) the business need for our idea wouldn’t have been very clear and 2) the larger opportunity might never have surfaced.

The process of developing an idea often leads in this direction — if you limit yourself to specific solutions to contextless problems, the quality of your ideas and the impact they can have on the business will suffer.

The idea template

What we created above is just one way to surface a compelling idea. How you approach the creation of a new idea proposal will vary based on how you’re most comfortable communicating ideas, what the actual idea is, what data you have access to, and what your end goal is for the idea.

If you are a visual thinker, you might find that it is helpful for you to sketch your idea, or you might find that using bullet points helps you organize your thoughts. You might find it helpful to think through detailed solutions to the problem or you may find it limits your ability to think about the problem if you focus too much on solutions.

The form of the idea isn’t particularly important as long as it hits these key points:

  • Provide a real world example
  • Establish the business context
  • Identify the reach of the idea
  • Explain the impact the idea will have

Note that I didn’t highlight offering a solution as a key point. The solutions to a problem can take various shapes, and any solution is likely to go through iterations as design and engineering teams do their work. Proposed solutions don’t hurt, but they aren’t a requirement for selling your idea.

Final thoughts

This process might feel daunting. Isn’t writing up a detailed problem statement someone else’s job? Shouldn’t I just focus on capturing client requests and let my product managers sort out the details? Why should I go through all of this effort?

Those are fair questions. The reality is that even going through all of the effort to write up a great pitch is not going to guarantee that your idea makes it onto the roadmap. You can probably find occasional success by just writing up context-free solutions. Sometimes your solution will line up with an idea your product manager already had, and they’ll give you the credit.

So why bother with all of this extra work?

Because building a strong business case will give your ideas a much better chance to succeed, giving you more influence on the direction of your product than you would have otherwise. Going through this process will also help you stretch your skills as a thinker, a writer, and a data analyst if ways that you might not expect. I hope that this deeper thinking will help you be a more effective, strategic thinker.

Have feedback for me? Have another method that you would like to share? Let me know in the comments.

Product, engineering, and marketing leader. I care about being kind, helping others grow, and building cool things. Infrequent tweets @davidcolbyatx

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store