Why You Should Stop Solving Problems Before Measuring Them
The Size Of Problem Worksheet is a straightforward assessment tool that helps you determine whether an issue you're facing is actually worth the resources required to solve it. It's used by product teams, engineers, and consultants who've learned the hard way that jumping into solutions without gauging problem scale is one of the most expensive mistakes you can make. The worksheet itself is usually a simple matrix or scoring system where you rate factors like frequency, impact, scope, and urgency, then get a composite score that tells you whether you're dealing with a real problem or just a symptom. You fill in a handful of fields and they combine into a number. That's about it. The fields typically include how often the problem occurs (daily, weekly, monthly), how many people it affects, how severe the consequence is if left unsolved, whether there's an existing workaround, and how difficult it is to verify a solution. Each field gets a weighted score, and the total determines whether the problem is classified as large, medium, or small. A large score means the problem deserves dedicated resources. A small score means you probably should just accept it and move on. Medium is where most teams get stuck and waste their time.
I've seen teams spend three sprints building a feature because they assumed the problem was bigger than it actually was. The worksheet would have scored it a 4 out of 20. They came back to it every time, frustrated, asking why nothing got done. The issue wasn't execution. The issue was they never bothered to measure the thing they were trying to solve.
Where People Go Wrong With It
The biggest mistake is treating it as a one-time formality rather than an honest assessment. Everyone fills it out optimistically. They rate frequency as daily when it's actually twice a month. They rate impact as critical when the actual consequence is mild inconvenience. This inflates the score and makes a small problem look large, which leads to overinvestment. Another common pitfall is conflating a hard problem with a big problem. Some problems are technically difficult but affect very few users. A Size Of Problem Worksheet will correctly score those as low priority, which frustrates engineers who want to solve hard things. That's a separate discussion about team motivation, not a flaw in the worksheet. There's also the issue of subjective weighting. Two people can look at the same problem and assign completely different scores to the same field. This isn't a bug. It's a feature that reveals disagreement, which should be discussed openly before the scores are locked in. I've had people argue for forty minutes over whether a problem's impact should be scored as 7 or 9. We ended up using the midpoint and moved on. It was still useful.
Get the Full Details
A Practical Example
Last year I worked with a SaaS company that was getting complaints about their onboarding flow. The team wanted to rebuild the entire welcome sequence. I ran the worksheet and here's what we got: frequency scored 8 (weekly at most), impact scored 6 (users churn within the first session), scope scored 3 (only affecting a specific enterprise segment), workaround scored 7 (account managers manually onboard these customers), and difficulty to verify scored 5. Total came to about 29 out of a possible 50, which placed it in the medium range. Medium meant the problem was real but not urgent enough to justify a full rebuild. We ended up making three targeted fixes instead of rebuilding the flow. The changes took two weeks and reduced the complaint rate by about sixty percent. A full rebuild would have taken eight weeks and might not have moved the needle much more.
When the Worksheet Fails You
It doesn't work well for problems that are early-stage or barely visible. If only two users have complained about something, the worksheet will score it tiny. But that could be a leading indicator of a much larger issue. In those cases you need to supplement the worksheet with qualitative research. Talk to the users. Look at support ticket trends over time. The worksheet is good at measuring known problems, not discovering hidden ones. It also doesn't account for strategic importance. A problem might score low but align directly with a company's stated strategic priority. In that case you solve it anyway because the business has decided it matters, regardless of the raw numbers. The worksheet is a decision aid, not a decision maker. If your organization needs something more sophisticated, you can layer in a RICE scoring model (Reach, Impact, Confidence, Effort) on top of the worksheet results. That gives you a more granular view, especially when you're comparing multiple problems against each other for limited resources.
Getting Started
You can find templates online. Most are just Google Sheets or Excel files with the scoring fields built in. The exact format matters less than the discipline of filling it out honestly. I'd recommend having at least two people complete it independently, then compare scores. The gaps between their assessments are usually the most interesting part of the exercise. That's where you find out what assumptions are driving the disagreement, and fixing those assumptions is often more valuable than the final score itself. The worksheet won't prevent every bad decision. It won't stop leadership from greenlighting something for political reasons. But it does give you a concrete data point to reference when someone says the problem is urgent and you're not sure they're right about that. Having a score on paper is better than arguing from opinion alone.
