Choose your next product improvement from reader evidence

Choose your next product improvement by comparing the problems readers encounter, the evidence behind them, their consequences, and the work required to address them. Check whether each problem belongs within the product's promise before ranking possible solutions.

For an author with consulting, speaking, and a book to manage, the scarce resource may be a few hours of focused attention. A long feature list can consume that time without improving the task readers bought the product to complete.

Start with one decision: what should receive the next available block of product work? Keep urgent corrections separate, identify requests you should decline, and use a simple scoring exercise only for the remaining candidates.

The example below is fictional. Its requests, reader counts, time estimates, scores, and decisions are invented to demonstrate a process. They are not customer data, forecasts, or evidence that a particular improvement will increase revenue.

Imagine an author sells a companion to a book about writing clear project briefs. Readers bring an intended project and leave with a brief that identifies its purpose, audience, scope, and unresolved decisions.

Requests arrive through several channels: an email asks for more examples, a reader wants presentation slides, a support exchange reveals confusion over a required field, and an enthusiastic customer suggests adding a team workspace.

Do not translate each message straight into a build task. Record who encountered what problem, when it occurred, and what evidence is available. Remove identifying details from shared notes when they are not needed.

Reader's intended task:
Relevant product version:
What happened:
Evidence or artifact:
Workaround used:
Requested solution:
Other readers with independently reported similar difficulty:
What remains unknown:

A product practitioner describes the difficulty of scattered signals:

“However, we don’t have an aggregated view of all the signals across the various systems of record.”

— u/KeepItBlazin, discussing prioritization

That account comes from a product-management discussion, not an author business. An author can face the same practical bookkeeping problem on a smaller scale: the evidence is distributed across inboxes, notes, and conversations. A single decision log makes the basis for a choice easier to inspect.

First, handle failures that break a current commitment. If a paid reader cannot reach material they should receive, or the companion gives an instruction that contradicts an essential method rule, investigate that issue directly. Do not let a popular cosmetic request outscore a serious obligation.

Second, identify work that belongs outside the offer. A project-brief companion does not automatically need to become a presentation designer, scheduling system, or team collaboration platform. Those may be legitimate customer needs, but accepting them changes the product and its maintenance burden.

A founder puts that concern this way:

“Either it adds complexity, bloats the UI, or pulls us away from the core use case.”

— u/Soft-Lime-9599, asking when to decline feature requests

The quote describes a concern, not a measured effect of any particular feature. It is a useful prompt for the author: would this request strengthen the reader task you promised, or create another product you must operate?

Keep a “do not build for this offer” category with a reason. That is clearer than placing every rejected request into a backlog that implies eventual delivery.

Here is the starting evidence for the project-brief companion:

Three reports are not proof of widespread incidence. Two requests from the same person would not be two independent cases. Keep both the count and the evidence description visible so the table cannot be mistaken for a population estimate.

Likewise, an unreported problem may still be important. If a reader stopped before reaching the feedback form, the absence of a complaint tells you little about that experience. Review willing non-completers and support exchanges as well as enthusiastic feature requests.

A score can make tradeoffs visible, but it cannot improve weak evidence by turning it into a number. Intercom's RICE framework considers reach, impact, confidence, and effort. The smaller worksheet here uses an original set of weights designed for comparing a few author tasks; it is not RICE and is not a validated forecasting model.

For this fictional decision, rate each in-scope candidate on four dimensions:

• Evidence quality, from 0 for a guess to 3 for a directly inspectable repeated problem.
• Consequence, from 0 for unclear benefit to 3 for blocking the intended task.
• Affected-reader evidence, from 0 for none to 3 for several independent relevant reports.
• Effort burden, from 0 for negligible work to 3 for substantial work and upkeep.

Use this illustrative formula: priority = 2 × evidence quality + 3 × consequence + affected-reader evidence − effort burden.

The weights deliberately emphasize the consequence for the reader over request count. They are a stated author choice, not an objective truth. Change them if your decision calls for a different tradeoff, and explain why.

The score suggests investigating the responsibility question first. It does not predict how many readers will benefit or how much revenue the author will gain. The table supports a decision, not a business-result claim.

Before committing, ask what would change the order. Perhaps the three ambiguous briefs came from the same misunderstood example rather than three independent problems. Perhaps the handover format is already available but difficult to find. Perhaps the volunteer reader's difficulty concerns the method's scope rather than the example's wording.

If the ranking depends on an uncertain assumption, spend a small part of the available time resolving it. Inspect the briefs, ask one clarifying question, or observe the relevant task with permission. Do not commission a large feature simply because it won a speculative spreadsheet.

For the fictional example, lower the first candidate's evidence rating from 3 to 1 and its consequence rating from 3 to 1. Its score becomes 7, below the handover format's 11. That sensitivity tells the author where verification matters. It does not mean the original score was a measurement.

Also check effort beyond the first edit. A new example needs method review. A new output format may need continued checks when instructions change. A workspace feature may create support and maintenance work far beyond its initial build.

Suppose inspection supports the responsibility problem. Define the work narrowly: revise the question, add an example that distinguishes a contributor from the decision owner, and check whether the new instruction preserves the rest of the brief.

Set the evidence you want afterward. For instance, a new reader attempt should identify the responsible person or explicitly mark that information as unresolved. The companion should not invent a name merely to fill the field.

The skill-testing guide can help check those instruction rules. Reader review then asks whether the change actually helps someone prepare a usable brief. Neither check alone proves commercial value.

Write a decision log:

Chosen problem:
Evidence considered:
Why it precedes the other candidates:
Work included and excluded:
Time available:
Expected reader-level change:
How we will check it:
What would make us revise the decision:

Keep the other candidates with their status. The handover format can remain next for review. The volunteer example may need more context. Decorative themes can wait for evidence. The workspace can remain outside the offer without becoming a promise.

Tell a reader what you understood from their report and what you decided. If you made a change, explain the task it addresses and invite a further attempt if they want to participate. Avoid treating the announcement as proof of improvement.

When declining a feature, acknowledge the underlying need and state the boundary. “This companion helps prepare the brief; collaborative editing is outside its scope” is more useful than a vague promise to consider everything eventually.

Repeat the review when new evidence or available capacity changes the decision. You do not need to rerank the entire product every time an email arrives.

To scope a paid companion around a clear reader task, visit Skillfully and choose Book onboarding. Bring your current product promise and five real reports, with private details removed. The decision log can help turn those reports into a manageable next step.