I studied sociology, philosophy, law, economics and a bit of digital literacy. I did not study computer science. I had never opened a terminal on purpose. My first week as a product management intern, someone asked me to "check if the endpoint returns a 401 before the retry," and I wrote it down phonetically so I could look up each word later.
A few years on, I run product and QA at an API documentation platform. Nothing about that path was planned. But looking back, the generalist degree I was slightly embarrassed about turned out to be the part that carried me.
This is what actually transferred, and what did not.
The degree that teaches you nothing specific
I went to the Free University of Tbilisi and studied Governance and Social Sciences. It is a generalist program by design: a semester of political philosophy next to a semester of microeconomics, legal reasoning next to research methods. You graduate without a trade. Everyone asks what job that prepares you for, and for a while I did not have an answer.
The honest answer is that it prepares you to walk into a room where people are arguing about something you do not fully understand yet, and figure out what the argument is actually about. In university that is a seminar. At work it is a sprint planning meeting where two engineers disagree about scope and neither of them is saying the real reason out loud.
What transferred, concretely
Research methods became user research. I was taught that how you ask a question determines the answer you get. Leading questions produce the data you wanted. The same thing happens in customer calls. When a client says "the search is broken," that is a claim, not a finding. My instinct from methods class is to go after the observation behind the claim: what did you type, what did you expect, what appeared. Half the tickets I write start as somebody's interpretation and end as somebody's actual behavior.
Philosophy became specification writing. Analytic philosophy is essentially professional pedantry about definitions, and product specs live or die on exactly that. What does "published" mean? Does an approved API contract count as published, or is approval a separate state? I spent one full week on a version of that question with our contract approval flow. Nobody in the room thought it was a philosophy problem. It was entirely a philosophy problem. Edge cases are just counterexamples, and I had four years of practice hunting counterexamples.
Law became precision under adversarial reading. Legal texts are written for someone who wants to interpret them badly. So are error messages, so are terms in an enterprise contract, and so are acceptance criteria that an engineer will read at 11pm. Writing so that one meaning survives a hostile reader is a learnable skill, and I learned it on statutes before I ever learned it on a Definition of Done.
Economics became prioritization. Opportunity cost is not a metaphor in this job. Every "yes" to a feature is a "no" to something invisible. Reading an economics problem set trains you to ask what the constraint actually is, and most roadmap fights are constraint fights disguised as taste fights.
Sociology became organizational sense. Processes are social objects. When I proposed changes to our QA process and release gates, the technical design was the easy half. The hard half was that a release gate reassigns authority, and people notice that even when nobody says it. I had read enough about institutions to expect it instead of taking it personally.
What absolutely did not transfer
I want to be honest, because "my humanities degree secretly made me great at tech" is a comforting story and only half true.
I had real gaps. I did not understand what an API was in any useful sense. I could not read a stack trace. I did not know why anyone would care about the difference between staging and production until I broke something. For the first months I was slow in a way that was visible to everyone, including me.
What helped was not pretending otherwise. I asked a lot of questions that were probably boring for the engineer answering them, and I kept a file of terms I did not know and worked through it on weekends. The generalist degree did not give me the knowledge. It gave me a fairly high tolerance for sitting in front of something I did not understand yet, which is a different thing, and it turns out to be the more durable one.
The intern-shaped middle part
The step people usually want to hear about is the jump from intern to owning product decisions, and I do not think there is a dramatic story there. It was mostly accumulation: I noticed things nobody had time to notice, wrote them down clearly, and did the unglamorous coordination work that makes releases go out on time. Being the person with the most complete picture of what is going on is not a title, and then eventually it becomes one.
Teaching helped too. I lectured at my old university while working, and explaining something to a room of people who will ask why is a very fast way to find out whether you understand it.
If you are in a similar place
A few things I would tell someone finishing a non-technical degree and looking at tech jobs:
- Your degree is not a disadvantage you need to apologize for, but it is also not a credential anyone will read for you. You have to translate it into concrete things you can do.
- Close the literacy gap deliberately. You do not need to become an engineer. You do need to stop being a person who has to be protected from technical conversations.
- Get close to where the product is actually decided. QA, support, and documentation are all excellent vantage points and are all underrated on-ramps.
- Write things down. In most teams, the person who writes the clearest document quietly ends up setting the direction.
I still think about my degree as generalist, but I no longer think of that as a gap. The specific knowledge was never the point. The point was learning how to enter an unfamiliar domain, find the real question, and stay there until it makes sense.
That is most of what product work is.
