Product operations is one of those roles that exists in most startups long before anyone gives it a title. Someone collects feedback from users, turns it into something the developers can build, checks the release before it goes out and tells users what changed. That someone is doing product ops.
I have done this work for Teckid Kenya, an online coding school for kids, and for AfriESG Metrics, a Kenyan ESG data company. Here is what the role looks like in practice.
What product ops does
Turns feedback into work the team can ship
Users send feedback everywhere: WhatsApp, email, calls, a comment in a demo. Product ops collects it in one place, groups it by problem and turns the most common problems into clear tasks. At Teckid, feedback from parents and learners shaped what the team built next.
Writes clear requirements
Developers build what you describe. A vague request produces a vague feature. Product ops writes what the feature must do, who it is for and how we will know it works, in plain words, before anyone writes code.
Checks before every release
Someone has to click through the product the way a user would before it goes live. On a product for children and parents, a broken sign-up flow costs trust you do not get back. I run a short checklist before every release: the main flows, the payment or enrolment steps and the pages that changed.
Closes the loop with users
When a fix ships, the person who reported the problem should hear about it. This one habit turns frustrated users into people who send you more feedback.
Where product ops fits
In a big company, product managers set direction and product ops supports them with data, tools and process. In an African startup with five to fifteen people, one person often does both. What matters is that someone owns the space between users and the build team.
Signs your startup needs it
- Developers ask what a feature is supposed to do after they have started building it.
- The same bug gets reported three times because nobody told the users it was fixed.
- Releases break things that used to work.
- Feedback lives in the founder's WhatsApp and nowhere else.
Skills that matter
- Listening to users without jumping to solutions.
- Writing clearly, because requirements are writing.
- Enough technical understanding to talk with developers about what is hard and what is easy. I started my career in software engineering at ALX, and it helps every week.
- Organisation: a tracker, a release checklist and a feedback log, kept up to date.
How to start
- Create one feedback log and move every piece of feedback into it for a month.
- Group it by problem and count how often each comes up.
- Write clear requirements for the top one and hand it to the team.
- Check the release against those requirements before it ships.
- Tell the users who reported it.
Questions about product ops
Is product ops the same as a product manager?
In a large company they are separate roles. A product manager decides what to build and why. Product ops makes the process around that work run well. In a small startup one person often does both.
Do I need a technical background?
It helps. You need to understand enough to talk with developers about effort and risk, and to test a release properly. Many people learn that part on the job.
What tools do product ops people use?
A feedback log, a task tracker the developers already use, a release checklist and a simple way to message users. Start with those before adding analytics tools.
This is the same way I approach every system I build: start from the people who will use it. If your product team is shipping without a clear line to your users, let's talk, or see what I have built.
