Last week a CTO posted in r/ProductManagement asking whether anyone uses a fractional or part-time product specialist. His company has no product manager and no product owner. Those roles are his, on top of being CTO, and he is falling behind.

He did something more useful than most people do when they ask this question. He wrote the list.

  • getting release notes published
  • user and stakeholder updates
  • roadmap editing and prioritization
  • user feedback management
  • UAT planning and implementation
  • sending comms to users about what's coming and what to look forward to, including light creative
  • knowledge base updating

His instinct was that he needs someone junior. Maybe offshore, because of budget. He said he had never hired a product person before and was not sure what this should look like.

(Full disclosure before I go any further: I am the category he is shopping for. I do this work for a living.)

What the thread told him

Fifty-three comments, and they sorted into three camps.

The first camp said automate it or spread it around. Give the knowledge base to a technical writer, UAT to a QA engineer, release notes to a tool, and keep the rest yourself. The second camp said his instinct was backwards, that a junior would cost him more supervision than they saved, and one contract product manager told him bluntly that he was doing far too much and needed to restructure his team before he burned out. The third camp said "hire me". Seven people pitched themselves in the thread, and he replied to most of them with some version of "DMs are open."

The diagnosis was good. One commenter split his list in half and told him that half of it was not a headcount problem, it was a no-system problem, and a person would not fix it because he would still be the input. Another, an ex-founder who does fractional work, told him not to hire too junior because quality of judgment suffers, which got two upvotes while the pitches got replies. I fully agree with both of those insights.

But nobody answered the question he was actually asking, which was what to buy.

Every camp argued about the role. Junior or senior. Fractional or part-time. Product owner or business analyst or VA. Nobody argued about the work, and the work is sitting right there in a seven-item list he was kind enough to write down.

So let me do the thing the thread skipped.

Three of these farm out

Getting release notes published. Somebody has to collect what shipped, write it up, and put it where users will see it. That is a real job and it takes care, and a capable junior person can own it end to end within a month.

User feedback management. Collecting, tagging, routing, making sure nothing sits unanswered for three weeks. This is a discipline problem more than a judgment problem, and discipline is trainable.

Knowledge base updating. Same shape. It needs someone who will actually do it, consistently, which is rarer than it sounds. It does not need someone senior.

A fair objection, and the thread raised it: all three of these are also the three most automatable things on his list. One commenter pointed out that AI can draft release notes with minor human intervention, and he is right. I would put an AI draft in front of a person for all three.

But somebody still has to read the draft before it goes to a customer, decide it is right, and be the one who answers for it when it is wrong. That job is small and it is real, and it is the difference between a tool that saves you an hour and a tool that publishes something embarrassing under your company's name while nobody is looking. Hire the junior person to own the outcome, and let them use whatever gets them there. What you are buying is somebody whose job it is to care that it happened. Junior is fine for that. So is offshore.

Four of these do not

Roadmap editing and prioritization. This is the obvious one. Prioritization is not editing a document, it is deciding what the company will not do this quarter. Nobody who does not understand the business can do it, and if they do it badly you may not find out for a couple of months.

UAT planning and implementation. Planning UAT means deciding what "done" means before anyone can argue about it afterwards. That is a definition of success, written in advance, and it is one of the calls that decides most in delivery while looking like paperwork.

Sending comms about what's coming. Telling users what to look forward to is making commitments on the roadmap's behalf. The light creative part is the easy half. The hard half is knowing what you are allowed to promise.

User and stakeholder updates. And this is the one that deserves some real attention, because it looks like the most junior item on the list and it is not.

Writing a stakeholder update means deciding how much to say.

Say too little and people fill the gap themselves, usually with the worst available interpretation. Say too much and you hand someone a detail they were not looking for and did not need, and now you have spent three days managing a reaction to a risk that was already handled. I speak from (painful) experience here - I've seen a single sentence in a status email send an executive down a rabbit hole, because there really is such a thing as too much information. Detail on how the sausage is made, after the fact, when the thing has already been handled, is a distraction at best and costs real money at worst.

Knowing which is which requires knowing who is reading, what they are worried about, what they were told last time, and what they will do with the information. That is not wordsmithing. The wordsmithing is downstream of a judgment call about the reader, and there is no process that makes it safe to get wrong.

So: three of the seven are a junior hire. Four of them are someone making decisions in the name of the leader (the CTO in this case).

"Product strategy is out of scope"

When a commenter told him the list read as ongoing tasks rather than strategic ownership, he agreed immediately. His words: he was struggling because he was not sure what he needed, and product strategy was out of scope for the role.

Half right, and the half that is wrong is the expensive half.

He is correct that he does not need to hire someone to set product strategy. That is his job, he is doing it, and he should keep doing it. He said elsewhere that he has a good product and a good value prop, that he likes the business and the customers, and that he has high standards for the brand. Nobody should take that off him.

What he needs is someone who can apply that strategy, several times a day, in decisions too small to escalate and too consequential to guess at. Whether this bug blocks the release. Whether this stakeholder needs the full picture or the headline. Whether this feature request is the thing the customer actually needs or just the thing they thought to ask for.

This is also why "get a part-time product owner" was the most upvoted short answer in the thread - but it's still not quite right. Let's unpack what that means.

A product owner, as the role actually gets run at most companies, owns the backlog. Writing the stories, refining them, accepting the work when it is done. A project manager owns the mechanics: scope, schedule, dependencies, chasing. Both are real jobs and both are harder than people outside them think.

But both of them start from the same assumption, which is that somebody upstream has already decided what the company is trying to do, and that the decision is going to hold.

What our CTO is short of is whoever handles it when the decision stops fitting, which is the more common case. A customer asks for something that was never in the plan. Engineering comes back and says the thing you promised takes twice as long. A stakeholder wants an answer today and the honest answer is uncomfortable. Every one of those needs somebody to decide what happens next, quickly, in a way that still serves what the business is trying to win.

He has been doing that himself, in the gaps between everything else. That is the job he is trying to hire for. It does not have a name on any job board, which is why he went looking for a fractional product specialist and got told he means a part-time PO.

It is the Operator Seat, and he is sitting in it.

The moment the Tool Trap walks in

Two commenters, both trying to help, told him to automate the list. One suggested bringing in a consultant to set the automation up. Another recommended a note-taking system he uses himself, so that the context in his head would stop being trapped there.

They are not wrong that tools help. I would automate some of this too, and I would hand the release notes to an AI draft before I handed them to a person.

But look at what the automation is being asked to do. It is being asked to hold the judgment. A tool can assemble a stakeholder update from the tickets that closed this week. It cannot decide that this particular stakeholder should not see the rollback, or that this one needs to hear about it from a human before Friday.

Tools are not the solution. They enable a solution you have already defined, and he has not defined one yet, which is the honest reason he is stuck.

What he should actually ask for

Not a fractional product specialist. Not someone junior to absorb seven tasks.

Two hires, and they are not the same hire.

A junior or early-career person, part-time, to own release notes, feedback triage and the knowledge base. Cheap, fast to onboard, useful inside a month, and free to use whatever tooling gets the job done. It's even possible he's already got someone junior on the team with the capacity available to do this along with an AI assist.

And a senior operator, genuinely part-time, for the other four. Someone who has been wrong before about what to tell a stakeholder and still remembers how that went. Someone the CTO can hand a decision to and trust to make it the way he would have, then hear about it afterwards rather than be asked about it first. That person costs more per hour and less per week than he is expecting, because four items do not need forty hours.

He needs a first officer. A right-hand man (or woman). The one who serves as the glue, the connective tissue, making sure users, engineers, leadership, and strategy are all in cohesive alignment.

The thread was right that he is drowning. It diagnosed him accurately and then argued about job titles for fifty comments.

He is not behind on tasks. He is the only person in that company who can make a certain kind of call, and you cannot hire an assistant for that. You have to hand it to somebody.