Open Site Navigation
  • Mike Lattiak

The Market Prioritization Framework (Part 2: Managing Your Pipeline)

Mike Lattiak, Senior Product Manager


With every product comes a backlog - whether it be big, small, lean, or bloated. It is the engine that allows your product to drive down the roadmap. So when your backlog is running on empty, how do you fuel it back up? Without a proper pipeline to deliver new data into your backlog, you run the risk of breaking down.


In this section, we’ll help you build a healthier backlog by identifying gaps in your pipeline and brainstorming ways to encourage data to push through. By completing these steps, you’ll be able to have more confidence in the overall direction of your product.


Mapping Your Pipeline (SET Method)

Let’s begin by mapping out how you receive information from your market. This can be done on a whiteboard and is meant to be a collaborative exercise across the entire product team. We will be following the SET Method for mapping your entire pipeline.


What is the SET Method? Well, it stands for Source - Expert - Tool, a three part flow that showcases the lifecycle of a feature request.


On the left hand side of your map, you will want to outline all the sources for your feature requests. These are the direct individuals who are sending out the requests. Your sources shouldn’t be granular, instead focusing on groups of sources. Examples of this would be:

  • Customers

  • Buyers

  • Internal Stakeholders (requests coming from your own organization)

To the right of these sources, you will want to begin mapping out how they submit their feedback. For example, look at your customer base and outline out each and every way they send a request. Are they using an online submission form? Are they talking to us in person? Breaking down by user personas can be very helpful here, especially if you realize that each one communicates differently with your product. Below is an example of how this mapping might look for a product that has customers and internal stakeholders:


You can see above that customers have four different ways to submit feedback to the company. They can talk to a customer support representative, they can be part of a sales demo, they can attend a user group meeting, or they can simply use a request form. Meanwhile, internal stakeholders submit feedback through weekly product meetings, demos, and an open slack channel. While you may be tempted to brainstorm new ways for users to send in feedback, hold off on that for now. We just want to map out the present - not the future.









Next, it is time to see how this information gets to your experts. An expert is an individual who has the qualifications to assess priority and update your backlog accordingly. Typically, these are the product managers in your organization. Mark your ‘expert’ on the map and begin making connections.


Here is where you will likely make these connections:

  1. You’ll see a quick link between the source and the expert. Sometimes your source directly connects to the expert with no middle-step needed.

  2. You’ll need to map out extra steps in order to observe how the request gets into the expert’s hands. For example, a request might go to customer support first and then go to the expert after a meeting occurs. You might also want to designate the frequency of requests, whether it be daily or quarterly.

  3. You’ll observe what is called a black hole, where either the source has no means to connect to your company, or the request never makes it to an expert. Make sure to indicate that on your map.

Finally, you’ll want to talk about what tools are being used to not only capture the requests, but get them into your backlog. Throughout the map, outline all the tools your organization uses. Are all requests going into these tools? Are their requests from specific sources that might hit an expert but never be documented? These are further black holes that should be examined. Below is an example of a completed pipeline map:


In the example above, it’s shown that there are two areas of the pipeline where feedback is not reaching the product team. The remaining map eventually makes its way to the product team, going through various tools at different times.


After completing this step, take a step back and examine your own map. You’ve successfully crafted your feedback pipeline. Is it confusing? Messy? Overly simplified? Or is it cluttered with black holes? Now will be the time for your team to analyze your findings and see how you can make improvements. Discovering black holes is crucial to understanding where you have critical gaps. You’ll want to make an action item for your product team to evaluate those gaps and see how they can be repaired.


Engaging Your Sources

It is one thing to have a pipeline established, but having it produce reliable and relevant data is another. Even when reviewing your map you might have identified areas where you simply are not getting as many requests as you’d imagine. Or maybe you want to fix a black hole but don’t know how to convince the other department to switch tools. Let’s break down some common strategies you can use to engage your sources to keep your backlog nice and healthy.

  • Treat Your Process Like a Product: Submitting feature requests can be an intimidating and error-prone process. Most of your sources, whether they are users of your product or people in your organization, will have reservations about sending in feedback. Your product team should look at the pain points each department or user persona has when it comes to giving you feature requests. Note these problems and find out how your specific organization can address them.

  • Educate, Educate, Educate: Sending feedback is a muscle that not everyone has exercised in the past. People naturally experience, hear, or feel pain points relating to the product but don’t have experience converting what they are seeing into useful feedback. When it comes to internal team members (sales, customer support, etc), the product team should reach out and frequently educate the art of submitting feedback to the company.

  • Be Transparent in the Value: If people can see how the pipeline works and what immediate benefits it has on the end product, they will feel far more invested in being part of the magic. This is very useful when onboarding a new client, who might not understand that your roadmap is fueled by customer feedback. If you have any case studies or examples of how customer requests have shaped your product, send them out!

  • Tool Assessment: Looking at the tools in your pipeline, ask yourself if they are helping both the source and the product team in collecting feedback. Tools that have a high frequency of leading to black holes should be re-evaluated on their usefulness.

Now that you have your product values (both current and aspirational) and a solid pipeline, it is time to take a deep dive into your requests. In the next part, we’ll be using everything we learned to help determine the overall market value of each feature request.