Product Development with an External Team

Everywhere you look, everyone is doing product and digital-service development (yes, us too), but let’s sort it out honestly: how product development differs from outsourcing and outstaffing, what parts the various contracts on the custom-development market are assembled from, who is responsible for what, and what is more profitable for the client and for the team.

This longread is based on a talk by Alexey Kulakov, CEO of the digital production studio JetStyle and CPO of the publishing service Rideró, about how product development differs from outsourcing and outstaffing, why do it at all, and what the main difficulties are. Alexey’s experience runs both ways, so there will be a lot of conclusions — and therefore a lot of text.

There’s a table of contents above — you can jump straight to whatever interests you most (but we recommend reading in order).

Introduction. Axioms

Let’s start with two and a half statements. For me these are axioms, and I won’t be proving them in this article. But if you want to — come and argue)

1. If you can agree with the product’s client on a retainer, you should agree on a retainer.

An important clarification — this is needed by you and by the client alike. But at the start of your collaboration the client may think otherwise. The truth is that this is the “do it as if it were our own” approach. If I were making my own product… No, no “if”. When I make a product for myself, this is exactly what I do. So I advise clients to do the same.

2. If you can run development in an iterative-incremental cycle, you should run it in an iterative-incremental cycle.

This is the best working scheme — there’s less turbulence, we deliver value faster, and we can adapt the product and the client’s processes to the needs of the market.

The same thing can be put more sharply and more contentiously: if you’re making some new product and you’ve decided to work off a technical spec, then you’ve decided to shoot yourself in the knee.

(Don’t do that. You’ll soon see why for yourself.)

Everything written below follows from these axioms.

Sorting out the terminology

For you to get anything out of reading this article, we need to understand the words retainer, iterative-incremental development and technical spec the same way, so let’s fix the definitions and the substance.

What a retainer is

A retainer is a scheme in which we and the client agree that one sprint of the team costs a fixed amount of money — say half a million rubles — and the team has a permanent roster of specialists agreed with the client.

For each sprint the client pays on the fact that the sprint is finished. A road map is usually used to coordinate development, but the commitments about which tasks will be done in the coming sprint are talked through immediately before it. It’s very important that this is done jointly by the whole team, consisting of the developers and the team on the client’s side. Unlike time & material, the money that gets paid and the composition of the team we ship don’t change from week to week. As a result, the product gets a stable team focused on its development.

A retainer is the most convenient scheme for developing products — for us and for the client — and we want as much of it as possible.

What iterative-incremental development is

Iterative means that we implement the decomposed plan in small stages, each of which is carried out within a standard cycle — an iteration. Every iteration has its own planning, implementation, handover and next planning.

Incremental is when we gradually build up the functionality of the system, implementing something important and needed every sprint. We start with the minimum that is fit for operation, or at least for testing in real conditions.

Iterative-incremental means that we act in cycles and try to add benefit with every cycle. Each of the two parts matters: iterations let us reflect and accumulate experience, and incrementality lets us hold the rhythm and not relax.

Why is this approach good for new products?

When we’re about to create some new thing that people will use, we most likely don’t know in advance which hypothesis will be confirmed and what exact functional portrait of the product — in combination with the business processes on the system owner’s side — will actually work. We’ll learn that later, and only in interaction with people. We say: “Right now we’ll make one small thing, look at how it worked, and after that decide what to do next.” We move into the future in small quick steps and each time we show what we’ve done. And we don’t just show it — together with the client and their customers we try to use it.

We aren’t trying to make the forecast bigger and bigger. We’re trying to eat the elephant in pieces. More precisely, we don’t even know whether what we’re eating is an elephant. We’ll find out whom we ate only once it’s been eaten. At the end of a sprint, what we’ve made can at minimum be observed somehow, and better still can be used somehow.

Why a technical spec is evil

There’s probably no need to explain what a technical spec is. But let me explain why working on a new product off a spec is harmful for both sides.

First, we all know that from an arbitrarily beautiful technical spec you can build and hand over an arbitrarily hideous project.

Second, a technical spec creates pressure from the client on the developer in exactly the places that will not lead the client to success. But the pressure doesn’t get any smaller for that. It’s a pain in the ass because of which the developer’s survival strategy on the project minimizes the chances that the result will be useful. You order by spec — you get “as per the spec”. To get benefit out of a product, you have to talk with the developer about the benefit from the product, make it the subject of the work.

Third, it’s clear in advance to us, reasonable people, that if a new product has been through a series of experiments, then its functional portrait at the moment we hand it over will almost certainly differ from the portrait we imagined at the start. Because if it doesn’t, then presumably we knew in detail in advance what it ought to be. And if that’s so, it can’t be new and useful thanks to that novelty. And if it hasn’t been through a series of experiments, then maybe it won’t differ, but that means it won’t be useful either, because we didn’t adapt it to the behavior of people in the market. We merely embodied our hallucination.

So you can work off a spec when your task is to reproduce a long-studied stable system or to embody a hallucination. Neither of those is product development.

So: retainer + iterative-incremental development – technical spec = the best working scheme.

But that still doesn’t make the development product development.

Software development ≠ product development

If you remember one thing from this article, remember this:

Product development is not software development at all.

When you develop a product, your subject of work is different. You aren’t developing a program. In product development the subject of work is delivering value and testing hypotheses.

By the way, that means you can develop a product without programming at all. And you can program software for arbitrarily long and then discover that there’s no product. But there is software. I’ve done that several times — sometimes with my own money, sometimes with a client’s — and I don’t want to do it again.

So what has to happen for software development to become product development? Right: test hypotheses and deliver value.

Anyone already sick of the words value and hypotheses before this article even started? You’ll have to bear with it a little.

What values, exactly, does development deliver?

What do we mean when we tell the client: “We want value to be delivered at the end of every sprint” (as holy agile teaches us)?

In my experience, values can be split into three layers: creating software, creating a product, and running a business. It’s easy to notice that this is a split by area of responsibility.

Layer one. Creating software

1. Features — in production

How did this go in custom development? We worked, features are in production. That’s it, hooray, value delivered! We get paid for features, we delivered features — and we’re pleased. And although the software quite probably doesn’t behave in a way that makes the client happy and the business grow, we’re great anyway. We delivered what we promised. If we’re lucky, it doesn’t even glitch much!

Features in production isn’t about product at all, but it’s the most common value sold on our market. It’s the subject of work of outsourcing and outstaffing.

In product development we consider that if some people haven’t started behaving differently, then as a result of your activity you’ve made nothing. Well, apart from getting money for the development. That’s an important part of our work, of course, but the value still hasn’t been delivered.

Layer two. Creating a product

2. The process — in operation

To say that we’re doing product development, we need to get at least to this point in delivering value. Because here we see that as a result of our activity someone changed their behavior — not the client’s customers yet, but at least their employees. As a result of our joint work their regular activity has started to change. Yes, that means the subject of product development is changing processes.

If the client hasn’t tried using the software, the client’s customer won’t be able to use it either, because software doesn’t work by itself. It would be more accurate to say that what actually works is not the software itself but the combination of our software and the client’s business. So when we iteratively embed software into the client’s business, we change the client’s business. We need to make sure the software isn’t isolated from the business, that it’s integrated into the client’s activity and brings observable benefit. Otherwise the software most likely won’t be used at all.

For example, when we started working with our client, the IQ007 speed-reading school, we could have simply been delivering features to production. But we agreed right away that this wasn’t enough. Every time you have to make sure the product got into operation — at least test operation, better still real operation. First the methodologists who put together the study programs started working with it. Then we started testing the product with students. And then the teachers came into the system, and we’re still developing the product with them today.

Another example. A startup came to us. By the time they got in touch they had already spent several million and a year of work. As a result they’d tested zero hypotheses and created no regular processes. What they had done was develop a pretty sprawling UI and even churn out a fair number of features. Only none of it brought the client any closer to the next round. Why? Well, because the guys were working off a spec and delivering features. The client now feels cheated and curses the previous team. I actually think that’s undeserved — the guys did exactly what they promised. It’s just that this work shouldn’t have been done in that logic at all. They should have been making a product.

So if we’ve got at least as far as changing (for the better) the client’s internal processes, we can already say that what we’re doing is product development. A little bit.

In the next layers there will be even more productness.

3. The client’s customers got value

Here begins the part we love our work for. Testing hypotheses about customer behavior. As a result of our work, live people got something important for themselves. How do we know? We look at their behavior and analyze it somehow. And if the customers’ behavior changes, if they’re glad about it — then we’ve delivered value.

This doesn’t necessarily mean yet that our client got a benefit. But there’s more meaning in the work. For it to be profitable as well, you have to not just make people happy but, together with the client, find a way to grow the business. For that you’ll have to go to the next layer.

4. Hypotheses get confirmed

By “hypotheses get confirmed” I mean that the client got new knowledge about reality and understood that this knowledge is solid. You can lean on it in order to invest a ton of money and effort into creating a product and not burst into tears at the end.

Strictly speaking, you can seriously claim to be doing product development only from this moment on — when a process of regular hypothesis testing has appeared. As a result we get the knowledge we need, and our product moves toward its goal. Importantly, this movement doesn’t happen on paper. We see the regular behavior of live people change in exactly the way we wanted. Someday we’ll talk about how to manage this process, but that will be another article.

5. The economic model adds up

One of the important hypotheses is about our product paying off. At this stage we find the combination of the value the product creates, its packaging into messages, and the channel we get customers from. And we see in the numbers that we’re scaling revenue and not losses.

The economics tells us: yes, our thingy works. The more customers the client has, the better. Now the only thing lying between the client and their goal is money — so it’s time to invest more of it.

If we’ve reached this step and done everything above it — we’re on the verge of conquering the world.

Layer three. Running the business

The last layer is handled not by the product team but by the business team.

6. Profit grows

That’s the CEO’s responsibility.

7. The business becomes more valuable

And that’s the business owner’s responsibility.

I listed these two points simply to say that the product isn’t responsible for everything in the world.

What hypotheses, exactly, do we help the client test?

We’ve dealt with values, now for hypotheses. In my view, when we talk about a new business or about changes in a business, there are only four hypotheses. More precisely, four piles of them:

1. Market hypothesis / size, what’s growing, what the driver is

2. Marketing hypothesis / CPA, channel, conversion

3. Product hypothesis / LTV

4. Team hypothesis / there are sources of competence

The business tests them on its own or with our help.

1. Market hypothesis

We gather everything we managed to learn about the market:

— how big the market is,

— how it’s carved up

— and, most importantly, what’s growing in it and thanks to which factor.

And in general, is the area we’ve barged into worth the bother? Is the prize big enough to risk time and money for? And if so, where is the best niche to enter right now and what should we talk to customers about?

For example, we’re currently researching pharma. And there the face-to-face communication channel has changed a lot: people, especially the elderly, have started going to clinics less often, so contact through the doctor works worse. We also know that this is the main channel for selling prescription drugs. As a result there’s a powerful trend toward digitalizing sales and a whole fan of problems that need solving. We don’t yet know how, but you can see it’s a big market and that the digital-communications segment in it is growing fast.

2. Marketing hypothesis

At the previous stage we understood that there’s a big growing niche and set ourselves the goal of conquering it. Now we have to understand what to sell into it and how. For that we need to find a combination of channel and message that gets us good conversion into sales.

Conversion is the key metric here, because it affects:

— how much a customer will cost us,

— what share of customers in this channel we’ll get.

Often the success of the whole product comes down to solving exactly this task. It isn’t always sufficient, but it’s almost always necessary — simply because without some success in marketing we won’t get enough customers for experiments. We won’t have any grip on reality with which to test hypotheses. If we have no answers here, then there’s no way to check whether customers got value, because there are no customers.

3. Product hypothesis

So, we’ve already found the client a market where they can make money. And come up with a way for their customers to give them money, at least once. That doesn’t mean we already know how to do what we promised the client — at the previous stage the only thing that mattered was that they believed us. And now what we promised has to be delivered. That is, the value we promised really does have to be created for the client’s customers, so that they change their behavior.

Usually this part can no longer be done by the developer alone. If marketing can still be outsourced entirely (though I think it’s better done jointly), delivering value can’t be outsourced entirely. Otherwise it turns out that your business is run — and potentially owned — by the developer. That’s possible too, by the way, but that’s a completely different model of relations.

Most often people come to JetStyle to test a product hypothesis, though they don’t always phrase it that way. But the tasks they set us often lie exactly in that plane. Although just as often they have no clarity about the market or about marketing either, and we help them with that too.

4. Team hypothesis

You can’t pour money into a hypothesis alone; you also need people who have demonstrated that they know how to test those very hypotheses. For that the client needs sources of competence and a team that learns fast.

What does that mean for us? That we can be a source of competence for the client.

What does it mean for the client? That they can significantly speed up creating the product, because forming a team is long and expensive, and finding a source of certain kinds of competence is also very hard.

That’s it, there are no other hypotheses in product development.

So, when we say that we develop a product, we mean that we help deliver values and test hypotheses.

Product development is about putting value into operation and testing these four groups of hypotheses.

And who formulates the hypotheses?

I’ve always underrated ideas, because if there’s one thing I have more than enough of, it’s ideas. But the difficulty isn’t in formulating ideas, and not even in how to reformulate them into hypotheses, but in testing them and embedding the resulting knowledge into processes.

So of course we can generate a pile of hypotheses for the client. And often we do. But what matters isn’t who generates them, nor whose hypothesis we’re testing together with the client. What matters is how fast it moves the client toward business growth.

Bottom line: product development = changing processes + delivering value + testing hypotheses + improving payback. Without that we’re just cranking out software. Beyond that, someone has to run the business.

The bricks of market offerings

We’ve sorted out what product development is. Now we can compare it with the other options. There’s a huge number of those options, and rather than list them all, I’ll first show what parts they’re assembled from, and then what the most common assemblies are.

Let’s imagine that what development teams compete on, what they’re responsible for and which payment scheme they use are the bricks that market offerings are assembled from. In short, here’s what it looks like:

Let’s go through each column of the table and each brick in it, to sync up our understanding.

1. What to compete on

Contract cost

When we go into tenders, we often run into the fact that to a large extent they’re going to pick us simply on the price of the solution. Whoever offers a lower contract price wins.

Cost of an effective hour

There’s more of this every year. Clients look at the price list and say: these guys’ hour costs this much, and these guys’ is one and a half times less, and we like them one and a half times more. Let’s go to them.

Level of expertise in the subject area

The market often picks a team for its experience of solving a similar task. For example, JetStyle has high expertise in pharma, the education market, foodtech and VR.

Recently we were selling the development of an online home-appliance store and haggled for a long time about the payment scheme. The client kept asking us: can you say that you’re those very guys who’ve launched marketplaces a million times, know everything about it, and stake a tooth on the aspic that everything you say and do will work? That right there is a request for expertise in the subject area.

Expertise in technology

Development, UX/UI, marketing, sales — that’s what we’ve always tried to differentiate on. Right now there’s a trend on the market toward outstaffing, whose leading way of competing is recruiting technology — how fast they hire and onboard employees and what size of labor-resource base they end up with. I.e. how much buyable expertise they’ve accumulated.

TTM

Time-to-market — the speed at which we deliver features to production.

Speed of hypothesis testing

How fast we answer the questions about market, marketing, product and team.

Since we focus on product development, this is exactly what we differentiate on. So if you need help testing hypotheses fast — welcome!

2. What to be responsible for

Deadlines and conformity to the spec

That means taking contracts worth many millions of rubles and being responsible for hitting the deadlines and the project boundaries. As I’ve already said, this isn’t what we want to be doing, for two reasons.

First, it greatly increases the risks. If we’re talking about developing something new, that’s true both for us and for the client.

Second, and this is the main thing, that way you can’t make anything new that will really be useful to the customer.

At JetStyle we decided that we don’t want to take large contracts with that kind of responsibility.

Feature delivery

You can make feature delivery the subject of work and take responsibility for the backlog, that is, for completing work tasks by order of importance. The guys who say they work by scrum most often mean exactly this. Although scrum is in fact trying to get them to concentrate on values as well, concentrating on the backlog is considerably easier.

Hypothesis testing

What makes product development different from outstaffing and outsourcing? That our backlog has hypotheses in it, and our responsibility is for the speed of testing them. Well, at any rate that’s how it is with our dream clients.

Changing processes and metrics

If you take responsibility not only for testing hypotheses but for embedding the results into regular activity, then we bring the business substantially more benefit. And of course that requires substantially deeper integration between the client and the development team.

3. Which payment scheme to use

Retainer

We talked about it at the very beginning, but it doesn’t hurt to repeat. It’s a scheme in which we and the client agree that one sprint of the team costs a fixed amount of money, and the team has a permanent roster of specialists.

Fixed price

A client comes, tells us something, then together we develop a technical spec, and after that we say: this technical spec will take this much time and money, and when we’ve completed it we should get the money.

Time & material

We don’t sign a technical spec. We just do things, and at the end of some period, say once a month, we sign an act that says: we worked this many hours, each hour costs this much, give us this much money.

License

The client gets the right to use our service (or other intellectual property) and pays for that. They pay in proportion to an agreed criterion — that could be time, the number of features or seats, available resources or something else. Importantly, this isn’t quite “development by an external team” any more — it’s selling your own product.

Ownership share

Sometimes the best way to hire a team is to create joint ownership. As a bonus this removes the question of whether critical functions can be outsourced. It would be good to say something here about when both sides should go for that, but that would take an article the same size, so — another time.

Bonus for metrics

Another way of settling up with a development team is to promise it a bonus for achieving metrics. This scheme does occur on the market, and sometimes a client offers it to us. But I don’t recommend it to anyone.

I wouldn’t do it inside my own company, and so I don’t think it’s a good practice for relations with an external team. Because any metric can be hacked if someone wants to. And in general, you shouldn’t play games of chance for money with programmers. Yes, I would also like us to have a metric that would motivate us to work better. What’s more, I’m sure that such a metric, or metrics, should be defined in product work. It’s just that you shouldn’t pay a bonus for them — because otherwise the data will immediately contain a lot of noise created by the metric becoming an object of bargaining. As a result:

— you won’t be able to lean on this data to develop the product,

— such an approach will most likely destroy the trust between the development team and the client, and trust is an absolutely necessary condition for the product to turn out well.

Outsourcing, outstaffing, product development: a cross-section

All that’s left is to assemble the popular builds out of the bricks and look at the difference. In short, it comes out as this table (and below I’ll comment on all of it):

1. What the business orders

From outsourcing they order execution of the spec and of tasks. From outstaffing — access to scarce competence. And in product development the business orders a change in processes. As a result of us starting to make a product, some people change their regular behavior. Processes change, and the business gets knowledge about how to grow through developing the product.

2. The result in case of success

With outsourcing, success is features working in production. With outstaffing — solving tasks for which internal resources or expertise are lacking. And in product development — tested hypotheses. What matters is that behavior and metrics changed.

3. Project management

With outsourcing — on the contractor’s side. With outstaffing — absent on the contractor’s side, but implied to be present on the client’s side.

And now comes my most provocative thesis:

When we’re doing product development, project management is absent on our side and on the client’s side alike.

It isn’t needed, because what we do doesn’t have the properties of a project. Our task shouldn’t have a ready solution at some point in time, and most often we don’t have a fixed budget. Instead we use iterative-incremental hypothesis testing. We have a different object of management and therefore a different methodology.

The fact that the words product and project sound similar has played a nasty trick on all of us: a project shouldn’t be shoved into product development at all. To the question “Where’s the place of the project manager in product development?” the answer is simple: “There isn’t one.”

4. Product management

With both outsourcing and outstaffing, product management is usually absent on the contractor’s side. And in product development it’s distributed between contractor and client. And when I say the word contractor here, it makes absolutely no difference whether they’re internal or external — it’ll be this way anyway.

5. Responsibility

Outsourcing’s — for feature delivery and the backlog. Outstaffing’s — for access to scarce competence. Product development’s — for testing hypotheses.

6. Pricing

Outsourcing’s — fixed price and/or T&M. Outstaffing’s — T&M or retainer. Product development’s — retainer. Ours is, at any rate)

7. Degree of isolation

In outsourcing they build a Great Wall of China between the client and the team. With outstaffing the developer is effectively under the client’s direct management. And product development is possible only if we have destroyed the wall between developer and client, because without that the feedback loop in an experiment will be so long that TTM (time-to-market) will be very big, and the whole story won’t make any sense.

8. What it aims for

Traditional outsourcing is interested in large contracts and often takes on huge risks. Outstaffing aims to sell its resources for the longest possible term. And product development aims to speed up and cheapen the first piece of work.

9. What it competes on

Outsourcing tries to win on the total cost of the contract. Outstaffing — on the availability of staffing resource and the cost of an effective hour. Product development — on the speed of hypothesis testing, because that’s what grows a lot compared with the other approaches.

10. What it means by the word quality

In outsourcing — the percentage of bugs and how pretty our portfolio cases are. Because how do you check the quality of projects from an external inspection? Right, you look at the design in the cases. With outstaffing — the qualification of the staff and their availability. And for product development — achieving the goals of the business.

It’s not that I’m ripping the sailor’s shirt off my chest here, claiming that only we deal with business goals. The point is that in product development there’s simply no other way it works. The moment we stop talking to the business and to the team about the business’s goals, everything falls apart and stops working.

The construction kit is ready!

Now you have a huge construction kit in your hands, and you can build very different things out of it. For example, if you assemble JetStyle, you get this:

• we take money for a retainer;
• we have hypothesis testing as the subject of work;
• we consider our competitiveness to be the speed of hypothesis testing;
• we try to erase the wall between the client’s team and the developer’s team;
• for this approach it’s very important to deliver benefit to the client for the first time as fast as possible, in a way they notice, because our goal is growing trust;
• if the client starts trusting us and sees that we really do deliver benefit, they grow the contract, and we can grow the team.

You can look at which bricks your business is built from and understand what advantages you have on the market.

Product development: inside vs outside

So, we’ve looked in detail at outsourcing, outstaffing and product development. But the thing is that product development can be external or internal. As per tradition, here’s a comparison table:

And now I’ll comment.

Responsibility

On the whole, product development by an external team and by an internal team are close to each other. Both test hypotheses and help change processes.

Pricing

The structure and volume of money are similar, with the only difference that we pay an external team by retainer, while the cost of your own team is part of the burn rate.

The money is usually comparable, though an hour outside does cost more. If you can do it in-house — all other things being equal, that’s always better. With an external order you pay more but save time and resources on forming a team, on management and other overhead. One typical option is to buy a development team for marketing in a situation where the in-house team is busy implementing the core functionality of a complex product while marketing is more than ready for experiments. You buy the ability to go and test market hypotheses while keeping the focus and pace of the main development.

Isolation

It often turns out that the barrier between an external team and the customers is lower than the barrier their internal developers had built between themselves and their own internal customers (of course, everything here depends on the corporate culture, and also on KPIs).

What it aims for

An external team aims to reduce the cost of the entry ticket and increase headcount. And an internal one — to increase accumulated competence (and headcount, of course).

What it competes on

In-house development doesn’t compete with anyone at all, while an external team tries to win on the speed of hypothesis testing.

What it means by the word quality

An external team with a product approach means achieving the goals of the business by quality, while the head of internal development is usually forced to mean fulfilling the company’s plans.

Why hand product management outside?

And now for the most interesting part. In what situations should you hand the product to an external team? And why, especially if you have developers of your own? Let’s reason it through.

So, look. We’re in a “fruit — fruit, boob — boob” situation:

What’s the important conclusion for us here? Right: that an external team is no worse in any way.

To which the internal guys reply: “You can’t outsource core!” Translated, that means: “If what you do is a core competence, then we won’t outsource it to you, because we’d rather do it inside, even if that’s slower and more expensive.”

Then the question arises: “Why would a business hand over product management?” And here let’s go into more detail.

First, because there aren’t enough working hands

For example, there isn’t enough development, or designers, marketers or salespeople. What should the client do? Hire hands onto the staff or through outstaffing. And yes, that isn’t product development in the slightest.

Here of course I’ll have to add: “No, hang on, we weren’t talking about working hands. We were talking about sources of expertise!” And then…

Second, because there isn’t enough competence

1. Development competence — no CTO of their own.
2. UX/UI competence — no art director of their own.
3. Marketing competence — no CMO of their own.

That is, what’s missing isn’t people who do the work, but people who know how to make the work useful.

When there’s no development competence — you can outsource the CTO. No UX/UI competence — you can outsource the art director. No marketing competence — you can outsource the marketing director. But, hell, that’s still outstaffing!

But there’s also this:

4. Sales competence — no commercial director with the right experience.

5. Product development competence — no product director.

And when you see those last two points inside your own company, everything changes — outstaffing alone can’t cover that any more. When we talk about outsourcing the product director, we land in the situation of product development. And JetStyle has a source of this competence, we can be donors.

Third, it speeds up the development of the business

1. The business gets access to a source of product competence

If the client has no source of some competence, then it makes sense to come to us, because you can simply buy speed. Once again: speed is the terminal value that we create for a business. That’s why I say that a product development team should differentiate on how fast hypotheses get tested.

2. The team has an interest in reacting fast and being flexible

For example, in our work with IQ007 there’s a phenomenon I’d never seen before on other projects: when we launched the learning platform into beta testing, we took on providing user support with our own people. Girls and boys and their parents call us, and with their help we discover bugs and new problems.

When we discover errors, we’re glad, because we get valuable knowledge and a chance to deliver new value faster.

It turns out that talking about bugs isn’t a pain in the ass but a source of knowledge for the product we’re creating together. And the developers want to talk about it. This is the complete opposite of the reaction we get when we hand over software by spec. Because usually, when we’ve handed over the software and bugs come pouring down on us, we feel like people who are being beaten.

3. Instead of local optimization, the bottleneck gets unblocked

To make the difference between local optimization and the bottleneck clear, you’d have to retell a couple of books (Eliyahu Goldratt’s “The Goal: A Process of Ongoing Improvement”, “It’s Not Luck” and “Critical Chain”). But it’s an effective approach.

4. Ultimately, hypotheses get tested faster

And not just by a factor of a few, but by orders of magnitude.

And what’s in it for the product development team itself?

I’ve explained why it’s beneficial for the client. Now about why it’s beneficial for us as a team. The scheme is simple:

There are two ultimate benefits.

First, if the client gets visible benefit and understands that the activity pays off, they increase the budget and continue the collaboration.

Second, and honestly this is far more important: team risks go down. Why? Because we feel that we’re needed. Because this approach greatly increases the chances not just that we’ll make something useful, but that the developers will see it live! And see it soon. That is, they’ll feel faster that what they’re doing isn’t nonsense. As a result the team is more cohesive. And in the conditions of the post-COVID world, I think that’s one of the few ways to survive at all.

Let me turn to my own experience again here. When I worked as a designer, I spent a huge amount of time trying to work out what to do so as not to get stuck in this story. There you are doing a design, for a long time, six months. A big design. Then you go off to do the next design, and something happens to that design of yours. First the front-end coders slowly chew on it. Then the backenders slowly chew on it. Then the testers slowly chew on it. Then the business dithers and doesn’t launch it. Then they launch it, a year and a half passes — and there you are looking at what came out and thinking: god, I designed something completely different, why is it so ugly? And most importantly: is this useful at all or not? I don’t know. And I as a designer simply don’t understand whether I’m doing something pointless here or not.

In the product approach that question doesn’t exist at all, because when a designer draws something right during the sprint, while we’re talking with the client, there’s a high chance that in the next sprint they’ll already hear from end users how they used the new thing. When the feedback loop is short, any of us gets the meaning of the activity fast. For me that value is absolutely ultimate. I understand that what I’m doing isn’t just for show. It’s clear to me what it’s needed for.

Such an approach gives two good effects at once: on one side the client starts to trust us, and on the other we understand that our labor is in demand by everyone in the process. It’s not only our client who loves us, but the rest of the client’s team too. We see directly that the client’s customers are also glad about what we made. That makes me happier too, and it makes me want to keep working. For me as a director it means my staffing risks are lower, and for me as an employee it means more meaning in the work.

Unresolved questions of product development

Even though we’ve talked about a lot of things here in great detail, there are questions I don’t yet have unambiguous answers to. These are topics I want to make the subject of our further discussions.

— Those who understand products leave for products.

— Okay, and so? What do you hold on to staff with?

I want JetStyle as a digital production studio to take the best of both worlds. I want each of us to have the chance to work on a product at the moment when the work on it is most interesting — that’s when the product is becoming itself, when it’s changing. Because that’s exactly the moment when an engineer’s labor has the greatest value and there’s still little routine.

I have the audacity to think that my product competence is deep enough. It’s deeper than if I worked only at Rideró. And it’s deeper than if I worked only at JetStyle. This combination of deep immersion in a product and switching between products grows product competence faster.

In my view (since I work both in a product and in a studio), working in a product has its advantages over working in projects. But our approach will come down to this: being a product team, we’ll both get the advantages of working in products and be able to choose the most interesting products. And in that case there’ll be no need to hold on to staff — because, as far as I’m concerned, it’s the best job ever.

— An external team has no right to decide important questions.

— Okay, and so? Become consultants or co-owners?

This one really is painful. Very often I find myself in a situation where the client acknowledges that my competence in product management is higher. But I’m just some outside guy, I don’t work inside the company and I have no decision-making rights, and I can’t kick doors open either.

What to do? Become consultants? That’s a completely different model. And to become co-owners you have to grow venture competence in yourself. Only it has to be better than that of the venture business, because they only stake cash, while we stake our own bottleneck on it. We have more risks, and we don’t have venture competence.

From time to time I find myself in a situation where it’s clear to me what the client’s business ought to do. But that’s just a view from outside, and it needs to be a decision taken inside. Because responsibility for a business can only be taken along with ownership. And in general that means that, whether we want to or not, we’ll have to find partner consultants or become consultants ourselves, because without that the client won’t be able to make use of our competence. We’ll have to help them change their processes. But for now it seems that isn’t what we’ll be doing in the next couple of years, because there’s plenty to get on with before that.

— Less and less responsible work gets handed outside.

— Okay, and so? Is the niche narrowing?

I don’t believe it, but maybe you’ll talk me out of it! The question of whether the niche of product development — custom and external — is narrowing or growing is extremely unclear. I racked my brains looking for a way to count this trend in numbers. Because how to count how much money is invested into the development market is clear, but how to answer this question inside it is not at all.

We’re actively researching this subject right now. And you know what? Over the last two years it’s become clear: because teams inside clients’ products have grown, there’s become more work on our custom-development market, not less. Because if you’ve started developing a digital product, you can’t stop developing it. IT will be in short supply for many years yet. However much IT there is in a company, it will always have to be topped up from outside.

And besides, there are always fewer brains than hands. If we have a reputation as the guys who know how to solve product tasks, then people will come to us with product tasks. Because people who really do know how to solve product tasks are in even shorter supply than good developers.

— A team is more than staff.

— Okay, and so? Does that hold on to staff or prepare the team for being laid off?

When venture people say they invest money in the team, they don’t do it out of foolishness. By becoming one team with the client, we get an additional value in continuing to work with each other — because we find each other interesting.

Conclusions

So, let’s repeat the main points.

• If you’re working on a new product, then you have an interest in a stable team focused on achieving the product’s goals, not on delivering features. With fixed costs per month, working in iterative-incremental logic. Technical specs for new products are evil.
• Product development is not software development. It has a different subject of work — not delivering features, but testing hypotheses about growth.
• If you don’t set changing people’s behavior (the client’s employees or their customers) as the goal of a sprint, then you aren’t developing a product.
• If you are developing a product and you have a system of goals shared with the client, then it’s much better for you and for the client — more predictable, more profitable and more interesting.
• And finally, oddly enough, there’s no big difference between an internal and an external product development team. But there is a difference — a big one — with outstaffing and custom development by spec.

Talk to me about this!

Those are my thoughts about product development, and I very much want to talk about it with you. And not only about the unresolved questions, but about everything. Shall we reason together? I’m waiting for your questions and comments here, or at kulakov@jet.style, or on my Facebook. Thanks for making it to the end)