How I Actually Used the Problem Atlas to Plan a Quarter

Every quarter, my team at Ambiki (a practice-management platform used by speech, occupational, and physical therapy practices) has to answer one hard question: what should we build next?

For the first quarter of 2026, I didn’t want to answer it the usual way. The usual way is a wishlist: a pile of feature requests, the loudest customer’s favorite idea, last week’s escalation, and whatever the most senior person in the room happens to remember. A wishlist will give you a roadmap. It just won’t give you a good one, and it definitely won’t give you one the team believes in.

A real plan has to do two things. Everyone has to know what we’re building, and everyone has to understand why: why these problems, and how we landed on them. A wishlist delivers neither. So instead of assembling one, I ran a Problem Atlas: a problem-driven way to build a roadmap, and one of the core tools in The Problem-First Method.

This is the field report — two surveys, one messy spreadsheet, a couple of meetings, and the quarter we committed to at the end of it, including the parts I’d do differently next time.

The trap: planning from a wishlist

I had a specific failure mode in mind. When you build a roadmap from requests, you optimize for the wrong thing: whoever asks loudest, most recently, or most senior. The quietest, most expensive problems, the ones nobody happens to be complaining about this week, never make the list.

There’s a subtler tell, too. Ask a team for “problems” and most of the answers come back as solutions. After years of building software, I’ve noticed our customers rarely arrive at support saying “I have this problem.” They arrive saying “I have this solution”: add this column to the export, change this button color, move this menu over here. They might be right. It might be exactly what we should build. But a request is not a problem, and a roadmap built from requests has skipped the most important step without anyone noticing.

The discipline (really, the whole discipline) is to pause, recognize a solution for what it is, and go back to the problem underneath it. What is the customer actually trying to do? What breaks when they can’t? Sometimes a different solution erases a whole cluster of problems at once, and you’ll never see it if you start from the request. Skip that step often enough and you become a feature factory: shipping steadily, tickets closed, and a product that somehow feels less coherent every quarter.

Why I chose the Problem Atlas

The Problem Atlas is a problem-driven roadmap. Instead of a list of features in flight, it’s a catalog of problems, each written without a solution baked in, each rated on how much evidence we have that it’s real and how much fixing it would matter. You prioritize on evidence and impact, not on volume of requests. (The full template is free: the Problem Atlas template.)

I had a specific reason for reaching for it now. A quarter is a real budget — three months of a small team’s time, the most valuable resource we have. And going in, I knew our sense of “the biggest problems” was scattered. Support saw one set of problems. Engineering saw another. Sales and implementation saw a third. No single person had the whole picture, and a single planning meeting would just hand the quarter to whoever argued best on the day.

So I decided not to run one meeting. I ran a structured, two-phase exercise (surface first, then rate) and only then sat down to decide. (The Problem Atlas is Chapter 15 of The Problem-First Method; this article is what it looked like in practice.)

Phase 1: surfacing problems from the whole team

Phase 1 was a short survey (about fifteen minutes) sent to seventeen teammates across support, engineering, sales, implementation, and leadership. It asked two questions. First: what are the top three customer and product problems you’re seeing right now? Second: what are the top three bigger, more ambitious problems (company-wide, not just product) that you think we need to solve?

That second question matters more than it looks. Some of what holds a company back isn’t in the product at all; it’s in how the company works. Splitting the prompt gave people explicit permission to name both, instead of cramming everything into a product-shaped box.

I went deliberately broad before going deep. The whole point of Phase 1 is coverage, not precision. Support lives in the billing tickets. Engineers feel the quality and release problems. Sales hears why deals stall. Implementation watches new customers struggle or thrive. Nobody sees all of it — so I asked everybody.

What came back was messy. Seventeen people produced eighty-eight distinct problems: fifty-seven on the customer-and-product question, thirty-one on the ambitious one. Some answers were a single line. Some were an essay. Many were duplicates of one another in different words, and plenty, as expected, were solutions wearing a problem’s clothing. That’s fine. Phase 1 is supposed to be complete; the tidying comes next.

From 88 brain-dumps to one clean list

Then came the unglamorous part. Honestly, it’s the part where the method actually starts. I took all eighty-eight raw answers and rewrote each one as a single, clear, solution-free problem statement. Where two people had described the same pain in different words, I merged them. Where an answer was really three problems stapled together, I split it. The eighty-eight became a deduplicated list of roughly eighty-six distinct problems.

Rewriting is not busywork. It’s the first real filter. The Problem-First Method has a rule for this (write what hurts, not what fixes it) and a test: read the statement aloud without naming a feature or a technology. If you can’t, it’s a solution in disguise. Here’s a real before-and-after from this exact survey:

Same underlying reality. But the first version has already chosen the answer; the second leaves room to ask how bad this really is, who it affects, and whether two-way texting is even the best fix. Do that eighty-six times and the wishlist turns into a catalog a team can actually reason about.

Phase 2: rating every problem by evidence and impact

A catalog of eighty-six problems is still too big to be a plan. Phase 2 was about pressure. It forced the list to show which problems actually rose above the rest.

I put all eighty-six problems into a second survey and asked a smaller group (seven teammates with deep, cross-functional context) to rate every one on a one-to-five scale. Five stars meant two things at once: we have strong evidence this is a real problem, and solving it would genuinely move the needle for the company. One star meant the opposite: we don’t really have evidence yet, or it’s the kind of thing that wouldn’t change much even if we fixed it.

The instruction I gave them mattered as much as the scale:

This is your chance to rank all of the problems from the first survey… be thoughtful and pragmatic. We can’t tackle everything in a single quarter, so please avoid giving everything five stars and focus on what you would truly prioritize.

That constraint is the engine. A rating scale only works if it’s allowed to discriminate. Most teams call a problem “validated” the moment one customer complains once; forcing a spread makes that impossible to fake. The book frames the same idea as an evidence ladder, which is the cleaner way to think about how sure you actually are that a problem is real:

The results were clearer than I expected. The seven raters didn’t scatter — they largely agreed. The bands were narrow, and twelve problems separated cleanly from the rest with an average of four stars or higher. That group of twelve was the answer to a question we’d never actually answered before: what are the highest-priority, highest-impact problems this team thinks we need to tackle this quarter?

The alignment meeting: pressure-testing the twelve

A survey result is not a decision. Before the twelve problems could become a plan, I sat down with the same seven people who had rated them and worked through three questions:

1. Do we actually agree these twelve are the highest-priority, highest-impact problems, now that we’re looking at them together, not rating them alone?
2. How should we organize the team to give ourselves the best shot at solving them?
3. What does “solved” look like for each one? If we fix it well, what is true three months from now that isn’t true today?

That third question is the one teams skip, and it’s the one that saves you. “Solved” has to be a future state you can recognize: a number that moved, a workaround that disappeared. A feature can ship without the problem ever going away.

Talking through the twelve, they sorted naturally into clusters. Some were product problems, but many were sales, marketing, support, and implementation problems:

Seeing them grouped like this changed the plan, because it made one thing obvious that a product-only roadmap would have hidden.

Deciding the quarter

On December 19 we held the Q1 planning meeting with the whole team, and I walked everyone through all of it: the surveys, the twelve problems, and the plan they pointed to. I wanted two things out of that hour: everyone leaves knowing what we’re doing in Q1, and everyone leaves understanding why and how we got there.

The twelve problems became the roadmap, not a list of features. The roadmap is literally those twelve problems, the ones the team surfaced, rated, and agreed on. That’s a sentence I could say out loud to the whole team and have it be true, which is the entire point of doing the work this way.

But the clusters forced a real strategic decision. If most of the twelve had been product problems, the move would have been simple: point the product team at them. They weren’t. A large share were sales, marketing, and implementation problems. And at the company level, what Q1 most needed was traction: winning new customers and showing real, visible progress on growth. You can hire a hundred engineers and build a flawless product and still not win a hundred customers; product quality is necessary, not sufficient.

So instead of aiming the whole team at the product, we paired people across it. We formed small, cross-functional groups (engineers working alongside sales, marketing, implementation, and support), each group owning a cluster of the twelve problems. We described it as a hackathon in spirit, minus the stay-up-all-night part: people from different corners of the company pointed at the same problem.

A few changes to how we operate shipped alongside the roadmap, all in service of that first goal, everyone knowing what’s going on and why:

• One weekly all-hands replaced three separate recurring meetings, and it opens with how the company is tracking against the quarter’s goals.
• A single shared channel where every group posts what it’s working on.
• A simple red/green marker in daily updates (an accountability nudge a teammate suggested) so a project slipping from “two weeks” to “two months” shows up early, not at the deadline.
• A pre-release review folded into QA: demo a feature to the whole company before it ships, not after.

Plenty of good ideas didn’t make the twelve. They weren’t rejected, only deferred. We plan one quarter at a time, on purpose. The roadmap is what we’ve committed to now; the longer-term vision still holds, and a problem that didn’t rise this quarter gets another honest hearing at the next planning round. Naming that out loud is what makes a “no” land as “not now” instead of “never.”

What was hard, and what I’d change

The exercise worked — it killed the wishlist and gave us a roadmap with a defensible reason behind every item. But it wasn’t clean. If you try this yourself, expect a few rough edges.

People answer with solutions. Phase 1 was full of fixes dressed as problems, which made the rewriting step in the middle heavier than I’d planned. Budget real time for it. That’s where the method earns its keep, and it can’t be skipped.

A single 1-to-5 rating is convenient but blunt. To get seven busy people through eighty-six problems quickly, I folded “how sure are we this is real” and “how much would fixing it matter” into one number. It worked well enough to surface the twelve. But evidence and impact are different things. A problem can be very real and low-impact, or genuinely huge and barely evidenced, and collapsing them into one number hides exactly that distinction. The book keeps them as separate fields for good reason; next quarter I’ll separate them too.

Raters can’t fairly score what they can’t see. Even with seven people chosen for broad context, nobody had real visibility into every corner of the company. A rating from outside someone’s domain is closer to a guess. A “no basis to rate” option, or scoping each rater to the areas they know, would sharpen the result.

The Atlas ranks problems but doesn’t size them. It told me which twelve problems mattered most. It didn’t tell me how much each would cost to solve, or whether twelve was even the right number for one quarter. That’s still judgment. The Atlas makes the judgment honest; it doesn’t make it for you. (When a top problem’s root cause is still murky, that’s a job for a Five Whys, not the Atlas.)

How this maps to the Problem Atlas in the book

If you’ve read The Problem-First Method, you know the Problem Atlas template gives every problem six fields: a solution-free problem statement, an evidence level, pain metrics, reach, business value, and a stage. What I ran for Q1 was a deliberately lightweight version of that, enough to plan a quarter without asking seventeen people for a dissertation.

The problem statements were there in full; that’s the rewriting step, and it’s non-negotiable. Evidence and impact were there too, compressed into the star rating. But I didn’t fill in detailed pain metrics, reach percentages, or business-value figures for all eighty-six problems, and I didn’t track a stage for each. That’s fine, and it’s the point. The Atlas is a living document, not a one-time form. You start light enough that people will actually do it, then deepen the entries that survive: the twelve that made the cut are the ones now worth full pain, reach, and value detail as we work them.

If you want to run this yourself, start with the Problem Atlas template (it’s free) and the 10-Question Problem Validation Checklist for pressure-testing a problem before you commit to it. Once the Atlas has told you which problem to solve and you’re ready to design the fix, a Feature Alignment Document is the next tool in the chain. The whole method (the Atlas, the rest of the framework, and the stories behind it) is in the book.