Product Manager At Greenspoon Kenya

What this role is

• This is an early-career product role for someone with 2 to 4 years of experience who wants to become a product manager and has the raw material for it. You will join our product team, work alongside our senior product owners, and take ownership of a slice of one of our product areas from your first quarter.
• Most of what we build is internal: the tools our buyers, warehouse staff, pickers, riders, finance and customer service team use every day, and the customer app and website they all feed into.
• Our engineering is in-house and so is our product thinking.

What you will work on

You will be assigned to one of our product teams and given real problems inside it.

Depending on where the need is, that could be:

• Inventory & Waste. Receiving, put-away, transfers between sites, counting, expiry and waste. Keeping what the system says we have in line with what is on the shelf. The apps used by people on their feet in a cold room, and the printers, scanners and scales behind them.
• Last Mile Delivery. Picking, packing, dispatch, routing, delivery slots, the rider app and proof of delivery. Getting the right order to the right door at the right time, and knowing straight away when we have not.
• Commercial Excellence. How much we buy, of what, and when. Product master data, pricing, promotions, supplier terms and margin. The tools our buying team uses to run their categories and to see whether a decision made money.
• Scale & Compliance. The back-office processes that carry volume: order to cash, procure to pay, finance close, controls and audit trails. Assets, facilities and quality, including temperature records and food safety. Making each process cheaper per transaction and less dependent on one person knowing how it works.
• Customer Value. The app and website, search, checkout, substitutions and retention. How we tell a customer what actually happened to their order, and what brings them back for the next one.

In every one of these you will do the same things: understand the workflow as it really happens, find the structural problem behind the recurring symptom, write it up so an engineer can build it, ship it, and check whether it moved the number.

How you will work

• You report to a product owner and work day to day with your engineering squad. You will not be alone, but you will be expected to own your problems rather than be handed solutions.
• You spend real time where the work happens: the receiving bay, the pick aisle, the rider hub, the customer service desk. Every process here is judged on the floor, and the best specs come from having watched the thing go wrong.
• You write. Short, clear problem statements and specs that an engineer can build from and an operations lead can challenge. If it cannot be explained on one page, it is not understood yet.
• You prioritise a backlog and you can say why the thing at the top is at the top.
• You use AI tools to prototype small internal tools and analyze yourself. Turn data into insight into action quickly, without waiting for a full engineering cycle every time.
• You make sure the team actually uses what you build. If they do not, it is on you to figure out why.

What we are looking for

• 2 to 4 years of experience in a demanding role. Many of the people who fit this description are developers who have found they care more about whether the right thing gets built than about building it themselves. Others come from operations, data or analytics, consulting, or a start-up where you wore several hats.
• Technically literate. You can read SQL, sketch a data model, follow an engineering discussion and have an opinion on the trade-offs.
• You have already been the person who fixed something nobody asked you to fix. A report people came to rely on, a script that removed a manual step, a process you rewrote because the old one kept breaking. We want to hear about it.
• You know how a product team is meant to work. Problem discovery, solution discovery, then delivery, in that order (Marty Cagan, Inspired). You do not need to have run it end to end yet, but you should recognise the difference between a team that ships features it was handed and a team that finds the problem, tests a few ways to solve it, and only then builds. If you have not read the book, read it before the interview.
• Curious about why. When a number looks wrong, your instinct is to go and find out, rather than correct it and move on.
• Comfortable with people who are not like you. A warehouse supervisor, a rider and a backend engineer will all need to trust you, and none of them are impressed by the same things.
• Commercially aware. You do not need to have owned a P&L, but you should be able to connect a feature to margin, availability, working capital or customer retention, and be curious when you cannot.
• Decisive with incomplete information. You would rather ship a decent fix this month and correct it than wait for certainty.
• Low ego. You listen, you ask good questions, and you are willing to be on the floor at 6am when that is where the answer is.

What makes people succeed in this job

• They accept being judged on outcomes. A developer is judged on what they built. A product manager is judged on whether it was the right thing and whether anyone uses it. Some people find that shift liberating and some find it uncomfortable. The first group does well here.
• They distrust stated requirements. What a user asks for is a clue. The good ones watch the work, ask the second and third question, and often end up building something smaller and more useful than what was requested.
• They write clearly because they think clearly. Short documents with the problem, the evidence, the proposed change and the number it should move.
• They say no, and explain it. A backlog with no noes in it is a wish list. Prioritisation is the actual job.
• They close the loop. They go back after shipping to see whether it worked, and they say so plainly when it did not.
• They stay close to the floor after they have stopped needing to. The ones who drift into meetings and dashboards lose the feel for the work within a quarter.

If you are a developer thinking about this

• This is a real option for the right engineer, and we want to be straight about what changes. You will write far more than you code. You will spend hours with people who do not care how elegant a solution is, only whether it works on a wet floor at 6am. You will hand your best ideas to other engineers to build, and you will be measured on what they ship. In return you get to decide what gets built, which is the part most engineers wanted all along.

What success looks like after a year

• You own a product area, or a substantial part of one, end to end, and the operations team treats you as the person to call when something in it is not working.
• You have shipped several things that are used by choice, because they are faster than the workaround.
• You can point to at least one number you were accountable for and show what you did to move it.

Do not apply if

• You want the plan handed to you. You will get support and a senior product owner to learn from, but nobody is going to write your backlog for you.
• You want to keep being a developer with a different title. You will prototype, but the production code will be written by your squad.
• You think product management is about managing people. You will have no direct reports and a great deal of influence, and you will need to earn all of it.
• You would rather be thorough than moving. We will take a decent fix shipped this month over a perfect one next quarter. You will often decide with about 70% of the information and correct the course later.