Principles

I have nothing against thorough analysis.

I have a problem with analysis that becomes a substitute for decision-making and action.

A company can spend months mapping processes, interviewing employees, comparing software, preparing reports, and holding management meetings.

Throughout that time, the actual problem remains.

The website or application still does not go live.

Development is at a standstill.

Manual work consumes people's time.

Sales promises something that delivery cannot provide.

The software systems do not work together.

An important decision continues to await someone's approval.

People solve the same problem all over again every day.

After six months, the company may have a very thorough overview of why it lost six months.

I prefer to identify the real bottleneck, make the necessary choice, and get the solution working.

Usually within 48 hours.

Most business problems do not require more analysis

By the time an executive comes to me, they have usually already thought a great deal about the problem.

They do not need someone to tell them that the situation is complicated.

They already know that.

They need answers to three questions:

1. What is the real problem?

1. What decision needs to be made?

1. How do we actually get the solution working?

From the outside, a company may appear to have ten different problems.

Sales are not growing.

The team is overloaded.

Projects are running late.

The software does not support the work.

Data is scattered across different places.

The executive has to intervene constantly.

Often, these are not ten separate problems.

They are different consequences of one or two unresolved bottlenecks.

If you start fixing every symptom separately, the work can take months.

If you find the point where the problems originate, one correct change can eliminate much of the confusion.

I do not start from scratch with every company

I have worked in IT since the late 1980s and have been an entrepreneur since 1998.

I have founded more than 20 companies, spent many years running a software development business, built systems, sold, managed people, advised entrepreneurs, and viewed companies from an investor's perspective as well.

Over that time, technologies, tools, and buzzwords change.

The fundamental logic of the problems repeats itself.

The wrong customer.

An unclear value proposition.

An undecided strategy.

A broken process.

Responsibility without decision-making authority.

The right person in the wrong role.

Software that does not fit the actual work.

A founder through whom every important decision must pass.

Experience does not mean that I know all the answers before the conversation.

It means that I can quickly distinguish what matters from what does not, cause from effect, and a real bottleneck from a problem that is merely loud.

I do not need to spend six months every time learning how companies work in general.

I need to understand how this particular company works and where its logic breaks down.

I have built specialized tools for analysis

Experience alone is not enough.

Human memory is limited, first impressions can be misleading, and a strong opinion is not yet evidence.

That is why I have created software tools that help me analyze a company quickly before the first substantive conversation.

Depending on the problem, I can bring together and work through, for example:

• publicly available background information about the company;
• changes in financial indicators;
• the company's positioning;
• the products and services offered;
• target audiences and their reasons for buying;
• signals pointing to growth or problems;
• the company's work processes;
• the software in use;
• dependencies between systems;
• roles, responsibilities, and potential bottlenecks;
• technical or business information provided by the client.

The software does not make the final decision for me.

It handles much of the slow preliminary work, consolidates fragmented information, and helps formulate likely hypotheses.

As a result, a client meeting does not begin with the general question: “Tell me what your company does.”

I have already done my homework.

In the meeting, I can check whether the visible picture matches reality and move quickly to where the problem is likely to be.

Speed comes from pattern recognition, not rushing

The promise of 48 hours may seem too fast.

But speed does not mean that I leave important questions unasked.

Speed means that I do not spend time on activities that will not change the decision.

An experienced person does not need to examine every possible problem in equal depth. They know how to ask questions that eliminate a large number of incorrect explanations at once.

For example, if sales are not growing, I do not automatically start by assessing the sales team.

First, we need to check:

• whether the company is solving a sufficiently important problem;
• whether the chosen customer is the right one;
• whether the value proposition is clear;
• whether the person the company is speaking with is the one who makes the purchasing decision;
• whether the price, sales channel, and cost to serve are aligned;
• whether delivery can fulfill the promise made by sales.

If a website or information system does not go live, there is not always a need to analyze the entire project again.

What is needed is to find the specific point where the whole breaks down:

• frontend;
• backend;
• database;
• API;
• environment configuration;
• authentication;
• build process;
• deployment;
• a missing decision;
• unclear responsibilities among the parties involved.

Speed comes from looking for the constraint, rather than documenting the entire company in equal detail.

I do not separate the business problem from the technical problem

Many technical problems are not actually only technical.

Development may be at a standstill because no one has decided what outcome needs to be achieved.

Software systems do not fit together because different departments have optimized their own work and no one has looked at the end-to-end flow of the customer or information.

Automation fails because the process itself is unclear.

The website does not convert because the value proposition is unclear.

A project repeatedly requires rework because the sales promise, the client's need, and the development input are not connected.

If you look only at the code, you may fix the symptom.

If you look only at the business, you may write a recommendation that cannot be implemented technically at a reasonable cost.

My advantage is that I can look at both sides at the same time.

What should change from a business perspective?

What process creates that outcome?

What software supports or obstructs that process?

Can the problem be solved through configuration, integration, a small development effort, automation, a change in responsibility, or by stopping an activity entirely?

I do not assume that every problem requires new software.

Sometimes the existing system needs to be configured correctly.

Sometimes two systems need to be made to work together.

Sometimes one broken step needs to be removed.

Sometimes the company needs to stop using software that creates more work than it eliminates.

Analysis is not my end result

The outcome of traditional analysis is often a document.

It describes the current situation, problems, recommendations, priorities, and next steps.

The company must then find someone to decide what to do with the report.

Next, it needs to find a person or partner to implement the solution.

The new partner has to understand the company all over again.

This leads to a new brief, a new quote, a new schedule, and a new handover.

Some context is lost with every handover.

I do not consider analysis the end result.

Analysis is sufficient when it enables the right decision to be made and the solution to be put into operation.

The client does not need proof from me that I did a great deal of analysis.

They need the problem to disappear.

More can fit into 48 hours when the problem is scoped correctly

I do not claim that a company's entire strategy, organization, and technology can be made perfect in 48 hours.

Usually, that is not necessary.

A company's performance may be constrained by one specific bottleneck:

• a missing integration;
• a broken function;
• unfinished development;
• an incorrectly configured workflow;
• a repetitive manual task;
• a lack of decision-making authority;
• an unclear process stage;
• information that does not flow from one system to another;
• an activity that no one has dared to stop.

Once the bottleneck is precisely defined, the smallest workable solution can be built around it.

Not redesign the entire company at once.

Not write an ideal vision of the future.

Solve the first constraint that prevents the work from moving forward.

Then it becomes clear whether the company's performance improved and which next constraint has come into view.

The smallest workable solution is better than a large ideal project

Companies tend to turn a simple problem into a large project.

They need a new feature and end up replacing the entire system.

They need one integration and embark on a major digital transformation.

They need clear accountability and restructure the entire organization.

A large project feels thorough.

But the larger the project, the more:

• assumptions;
• people;
• dependencies;
• approvals;
• time;
• budget;
• opportunities for misunderstanding.

I look for the smallest change that removes the actual constraint.

It may be one decision.

One corrected process stage.

One integration.

One small software solution.

One automation.

One fix to a broken function.

One responsibility moved to the right place.

If a small solution delivers the desired result, there is no need to build a larger one.

If it does not, we have quickly gained new information without spending six months and a large budget.

Why can six months of analysis be dangerous for a company?

The problem does not stand still during the analysis.

A broken process continues to produce errors.

People build new manual workarounds around it.

Customers experience the same problem.

Employees become accustomed to an inefficient way of working.

Management postpones decisions because the analysis is not yet complete.

The longer the problem exists, the more it accumulates:

• exceptions;
• temporary fixes;
• spreadsheets;
• controls;
• roles;
• software systems;
• unspoken agreements.

After six months, the original problem has not simply remained.

It has become more deeply embedded in the company.

Sometimes lengthy analysis is necessary. Major investments, complex regulatory risks, and irreversible decisions require thoroughness.

But a very large proportion of companies' everyday bottlenecks do not require six months of investigation.

They require someone who can quickly see which part of the problem is real and implement the solution immediately.

My 48-hour working method

My work does not begin with the first meeting.

1. I do preliminary research on the company

I use the analysis tools I have created to uncover the company's background, business logic, potential signals, and the context of the problem before the conversation.

2. I test the hypotheses with the executive

The purpose of the conversation is not to retell the company's entire history. We check where the visible symptom arises and what impact it has.

3. I trace the problem back to its origin

I review the process, software, data, responsibilities, and decisions on which the outcome depends.

4. I separate the bottleneck from the surrounding noise

We do not solve every problem at once. We choose the constraint whose removal will have the greatest impact on the company's performance.

5. I make the necessary strategic or technical choice

Should we change the process, responsibility, system, integration, or automation, or stop an unnecessary activity?

6. I get the solution working

I do not stop at a recommendation. I usually deliver a working solution within 48 hours.

What does the client get after 48 hours?

Not a hundred-page report.

Not a list of everything the company might one day do better.

The client gets the most concrete result possible:

• the real bottleneck has been identified;
• the necessary choice has been made;
• the problem has been fixed or the smallest workable solution is running;
• the impact can be measured;
• the next decision is clear.

Sometimes the result is a working technical solution.

Sometimes it is an improved process.

Sometimes it is automated manual work.

Sometimes it is a clear decision to stop an activity that creates no value.

Sometimes, within 48 hours, it is possible to eliminate a problem that the company has spent months discussing.

Not because the problem was trivial.

Because no one had previously looked at the business logic, process, and technical implementation together.

I sell a solved problem, not hours of analysis

My goal is not to keep the client in a six-month analysis project.

My goal is to get them moving again as quickly as possible.

If the problem is solved in 48 hours, that does not make the work less valuable.

On the contrary.

The client retains the time, money, and management attention that would otherwise have been spent living with the problem.

Long work is not automatically thorough.

Fast work is not automatically superficial.

What matters is whether the right problem was identified and whether the solution works.

If there is a problem in your company that has already been discussed for too long, you may not need another analysis.

You may need someone who can quickly determine where the work actually breaks down and fix it.

Send me the problem in three sentences.

I will tell you whether it is something for which I can usually deliver a working solution within 48 hours.

Mikk Orglaan

Challeng.ist