Setting up a product function usually starts with people. Roles are drafted, reporting lines are agreed, a few hires are made, and the first months go on getting the right people into the right seats. Process arrives later, if at all. By the time anyone writes anything down, the function has accumulated a set of habits that nobody chose and that nobody can explain to a new starter.
There is a reasonable argument against writing process down early. 'Principles over Process' is one of the four product principles in the Silicon Valley Product Group's account of the product operating model, and the warning behind it is well aimed at organisations that use documentation as a substitute for judgement. A new function has the opposite problem. Nothing has been agreed, so every decision is worked out from scratch by whoever is in the room, and the outcome tends to follow influence rather than reasoning. Both things hold. A small amount of written process helps a new function; it is worth very little if the roles and decision rights underneath it are unclear.
It is worth being clear about what good looks like here, because it is easy to aim at the wrong target. The best process is the smallest one that lets decisions get made without the head of product in the room. Completeness is not the goal, and neither is formality. A process earns its place by removing a recurring argument or a recurring delay, and a process that does neither should be deleted rather than improved. If following it costs more than working around it, people will work around it, and they will be right to.
The second thing to be clear about is that the process has to fit the organisation you have. What a well designed version looks like in the abstract is close to irrelevant if it assumes a level of formality, seniority or evidence that this company has never worked with. A gate that requires a business case will stall in a business that decides in conversation. A lightweight, verbal approach will not survive in a regulated environment where decisions have to be evidenced. Start from the job the process needs to do, then design the lightest version of it that the people here will actually use, in the language they already use. The measure is whether it works in this culture, not whether it would score well in someone else's.
What follows is the minimum I would write down first, in this order, when standing up a product function or resetting one that has drifted. Each of these should fit on a page. Together they are enough to run a function, and they are meant to be added to only when something specific goes wrong.
1. What counts as a product here, and who owns it
This sounds like definition rather than process, and it is the one most often skipped. The consequences turn up months later as teams organised around systems, or around whichever manager happened to be available at the time.
Agree the test and apply it. A product usually has a distinct group of users or customers, delivers value that can be described without reference to another product, and can be invested in, changed or stopped on its own. Internal platforms qualify if other teams depend on them. Features do not, however large they are, and a big feature should not be promoted to product status because someone senior sponsors it.
The artefact is a short register: each product, its owner, who it serves, what it is for, and where it sits in its lifecycle. A page is enough. The value is in the arguments it forces. Most organisations find at this point that two products are really one, that something significant has no owner, or that a system everyone depends on belongs to nobody.
2. How work arrives
Requests reach product from sales, support, compliance, delivery and the executive team, and in a young function they arrive by whichever route the requester finds easiest. Commitments get made in passing, and the same request appears three times in different forms.
One route in, and it should be written. Keep the required fields few enough that people will complete them: the problem, who has it, what evidence there is, what happens if nothing changes, and any date attached to it with the reason for that date. Five fields is usually the right order of magnitude. Anything longer will be filled in badly or bypassed. Acknowledge everything within a stated period, usually a week, and keep the queue visible to the people who submit to it.
Two points make this work. The first is that submission is explicitly not a commitment, and the wording should say so, because otherwise a stakeholder will believe their request was accepted the moment they typed it. The second is that the queue becomes evidence. When the same problem arrives from four accounts in a quarter, that is a stronger prioritisation input than any single conversation, and it only exists if requests are recorded in one place.
3. How work gets chosen, and by whom
The choice of prioritisation method matters less than most teams expect. What matters is that decision rights and cadence are written down and honoured. A simple scoring approach that people apply consistently will beat a sophisticated one that gets rebuilt every quarter.
Say who decides what. Portfolio level decisions about where investment goes across products sit with product leadership and the executive team. Decisions within a product sit with the product manager and their team. The boundary between them is where most disputes occur, so define it explicitly, including the size or spend above which a product level decision becomes a portfolio one.
Say when decisions happen. A quarterly portfolio review and a shorter monthly or fortnightly product level cycle is enough for most organisations. A predictable cadence removes a surprising amount of pressure, because a stakeholder who knows the next review is three weeks away will usually wait for it, whereas one who has no idea when the next decision point falls will escalate immediately.
Write down the criteria, and be honest that they are weighted rather than equal. Include the exception route for genuinely urgent items, name who is allowed to use it, and record how often it gets used. If it is being used every week, the written process no longer describes how the organisation actually decides, and one of the two needs to change.
Record the decision, the reasoning and what was displaced. A few lines will do, and they pay for themselves the first time someone asks why a commitment was made.
4. What has to be known before a commitment
Every product function needs an agreed answer to the question of how much evidence is enough, sized to what is at stake. Applying the same standard to a small change and to a new proposition wastes effort at one end and carries real risk at the other.
For small work, a named problem, some evidence that it is real, and a rough size is enough. For anything that consumes a meaningful share of a quarter, or that commits the organisation to a new market, a short gate is worth having. Keep it to a handful of questions: what problem this solves and for whom, the evidence it exists, the size of the opportunity, whether it can be built and with what data, how it will make money, and what would cause the organisation to stop. Ask for a page or a few slides. A template that takes three weeks to complete will delay the decision it was meant to improve.
The honest answer at a first gate is often that several of these are not yet known. That is a legitimate outcome, provided the decision is recorded as a deferral with the specific questions named, an owner for each and a date. A gate that ends with a general call for more research and no named questions will produce another meeting with the same conclusion.
The lasting value of a gate is the record of what was believed at the time. It is the only way to tell a decision that was reasonable on the information available from one that was not, and that distinction is what allows a function to learn rather than to argue the same case again.
5. How commitments are communicated and reviewed
The last process is the one most often left out, and its absence is why prioritisation quality does not improve over time.
Publish the roadmap in a form other functions can read, in their language rather than in delivery terms, with dates only where there is a genuine commitment. Each cycle, state what changed and why. Sales and customer success will tolerate a roadmap that moves if they understand the reasoning. They will not tolerate hearing about the change from a customer.
Then close the loop. Agree an interval after release, usually somewhere between one and three months depending on the product, at which the outcome is reviewed against the claim made when the work was chosen. Keep it short and unceremonious. Record whether the expected result appeared, and if it did not, whether the problem was the idea, the execution or the measurement. Without this step the organisation has no feedback on the quality of its own decisions, and the same optimistic reasoning turns up in the next planning round.
Writing them so they get used
One page each, in plain English, with a named owner and a review date. Draft them with the people who will use them rather than presenting a finished version for comment, and get sign off in a single session with everyone present. Processes agreed by circulated document tend to go unread.
Resist the pull towards completeness. Most published frameworks describe a mature function and are written to cover every case, which makes them a poor starting point for a function of six people. Roman Pichler's advice on adopting the product model applies just as well to the process that supports it: 'Instead of opting for a big-bang implementation, adopt an incremental approach.' Take the parts that answer a problem you actually have and leave the rest until the problem appears. A gap in the written process is acceptable while it is a gap nobody has fallen into.
Then treat the first version the way you would treat a first release. Announce it, say what it is for and what it is meant to fix, be explicit that it is version one and that it will change, and tell people where to send feedback. A process launched quietly gets read as something imposed, and the first person to find a flaw in it concludes the whole thing is unserious. A process launched as a first version invites the flaw to be reported.
Then do what you would do with a product. Watch how it is used rather than asking whether people like it, look for the places where it is being worked around, and change it. Expect to reach a third or fourth version within the first year. That is normal and is a sign the processes are being used. Someone has to hold the upkeep, though, and it is worth naming who. If nobody owns it, the documents drift away from practice within about two quarters and are then ignored.
The two ways this goes wrong
The first is process that exists on paper only. Documents are written, forms are completed, a review board meets, and the work routes around all of it. The signal is that decisions are still being made in side conversations while the formal process ratifies them afterwards. The response is to cut the process back until it is cheaper to follow than to avoid, which usually means removing steps rather than enforcing them harder.
The second is the undocumented function, where things work because the head of product remembers how they work. It performs well while that person is present and available. Onboarding takes months, little can be decided in their absence, and the same argument recurs every quarter because there is no record of how it was settled last time.
Where this leaves you
These five are a floor. A mature function will have more, covering release management, pricing, sunsetting and the interface with support and delivery, and those are worth adding when the function is large enough to need them. What the five buy in the first year is the ability to make and defend decisions at a reasonable pace with fewer people in the room, which is usually what a new product function is being asked for.
Each takes an afternoon to draft and a session to agree. Left unwritten, they get invented again every time they are needed, and rarely the same way twice.
