A roadmap can become a list of features very quickly.
Add this screen. Improve that flow. Build the next integration. Redesign the settings page. Support another platform.
Lists are useful, but they can hide the most important part of product work: what each change is supposed to teach you.
For a small app portfolio, a better roadmap is often a set of questions.
Features Are Answers to Problems
A feature should be an answer to a problem, not the starting point of the conversation.
Before adding a feature, ask:
- What user problem does this solve?
- How are users handling that problem today?
- What part of the current experience is creating friction?
- Why is this more important than the other available work?
- What would we expect to see if the change helps?
These questions create a stronger connection between development and usefulness.
For Rally Track, the question might involve making scoring during a match faster or easier to follow. For Bean Hunt, it might involve helping users record a coffee experience with less effort. For Real Estate Manager, it could involve making lease details or move-in and move-out tracking easier to maintain.
The feature is not the goal. The improved outcome is the goal.
A Question Keeps the Scope Smaller
When a roadmap begins with a feature, the scope can expand in several directions.
A simple request may lead to new settings, new data models, new notifications, and new screens. Each addition may be reasonable on its own, but the original problem becomes harder to see.
A question creates a natural boundary.
If the question is, “Can a new user understand the main workflow more quickly?” the work may be limited to onboarding copy, the first screen, and one clearer action.
If the question is, “Can users review their past activity more easily?” the answer may require a history view, but it may not require an entire analytics system.
A focused question makes it easier to stop when the problem is solved.
Different Apps Need Different Questions
A portfolio of small apps should not share one universal roadmap.
The products have different audiences and different definitions of success.
Heirloom is concerned with making old letters readable and preserving their meaning. Fillbook is concerned with helping traders organize and review their activity. Fillin is built around a daily word-puzzle loop. A property-management app needs dependable records over a longer period. A sports app needs to remain clear while the user is actively playing.
These products may share release systems, support practices, and deployment workflows. They should not be forced into the same product strategy.
The questions should match the job of each app.
A useful question for one app may be irrelevant to another. That is not inconsistency. It is product-specific thinking.
Good Questions Create Better Feedback
A question also makes feedback easier to interpret.
Suppose the question is, “Do users understand the main value before starting?”
Feedback might include:
- Support messages asking what the app does
- Users leaving during onboarding
- Reviews describing unexpected behavior
- People opening the app but not reaching the main action
- Test users using a secondary feature before the primary one
None of these signals is a complete answer by itself. Together, they can reveal where the product’s promise is not being communicated clearly.
If the question is, “Does this workflow save time?” then the relevant evidence changes. You may look for repeated actions, abandoned flows, or requests for shortcuts.
Without a question, feedback becomes a pile of observations. With a question, it becomes easier to decide what matters.
Not Every Question Needs a Large Release
Some questions can be answered with a small change.
A revised label may show whether users understand an action. A new default may show whether a setup step is unnecessary. A reordered screenshot sequence may show whether the product is being explained clearly. A better empty state may help reveal whether users know what to do next.
Small changes are valuable because they reduce the cost of learning.
If the change does not help, the product has gained information without absorbing a large amount of complexity. If it does help, the result may justify a larger investment.
This is a useful pattern for independent builders because attention is limited. A small experiment can move a product forward while preserving room for other responsibilities.
A Roadmap Should Include “Not Yet”
A good roadmap contains more than active work.
It should also include ideas that are intentionally waiting.
An idea may be waiting for more user feedback, a clearer business case, a platform dependency, or evidence that the problem is common enough to prioritize. Writing down the reason prevents the idea from becoming an open mental loop.
“Not yet” is a real product decision.
It means the idea has been noticed but does not currently deserve to interrupt the work in progress. That protects focus without losing the possibility of future improvement.
A waiting list can include the original problem, the evidence so far, and the condition that would cause the idea to move forward.
That is more useful than keeping a vague promise to “get to it eventually.”
Questions Help With Portfolio Priorities
When several apps are active, questions help determine where attention belongs.
An app with a clear, important question may deserve the next work session. Another app may be stable and need only monitoring. A third may have ideas but no strong evidence yet.
This creates a practical portfolio rhythm:
- Choose the most important current question.
- Make the smallest change that can provide useful information.
- Observe the result.
- Decide whether to continue, revise, or stop.
- Record what was learned before moving on.
The rhythm does not require every app to receive equal attention. It requires every decision to have a reason.
That makes the portfolio easier to manage and the work easier to explain.
The Builder Learns Alongside the User
A roadmap built from questions creates two feedback loops.
The first is about the user: does the product help them complete their task?
The second is about the builder: does this process create a better way to choose, ship, and support the next improvement?
Over time, the second loop can become a meaningful source of leverage. A clearer question leads to a smaller release. A smaller release creates cleaner feedback. Cleaner feedback improves prioritization. Better prioritization reduces wasted work.
The product improves, but the operating method improves too.
A Question Is a More Honest Commitment
Feature lists can create the impression that progress is measured by how much gets built.
Questions create a more honest standard.
They make room for an answer that says the feature was useful, the idea needs revision, the evidence is inconclusive, or the change should not be pursued. Those are all valid outcomes.
The purpose of a roadmap is not to guarantee that every idea becomes software. It is to help decide what deserves to become software.
For a small app portfolio, that distinction matters.
The strongest next step may be a new feature. It may be a simpler explanation, an updated icon, a better support page, or a period of observation.
Start with the question.
Then build only enough to learn what the product needs next.