Pain points only exist within the context of jobs-to-be-done
a helpful mental model for unlocking the problem space
In recent posts, I’ve argued that sustainable business growth requires the ongoing creation of new value for customers and that solution-first thinking (a.k.a. product centricity) fails as a system to deliver that. With customer-centric product management (CCPM), the opportunity for growth lives in the problem space. Products that solve problems are vehicles for delivering progress that customers desire, and value delivered to customers is the ceiling on business opportunity for a firm.
“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” — Albert Einstein
When teams talk about problems, often they blend jobs and pain points. Customers use mixed language, too. However, jobs-to-be-done (“jobs” or “JTBDs”) and pain points actually push in opposite directions. Jobs are progress-oriented, while pain points are things that get in the way of progress. Pain points are resistance that people must overcome in order to fulfill their jobs-to-be-done, and they can strongly influence customer decision-making.
It’s helpful to remember that pain points only exist within the context of jobs. After all, pain points wouldn’t be pain points if they were not an obstruction to what a user is trying to achieve (a.k.a. the job-to-be-done). Nesting pain points within jobs-to-be-done can be a useful mental model during product planning. Here are some reasons why:
1 Jobs help with long-term thinking. Markets are not stationary, and pain points do change. Pain points like “there aren’t enough EV charging stations near me,” “the internet is too slow for streaming video,” or “solar panels are too expensive” are impermanent. However, this is the language customers will often use to convey their wants and needs. Firms that frame up product work in the current environment become more transactional in nature rather than relationship-oriented. They will be less responsive to market shifts. Product-thinking that begins with the job sets the stage for serving customers over lifetimes. Since customers are the central economic unit in customer centricity, building relationships that evolve with them means building residual equity in each customer, which contributes to firm value.
2 Jobs-thinking expands opportunities for innovation. Pain points often stem from current solutions rather than the customers’ job-to-be-done itself. Pain points such as “my internet is slow,” “passwords are hard to remember,” or “this interface is confusing” are all solution-dependent. Solving current pain points may anchor ideation to current solutions. Aligning pain-points to jobs can help preserve a focus on users’ desired progress less constrained by the state of current solutions.
“The electric light did not come from the continuous improvement of candles.” — Oren Haran
3Jobs help align teams. Siloed problem-solving that comes from assigning discrete pain points rather than broader jobs-to-be-done should be avoided. For a product organization split into feature teams, this is the unfortunate norm that is definitively not customer-centric. With large-scale initiatives, multiple teams need to pull in the same direction to maximize impact. This extends beyond product teams. JTBD-level clarity can be an exceptional tool for aligning the activities of many teams toward serving a common customer objective.
FOR EXAMPLE:
Consider the target job of helping traveling performers fill empty dates on their calendars last minute. Many teams need to contribute:
→ Product teams will need to build this market-matching capability and experience.
→ Partnerships will need to sign venues onboard.
→ Legal will have to come up with agreements that work for venues and artists alike, which can be executed quickly and online.
→ Marketing will need to get the word out to traveling performers and venues.
→ Talent acquisition may need to find some industry veterans to join the team with specialist expertise.In the OKR framework, all five teams could share the same multi-quarter (O)bjective. Each team can then define quarterly (K)ey (R)esults that reflect a suitable measure of success for its contributions. This empowers each team to apply its own capability toward the initiatives that best align to driving a key metric that supports the shared objective across teams.
4 Aligning pain points to job context adds focus. A product can get very complicated by trying to solve every problem without the context of progress desired by target segments. Each feature not relevant to a given user circumstance becomes an experience burden, so by solving for the few, product teams sometimes end up penalizing the many (think: Microsoft Office toolbars through the 2000s). Product fragmentation leads to slower development cycles and higher risk of unintended consequences with each release. Changes become even more expensive with complexity. Simple is hard. Focus on pain points that fit within the jobs that are most important to priority user segments, and deprioritize the others.
“The main thing is to keep the main thing the main thing.” — Stephen Covey
5 Pain points are hard to prioritize without an aligned job. Once pain points are filtered to those nested within the highest priority jobs-to-be-done, teams must prioritize within the job. Without understanding each pain point in the context of an overarching job, it is difficult to assess the relative value of each to customers. Aligning pain points under their respective jobs-to-be-done helps mitigate the apples and oranges problem, so that product managers can prioritize by relative impact of an encompassing customer job, including all its rich context.
FOR EXAMPLE:
You are the product lead for a transit app. Your team has highlighted two pain points raised during a recent consultation with customer support:
(a) it takes several tries for customers to generate the ticketing barcode they need to scan when boarding, and
(b) customers are complaining that digital ticketing is not available on Android.
Which is a higher-priority pain point to solve? How do you decide? Yes, you should look at things like how many people are affected, and surface any potential quick-win opportunities, but in real life, there may be dozens of these in your backlog, and many look very similar. So, which pain point do you address first?
What if I told you the app’s target job is to reduce transit delays by speeding the boarding process?
What if I told you the app’s target job is to make public transit more accessible to all citizens?
“Risk comes from not knowing what you’re doing.” — Warren Buffett
Jobs are a great forcing function to think about how investments ladder up to driving customer outcomes rather than focusing on often disconnected, yet often critical, pain points along the way. By preserving the context of the parent job-to-be-done, teams can make sure the most impactful product investment decisions are prioritized.
