essay
Product engineering from Africa
What product engineering actually asks of you, how I try to practise it, and what changes when you do it outside the usual markets.
I call myself a product engineer rather than a developer because the part of the job I care about is deciding what to build, and that decision is usually made badly when it is made away from the person who has the problem.
Everything I have shipped in the last two years started the same way. I hit a problem myself, or watched someone near me hit it, and the existing answer was either missing or built for conditions we do not have.
What the title actually means
PostHog’s product engineer handbook is the clearest writeup I have found on this, mostly because it refuses to make it sound noble. Their version of the role is a developer who talks to users, decides what to build, owns pricing and revenue and support, and is accountable to the people using the thing rather than to a ticket.
The definitions they collect are worth sitting with. incident.io describe product engineers as people who “care more about outcomes and impact than the exact implementation, or the tools used to solve the problem.” Lee Robinson describes them as working backwards from the desired product experience to the technology that enables it, which is the opposite of how most of us were taught. Gergely Orosz’s product-minded engineer is someone who would probably make a decent PM and does not want the job.
The line from the handbook I keep coming back to is that you can wake up tomorrow and decide to be one. Nobody assigns it. It is a set of things you start doing.
How I actually go about it
The practical version, as I run it:
Start from a problem you have watched, not one you have read about. PeerDrift exists because AirDrop does not work between a Mac and an Android phone and every alternative wanted an account and an upload for a file that was going three feet. That is a problem I hit on a Tuesday, not a market I identified.
Be your own first user, then get out of the way. I used FastCV on my own applications before anyone else touched it, which is how I found out the output was too generic to survive a real job description. Being the only user for a while is fine. Being the only user forever is the failure mode.
Ship the smallest thing that can be judged. Not an MVP in the pitch-deck sense, a version narrow enough that user reaction tells you something specific. A file transfer that only does one file teaches you more than a half-built suite.
Own the boring parts. Pricing, the error copy, the empty state, the support reply. Every one of those changed my products more than a refactor did. Setting FastCV at a single low one-time export price rather than a subscription was a product decision made from watching what people here actually pay for, and it removed an entire class of objection.
Instrument before you argue. Opinions about what users do are cheap. A number that says how many people reached step three and stopped is not.
Be disloyal to your own features. The handbook puts this as being “less loyal to features they’ve added in the past.” I have deleted more of my own work in the last year than I shipped in the year before, and the products got better each time.
Read the failures. Not the crash logs, the drop-offs. The place someone quietly stopped is where the product argued with them.
The conditions actually matter
The reason this role changes shape here is that the assumption set is different, and the assumptions are where product decisions get made.
Bandwidth is not free. Bank and network downtime is normal. Devices are older and kept longer. People are cautious about handing documents and money to systems they cannot appeal to. DocShift exists because people wanted to fix the files they had just moved, and uploading a payslip or a school document to an unknown server is a real hesitation, not a hypothetical privacy concern.
Build with those in the room and you get different software, usually smaller and more local. That is not a regional style. It is what happens when you take the operating environment as the spec.
What the constraint gives back
Constraint is not something I am romanticising. It costs real capability. But it does force decisions that improve the product for everyone.
Client-side processing was a privacy choice in DocShift, and it also removed the server bill and the upload wait. A 50 MB cap and a 30 minute expiry in PeerDrift were operational limits, and they also turned out to be the reason people trust it with things they would not put in a cloud drive. A one-time low export price in FastCV was a read on what people here will actually pay, and it is also simpler to explain than a subscription.
Every one of those started as a limitation and ended up as the reason the thing works.
Judgment is the scarce part
Writing the code is rarely the bottleneck now. Knowing which version to write is. The questions I keep asking on every project are the same four, and they are the ones I want this site to show:
What did I notice? Why did I build this rather than the obvious alternative? What did the constraints teach me? What would I do differently?
That is also why I keep teaching through Programmify. The gap I see most in people learning to build is not syntax. It is that nobody has shown them how the decisions get made, so they can follow a tutorial and still freeze in front of a blank problem.
Where I want the work to sit
I want to build tools that hold up outside the conditions they were demoed in, from here, for people who deal with the same friction I do. Not as a category or a niche, just as the honest description of where I am standing when I decide what is worth building.