Who You Can Be in an IT Product: Career Strategies for Every Occasion

I gave a lecture on the topic of this article to students at IRIT-RtF, Ural Federal University — the material is especially useful for beginners facing the choice of how to build a career. We’ll talk about what a product team is and how it connects to your potential career, why you need to think about the product, what sources of competence exist inside a product, and which roles you can play there.

In general, this is a reflection on “What would I do if I were 20 today and knew what I know now.” Because everything I say is a conclusion drawn from my own experience. I’ve been working with the internet since 1997, and over that time I’ve played different roles and combinations of them: designer, UX engineer, various kinds of manager, art director, chief product officer, and — longest of all — CEO.

My background is in user experience, but I haven’t worked hands-on for quite a while now; instead I command other people: programmers, designers, managers. My area of expertise is customer experience and product management.

The product and the product approach: the main ideas

Before I talk about career paths, I’ll say a bit about the product, because in the field of business automation — the field I work in and the one I’m telling you about — a big change has happened in Russia over the last 10 years, and in the world probably over the last 40: the product approach developed and became popular.

The first thing we picture at the word products is what’s in stores: craft cheese, say, or cars. But I mean something slightly different — digital products: search services, VR games, or some other experience of interaction between human and machine.

Digital products aren’t a one-off activity, they’re a continuous process of changing customer behavior, in the course of which customers get value. That is, something good happens in the customer’s life from interacting with the product, they notice it, and they’re willing to pay for it.

In the general sense, products are value for the people who pay for them, and for the people who sell them they’re a process of creating value and a source of profit.

Before the product approach to growing a business, most of us stuck to the project approach. A project is an undertaking to change something, and the project approach is aimed at launching some kind of change in a business. The changes happen — and the projects end. With products it’s the opposite: their creators try to make sure they don’t end and bring in more and more profit.

Don’t get me wrong. Project management is needed. And in business there are tasks that are built backwards from a deadline. You simply can’t do them with the product approach, so you have to do them as projects.

The product approach added a focus on continuous, managed development to the project approach. Its main ideas:

• Relying on data.
• Fast business scaling — the company’s entire activity is aimed at making the business grow faster: capture more territory, get more users, earn more money, and change the world more.
• Iterative-incremental changes — instead of working away for ages and then rolling out one giant release a year, we change the business constantly and, relying on data, we see it growing fast. The main idea of the product approach is to shorten the feedback loop between the developers’ effort and the effect of that effort. The faster we understand how the changes we’ve made are working, the faster we’ll help the business grow through automation.

The product approach is a combination of three ideas: how to grow a business fast through incremental changes and by relying on data. I think for at least the next 10 years this approach will be considered the best practice for managing and automating digital businesses.

The product team: properties and composition

I’ve run a lot of interviews and noticed that engineers — whatever the breed, programmers, designers, testers — generally hold two beliefs about careers.

First, 90% answer the question “What kind of work do you want?” with “Interesting work,” and everyone means something of their own by that word. (More on that later.)

And second, for newcomers a very important value is the growth of professional skill. Most of them focus on individual skills. And it’s great that people coming into the industry want to grow. If an engineer doesn’t want to level up their skills constantly, they picked the wrong profession. But something else matters far more to a company: businesses are interested not in atomic talents, but in people capable of forming social molecules that combine into effective chains and create value.

To reach your career goals you need to understand not only which skills to level up, but also in what way and with which people you want — or will have to — form effective pairings. That is, you need to be able to become part of a product team, not just a skilled specialist. And those thinking about a career as a manager need to be able to build such a team.

Being a useful part of a group matters not only to engineers. It’s the main factor of usefulness in any task that takes the effort of several people. If you’ve played team computer games, I think you’ll agree: it matters that your teammates always do something appropriate and can pick things up at the right moment. I’ve had plenty of that experience in backpacking, for example. It matters to feel the person next to you, to be able to shift part of the responsibility onto them, to be sure that at the critical moment they’ll do exactly what you expect of them. It matters to be able to share your consciousness with “that other guy.” And then you become a collective brain, an organism made out of many people.

And for a business this matters even more. A team that makes a product has to be able to:

• Think off one another
• Work toward a shared goal
• Complement one another
• Carry shared responsibility for the product

If the unit that does the automation doesn’t have these skills, then it isn’t a team — it’s just a scattering of people. And that’s bad both for the employees — everyone is sick of each other, and it seems like everyone else is an idiot because they’re not doing what’s needed (they’re probably not stupid, your expectations of them just don’t match reality) — and for the company: all the processes are very slow, everyone works only when prodded, decisions are trivial and compromised, strictly by the book, because people don’t support each other.

The product team is the main driver of a product business.

Four groups of employees in a product

Specialists

These are professionals who command themselves, and whose individual competence the company buys. Specialists in information technology got lucky. I often say that IT is the best of worlds, because interesting and smart people work here, and quite a lot of career paths are open to them that let you play individual roles: stay a specialist, command nobody, and still grow your value to the company. You just have to find the right specialization.

A reliable way to figure out whether a specialization suits you is to answer the question of whether you’re able to get into a state of flow in it.

For example, my background is UX engineering, and honestly, I like doing design far more than making decisions, dealing with partners, and sorting out people’s problems. And so, when Midjourney came out — the neural network that creates images from text descriptions — I got an excuse to dive into flow: that’s when you start doing something and then look at the clock and think, “Oh my God, it’s the day after tomorrow and I didn’t even notice.” But unlike a similar situation with a computer game or a TV series, when you surface from flow you discover that you’ve learned something and made something you can brag about to your colleagues. It’s engineering joys like this that make people stay specialists.

Managers

Although a narrow specialist’s career is nothing bad, growth in a company usually means moving up the management ladder: as a person accumulates more experience, more responsibility falls on them, and they start managing not only themselves. In other words, they get the role of a manager, and then of a leader.

Leaders

Here there are a lot of words starting with the letter C, which stands for chief and points to C-level — the highest tier of positions, the one that implies responsibility for an entire area. A corporation usually thinks that getting a C-level role is what everyone should strive for, but, as you’ve probably already gathered from this text, that’s far from always true. Leaders have their own joys and problems, and specialists have theirs.

Super-universalists

I count myself in this group to some degree, because I have a lot of different competences. True, that means my native competence — UX design — suffers for it. If I had done only UX design, I’d be a deeper and more valuable UX specialist today than I am. That’s what I pay for working as a leader instead of a specialist. But in exchange I do a lot of other things, and I have a broad set of competences.

The younger the company, the more arguments there are for betting on super-universalists. Because when the team consists of roughly one person, it’s good if that person can do everything themselves: pick the spot for the business, test the business model, find customers, do the design, program it, test it, roll it out. And I know people like that — they’re very valuable.

But it often turns out that super-universalists can’t work with anyone, can’t form molecules. Which means there’s only a use for them at the stage of a company’s life when it doesn’t have a collective yet.

Why should some people know about the others?

When I talk about the product team to IT students, I often hear the question: “We’re programmers, why do we need all the other roles?” And now it’s time to work out what interesting work is. I put together a list from the answers I got from students and candidates, and from my own thinking.

So, interesting work is:

• Hard and creative — it lets you make something new and unique that you can be proud of;
• To your liking, motivating, work you want to go to and don’t get tired of;
• With comfortable conditions: a normal team, deadlines, rules;
• On interesting technologies;
• In demand — you can see how the results of your labor are used and how the world is changing;
• When you can influence the decisions that get chosen and the work you’re trusted with;
• When you work with people who value you;
• Work that pays well.

Everyone’s list can be their own.

What interesting work means is clear. But how do you get it?

For work to be interesting, you need to influence which tasks you’re given. And for that, your voice has to be heard and you have to be taken into account.

You’ll be taken into account if you’re a valuable specialist whom it’s scary to lose and whom people can lean on, that is, you are:

1. Competent — you don’t just have valuable knowledge and skills, you can also apply them to solving the problems the company actually faces (and that matters more);
2. You understand the context and the goals — you know what different people in the company are responsible for;
3. You know how to fit your effort into a team result — again, you can form social molecules.

And if you don’t find a team you’re valuable to, you won’t be able to influence anything, and whether your work is interesting or not will be a matter of chance: lucky or unlucky.

The most interesting work goes to the combination of “IT + something else”

I’ve highlighted the roles for which an IT background matters a lot:

In the leaders’ column, that background matters for every one of the roles, because if the head of a business that leans on automation has an IT background, the chances that the company will manage to create a product that grows fast and captures big markets are orders of magnitude higher.

Most product leaders came either from programmers or from analysts. People like me, who came from designers, are about 10% — it’s a fairly rare mutation. But there are even fewer good CPOs who started out as plain managers with no hands-on experience to their name. Same story with marketing. But marketing is a separate hardcore qualification.

There are two paths to becoming “IT + something else”:

1. First become an IT person, and then pick up some additional managerial and leadership skills;
2. First become a specialist in some other area, and then realize: “God, now I somehow have to figure out IT.”

The first path is far more organic and easier.

The only two specialties I didn’t highlight are researchers and salespeople. Researchers — first of all the ones who study customer experience — play a very important role in growing products. They gather primary information about how people and businesses behave and draw conclusions from it. And most of them used to be salespeople, because to research people you have to want to and know how to talk to them. And also to be able to get over the social barrier — to put it plainly, to call someone on the phone and not be shy about it.

That said, if a researcher or a salesperson used to be an IT person, they’ll be more valuable too; it’s just not extremely important for them.

“IT + something else”: examples from life

I have a son, he’s 23, and last year he worked at a startup that makes cargo e-bikes. That startup’s CEO is an engineer, and he started out selling all kinds of personal electric transport. And he’s a good CEO for this stage of the business, because he can both program and sell.

Or the opposite example — the founder of the self-publishing platform Rideró, where I’m a co-founder. He found a source of technical competence on the outside, because he couldn’t program himself. In the end, because he found such a source, we got a product. But because he isn’t a programmer himself, the company’s vision is built not so much around technology as around service.

I’m not a programmer either, and that limits me considerably. I can’t invent software architecture myself. I can find a niche, make an invention, design the user experience, but when I start thinking about what means to do it with, I’ll need another person’s brain. My decisions will be limited by the best practice I know about — I won’t be able to invent anything fundamentally new in programming.

But a leader has a special competence — they know how to command “over their own head,” that is, to command subordinates who do something the leader doesn’t understand. To acquire this competence you have to learn to lean on other people’s competences, to learn to think with other people.

Career: the starting point and the paths of development

I drew a chart of career development and marked the point on it where everything usually starts.

The vertical axis shows breadth of competence: a narrow specialist knows one thing, while a universalist knows many — for example, they don’t just know how to program physics engines, they’re also familiar with modern CG approaches for gamedev and know how to design the experience around that. I’ll say it again: the bigger the company, the more roles it has for narrow specialists. And vice versa.

The horizontal axis shows breadth of responsibility: an employee is responsible only for themselves, and a leader for many subordinates.

Practically every career starts with a person knowing one thing and being responsible only for themselves.

As I’ve already said, developing within the lower-left quadrant is a good strategy too. But the natural current of career paths pushes everyone up and to the right — toward universalist leaders.

Any business is limited by the time of the people capable of making decisions. So if someone in the company shows that they can make decisions and be accountable for their words, that people listen to them, and that with the help of others they can achieve predictable results — the company will try to turn them into a leader. Which means the person will have to immerse themselves in adjacent contexts, and that will make a universalist out of them.

The rungs of the career ladder

The diagram shows a generalized career ladder: at the start there are different specializations, and above them the responsibility tracks begin. Interns, juniors, middles, and seniors differ from each other in how big a piece of work you can hand them. But a senior is also a source of competence — they’re the one who grows juniors, shares experience with them, and gives feedback.

The company has an interest in steering employees who make it to senior into adjacent specializations. The most logical track is: a senior programmer becomes a team lead, and then a CTO. But in fact QA leads, project managers, and product managers all come out great from people who started as programmers.

You can start developing toward one of the tracks at earlier stages too. For example, if a junior wants to be a project manager, they can already start watching how the manager behaves and taking on some of their tasks. And when that junior gets to middle, they’ll go not into senior programmer, but into a different track.

Who comes out of whom

The pink ones on the diagram are the places you can occupy while remaining a specialist. And the blue ones are roles with a large amount of responsibility that you can get if you go higher up the ladder.

Testers turn into QA, developers first into team leads and then into CTOs, analysts into project managers, researchers into product managers. (In reality product managers come out of analysts too.) Product managers turn into chief product officers, marketers into chief marketing officers.

And the CEO comes out arbitrarily, but the company will be very lucky if they come from one of the three C-level tracks. If the CEO used to be a CTO, then the company will have strong technology it can lean on. If, as in my case, the CEO knows how to command products, then the company will have strong product competence — it will know how to create products. If the CEO understands marketing, then the strong side will be acquiring customers through external channels.

A CEO can also come from outside these tracks, that is, from outside IT. For example, they might have been a salesperson or a procurement manager in the past. Then the company most likely won’t have a strong IT culture, and it will have fewer interesting career paths for IT people.

Startup or corporation — where to start

Those who like a bird in the hand should go into corporations. There’s more order there, more conditions for comfortable work. Startups are for the adventurous, for those who like risk, for whom comfort matters less and personal significance matters more.

Corporations have positions for narrow specialists, and it’s clear in advance what to do. In startups the team often consists of about four people, so everyone does everything, and being a narrow specialist is hard. On top of that, startups usually don’t have intern openings — for that the company needs a spare senior who’s ready to grow interns.

In a corporation you can get a stable salary, whereas in a startup there’s a better chance of earning really big money. And it’s far easier to get to C-level when there are, roughly speaking, four of you — in small companies 80% of the staff have the word “director” on their business cards.

You can get into a startup even with no qualifications at all, but you have to be ready to carry a lot of responsibility. There are only two paths: either you swim out or you croak.

Critical competences for an IT business

There are five competences without which a business built around automation will have a very bad time.

1. The entrepreneur

If there’s no entrepreneur, you might as well not get out of bed. An entrepreneur is a person who gets the idea to change the world and make money on it. And in the company’s first years they’re the main one, because they:

• Are accountable for the consequences if nothing works out;
• Make the decision when everything has to change and go a different way;
• Hire all the other sources of competence;
• Find the source of money.

2. Technology

If a company wants to take its share of the market, it inevitably has to secure the best processes in its niche. That is, the processes with the lowest cost per unit of delivered value. And in 80% of cases that implies automation, which is why the person who will lead development matters so much.

3. Industry competence

For every market this is something of its own: if we’re making a technology startup in pharmacology, we have to understand how to develop and sell drugs; if in construction — how to build and sell houses; if in gamedev — we have to be able to create impressive gameplay.

As a tracker, I run a startup working in the car market. Its creators are a team of IT people; none of them ran a car dealership or sold cars. They found a market and learned how to make money on it, but to grow further they need someone with industry competence. You can of course learn everything yourselves, but usually a business simply brings onto the team someone who already has that competence — a person with experience working in the industry.

4. Sales

Unlike the entrepreneur, salespeople don’t invent what to sell — they optimize the ways of selling. They make sure there are more deals and that the deals come cheaper.

Sales management used to be a field fairly far from IT, until sales strategies appeared that lean on data analysis and automation, that is, sales through various interfaces. In that case the salesperson commands not people but a combination of product and marketing. That is, they set tasks for the team of developers and marketers. And although IT people rarely turn into heads of sales, the expertise in sales management required from development is fairly deep.

5. Marketing

In Russia the word marketing usually means performance marketing — attracting traffic on a pay-per-action basis so that it converts into customers efficiently. In other words, it’s data-based marketing with a fast, visible result.

A marketer today is a person who understands how to work in a big pile of specific software products, like managing ad campaigns in social networks and search. But very often an effective marketing strategy is built on replacing manual labor with automation. And here there’s a mountain of tasks for data science and machine learning, not to mention plain integration.

In any specific case, any of these competences can be the critical one — the one without which nothing at all will work out — but most often the critical ones are the entrepreneurial and the technical competences. Properly speaking, you can only outsource the non-critical ones — and you need to have the source of the critical ones inside the company.

Sources of competence

A source of competence is the first person in the company who knows how to command people like themselves. Being a source of competence means achieving business goals with that skill, and also building that competence inside the company — being able to hire such people, onboard them, teach them, manage them, and ultimately fire them.

Without a source of competence, starting to use it is very expensive and risky. But finding a source for each of the five tracks of the career ladder is always very hard. A big pain for the whole industry is finding a CTO. Same story with a good chief product officer and a strong entrepreneur.

Instead of a conclusion

When I started working with the internet in 1997, there were few sources of knowledge and little access to good practice, and we did terrible nonsense. And now there’s plenty of all of it. And while you’re at the start of your career you’re only risking your personal time, so you can just go and try to make your own product. It won’t work out the first time, of course, but you’ll understand a lot.

Step on rakes while they don’t hit hard and you’re only risking time

If you want to know the details about the individual roles — who is responsible for what, what they do best, and what interesting things they work on — download my presentation. In it I went through the roles of investor, entrepreneur/CEO, head of development, product manager, project manager, developer, DevOps, UX engineer/designer, QA, researcher, and marketer.

And if you’ve already figured everything out and are ready to start your path in an IT company, send an application to our email jobs@jetstyle.ru — we have openings for any level of experience, including intern positions.