Product vs Project: Tested by Freedom

The received wisdom is that building a product is a kind of “blue ocean” — freedom, unexplored expanses of new possibilities, romance. And doing individual projects is a business for people who don’t want to take risks. For me that translates as: in project business the money is small, understandable and relatively predictable, and in product business it’s long, unclear and risky. But that isn’t the main difference.

A product is always a story about building a machine out of interfaces, people, and customer-service processes. It’s a contraption that is supposed to deploy the process of success across the whole world, cheaply and technologically. The key word for a product is scaling. Don’t want to scale — don’t build a product.

Project business, on the other hand, is about having a team you love that accumulates some competence and gives its respected neighbours access to that competence. For me, project business is a way to live your life. You can build a company around yourself that resembles you. Arrange everything around you the way you like it, and live in that built world, stay relevant, change along with your team.

A product is a way to conquer the world. It’s far harder to forecast, and it is under no obligation whatsoever to resemble you. And in fact, if you’re doing everything right, a successful product should one day outgrow you.

In other words, one day you’ll become irrelevant to the tasks the product will face. Simply because at the next stage of development the business will need people with different competences. And then you’ll have to either ruthlessly change yourself, or exit the business, or deform the business to fit your own inadequacy and incompetence.

Project business is a way to live your life. A product is a way to conquer the world.

As I’ve already said, I work as the director of a large custom-development studio and at the same time as head of product at a startup. So I’ll try to show the difference between these two spheres, which are in some ways very similar and in others completely different. What joys and difficulties each holds, and who should be doing what inside them.

The object of management

Let’s start with the fact that a manager in a project and a manager in a product point their attention at different things — because they manage different objects.

In project business that object is client projects, moving along at some rhythm. But sooner or later each of them ends. In product business we organise processes. A product is a bundle of processes created to be endless.

If you suddenly decide to launch a product inside your project business, the first thing you have to do is build a reinforced-concrete wall between the projects and the product. Because otherwise the more predatory projects will eat the young and still defenceless processes, guaranteed.

Here’s how it happens. In the very first days of the startup a project manager will inevitably walk up to you and say, “A client came to me, gave me two million in cash, give me a developer.” You have to believe in your product very, very, very much to tell that manager to piss off. Because if you hand over a developer even for one day, that’s it — you’re screwed! There will be no product. Other managers will pour through the little hole in the dam. And your idea will stay an idea, because people will go on doing projects.

My way of building the wall is to give the product a different ownership structure. The product and the projects must not belong to the same people. If a developer belongs to the product, then I can’t just take them onto a project — I’ll have to negotiate with the partners who have a stake in the product’s development.

People

A product is a business to a far greater degree than a project studio is. It’s a system created to seize the world. Which means that sooner or later it must become possible to separate the product from its founders. If only so that its shares can be traded. A machine made of people in the shape of a sales funnel — that’s what a product is in most cases.

Doing projects isn’t quite a business. It’s hard to scale, it’s always local to some degree and heavily tied to personalities. It isn’t very clear how to tear it away from the core team, or how you’d sell it, for example. That is, you can certainly make money that way. But it only makes sense if you like the people and the process of solving assorted client puzzles.

A project studio is above all a story about staff. For my first ten years as director, every time somebody quit I felt like Prometheus with that bastard eagle tearing a piece of liver out of me. Tearing it out and hauling it off somewhere. To the Yandex company, say, or to Moscow.

Then I understood that people work for you as long as you’re teaching them. More precisely, as long as they can see there’s still something valuable to learn here. Project business has to be built so that people always have tasks in their zone of proximal development. You hire people, they get stronger. And as long as they’re getting stronger, they’ll stay with you.

The whole catch is that sometimes people outrun the development of the business — they level up faster than new slots appear in the team where they could take on harder tasks. Then they leave, and there’s nothing to be done about it.

The structure of responsibility

For project work, clients are the best people. Seriously. And not because they pay money. It’s the client who takes on the responsibility for choosing the goal. To feel like a champ, all that’s left for you is the simplest part: being honest, predictable and extra-competent. Because the client has taken the hardest thing onto himself: he has decided where you need to go.

Besides, in project business you and the client are equals and can behave like partners — two independent, grown-up, responsible parties who can agree on shared goals and on the ways to reach them. That, actually, is half the joy of it, if you know how to do it.

But if nobody is holding the frame of the goal, you feel monstrous pressure — that’s the world pressing on you. There’s nobody between you and the terrible cosmos. In a product, if you chose the goal wrong or, God forbid, chose more goals than you should have, it all ends sadly.

When you’re first left without a client who makes those decisions for you, it turns out this is a very heavy responsibility. Only at that moment does it become clear that choosing the goal isn’t only possibility and freedom, but also a terrible pain in the ass, a never-ending argument and team schizophrenia. You get used to it eventually, of course.

In a product, you’re the one in charge. Here you can’t treat clients as equals — there are too many of them. If you listen to every one of them, you can get tangled up in contradictory demands and expectations. And clients also aren’t ready to take on responsibility; they want to get some enjoyment, and that’s it.

Only your team is answerable for everything: for the service, the payback and the scalability, for the priorities and for the choice between fast money and strategic development. It’s important not to let money, users or responsibility leak away.

Unlike project business, a product is a bundle of processes that have to launch simultaneously. It isn’t enough just to design the interface, write the code and test it. If you’ve released a new feature, then the change has to touch all the processes at once: development, production, the lawyers, tech support, the salespeople, finance and the lawyers. Otherwise the money and the clients’ loyalty will seep away into the seams between the processes.

Marketing

The main thing to understand about marketing in project business is that there basically isn’t any. There’s a frontman who sells. And at first he does it better than a whole marketing operation. If that isn’t the case — there simply are no sales. It isn’t hard, but there is one problem: sooner or later the frontman runs out. And when he runs out, it turns out your marketing never grew in.

You were selling with yourself, without any marketing process at all. And all you have by way of marketing is PR. That’s in the best case. Yes, it’s useful, clients come from it. But PR is a different, broadly local instrument; it scales badly and lives around the talent and connections of particular people. It’s barely manageable and doesn’t help much with entering new markets.

When you do finally decide to enter a new market, this difference becomes obvious. You’ll discover that leads are very expensive. But that isn’t a problem if you have a high ticket (backed by reputation, though unfortunately on the local market). A much more serious problem is that the new clients coming from marketing will be cold, and it will be hard to turn them into long-term ones.

The product’s problem is a completely different one. Usually from the very beginning your attention is focused on the efficiency of your marketing machine. If you do everything right — set up your unit economics and learn to calculate them, find your effective sales channel and build a machine for producing clients — then sooner or later the market runs out. That’s the problem.

Working in project business, you get used to a bottomless market. So when this happened to me for the first time in a product, it was unexpected. What do you mean, we can’t bring in even more clients per month? Why not? Because you built a machine, and it efficiently eats through the channel. It’s not that clients disappear altogether, no. It’s just that the growth rate flattens out onto a shelf, and you’ll have to do something about your plans for constant extensive growth.

How do you avoid that? Change the product, find new niches, create new value, build a new channel. Then you get to enjoy the growth for a while, until that niche runs out too. And so on, endlessly. You get used to that too.

Managing time

The main difference between project business and product business is how time is arranged in each. In project business everything is subordinated to the cash-flow balance. Your mood and the state of the business at the end of the month depend on how much money you spent on salaries and suchlike and how much you took in.

By payday, employees turn from capital and near-family members into a blocking detachment breathing down your neck and watching whether you’ll have enough money to pay for their work. Especially at the start, while you haven’t yet learned to handle the rhythm of projects confidently — and every project has its own particular rhythm. Roughly speaking: they pay you an advance, first you live on it, and then you hold out until the final payment.

The hardest stretch is right before the final handover of the project, when the costs have already been incurred but the money isn’t with you yet. If you do nothing about your projects, the rhythms of all of them will synchronise, and one day it will turn out that right now we’re waiting for payments from every project at once, while we owe everyone.

Under those conditions, even a small payment delay turns into an enormous problem. So the main task in managing time in project business is to desynchronise the rhythms of the projects. To arrange things so that payments on some projects compensate for the dips in others.

In product business, time is subordinated to the rhythm of client processes. So you’ll have to analyse the existing metrics daily, weekly, quarterly — that is, constantly. You’ll set up a lot of analytics tools, and it will still feel like too few.

Analytics in a product is an infinitely delicious orange; you can’t stop digging deeper into it. And besides gaining knowledge in each of the processes, you’re doing two things: accumulating momentum and reducing friction. Optimising, in short. How to do that is a topic for a whole book.

The stages of a product’s life

I’m used to looking at the stages of a business’s life as the inflection points on the return-on-investment curve. Here’s the graph. In the picture it’s smooth, but in real life it’s all much bumpier, of course.

Let’s look at the points on the graph:

1. The idea — this is where you started spending money.
2. You started taking money from the client.
3. You’re getting as much from clients as you’re spending.
4. This is where you recouped your investment.
5. You’ve hit the ceiling of the channel’s efficiency.
6. Your business has started dying (if you didn’t manage to grow the next version of it inside).

Birth — from the idea to the MVP

Almost every startup conference is devoted to the birth stage. And their participants often think that a startup is only about being born. Until the project has shown itself, you’re having the most fun — you’re doing everything at once: testing the idea and the sales, recruiting employees, designing the UX, and so on. Peppy, creative, “startup spirit”, the whole deal.

All that is fine, but the main thing is to make sure you have enough faith and will to drag the idea all the way to payback. My main conclusion at this stage: if you don’t have an entrepreneur who will devote his entire self to embodying the product, or you don’t have a team lead who knows how to herd programmers — just don’t do the business. And yes, a hired director is not an entrepreneur.

Childhood — from alpha to stable sales

At this stage the product turns into a process of inflicting usefulness, already packaged into software and marketing so it can be sold to clients. The main problem is a lack of concentration. A mass of factors will constantly be pulling you out of focus.

Build features for one group of clients or for another. Push on sales or on convenience. Sort out the suppliers or improve the quality of service. Raise prices or do a big project for an important client. But the most important one is the constant conflict between tactics and strategy.

You need to do two things at once:

• Develop the project so as to conquer your market (and the next one);
• Earn the money for that development.

And the most unpleasant part is that you’ll never know for sure which matters more: earning money now or working on development. More precisely, it will always be obvious that development matters more, but the money will still be desperately needed.

The saddest thing is that money from an investor — which you’d think could solve this problem — only makes everything harder. Before the investment, the need to earn was what kept you from idiotic decisions. The moment you have spare money, you get a mass of excellent ideas about which unnecessary undertakings to spend it on.

It’s very dangerous not to lean on the real needs of the business today — that’s how you can drift off into dreams and lose touch with reality. And simply eat through the money without reaching payback.

It’s very dangerous not to work on strategic development. That’s how you can miss your window of opportunity and sleep through the moment when you could have seized the market and turned into a local business.

There is no reliable rule for choosing between these two priorities. But besides them there will be a huge pile of ideas about what else you could do. If you give in to them and start developing “side branches”, you’ll inevitably lose momentum. So the main job of the head of product is to tell everyone and everything that isn’t in your business’s focus to piss off. And the main problem and the main risk is not getting that focus wrong at each of the stages.

Independence — from sales to self-sufficiency

When you go into product, you’ll think that at first it will be hard and difficult, you’ll have to strain, and then it will get easier. That’s only half true. At first it really will be hard and difficult, but there won’t be any “easier”. If it got easier, that means the product stopped developing. So the ghostly hope of a rest will remain a ghost.

And once more about ambitious goals and focus

Since you’re doing a business, you have an ambitious goal. But sometimes a second ambitious goal bursts in. Defocusing happens. What does that mean? That you as the director failed and didn’t tell someone to piss off in time.

Usually it goes like this. Somebody from the board, or a valued client, or a smart colleague comes to you. And says: “Let’s build an awesomely useful thing into the project.” Notice that nobody comes to you with idiocy (the ones with idiocy are easy to tell to piss off). And if you agree, you’ll build a very useful thing, you’ll make money, but you’ll lose your product’s momentum.

Which raises an idea: why not tell everyone to piss off without even looking? Because one day your product will have to change. And you have to realise that not at the moment of the change, but at least a quarter beforehand. How do you tell which kind of change this is: a pivot (a key change to the product that will create new value in combination with a new channel) or a side quest (a secondary mission that only distracts you from the goal)? It’s very important to tell them apart, because a pivot is necessary and a side quest is harmful.

If it’s a pivot, then the first ambitious goal no longer exists. Now you have a different ambitious goal. Unfortunately, that’s usually not how it goes. What most often happens is this: a partner comes up to you — a smart, competent person. And says: “Time is expensive, let’s go for two goals at once, otherwise the competitors will overtake us…”

I’m an idiot. I twice agreed to two goals at once. Don’t do what I did. (Yes, I know this sounds like “flap your arms harder and you’ll take off.” That is, absolutely correct and completely unworkable in practice. So I’m writing this for my future self: “Future Kulakov! Don’t go for two goals at once!”)

To go for two goals at once you need two teams. And two teams cost not twice as much money but three times as much. And that’s only the optimistic estimate. Because the teams will have to be coordinated with each other, and that’s an extra cost. And yes, at first you get not an increase in momentum but a decrease. Exactly like in the good old “mythical man-month”, yes.

But if you do decide to chase two goals at once and it all goes wrong, never say afterwards, “I pissed the business away.” Say, “We gained invaluable experience.” That’s what everyone says.

Projects or product — how to choose

If the phrase “I want to change the world” isn’t a pompous slogan for you but a concrete necessity; if you really do have an idea that it will be great if people start doing something differently (the test is this: if you didn’t need to earn money, would you still want to work on it?); if for some reason you really are dead set on conquering the world — go into product.

If you want simply an interesting job; if you want there to always be a relevant task, for people to look at you as a professional, and for the guys working next to you to be people you find interesting — go into projects.

You can also combine the two (like me), but I don’t advise that for anyone, because few people enjoy a sixteen-hour working day.