throw out your spec—meet the problem page
If not a spec, what?
We all know—I don’t love a spec. I don’t like “requirements doc,” and I certainly do not like a waterfall process. That said, we product managers have to do, well, something, right? Probably. One of the key foundational activities of a product manager should be exploring and defending what should be prioritized and why. We can’t just say “no” and expect people to go along with it. That would be much too easy. Instead, we have to justify why certain things are more important than others.
A quick tangential aside on prioritization
One of my pet peeves with some leadership teams is their inability to effectively prioritize. You’ve probably seen this before—a list of 20 company priorities are presented, and 10 of them are P1s, 8 P2s, and 2 P3s. I just want to be clear here… this is not prioritization. This is basically saying “EVERYTHING IS EQUALLY IMPORTANT except for these other things that we will never have enough time to do”
This IS NOT helpful. By definition, you should have more P2s than P1s. P1 is the top of the pyramid. If the top of the pyramid is larger than the bottom, well, first of all, it isn’t much of a pyramid is it? And more importantly, the damned thing is going to topple over. Please don’t crush us with your inability to prioritize, dear leaders.
Enter Problem Pages
Since we know people won’t take our word for it, we need to put pen to proverbial paper and make the case. To do this, I find it very effective to create an internally-facing document for each general set of problems—a problem page. This document should articulate what problem set you’d like to address, for what audience, and why.
While this page should serve up data and facts, its purpose is also to persuade your internal audience that this is, in fact, the thing you should be working on. This is the time to get on your soapbox, to tug at heartstrings. You want a rallying cry that is as persuasive as Daenerys on her best day. You want for someone to read your words and jump up from their desk to CHARGE!
Note: This has never happened to me, but a girl can dream.
Anyway, I love to see this in a wiki format—whether that’s Confluence, Notion, or something similar. It should live in a place that is easy for engineers to find, product people to collaborate on, and internal stakeholders to engage with through comments. This is why I call it a “problem page” and not “problem document that will never change.”
I also want to note that what is covered below only pertains to the first part of the process. This same page will eventually be used to communicate possible solutions, eventual designs, and progress updates when actually in development. But, for the sake of brevity (who, me?) we’ll leave that for a future post.
Before you dig in
By the time you’re writing a problem page, you should already have done a ton of information gathering that led you to the point of creating the page. You shouldn’t need to do explicit research on the what, as that was likely the impetus for prioritizing the problem to begin with.
Before you even start, you should already roughly know the following:
Who within your customer base is facing this challenge or would benefit from addressing this area
What the problem is
How the problem fits into your vision for the product
How the opportunity fits into your team’s goals
A Word to Newbies
This is one of those things that gets way easier with practice and familiarity with your product area. If you’re new to being a PM or new to this concept, this is gonna suck a little bit. That’s ok. If you’re new to a particularly complex product, this is gonna suck a little bit. I promise you, though, that with time and experience this will be incredibly straight-forward.
If you are new to this concept, I’d highly recommend reading examples that already exist in the world. It might also help to start with a straw man of one of your problem areas, and then pair up with a more experienced PM to flesh it out. Engineers are always pairing up, but it’s just as useful for product managers. Talking these things out have a way of solidifying the reasoning in our heads.
So what’s in a Problem Page?
There is a basic, recommended structure to a problem page. The exact headings and sections aren’t worth losing sleep over, but you should make sure the content is there.
Overview
Description of Problem or Opportunity
This is an overview of the problem you’d like your team to solve.
It could be:
A challenge current users are facing
A capability deficit preventing new customers from adopting your product
A usability issue preventing customers from finding / using / valuing something in your product
An opportunity for some tangentially related problem space that isn’t represented in your current product
It should be:
Phrased in terms of the challenge(s) you hope to tackle
It should NOT be:
A specific feature
A description of a solution to the problem
Target Audience
This might seem relatively self-explanatory, but it’s important to make this as broad or as scoped as is needed to really describe who you’re going to solve these problems on behalf of.
Things to consider
If you have a multi-tiered product, is the problem space most important for a subset of tiers?
Is there a certain size of customer? A certain captured revenue?
Is this for existing customers, is it to encourage existing customers to choose a higher tier? Is this to attract new customers?
Is this meant to impact/help an internal audience? (Very often this might be Support, Fraud, Trust & Safety, Billing, etc)
Problem Prioritization
To really make a compelling argument about WHY you’re assigning priority to an issue, you may need to go back and gather more detailed information than you needed when working on the overview section. I highly recommend you have as much explicit data as possible—both qualitative and quantitative.
Customer Impact (Qualitative!)
Get yourself some customer quotes. I’m talking first names of specific people. I want you to be able to write about Andrea who is trying to accomplish this task for her company. It’s a brutally manual process, and she dreads it every month. In the meantime, Wes from this other company is having nearly the exact same challenge.
You’ll want to discuss the FUD (fear, uncertainty, and doubt) of users in this area, and really tug on the heartstrings of your audience.
Supporting Data (Quantitative!)
Collect a variety of quantitative data, which could include any of the following:
How much this impacts your customer
Hours spent
Money spent
Satisfaction levels
How this issue impacts growth
Blocking deals?
Would unlock a market?
Contributing to churn?
How this issue is placing burden on an internal team
Billing Team has to do x things manually each month
Customer Support is receiving x tickets per week
Trust & Safety spends x hours per week addressing this issue
Don’t forget to quantify qualitative results if you have them!
NPS
Customer satisfaction
Task success
Company Goal Relevance
Time to bring it home. You’ve already tugged on heart strings to show why this is important to your target audience. You’ve queried the data warehouse to prove this is a meaningful pursuit. Now it’s time to relate it back to your team’s goals (which... hopefully roll up to your company’s goals…). How will this move your team toward its goals? How will this help achieve your company’s goals?
Now, this does not have to be a hard company metric type goal. A lot of us get caught up thinking this has to be a number like cohort retention rates or customer acquisition numbers or churn rates, but those are just a subset of the type of goals your team might be pursuing. Your goal might be to increase customer satisfaction, or to increase task success on a particular feature, or even to simply half an answer to a problem area that your competitors already address. (Though, never implement something just because your competitor has it. Perhaps this is a good topic for another post.)
The key here is to make a compelling argument that not only is this problem important to your customers, but it also helps the team move toward its goals.
Go forth and write
Let me know if you’ve ever tried something like this, and how it went for you. Do you have an example you’d be willing to share? Any helpful tips to share with your fellow PMs? Comment below! I may pull together some examples for a future post (with permission).
