Problem-Solution Fit Comes Before Your Feature List

An all-in-one product can make perfect sense on a whiteboard. The features connect neatly, each missing piece suggests another module, and the roadmap begins to look like a complete answer.

The uncomfortable question is whether anyone has established the problem underneath it.

FiscoBud gave me a reason to step back from that kind of thinking. The early concept brought together fiscal, financial and workflow concerns for independent workers. Those areas are related, which makes it easy to accumulate features that sound mutually reinforcing. But a coherent product concept is not evidence that a particular group needs that combination, at that moment, enough to change how it works.

This is a reflection on the project’s direction, not a launch announcement or a claim of validated demand. The useful change was returning to questions about the problem before treating the feature list as the plan.

A category is not a problem statement

“Independent workers need better financial tools” is broad enough to support almost any proposed feature. It says little about who struggles, what they are trying to accomplish or what happens when the current approach fails.

A person starting independent work may be trying to understand unfamiliar obligations. Someone with an established business may already have professional support but lack a useful view of operations. Another person may have a narrow, recurring workflow that is awkward to complete across several tools.

These are possible problem areas, not customer findings I am reporting. Their value is showing how quickly one audience label can conceal different needs. Education, uncertainty, business control and a specific administrative workflow might call for very different interventions.

If I begin with a dashboard, every problem starts looking like missing visibility. If I begin with an automation, every problem starts looking like unnecessary manual work. The proposed solution becomes a filter that edits the evidence before I have collected it.

I would rather write the situation in ordinary language: who is doing what, under which constraint, and with what consequence? That sentence should still make sense if the product idea disappears.

Features are commitments to an interpretation

A feature is more than a piece of implementation. It encodes a belief about the user’s problem and about how the product should respond. Building several features in parallel can therefore multiply untested beliefs while creating the feeling that uncertainty is shrinking.

Take an illustrative planning tool. A forecast assumes that useful inputs are available, that the user trusts the calculation, that the result influences a decision and that the decision occurs often enough to justify the effort. A polished interface might validate none of those assumptions.

Adding educational content would introduce another interpretation: perhaps uncertainty comes from missing knowledge. Adding reminders suggests that remembering is the difficulty. Adding integrations suggests that transferring information is the obstacle. Each could be useful. They are different explanations, and they should not be bundled together merely because they fit one navigation menu.

This is the part of product work that engineering habits can obscure. Implementation gives me tangible progress. Understanding why a proposed feature may not matter can feel less productive, even when it prevents a much larger waste of effort.

The remedy is not to stop building. It is to connect the next thing built to a question whose answer could change the plan.

Give an experiment a decision to make

The Lean Startup methodology places learning at the centre of the build-measure-learn loop. I find that framing useful when the “build” is selected to resolve an uncertainty rather than to demonstrate how much of a product can be completed.

For an early FiscoBud direction, I would start with a narrow assumption. For example: a defined group repeatedly struggles to understand a particular operational decision, and its existing workaround is costly enough to reconsider. That is an assumption to investigate, not a statement that the project has already proved.

The next activity could be a structured conversation about a recent occurrence, a walkthrough of an existing workflow or a small assisted pilot. Which one makes sense depends on what remains unknown. A prototype can test whether an interaction is understandable while saying little about whether the underlying problem is important.

Before running the activity, I would write what result would change my mind. If every possible answer leads to the same roadmap, the exercise is serving presentation rather than discovery.

I would also define the scope of the inference. One participant completing a task can reveal an interaction problem. It cannot establish the prevalence of a need across a market. A paid pilot can provide evidence about that particular commitment while leaving retention and acquisition unresolved.

Keep the evidence separate from the interpretation

A simple working record can help avoid accidental certainty:

The example is fictional. The separation is the point. Without it, a small observation can become “users need a dashboard” after a few rounds of discussion.

I want contrary evidence preserved too. If someone already solves the problem comfortably with a spreadsheet and professional advice, that is useful information. It may identify a segment I should not target. It may reveal that the proposed value depends on a different circumstance. It should not be edited out because it makes the concept harder to explain.

There is a practical benefit to this discipline: the team can disagree about an interpretation while still sharing the observation. That creates a more productive conversation than competing summaries in which the original evidence has disappeared.

The next article, validation beyond positive reactions, develops this distinction into a more concrete research approach.

AI can accelerate the wrong learning loop

My bachelor’s thesis, How to Reach Problem-Solution Fit? AI-Powered Build-Measure-Learn Loops, examined AI-assisted learning and experimentation, including FiscoBud and Bundyclock. The research summary describes the project and its scope. I am not using it here as proof that AI automatically improves validation.

The attraction is clear at the workflow level. Assistance can help organize notes, propose alternative explanations, compare concepts and prepare experiments. Those are useful activities when the underlying material is trustworthy and the interpretations remain reviewable.

The risk is that an attractive synthesis becomes a substitute for contact with the problem. A model can generate a plausible description of an independent worker’s frustrations without observing anyone. It can produce a convincing interview guide that mainly confirms the assumptions embedded in the request.

I would use it to challenge the idea as deliberately as to develop it. Ask which claims lack evidence, what other explanation fits the observation and what result would weaken the current direction. Then take those questions back to real situations. The generated answer is preparation for learning, not the learning itself.

That boundary matters more as implementation becomes easier. Faster construction makes it possible to test sooner. It also makes it possible to build a larger response to an unexamined problem.

Smaller can mean more specific

Stepping back from an all-in-one concept does not necessarily mean abandoning ambition. It can mean choosing a problem with sharper boundaries and a more credible path to understanding it.

A vertical workflow might be less visually impressive than a comprehensive platform, but it gives the next experiment a clearer subject. Which step is difficult? Who owns it? What information is missing? What happens before and after it? How would a useful intervention fit the existing work?

I would still watch for dependencies. A narrow feature may require access to information that users cannot provide, or trust the product has not earned. Smaller scope reduces some questions; it does not answer them automatically.

Reversibility is useful here. A limited experiment should allow the project to learn without making every early assumption expensive to change. That might mean a manual process behind a prototype or a bounded pilot rather than an extensive integration. The choice should match the uncertainty being tested.

The roadmap can wait for a clearer sentence

For me, the valuable outcome of revisiting FiscoBud is the permission to distinguish a product I can imagine from a problem I understand. Those are both legitimate stages. Confusing them makes the roadmap look more certain than it is.

I still want to build things. I just want the next feature to have a better reason to exist than its ability to complete a tidy concept. Before adding another module, I would like to finish a less impressive sentence: this group encounters this situation, the current response has this consequence, and here is the evidence that makes it worth addressing.

Sources

1. The Lean Startup: Methodology — checked 2026-10-11