Start with the Cherry! Identifying the Main Process in a New Product or Business: the Search Principle, Methods, Examples. Part 1

Every business starts with someone seeing an opportunity. That can happen inside an already existing process, or it can be the idea for a new one. It can be in familiar territory, or somewhere else entirely. In the cases I run into there’s one more detail — technology is one of the components of the opportunity. Part of the idea is that thanks to technology people will somehow change their behavior. That idea is the driving force of the whole business, and it’s also the source of its main risks.

One of the hardest and most consequential moments is choosing the place where the technology is actually worth applying. If I compressed everything I want to tell you into one sentence, it would be this: pick the process that limits the performance of the system, and start putting effort into lowering the cost of that particular activity. It’s a very simple thought (and, by the way, not mine, but Eliyahu Goldratt’s).

In the course of my work I often take part in conversations about what exactly is worth investing in. That happens in talks with JetStyle clients who are commissioning the development of new products (by the way, if you need a conversation like that — come along). I also work as a lead tracker in corporate acceleration and talk a lot about the architecture of a future business at the stage when it’s only being conceived. And I know that saying this key thought out loud isn’t enough for an entrepreneur to be able to use it. Because when an entrepreneur comes up with something, it’s hard for them to see the main process and hard to understand how their concept maps onto real activity.

And now let’s look at how to turn an idea into a product.

What a business vision is and why it matters

At the start of a new venture the entrepreneur has a business vision — an idea, a notion of:

• How the product will be built when it comes to be
• How the world around it will change
• And thanks to which properties of the product that will happen

That is, a vision of the situation in the future, when everything works, customers behave the way they should, value is created, and customers understand that value.

And from that idea entrepreneurs often jump straight to technological creativity — they hand IT teams tasks to build technological artifacts.

They see a weak spot, for instance: “We have a personnel problem: in one place there are lots of employees with nothing to do, in another there’s a terrible shortage, and the people we need aren’t sitting on HeadHunter, so we can’t find them, and instead we’re fiddling with paperwork like idiots, as if it were still the 20th century.” And then they say: “We got to thinking about what could be done, and decided we need to create a portal.” That’s a vision (from here on, by the word vision I mean business vision specifically). And up to the “what could be done” part it was valuable knowledge and an even more valuable emotion, the kind that gives a product team energy. But then they turned into a pumpkin — because instead of digging deeper into the market insight, the team in this imaginary example went straight to describing the means. That’s a trap.

Vision in general is a great thing. Sometimes the main thing required of an entrepreneur is to give birth to a vision — a picture of the desired future. It is for the sake of that picture that the entrepreneur pours in energy and infects everyone with the idea of how the market will change thanks to our efforts. If that picture doesn’t exist, then nothing at all will happen.

Worth a short digression here. In Russian startups the main path to building a business is often the path in which there is, as it were, no vision. It’s the researcher’s path:

1. First you have to find a large and, most importantly, growing market niche.
2. Then you have to run research in that niche and understand what problems customers have.
3. And only after that should you start thinking about which properties the product you’re looking for will have.

Before stage 2 you’re advised to clear your mind of any ideas about functionality. So — despite the fact that this is a good sequence of questions, I’m not in the camp that says the vision has to be thrown out. Because:

Without a vision there’s too little energy in a business

Without a vision there’s too little strength for an attempt at a revolution, at a radical change, and too little chance of fast growth. The fact that the entrepreneur has a notion of what exactly they want to achieve and what they’re acting for is a very, very important component of success. That’s why I don’t like it when experts tear an entrepreneur to shreds from the position of “You’ve come up with rubbish, throw your idea out and start with research.” It seems very important to me to preserve the energy and to find in the idea the thing that makes the entrepreneur and the team want to bring the product to life. It’s another matter that you have to be able to reconcile that crystal dream with reality — in such a way that reality doesn’t reject it. But don’t throw the dream out.

If you have an idea that gives you energy, you act for its sake. And telling you to throw it out is counterproductive, because you’ll throw the energy out along with it. And despite the fact that this idea is very likely wrong, there’s a kernel of the concept in it. It just has to be cleared of secondary details.

When an entrepreneur who works in a specific subject area notices something bad in the existing processes, they see an opportunity in it: “I can see exactly what’s wrong, and this is a great chance to fix the situation and make money on it.” If they have industry expertise, there’s a lot of value in that impulse: they know how their subject area is arranged, who pays for what, who has which problems. A person outside the subject area doesn’t have that knowledge (unless another person who understands the area deeply has shared it with them).

Your intuition about a subject area you’ve worked in for a long time is worth trusting. Your intuition about how to make products can be trusted if you’ve made products, and if you haven’t — it can’t. So you need to separate the one from the other. And that’s another reason you need both industry and product expertise on the project.

Let’s work through an example

When we were making the publishing service Rideró, at the very earliest stage we told ourselves it was an online editor for laying out books. We thought the main value was the quality of the typeset book and the simplicity of creating its layout. So we put a huge amount of effort into making a WYSIWYG book editor right in the browser. We wanted the book to look the way it would later look on paper. Technologically that’s a very hard task — for it to work fast, a big book requires so much computation on the client that the browser can’t take it. Progress has of course moved on a lot since then, but eight years ago the situation was like that.

But then we said to ourselves: maybe instead of chasing that flawless experience we drop WYSIWYG, do the layout rendering on the server, and better put our authors’ books on sale faster? Yes, that will make the user experience worse during layout, the writer won’t be able to see “right there on the screen” what the typeset paper book will look like. But it’s still far faster than a live typesetter, even if not as beautiful as we wanted.

Why did we do it? Because it turned out that the more significant value wasn’t the layout, it was getting into the online stores. We were the first in Russia to give authors a way to get onto the shelves of online stores quickly and for free. We stopped chasing the feature, started following the problems of real people — and got more authors than anyone else in the country.

If you want to change people’s behavior in order to solve their problems, and that’s what drives you, then let’s defend that and build the work around it. The vision is a symptom of that problem. It’s valuable, but not as a set of features.

A business vision ≠ a product feature list

So, vision in itself is a good thing. The problem is that often the main part of that vision turns out to be not so much people’s behavior, the benefit being created and a picture of how people will interact with the future service, as a feature list. And if the vision isn’t a deep understanding of what the market and people need but a shallow entrepreneurial dream about functionality, that kind of vision will work badly. It often turns out to be fragile, mismatched to the demand, and hard to test.

Let’s work through this point on a made-up example

Let’s imagine we’re making a social network for the elderly. Our vision: it will have a voice assistant, a personal concierge service built on voice technologies, and a marketplace of services. (I made this example up specially for the article, because my dad has all sorts of hassles and I don’t live near him right now. But it’s improvised.)

This vision can be interpreted in two different ways:

1. We’ll create a situation where, thanks to certain properties of the product, its target audience gets a simple and comprehensible way of ordering services such that their children pay, while the way of ordering will on the one hand be convenient for elderly people and on the other will give exhaustive information to those who will be supplying these services. And the services themselves will be exactly the services that suit such a target audience. Look: I’ve already gone into the detail of the vision, and I still haven’t named a single IT detail.

2. The same thing in terms of features:

• We’ll make a voice assistant robot that will recognize what elderly people are saying;
• With the help of AI we’ll implement fact extraction from natural speech;
• The robot will address all of that to an order database and send a payment link for a card that another person has linked to their relative’s account.

These seem like similar things, and I’m apparently describing one and the same thing. But if we start from the vision formulated the second way — what will we get busy with? Most likely we’ll start making the AI, because that’s what it’s all about. And we’ll focus on how exactly to make the AI effective enough. We’ll gather a data collection, we’ll bury ourselves in whitepapers that explain how the technology works. We’ll work to make the robot really able to recognize an elderly person’s voice with the specifics of their vocabulary and their difficulties with diction. And when we’ve finished, we’ll start testing.

There’s a high probability it’ll turn out that this isn’t the method that would be convenient for elderly people. And that the main thing they were waiting for was something entirely different. For instance, they were waiting for a conversation with anyone at all who shows sincere interest in them. With someone alive. Or, the other way round, that they don’t have too much trouble working with a smartphone and don’t want to talk to people — they need to be able to simply repeat a regular order with one button. Or something else. Even when the market exists and the problem exists, in most cases the process that needs to be automated is only discovered as a result of an attempt at implementation. Or as a result of an experiment in the course of which we try to understand what exactly limits the effectiveness of people’s activity.

Don’t get me wrong — a breakthrough technology can come out of research like that. But the fact that a business can be built on it is true only insofar as that technology helps to change the key process. And for that you first have to find it.

Let me repeat the thought briefly: if you formulate the idea as a set of functional features, that pushes you toward implementing those functions rather than toward testing processes. As a result you get program code, not changes in the business.

The same vision can be laid out a different way — in the form of hypotheses tied to the behavior of people and the market. And then you can test them, starting from the process that will bring tangible benefit fastest, and take the whole story to market iteratively.

What could such a process be in this case? What do we even have in the idea? The entrepreneur wants to change the lives of elderly people and find new, simpler and more convenient ways of helping their parents. That’s the whole idea.

What does that mean in terms of processes? What does this activity look like today? What do the participants in this activity do? It seems to come out roughly like this:

• First people work out that they need the product. Sometimes older people decide what exactly they need with the help of their children. Sometimes it’s urgent (a tap has sprung a leak). Sometimes it’s a chronic problem (there’s nobody to look after a person who is gradually losing their memory). Often the elderly person doesn’t immediately understand whether they can afford it right now or not;
• Then they choose the service provider. On their own (or with their children’s help) the customer somehow finds a plumber, a caregiver, or a tablet;
• They pay for the services — themselves or from their child’s card;
• They order delivery and receive the goods;
• They receive the service and assess its quality.

In short, people are already behaving in some way. And if we’re going to create a new service, we’ll be changing these processes. And the main question is: which process do we start from?

The way I see it, a good service architecture should be perceived as simple and clear — there’s something core in it, some single main way of changing life. For example: Uber is ordering a taxi from point A to point B. Yandex is a way to find a link to a place where someone will help me solve my current question. YouTube is a place where I can find a short video on any topic. Samokat is the guys who deliver food in 15 minutes. Yes, each of these services has an enormous heap of satellites, additional functions and a huge (HUGE) iceberg under the hood. But the core architecture, the load-bearing trunk, the main process that this service improves:

1. Is simple and comprehensible

2. Is clearly visible

3. Subordinates every aspect of the service to itself

But let’s go back to the example with the parents we want to help. Look at the processes a business could be built around:

• We can improve the process of choosing goods — then our main work will be tied to curating the assortment, describing its properties and solving problems such as elderly parents being bad at articulating their needs in the modern world;
• We can come up with a way to lower prices — redistribute the costs somehow and make it so elderly people pay less;
• We can improve the process of choosing a supplier — and somehow solve the problem of scammers. For instance, create a method that would be easy for anyone to use, even someone with a very weak grasp of the internet, and moreover in such a way that their children can be sure that he’s now protected from accidental spending;
• We can improve the payment process — so that the parent can spend money while the children handle control and provision of the funds;
• We can improve the delivery process — so that elderly people don’t run into problems with couriers;
• We can improve the interaction with the staff providing the service — so that the parent doesn’t end up in stressful situations and knows how to check the quality of the service when accepting it.

A business can be built around each of these processes. But which one to choose? After all, we wanted to improve the lives of elderly people in every aspect? Do we really have to give up all the rest?

My thought is this: one of the processes will be the trunk — the load-bearing structure — and the rest will be branches. And when you’re starting a business, work on the trunk ONLY at first. Let the branches grow later, when your business’s tree has grown strong.

In short, the problem isn’t that you can’t start from a vision, it’s that entrepreneurs formulate the vision in terms of features, after which, instead of changing processes, programmers churn out those features.

Three scenarios for automating from a feature list

Next there are three scenarios. The sad one, the awful one, and the miracle. Let’s look at them using a notional company where some notional new software is being rolled out.

The sad scenario

After the software has been written, it turns out that programming something and rolling that something out are two different jobs. And when they attempt the rollout, the new contraption runs into resistance among the employees who are busy with the actual work, and no rollout happens. What you get is that the company has simply buried a certain amount of money and time in software nobody needs.

The awful scenario

Yes, this software meets resistance. But management has enough force to cram the existing processes into the Procrustean bed of the software that’s been written. To make the hedgehogs eat the cactus, despite all the pain and suffering. First, if it turns out that the automated process is suboptimal, that can do substantial damage to the business. And second, a well-automated business doesn’t budge — after automation a process is hard to change.

Automation is a pretty hard thing, like cement. If we automate something, we’re assuming it’s supposed to be exactly like this and won’t change. And if something does need changing, then everything that came before can be thrown out and you start automating again from scratch.

The miracle scenario

You got lucky, and it turns out that we picked exactly the process that was causing employees the most trouble. And changes in that process will bring a fast and significant return, and the results will be plainly visible. So the rollout will go like clockwork. It happens. There are three cases:

1. You’re automating a process that has existed for a long time. You know everything about it. You know exactly what’s wrong. You have a good picture of the metrics system. You start from the place in the process where changes can be made fast and the effect immediately improves the work of the people who interact with the software.
2. You have a product that has proven itself, and you’re simply making a clone. And the operating situation is identical, and what’s needed isn’t “something similar” — it’s exactly this. (Here, though, a question comes up — why invest money in programming at all? Why not use that existing software?)
3. You’re a damn genius. The depth of your vision is such that you can be trusted. That’s a rarity. And a mandatory condition for such a miracle is that you have deep expertise both in the subject area and in the product. I.e. this isn’t the first, or even the second, software product you’ve rolled out.

But there’s a way to summon the “miracle scenario” into being in a controlled way, rather than hoping for luck. So when people come to us with a request to create a career portal, a social network for the elderly or any other technical thing, we say: “Let’s not build the whole spaceship right away, because that doesn’t work. (And how it does work, I described in another article of mine: IT Entrepreneurship: How to Change the World Without Attracting the Attention of the Orderlies?.) Let’s first find that very process where changes will give us a fast rise in the efficiency of the processes. And improve only that one.”

And now, in theses

All the important thoughts in one list:

1. A business vision is an idea, a notion of how the product will be built when it comes to be, how the world around it will change, and thanks to which properties of the product that will happen.
2. Sometimes the main thing required of an entrepreneur is to give birth to a vision, a picture of the desired future. Without a vision there’s too little energy in a business.
3. The business idea is most likely wrong in its specific details. It has to be tested before you spend money on automation.
4. If you want to change people’s behavior in order to solve their problems, and that’s what drives you, then defend that and build the work around it. The vision is a symptom of that problem. It’s valuable, but not as a set of features.
5. If you formulate the idea as a set of features, that pushes you toward implementing those functions rather than toward testing processes. As a result you get program code, not changes in the business.
6. One of the processes will be the trunk, the load-bearing structure, and the rest will be branches. Start from the trunk.
7. If we automate something, we’re assuming it’s supposed to be exactly like this and won’t change in its main features.

Next time we’ll talk about which methods reveal the main process in a new product and why it’s so important to start the implementation from exactly that one. Subscribe to our Telegram channel so you don’t miss the announcement of part two of the article.

And if you want to discuss the vision for your new business or product with someone, you can write to me on Telegram or book a slot in my calendar for a short Zoom call. Together we’ll find the answer to the question of how to change people’s behavior in the subject area that interests you so that it brings benefit to everyone.