Running a one-person product portfolio

I run several live products by myself. There’s motomotar.com, an eval-gated AI content operation for Indian car buyers. There’s a local commodity-price site with a scheduled data job, a single-model car-price site launched from a 197-page topical map, and a reality-TV voting app I shipped on Android in two languages that has passed 10,000 downloads. A native iOS app in SwiftUI is in build, aiming for December.

None of them is my job. I’m a full-time product manager, and these products get evenings and weekends. So the decision this essay helps with is the one any PM with too many bets and too little capacity faces: how to allocate one person’s time across several live products, what gets built, what gets automated, what gets killed, and which number tells you whether the allocation is working.

The day job sets the budget

I’ve done this before. I co-founded an entertainment news site, bootstrapped it over seven years to 3M monthly users, and ran it in parallel with my first product roles. The habit that carried over is budgeting from the top down. The job takes what it needs first. The products share what’s left, and in some weeks nothing is left.

That changes how each product has to be designed. A product that needs me every evening to stay at its quality bar will fail the first week I’m busy at work. So every product has to be able to coast, and anything that can’t coast is either still in build or has a design problem.

The portfolio metric

Revenue and traffic are product metrics, and they don’t compare across a content site, a data site and an app. At the portfolio level I watch one thing: how many products can run a week without me and still meet the bar. A product that can coast for a week is healthy. A product that can’t is where the next block of build time goes, because the fix is usually automation or a cut.

Underneath that sits a second rule. Every product has to produce one readable signal on a schedule, so I can tell whether the time I gave it was well spent. For the content sites it’s indexation in Search Console. For an app it’s installs and whether people return when the weekly notification goes out. A product without a signal can’t compete for time, because I can’t tell what my time bought.

Automate the data, keep the judgment

The commodity-price site has been live since September 2026, and its whole value is a number that keeps changing. A scheduled job collects it and the site updates without me. That’s the right thing to automate: repetitive, checkable, and boring to do by hand.

What the job doesn’t do is decide anything. Which pages exist, what they say about the number, and when to change course are still my calls. motomotar follows the same split at a bigger scale. Daily fuel prices for 658 cities and the 36-state road-tax dataset come from maintained data pipelines, and the model writes around the numbers without ever producing them. Pages pass through a scored rubric with publish bands at 85, 82 and 78, and publishing is always my manual action.

Automated judgment still needs an owner. In June 2026 the LLM judge that scores motomotar’s pages drifted. When I re-anchored the rubric and rescored everything, uniqueness dropped by a mean of 10.2 points across the six pages present in both snapshots, and the rankings inverted. The automation kept running perfectly the whole time. What it needed was a person who owned the bar and noticed it moving.

Scope with a map before you build

The car-price site went from start to live in about twelve days, with 199 URLs live on 1 November 2026. The speed came from deciding the scope before writing any code. A 197-page topical map defined what the site was, which made “done” countable. It also defined what the site wasn’t, which mattered more. With one person there’s no planning meeting where someone asks whether a new section belongs. The map plays that role.

The iOS app’s plan was approved the day after the car-price site went live. That ordering is the pattern I’d recommend to anyone in this position. Keep one product in build at a time, because the product in build is the one allowed to eat most of the evenings.

Seasonal products get seasonal attention

The voting app follows a TV season. The season moves in weeks, so the product does too: a weekly push notification brings people back for the next vote, and the companion web property gets a weekly update. Its attention cost follows the broadcast calendar, with a fixed weekly rhythm while the show is on air. Planning around that calendar is cheaper than treating the app as if it needed the same effort every week of the year.

One bar for every property

Several products run by one person tend to drift toward several different standards, because each one gets built in a different month with whatever I believed that month. In October 2026 I wrote a single standards playbook that every site is held to. Between September and October I also built four SEO agent skills (information gain, search-intent fit, on-page QA and term coverage), so the same checks run on every property instead of living in my head.

It’s the same principle motomotar applies internally. Its banned-phrase list lives in one file that both the draft gate and the post-publish verifier load, and a test asserts that they do. Keep a rule in two places and one copy will drift without anyone noticing.

What gets killed

A one-person portfolio can’t afford zombies. A product or program that’s neither growing nor teaching still costs attention every week, so I’d rather cut early on evidence. Three kills I’d defend:

The question-page cluster. I built motomotar pages targeting “People also ask” questions, expecting them to earn topical authority for the price pages. Google deindexed the cluster wholesale, while all nine state road-tax rule pages indexed at positions 6 to 12 over the same months. I stopped adding to it. The full reasoning is in Killing a content cluster on evidence.
The keyword ladder. A strict one-cluster-at-a-time vetting program. It showed me which pages earn a crawl, and I closed it on 18 October 2026, keeping its verification steps.
A Chrome extension. Built, working, never uploaded. Building it was cheap. Shipping it would have meant owning it in public indefinitely, and I chose not to.

Each kill hands attention back to the products that are still earning it.

What this means if you’re the PM

Budget from the top. Decide what the main commitment needs first, and design everything else to survive a week of zero attention.
Use a portfolio metric that measures your scarce resource. For one person it’s attention. Count how many products can run unattended at the bar, and spend build time on the ones that can’t.
Automate the data, keep the judgment. Scheduled jobs are for numbers that change. Decisions about what exists and what ships stay with a named person, even when a model scores the work.
Scope with a map and write the bar once. A fixed page list and a shared standards document do the work a team’s planning meetings and reviews would otherwise do.
Kill on evidence, early. A program that has taught you what it can is finished, even if it’s still running.

Facts here come from my own build records and Search Console; the motomotar system is documented in the motomotar case study.