80 lvl doesn’t exist

Some games let you reach the last level, kill the final boss, watch the credits, and close the window. Done. You beat it.

In this line of work, there are no credits.From the 80 lvl manifesto

I’ve been in product for twelve years. Marketplaces, SaaS, high-load systems, international markets. In that time I’ve been the guy who tells a team, with real confidence, how the work should be done — and the guy who, six months later, realizes he was talking nonsense. Both of those people are me. The only difference is the level.

My name is Denis. I’m a product owner. This blog is about how that skill actually levels up — not by years on a résumé, but by the problems you’ve solved, and by how many times you were wrong and then figured out why.

Why 80 lvl

The name came from a simple thought I couldn’t shake.

On a résumé we write “5 years of experience,” “10 years of experience.” Experience isn’t measured in time. You can run the same project on autopilot for five years and stay exactly where you were in month one. Or you can eat three failures in a single year and grow so much that your old decisions look like a kid drew them.

Level isn’t a calendar. It’s how many different kinds of problems you’ve already held in your hands, and what you did with them.

80 lvl isn’t a destination. It’s a direction. There’s always a problem you don’t know how to solve yet, and that’s fine. What’s not fine is thinking you’re done.

The point where it broke

Now, the story that made me start this blog in the first place.

A few years ago I landed a project that was clearly bigger than anything I’d run before. An international brand with half a century behind it, Ukraine as the market. A grown-up client with grown-up expectations.

And me, running freelance the way most freelancers do: in my head, in chat threads, and across twenty browser tabs.

There were no processes. Or rather, there were — each one living in its own silo.

Project tasks lived in Trello. Then I dragged them into Asana, because Trello couldn’t handle dependencies. The tools, honestly, are excellent. I’m not going to sit here and tell you Trello is bad or Asana is bad. They’re great, each in its lane.

The problem wasn’t the tools.

The problem was that none of them held everything I needed for a project.

Tasks in a task manager. Agreements with the client in email and messengers. Invoices in a separate spreadsheet I updated by hand and reliably forgot to update. Which contractor was doing what, and what they were owed — somewhere else. The history of talking to the client — nowhere, except my memory.

With one project, it works. Crooked, but it works.

The mess tax

Once you have more than two projects, you start paying what I later named the mess tax. You don’t pay it in money. You pay it in attention. Every switch between projects costs you ten minutes just to remember where anything lives. Every client question — “did we talk about this?” — costs half an hour of archaeology in a chat log. Every invoice the client remembers before you do costs a little reputation.

Table · the mess tax

What really got under my skin: I couldn’t answer a basic question — how much do I actually make on this project. Not “how much did they pay me,” but what was left after every contractor payout and every hour I put in. The data existed. It just sat in four different places and refused to add up.

The moment it clicked was not heroic. No missed deadline. No blowup. I was sitting there reconciling numbers by hand, again, and I caught myself thinking:

I’m doing work a system should be doing. And I’m doing it worse than a system would.The point this blog started from

Perfex

What followed was a pretty ordinary search.

I went through what was sitting in plain sight. The big CRMs were either bloated or ran on a subscription that didn’t pay for itself at my volume. I didn’t need an enterprise Swiss Army knife. I needed one place where projects, tasks, clients, invoices, and contractors lived — and where all of it was actually connected.

I found it on CodeCanyon: Perfex CRM. Self-hosted, one-time purchase, runs on your own server, you can bend it to fit.

I installed it and started moving clients over. One, then another, then a third.

That’s when it got interesting.

The second everything sat in one place, I had numbers for the first time. Not feelings — numbers. How many projects were in flight. How much had been invoiced, how much paid, how much was hanging. Which client paid steadily, and which one demanded a lot and paid a little. What was going out to the team.

And it turned out some of my feelings were wrong. The project I thought was my most profitable one was, after an honest count, average. The one I treated as small and almost a chore was the steadiest earner I had.

Getting organized isn’t about order for order’s sake. It’s about finally seeing reality instead of your story about it.

Working with the team changed too. Before, “bring a contractor in” meant start a chat, explain the context out loud, and hope. After, it meant give them access to a project that already had history, tasks, and agreements. Context stopped living in my head.

How it became OneBigPro

From there it started to run on its own, because there was something to stand on.

When work with one client is written down as a process, the second client plugs in faster. Once the second one goes well, you start to see which services you actually do well, and which ones you should stop taking. Your own rules show up — what we do, what we don’t, on what terms.

Products showed up — not one-off tasks, but things you can repeat. Ongoing support became its own line of work, with its own economics. New clients started arriving on referral, because the last ones had found the work clear and predictable.

The team grew — not because I decided to “hire,” but because the processes finally let me hand work to someone else without losing quality.

That’s how freelance turned into OneBigPro. The agency is more than four years old. We have clients who come back year after year, and projects I can show with numbers, not the phrase “we built a website.”

It started with one project that was too big for me, and with irritation at a spreadsheet I had to reconcile by hand.

Why this blog

I have to say this honestly, not prettily.

I write this blog first of all for myself.

Over the years I noticed a pattern: while a thought is spinning in your head, it feels coherent. The moment you try to write it so a stranger can follow, you find the holes. Half of the “obvious” conclusions fall apart on the page. The other half get twice as sharp.

Self-reflection works. Not in the sit-down-and-think-about-yourself sense. As a working tool: write the situation down and you can see what actually worked, and what just happened to coincide.

The second reason is people walking a similar path. I remember looking for answers to questions like “how is this even supposed to be set up” and finding either textbook theory or success stories where everything worked on the first try. What I wanted was a straight postmortem: here’s the problem, here’s what I tried, here’s what didn’t work, here’s what stuck.

Those are the write-ups I’ll do here.

What’s in the blog

Six sections. I’ll split them into three pairs — it’s clearer that way.

Mindset and Process

The first is how a product person thinks: decisions when you don’t have enough data, burnout, priorities, working with a team and with stakeholders. The second is how I actually run the work: processes that stuck, and processes I threw out after a month.

Tools and Experiments

Tools is the stack: CRM, automation, n8n, integrations, everything I actually use every day, with a read on where it applies and where it doesn’t. Experiments is hypotheses under test. Some of them will work. Some won’t. I’ll write about the “won’t” too.

Results and Inbox

Results is case studies with numbers. Not “we did a good job” — how much it was, how much it became, over what period, and what actually moved the needle. The failures too. Those are more useful. Inbox is raw: news, finds, thoughts that aren’t a full piece yet, but I don’t want to throw them out.

Table · what each section is for

What’s next

I don’t write on a hard schedule, but I write regularly. Real experience doesn’t accumulate on a calendar, and I won’t publish just to hit a quota.

The next post is a detailed write-up of the Perfex rollout: what I configured, what I had to custom-build, the mistakes I made moving clients over, and what I’d do differently if I were starting today.

If you’re in the same place I was — twenty tabs and a spreadsheet you reconcile by hand — this will be useful.

Let’s go grind.

FAQ