My product has no PM, so every feature competes for the same person’s time

In a solo product, feature requests often arrive in lightweight language: “just add a button,” “one more category,” or “put a setting here.” The code may genuinely be easy. With AI, an interactive screen can appear within minutes.

The work begins again after the feature is built. It needs copy, translations, empty states, error handling, analytics, and tests. Once people rely on it, it also needs maintenance.

My products have no PM to manage those trade-offs. More precisely, the PM work still exists; it all returns to one person.

No PM does not mean no product management

Product management is more than arranging a roadmap. It includes deciding whom to serve, which problem matters now, which requests to refuse, and what evidence should change the direction.

In a team, engineering, design, marketing, and support can challenge a feature from different angles. In solo development, one person usually switches through those roles in sequence. Nobody else is in the meeting to say, “This will be quick to build, but are you sure you want to own it?”

The missing piece is not a title. It is a mechanism that separates something I want to build from something worth building.

A feature is not a file

A Git diff makes it easy to underestimate a feature. Once merged, it spreads into the rest of the product and becomes an ongoing responsibility.

Implementation: interface, data, APIs, and error handling
Product: user moment, defaults, permissions, and boundaries
Presentation: copy, translation, empty states, and accessibility
Operations: analytics, support, billing rules, and release notes
Maintenance: tests, compatibility, refactoring, and safe removal

AI is good at reducing the first cost and can sometimes help with the others. It does not take responsibility for future support, compatibility, or product promises. Cheaper implementation does not make ownership free.

The most dangerous feature often looks almost finished

Large features make their cost visible. Small additions are easier to admit because they seem to require no major decision and rarely come with a written stopping condition.

A new field can affect old data. A new entrance can require onboarding changes. A new category can create branches in search, filters, and analytics. Each change is small, but together they alter the maintenance speed of the whole product.

That is how feature lists become heavy. The problem is not that every choice was wrong. Each choice considered only the small piece directly in front of it.

Every feature charges the same person

On the same day, I can write code, fix a problem, prepare an app update, edit an article, or research a product direction. They look like separate projects and use the same attention.

Adding a feature does not create more time. It reallocates time that could have gone to existing problems, user understanding, documentation, or moving another product forward.

That is why “can I build it?” is a low bar for solo development. The real question is whether I am willing to remain responsible after it ships.

I now ask five harder questions first

When a feature idea appears, I write down what it must change before deciding whether to implement it. These questions reveal more than an estimate:

At which user moment does it appear?
How does the user handle this now, and what is actually blocked?
What observable change would make the feature worthwhile?
Who will maintain it, and which existing flows will it affect?
If the result does not happen, when will it stop or be removed?

A feature without those answers is not necessarily bad. It may simply be unready for the roadmap. Preserving the idea is usually cheaper than preserving a new maintenance obligation.

KOFNote’s feature list can keep growing easily

KOFNote could add capture sources, import formats, AI fields, categories, and automated flows. Each would make the product look more complete and can be justified by a plausible use case.

The Outcome Contract returns the priority to another question: does saved material return when needed and get used again? Without enough evidence, expanding the entrance can make the product busier without making it more effective.

The website, apps, and games also compete for one pool of attention

KeepOnFirst contains articles, apps, games, research pages, and open-source tools. They can provide ideas and technology for one another, and each carries its own publishing, compatibility, and update responsibilities.

One website article is not only one data file; it needs an English version, SEO, prerendering, and sitemap changes. One app feature is not only one screen; it carries state, data, billing, and release work. Every apparently separate output returns to the same maintainer.

I no longer try to make every project advance evenly. A more useful order is to ask which problem deserves evidence now and place the time there.

A roadmap is also a maintenance list

A roadmap item looks like a future result. Once released, it becomes a promise: data should not disappear, controls cannot move casually, and established user habits deserve respect.

The advantage of having no PM is that direction can change without passing through many layers. The cost is that nobody else will block the reasonable-looking features that make the whole system slower.

I now understand product management as allocating time. Every new feature competes with fixes, research, writing, support, and the next genuinely important question. Saying no clearly is how I preserve enough room to do justice to what I have already promised.