Good Problems are Load-Bearing Problems
Good Problems are Load-Bearing Problems
Res Extensa #75 :: What do we mean when we say "that's a good problem to have?"
In the early days of Fulcrum, within the first few months after we shipped an MVP and started charging our first few customers.
A user could sign up and create digital forms and start collecting data, and even run primitive reports. We'd closed the loop on a common workflow, enough that we had dozens of signups in the first month. We were stoked. After months of building, prototyping, testing, rebuilding, and reshipping, something clicked. New users were finding us online and giving us money for what we built. But we ran into a problem.
The initial paid subscription we offered only supported single-user mode. It only took a few weeks of the product out in the wild to realize what was missing. There was an immediate fit for the product to the customer need (data collection), but these users wanted to bring their team onboard to collaborate. We had plans for multiplayer support eventually, but the demand spike was immediate. We had a problem to solve, and quick. But it was a good problem to have.
What do we mean when we say "good problem to have"? Why would a problem be good?
A "good" problem is clearly visible, and can be articulated in-depth. It's salient and undeniable. The missing solution is self-evident because the problem's left and right edges are clear as day. And importantly, a good problem signals the need for a solution — hopefully your solution. It's like watching an assembly line fall apart because one link in the chain is broken. We can see exactly what's wrong because the missing link is obvious.
Good problems to have are load-bearing. There's a weight of expectation that can be measured, which means we can design a means to support it. If a roof load is 10,000 pounds, we can use that quantified number to design the underlying rafters and wall framing to hold it up safely.
In our case with Fulcrum, the need for multiplayer support in our app was abundantly clear: people told us! They wouldn't stop telling us! And this problem was great because we could define it in sharp detail — we knew exactly what to build, and we knew there was this latent demand to solve it.
I'm reminded of this quote from the late Clayton Christensen:
Questions are places in your mind where answers fit. If you haven’t asked the question, the answer has nowhere to go.
Problems are places where solutions fit. The more we understand about the problem's context and details, the clearer it is what can be done about it.1
Good problems indicate unmet demand: gaps in an expected outcome, struggles encountered during the course of getting work done. A good problem to have is one where demand for a solution outstrips the supply of available solutions.
What makes a problem good to have? A good problem to have is a problem that emerges after the flywheel is already spinning. It emerges at scale, under rapid growth. Since the flywheel is already spinning, the momentum of the flywheel can be turned toward solving the problem. A rapidly growing ecosystem will be intrinsically motivated to solve obvious problems of scale.
–
, Create Good Problems to Have
If we can solve a good problem, there's net positive upside. A bad problem, on the other hand, is one where a problem appears with no related benefit — the servers are down even with limited use, no one responds to appeals to try the new feature, you have to update the subscription billing code, but you still have no one to bill.
In the world of making products, problems are so fragmented, varied, and elusive that good-to-have, load-bearing problems are a godsend. They telegraph exactly where to spend your time.
A solution's viability, cost, and practicality are different — yet very important — matters. But the first step is knowing even what the problem is in the first place.