On focus, hard decisions, and the mistake smart CEOs make over and over.

Author: Lior Romanowsky (ליאור רומנובסקי) Published: 2025-01-04 URL: https://thrive.co.il/en/article/why-your-startup-is-stuck Section: Strategy

TL;DR

Startups don't get stuck because of technology or money. They get stuck because of one decision CEOs keep avoiding: pick a single direction and kill the rest. Being stuck isn't bad luck. It's the output of a management pattern. The fix isn't more effort or another opportunity. It's a harder call: one 90-day goal, one killed initiative, one sharpened audience, one success metric. Focus isn't giving up. It's the precondition for growth.

The opening no one likes to admit

On paper, everything looks fine.

There is a product. There are first customers. There are meetings, tasks, ideas, decks. Everyone is working hard. Everyone is "on it."

But inside, you feel that nothing is actually going anywhere.

No jump. No momentum. No moment where you tell yourself: now we are on a clear path.

Most CEOs do not call this being stuck. They call it "a phase." Or "just another moment." Or "we are testing a few directions in parallel."

That is exactly where the problem starts.

Being stuck is not bad luck. It is the output of a management pattern

Startups almost never get stuck because of technology. Not because of money either. And only rarely because of the market.

They get stuck because of decisions that never get made, and above all because of one decision CEOs struggle to take:

> Pick one direction, and kill everything else.

Missing focus does not look like a mistake. It looks like openness. Like creativity. Like "not closing any doors."

In practice, it is one of the most destructive forces on early and mid-stage startups.

Busy is not Progress

This is the first pattern that shows up in almost every stuck startup.

Calendars are full. The team is working hard. There is a lot of motion. But there is no real progress on one clear metric.

Busy is comfortable. Progress is painful.

Progress requires:

• Stopping initiatives
• Saying "not now"
• Disappointing smart people with good ideas

Busy lets you avoid decisions. Progress forces them.

Missing focus: the quiet illness of startups

Missing focus almost always starts with good intent.

There is excitement. There are opportunities. There is a customer saying "if you just added X." There is an investor suggesting a direction. There is a new idea that sounds promising.

Instead of choosing, the startup starts spreading. One more feature. One more audience. One more use case. One more POC.

On paper: progress. In practice: dilution.

Dilution of money, time, management attention — and maybe most important, the team's trust.

> People do not burn out from working hard. They burn out from not understanding why they are working hard.

Over-excitement: when enthusiasm kills the company

One of the most dangerous patterns is management-level over-excitement.

The CEO sees possibilities everywhere:

• "This could also work for that market"
• "If we add this, we open a big door"
• "Let's just try it. What is there to lose?"

Every "let's just try it" has a cost. A startup does not have infinite resources.

Over-excitement produces constant context-switching, a confused team, and a product no one can describe in one sentence.

And worst of all: it creates a fake sense of motion while the core weakens.

The CEO as bottleneck (even when he is talented)

In stuck startups, you almost always see a CEO who is too strong.

He is involved in every decision, solving problems fast, handling loose ends. But he is also deferring strategic decisions, leaving too many options open, and not producing sharp focus for the team.

The CEO stays "the best worker," instead of becoming the one who forces the org to choose.

This is not an ego problem. It is a role problem.

A simple diagnostic: where are you actually stuck?

Being stuck breaks down into four areas. A stuck startup almost always falls into at least two.

1. Direction. Can everyone explain who the product is for, what problem it solves, and why now? If there are too many different answers, there is no direction.

2. Product focus. How many use cases are actually in development or sales? More than two at an early stage is almost always a warning sign.

3. People. Do people know what matters more and what matters less? Or are they just running to the next task?

4. Decision cadence. How many hard decisions were deferred in the last month? If the answer is "not sure," there are probably too many.

Patterns that keep coming back from the field

In the organizations I work with, being stuck looks similar:

• A startup with great technology that cannot explain who it is for
• A talented team spreading across five "promising" directions
• A leadership team afraid to kill features because "we might still need them"

The moment the painful decisions get made — cut back, cut, say no — something strange happens: the team relaxes, the pace picks up, and results start showing up.

A CEO self-diagnostic

Answer honestly:

• Can I describe our product in one sharp sentence?
• How many initiatives are actually active right now?
• What have I said "no" to recently?
• What did I stop on my own?
• Does the team know what is not important right now?

If these questions are not comfortable, that is a good sign. It means you are touching the core.

Checklist: how to get out of being stuck through focus

• Pick one 90-day goal
• Kill at least one initiative
• Sharpen a single target audience
• Define one success metric
• Tell the team why things are stopping, not only why they are starting

Focus is not giving up. It is the precondition for growth.

FAQ

Why is my startup stuck even when everyone is working hard? Busy is not Progress. Stuck startups create motion, not progress.

How do you get out of being stuck? Pick one goal, kill one initiative, and sharpen one target audience.

Can the CEO be the reason the company is stuck? Yes. A CEO who is too strong, deferring strategic decisions and leaving too many options open, becomes the bottleneck.

What is over-excitement and why is it dangerous? It's a management pattern of seeing possibilities everywhere, producing constant context-switching, a confused team, and a product no one can describe in one sentence.

How many use cases are too many at an early stage? More than two active use cases at an early stage is almost always a warning sign.

Is focus the same as giving up? No. Focus is not giving up — it is the precondition for growth.

Summary: being stuck is not failure. Missing focus is.

Every startup goes through hard phases. That is natural.

But staying stuck because you are afraid to choose is already a decision. Even if it is not a conscious one.

Startups do not die because they picked an imperfect direction. They die because they never picked at all.

And the responsibility to choose, even when it is not comfortable, always comes back to the same place.

The CEO's desk.

Why most opportunities are noise, and how good CEOs build a brutal but smart filter.

Author: Lior Romanowsky (ליאור רומנובסקי) Published: 2026-07-16 URL: https://thrive.co.il/en/article/how-to-know-what-to-ignore Section: Strategy

TL;DR

A CEO's problem isn't a shortage of opportunities. It's the surplus of them. Every "yes" builds another small company inside your company, and the real cost never shows up in the budget — it shows up in attention, momentum, and team trust. A six-question filter plus a simple management ritual separates noise from real opportunity. Focus isn't a statement. It's a list of things you stop doing.

The problem isn't a shortage of opportunities

Monday, 8 AM.

An existing customer asks for a new feature. An investor offers an intro to a big company. A potential partner wants to explore a collaboration. Someone on the team spots a new market. And in the leadership channel, someone drops an AI tool that "could change our whole product."

None of these ideas sound stupid. That's exactly the problem.

By Wednesday, four meetings are on the calendar. By the weekend, three spec docs are open. A month later, the company is working on several directions in parallel without ever having really decided to enter any of them.

From the outside, it looks like momentum. From the inside, it's dispersion.

> Startups don't only die from missing a big opportunity. Many die because they couldn't ignore ten opportunities that looked good enough.

A CEO's job isn't to find more options

Most CEOs got where they are because they see options others miss. They spot connections, imagine products, hear one line from a customer and instantly understand what else could be built.

That's a strength early on. As the company grows, the same strength becomes a liability.

At some point the problem isn't finding ideas. It's deciding which ideas are not allowed to become work.

A good CEO isn't the person with the most ideas in the room. The good CEO is the company's editor-in-chief.

A good editor doesn't just add words. A good editor cuts good paragraphs to save the story.

The job is to let the organization invest enough time, money, and attention in a small number of important things. To do that, the CEO has to protect the company from good ideas too.

Every "yes" builds another small company inside yours

We tend to think of an opportunity as a discrete action: add a feature, test a market, run a pilot, sign a partnership. But almost every meaningful opportunity creates a full system around it.

• A new feature needs specs, engineering, testing, support, and enablement.
• A new market needs a message, pricing, sales channels, and a new buyer to understand.
• A new partnership needs meetings, coordination, ownership, and success metrics.
• A new type of customer often needs a new way to deliver the service.

So the real question isn't only how long the opportunity takes to execute.

> The question is which company we'd need to become in order to support it.

Sometimes the answer is: a completely different company.

The real cost of an opportunity never shows up in the budget

It's easy to estimate the build cost of a new initiative. It's much harder to price the hidden costs.

Management attention

Attention is one of the rarest resources in any organization. You can't hire it, buy it, or restock it next quarter. When leadership spends time on a new opportunity, it necessarily spends less time on a problem it already committed to solving.

Context switching

Every shift between audiences, products, and goals has a price. The team isn't just running one more task — they have to switch context, understand a new world, remember another decision system, and manage a more complex priority stack. The cost isn't one more hour of work. The cost is a drop in sharpness.

Lost momentum

Companies move when effort compounds in one direction. Every initiative that pulls the company sideways weakens that compounding effect. Instead of getting better at the same game, the organization starts over in several different games.

Team trust

When priorities keep shifting, people stop believing the current direction will hold. They keep executing, but they stop committing. Why invest deep thought in a move that might get replaced in two weeks?

> Missing focus teaches people to wait for the next management enthusiasm to pass.

Why smart CEOs say yes to the wrong things

Most dispersion doesn't come from a lack of intelligence. The opposite — smart people can build a persuasive case for almost any opportunity.

External validation

When a big customer, an investor, or a known brand offers something, it's hard to separate strategic value from the feeling of prestige. But a big logo isn't a business model.

Fear of missing out

The thought that someone else will move before you creates artificial urgency. Suddenly you have to test now, build fast, get in before the window closes. Sometimes that's true. Most of the time, it's an elegant way to skip serious diligence.

Addiction to the new

A company's core problems tend to be familiar, hard, and a little boring: improve the sales process, sharpen the message, reduce churn, finish the existing product. A new opportunity feels different — clean of the complexity we've already accumulated. It's easy to fall in love with a future that hasn't disappointed us yet.

Revenue that hides strategic drift

Not all revenue is good revenue. A deal can bring in money and at the same time bend the product, load up the team, and create expectations you can't replicate. Money from one customer can look like market proof when it's really a payment to leave your direction.

Not every opportunity is progress

A real strategic opportunity does at least three things:

1. It strengthens the company's core direction. 2. It's based on real customer pain, not just interest or curiosity. 3. If it works, you can repeat it without reinventing the company.

Noise can look exactly like an opportunity. It can come from a real customer, promise revenue, involve a known brand, and even produce an impressive product.

> A good opportunity builds compounding strength. Noise divides the strength you already have.

Five common shapes of noise

1. A customer request that pretends to be a market signal

One customer isn't a market, and one request isn't product strategy. Before changing the roadmap, check whether the same problem shows up with other customers, whether there's a clear budget, and whether the solution fits the core product.

2. A prestigious opportunity with no distribution engine

The name looks great on a slide. But there's no accountable sales owner on the other side, no distribution commitment, no commercial target, and no timeline. That isn't a partnership — it's a long conversation with a nice logo.

3. A neighbouring market that looks too easy

The same technology could serve another industry. On paper the change looks small. In practice: the buyer is different, the budget is different, the sales process is different, and the trust required is different. Same code isn't the same business.

4. Technology looking for a problem

A new tool lets you build something you couldn't build before. Technical capability isn't necessarily a business need. A product born from "we can now" still has to answer "who cares?"

5. A free pilot with no decision path

Without clear criteria, a defined buyer, and a decision that's supposed to come out the other end, a pilot is often an unpriced project. Learning is a legitimate outcome. Activity isn't.

The opportunity filter: six questions before saying yes

Enthusiasm isn't a problem to erase. It's an energy to route through a system. Before a new initiative enters work, run it through six questions.

1. Does it serve our central goal?

Not the general vision. The central goal for the next 12 months. When the explanation needs too many "indirectly" and "maybe later" caveats, the connection is usually weak.

2. Is there pain, a buyer, and a budget?

Interest isn't demand. A compliment isn't a purchase intent. You need to know who has the problem, who's authorized to decide, why they need to solve it now, and which budget the money should come from.

3. Why us specifically?

What do we have that shortens the path — knowledge, technology, data, customer access, reputation, distribution, or unusual execution ability. If our only edge is that we're excited about the idea, we don't have an edge.

4. Is success repeatable?

Imagine the first move succeeds. Will the second customer be easier? Can we use the same product, message, and sales process? A good deal builds capability. A weak deal re-hires the organization every time.

5. What are we stopping to do this?

The question most discussions skip. If the answer is "we don't need to stop anything," we either haven't calculated the cost or we're lying to ourselves politely.

> There is no strategic "yes" without an operational "no."

6. Would we want the company this creates if it succeeds?

Imagine the opportunity works ten times better than expected. Do we want to serve more customers like this? Do we want the team, product, and brand to evolve in that direction? Sometimes we chase a success we have no wish to live inside.

Four possible decisions, not just yes or no

A good filter isn't binary. It keeps curiosity alive without turning every idea into a commitment.

Continue. There's strategic fit, evidence of demand, a clear edge, and a cost the organization is willing to pay. A decision with an owner, resources, a target, and a timeline.

Test. The opportunity looks promising but lacks evidence. Define a small experiment: interviews, a landing page, a paid offer, a narrow prototype, or a pilot with criteria. The point of the test isn't to prove the idea good — it's to produce the information needed to decide.

Park. The opportunity is good but wrong now. "Not now" has to come with a trigger for returning: "revisit when three customers ask for the same capability." Without a clear trigger, the "not now" list becomes a well-dressed graveyard.

Kill. No fit, no edge, or no wish to build the company this opportunity would create. A final decision frees more energy than another meeting.

A simple management ritual for filtering opportunities

New opportunities enter an organization from everywhere — a hallway chat, a WhatsApp message, an email from a customer, an idea mid-leadership meeting. Without a fixed mechanism, the most enthusiastic or most senior person in the room wins.

A one-page opportunity card

Every new opportunity gets written up in the same format:

• What's the opportunity in one sentence?
• Who's the customer and what's the problem?
• What evidence exists?
• How does it strengthen the central goal?
• Why do we have an edge?
• What will we stop?
• What's the smallest experiment that would reduce uncertainty?
• What decision follows a successful or failed experiment?

If you can't explain the opportunity on one page, it isn't ready for a decision.

A short filtering meeting

Once a week or every two weeks — only opportunities with a complete card get presented. Separate facts, assumptions, and hopes. Reach one of the four decisions. Nothing gets left in "we'll talk about it" status.

Patterns that keep coming back from the field

The big customer asking for "just a small adjustment"

The deal looked significant. But serious diligence showed the adjustment would require separate infrastructure, ongoing support, and a roadmap change — with no other customers needing the same thing. The fix: a paid discovery process, demand checks with other customers, or pricing that reflects the real cost. The filter doesn't kill deals — it stops one deal from silently changing the whole company.

The partner with the big name

There was no accountable owner on the other side, no defined goal, no distribution commitment. Instead of starting to build, we defined three conditions: a commercial owner, a specific number of customers, a decision timeline. When the conditions aren't met, there's no partnership — there's interest.

The new market that looked almost identical

The technology fit, but the buyer was different, the procurement process was longer, and the problem wasn't seen as urgent. Instead of standing up a new operation, we ran buyer conversations and tested a paid offer. The test saved months of building for a market that looked close on the product map and was very far away in business reality.

How to say "no" without killing initiative

A brutal filter shouldn't create a brutal culture. The idea is to be tough on priorities, not on the people bringing ideas.

> That's a good idea, but it doesn't serve our central goal this quarter. > Before we build, we need to see two more customers willing to pay for the same problem. > If we add this move, what do we drop? Until there's an answer, we don't start.

When people understand the criteria, "no" stops feeling like a personal rejection. It becomes part of how the company thinks.

A CEO exercise: the ignore list

Open a document and list every active initiative right now — not only the official projects. Pilots, tests, partnerships, features, and new markets too. Next to each one, write:

• Which central goal does it advance?
• Who owns it?
• What evidence justifies continued investment?
• What did we stop to make room for it?
• What's the next decision point?
• What would make us kill it?

You'll probably find some initiatives have no answers. They aren't necessarily bad — they just entered work before they entered strategy. Pick at least one to stop, one to narrow into a small test, and one to move to the "not now" list.

> Focus isn't a statement. It's a list of things you stop doing.

Focus isn't blindness

There's a danger on the other side too. A company can hold on to its current direction too long, ignore market shifts, and call its stubbornness "focus."

A smart filter doesn't close the door on exploration — it limits its price. You can pre-define:

• How much time is dedicated to experiments?
• How many experiments can run in parallel?
• What's the maximum budget before a new decision is required?
• What evidence is needed to move an opportunity from experiment to investment?

The difference between focus and fixation is the ability to test new ideas cheaply, learn fast, and avoid commitment before there's justification.

FAQ

Why should a company turn down opportunities that look good? Because every opportunity carries a hidden cost in management attention, momentum, and team trust. Chasing multiple directions divides the strength the company has already built, even if each individual opportunity looks reasonable on its own.

How do you tell noise apart from a real opportunity? A real opportunity strengthens the core direction, rests on genuine customer pain, and can be repeated without reinventing the company. If it fails any of those three tests, it's probably noise dressed up as an opportunity.

What should you do when a big customer asks for a special adjustment? Check whether the same problem shows up with other customers, whether there's a clear budget, and whether the fix fits the existing product. If not, the adjustment could quietly reshape the whole company — price it accordingly or require more evidence before building.

How do you say no without hurting team morale? Be tough on priorities, not on people. Explain the criteria openly: what's missing to move forward, and what condition would bring the idea back. When the team understands the rules, "no" stops feeling like a personal rejection.

What's the difference between focus and stubbornness? Focus includes a defined mechanism for testing new ideas cheaply and quickly — with a pre-set budget, time, and number of experiments. Stubbornness is refusing to look at market shifts and calling it focus. The difference is the ability to learn without committing.

What is an "opportunity card" and why use one? A one-page document that captures a new opportunity: what it is, who the customer is, what evidence exists, how it serves the central goal, and what you'd need to stop to pursue it. If you can't explain the opportunity in one page, it isn't ready for a decision.

In the end, strategy is measured by what you didn't do

It's easy to show what a company built. It's harder to see the projects it didn't start, the markets it didn't enter, the customers it didn't agree to serve, and the features it didn't add. But often, those are exactly the decisions that kept the company alive.

The best CEOs aren't the ones who chase more options. They're the ones who built a mechanism that lets them recognize what deserves attention, test what isn't yet clear, and defer everything else without apologizing.

Ignoring isn't indifference. It's loyalty to a direction.

How to lead a smart organization in a world where technology moves faster than management thinking.

Author: Lior Romanowsky (ליאור רומנובסקי) Published: 2025-01-04 URL: https://thrive.co.il/en/article/ceo-guide-to-ai-era Section: Technology

TL;DR

AI is not a product and not a strategy — it's a multiplier. A good process gets dramatically better with AI. A bad process falls apart faster. A smart CEO doesn't build an "AI strategy." A smart CEO embeds AI inside an existing business strategy, across four layers: personal efficiency, repeating processes, decision-making, and finally the business model itself. Start where there's a real, measurable, painful process — not where there's hype.

The real confusion around AI

Most CEOs are not afraid of AI. They just don't know what to do with it.

There's endless noise: everyone talks about a revolution, every vendor promises dramatic change, every employee wonders if they're still relevant tomorrow. Meanwhile, the CEO is alone with an uncomfortable question:

> How am I supposed to make good decisions about a technology I don't really understand, but that's clearly going to affect every part of the organization?

This piece isn't written for engineers. Not for data people. It's written for whoever is responsible for direction, money, and people.

AI is not a product. It's a multiplier.

One of the most common mistakes is thinking about AI as something "you do."

AI isn't a feature, not a system, and not a magic fix. It's a multiplier of what's already there.

A good process gets dramatically better with AI. A bad process falls apart faster.

If your organization isn't clear on:

• Who owns what
• How success is measured
• Where value is created for the customer

AI won't solve that. It will just surface the problem sooner.

A simple rule of thumb for a CEO: before asking where to add AI, ask where there's a process that repeats, is measured, and hurts.

Five illusions CEOs have to let go of

1. "AI will replace employees"

AI replaces tasks, not people. At least at this stage.

Organizations that don't redesign roles will see burnout. Organizations that do will see a jump in productivity.

2. "We need an AI strategy"

No. You need a clear business strategy. AI is a tool inside the strategy, not a strategy of its own.

When an organization starts from AI and not from the business problem, it ends with a pilot no one uses.

3. "This is an IT thing"

The moment AI lives only in the technology group, it fails.

Real value shows up in sales, operations, service, and management. The CEO has to be involved, even without understanding the code.

4. "Everyone is doing it, so we should too"

An efficient way to burn money.

You adopt AI when there's a clear problem and at least one success metric. Not because of social pressure.

5. "We'll wait another year"

Waiting doesn't leave you neutral. It just lets others compound an advantage.

A practical model for a CEO: four layers of AI adoption

Layer 1: personal efficiency

This is the fastest and safest layer.

• Summarizing meetings
• Drafting emails
• Analyzing documents
• Preparing management materials

There's no project here and no big budget. There's a change in habits.

Diagnostic question: does your senior leadership use AI as part of their daily work? If not, that's the first bottleneck.

Layer 2: repeating processes

This is where organizational value starts.

Look for processes that repeat, consume time, and are measured:

• Lead qualification
• First-line customer response
• Quality control
• Data analysis

At this layer AI doesn't replace people. It frees them up for thinking and high-value work.

Short exercise: pick one process that generates complaints or workload, and try to improve just 20% of it with AI.

Layer 3: decision-making

The layer most people talk about and fewest people apply well.

AI can spot patterns and raise early alerts, but it doesn't replace judgment. Without reliable data and clear definitions, it produces noise.

This layer needs management discipline, not another tool.

Layer 4: business model

Only here does AI become part of the product or service.

This is an advanced stage. Organizations that jump to it too early usually pay a high price.

What a CEO has to understand personally

You don't need to know how a model is trained.

You do need to understand:

• The difference between an off-the-shelf tool and custom development
• Why accuracy is a relative concept
• Why data is an asset
• Where the organizational risk sits (privacy, trust, regulation)
• Why a small experiment beats a big project

If you don't control this vocabulary, you're fully dependent on others. That's a dangerous position for a CEO.

Patterns from the field

In the organizations I work with, the same patterns keep repeating:

• Companies investing months in AI development when the real problem is a broken sales process
• Leadership teams that start from personal use and see natural adoption
• Organizations that get excited but never define one clear KPI

Successes look similar: a small start, clear measurement, and management involvement.

A CEO checklist: what to do tomorrow morning

• Pick one process that hurts
• Define success in one number
• Try a simple solution before building anything custom
• Involve one strong employee, not a big team
• Review after 30 days
• Decide: expand, change, or stop

That's the whole thing. People who work this way move forward. People who wait for perfection stay in place.

FAQ

Does a CEO need a separate AI strategy? No. You need a clear business strategy, and AI is a tool inside it.

Where should a CEO start applying AI? At the first layer — personal efficiency for leadership.

Will AI replace employees? AI replaces tasks, not people, at least at this stage.

Who owns AI adoption — IT or leadership? The moment AI lives only in the technology group, it fails. Real value shows up in sales, operations, service, and management, and the CEO has to be involved.

When is it right to build AI into the business model? Only at an advanced stage, after personal efficiency, repeating processes, and decision-making have already matured. Jumping there too early usually costs a high price.

Summary

AI won't turn you into a better CEO. But it will expose whether you are one.

It sharpens thinking, priorities, and management courage.

In this era, the advantage doesn't belong to whoever has the most advanced technology. It belongs to whoever knows how to apply it in a smart, human, and precise way.

That, in the end, is a CEO's responsibility.

How to move a meaningful initiative forward in 30 days without burning out, spreading thin, or killing momentum.

Author: Lior Romanowsky (ליאור רומנובסקי) Published: 2025-01-04 URL: https://thrive.co.il/en/article/30-day-sprint-framework Section: Tools

TL;DR

A 30-day sprint isn't a small project — it's a move that produces one clear outcome you can decide on: continue, change, or stop. Structure: week 1 define and align, week 2 build the core, week 3 iterate and test, week 4 ship and learn. A good sprint always ends in a decision. Even a decision to stop is a success, because it prevents further investment in a wrong direction.

The real problem with execution in organizations

Most organizations don't fail because of bad ideas. They fail because good ideas get smeared out.

A project starts with energy. There's a kickoff, a deck, a sense of "we're on our way." Then: another meeting. Another scope expansion. Another dependency. Another week that passes without a clear result.

Two months in, no one is sure what we were supposed to achieve, who is really accountable, or whether it's still right to continue.

That isn't a people failure. It's a time-frame failure.

Why projects get smeared out again and again

At Spartans we've seen this across dozens of initiatives, internal and external. Three patterns show up almost every time:

Silent scope creep

The project doesn't expand all at once. It inflates through "just one more small thing." Each addition looks reasonable. Together, they break focus.

No deadline that forces decisions

Without a clear end, there's no moment where you have to choose. Everything stays open "for more diligence."

Too many partners, too little ownership

Big teams feel safe but blur accountability. Everyone is involved. No one holds the outcome.

The result is always similar: time, money, and trust burn slowly.

Why 30 days specifically

30 days is an uncomfortable window. That's exactly why it works.

Short enough to:

• Create real urgency
• Prevent politics
• Force hard choices

Long enough to:

• Build something of value
• Meet real users
• Learn something you can act on

Shorter than that and you're only reacting. Longer than that and you start to spread.

In practice, it's the time window where organizations either move forward or find out early they're going in the wrong direction. Both outcomes are good.

Foundational principle: a sprint is a move, not a small project

The goal of a 30-day sprint isn't to "finish everything." The goal is to produce one clear outcome you can decide on.

If at the end of 30 days you can't say "continue," "change," or "stop":

> That wasn't a sprint. That was another polite attempt.

The framework: the 30-Day Sprint

The sprint is built from four weeks. Each week has one goal, clear deliverables, and a Definition of Done. Without that, the sprint falls apart.

Week 1: Define & Align

Set focus, boundaries, and ownership.

This is the most critical week. Most organizations rush through it.

What you do

Define one goal, and only one. One sentence. Measurable. No "and also." Example: "Ship a version that gets real usage from 5 customers."

Define what is not in the sprint. An explicit list of things that won't get in, even if they're good ideas.

Appoint one Owner. One person accountable for the outcome. Not a committee.

Define one success metric. If there's no number, there's no success.

Definition of Done — Week 1

• Goal written and agreed
• One clear Owner
• One KPI
• A "not in this sprint" list

Without that, you don't move to week 2.

Week 2: Build Core

Build the core, not the dream.

This is the week when the temptation to spread is strongest.

Guiding principle: build the minimum version that lets you test the goal.

Not:

• Future infrastructure
• Edge cases
• Perfect design

Yes:

• Something that works
• Something you can run
• Something you can break

A common field pattern

On day 8 or 9, a scope expansion request always shows up. At Spartans, this is the moment we stop and ask:

> Does this serve the sprint goal, or does it just feel right?

In most cases, the answer is "no" and we keep going.

Definition of Done — Week 2

• Working core
• No supplementary features
• No optimization

Week 3: Iterate & Test

Meet reality without ego.

This is the week the organization discovers whether it's really ready to learn.

You test:

• With real users
• With real data
• In imperfect conditions

The goal isn't compliments. The goal is friction.

Recommended ritual

A 20-minute mid-week checkpoint:

• What isn't working?
• What is confusing?
• What would we drop if we had to?

Definition of Done — Week 3

• At least one real testing round
• A written list of insights
• Focused correction decisions

Week 4: Ship & Learn

Ship, measure, and decide.

A lot of sprints fail here. "Just one more fix." "One more test."

No. You ship. Even if it isn't perfect.

By the end of the week you must have:

• Something actually operating
• Data, not feelings
• One clear management decision:

• Expand
• Change direction
• Stop

> A good sprint always ends in a decision. A decision to stop is also a success.

Definition of Done — Week 4

• Ship / rollout / real experiment
• Written conclusions
• A formal decision

Patterns from the field

After dozens of sprints, the patterns are clear:

• Sprints succeed when the CEO protects the focus
• Sprints fail when the team tries to "get more done"
• Teams come out stronger even from a stopped sprint, when the learning is clear

The most important insight: 30 days aren't meant to prove you're right. They're meant to make sure you're not wrong for too long.

The checklist: are you ready for a 30-day sprint?

Before you start, answer honestly:

• Is there one clear goal?
• Is there one Owner?
• Are we willing to say "no" to good things?
• Are we willing to stop if it isn't working?

If any answer is "no," don't start yet.

FAQ

Why 30 days specifically? It's short enough to create urgency and force hard choices, and long enough to build something real and learn from it.

What happens when a scope expansion request comes in mid-sprint? We stop and ask whether it serves the sprint goal. In most cases the answer is no, and we keep going without it.

Is a stopped sprint a failure? No. A decision to stop based on real data is a success — it prevents further investment in the wrong direction.

Why does the sprint need a single Owner instead of a team? Large groups blur accountability. One person accountable for the outcome keeps decisions fast and clear.

What's the difference between a sprint and a small project? A small project just tries to finish tasks. A sprint is built to produce one clear outcome you can decide on: continue, change, or stop.

Summary

Speed isn't running fast. Speed is making decisions at the right cadence.

The 30-Day Sprint isn't a management trick. It's a discipline.

In a world where everything moves fast, the real advantage belongs to organizations that know how to move things forward in a focused, measured, and courageous way.

It isn't sexy. It just works.

On the dangerous gap between product excellence and business success — and where CEOs get confused.

Author: Lior Romanowsky (ליאור רומנובסקי) Published: 2025-01-04 URL: https://thrive.co.il/en/article/product-vs-strategy-gap Section: Product / Strategy

TL;DR

Product quality is the price of admission — it isn't a strategy. Great products fail all the time because the strategy around them is weak, muddled, or missing: no sharp target audience, no one-sentence value proposition, product leading the company instead of the other way around, and no business model that holds up. "One more feature" is the most dangerous pattern. Companies aren't built from quality alone. They're built from choices.

The most common illusion in the startup world

> We have a great product. The people who know it love it. If more people were exposed to it, everything would look different.

It's one of the most common lines from CEOs. And one of the most dangerous.

Behind that belief hides a quiet, almost automatic assumption:

Good product = business success, if you just give it time.

In practice, reality shows the opposite over and over: great products fail all the time. Not because they aren't good, but because the strategy around them is weak, muddled, or missing.

A good product is an asset. It's also the most comfortable place to hide when you don't want to deal with strategy.

Product quality is a condition. It isn't a strategy.

Let's say this sharply: a bad product almost never wins. But the reverse simply isn't true.

Product quality is the price of admission. Strategy decides whether you stay in the game.

A lot of CEOs, especially those with a technical or product background, make a dangerous swap: they treat product decisions as a substitute for strategy.

• One more feature.
• One more improvement.
• One more version.

While the product gets better, the critical questions stay open.

The critical shift: from product thinking to systems thinking

This is the moment where companies get stuck.

Product thinking asks: how do we do this better?

Systems thinking asks: is this the right thing to do at all?

Without that shift, the organization gets very good at building things. But not necessarily good at building a company.

Where the gap forms between a great product and a company that isn't moving

The gap almost always forms in one or more of these places.

1. No sharp target audience

The product "fits a lot of people." Meaning: it doesn't really fit anyone sharply.

When a CEO can't say with confidence:

• Who the product is for
• What one problem it solves
• Why we're the best choice

The product, however good, stays too generic.

Customers don't buy quality. They buy relevance.

2. No value proposition you can explain in one sentence

If you need a 20-slide deck to explain why the product is worth money, you have a problem.

A great product with a fuzzy message creates friction:

• In sales
• In marketing
• In partnerships
• Inside the team itself

People work hard, but not always on the same thing. That isn't a communication problem. It's a strategy problem.

3. The product leads the company, instead of strategy leading the product

A pattern I see over and over.

The team builds what it knows how to build. The technology enables it. Ideas flow. But no one stops to ask: does this move us toward a clear business goal?

When the product sets direction, the organization reacts instead of leads.

4. No business model that holds up the product

A product can be loved, useful, and impressive — and still not hold up a company.

If it isn't clear:

• Who pays
• For what exactly
• And why now

Quality won't save the model.

A lot of companies defer these questions because "it's still early." In practice, they just don't want to find out the answers are uncomfortable.

The most dangerous pattern: "a bit more product"

When a company isn't growing, the automatic response is: "let's improve the product."

• One more feature.
• One more integration.
• One more version.

But often, that isn't what's missing.

What's missing:

• Focus
• A choice
• Deliberately dropping audiences
• A clear decision about who we're not building for

Without that, every improvement only deepens the confusion.

Patterns from the field

In the organizations I work with, it looks very similar:

• A strong product, but a sales team that doesn't know who to approach
• Impressive technology, but a message that fits "everyone"
• A CEO who knows every feature, but can't explain why one customer pays and another doesn't

The moment a clear strategic move happens:

• Audiences get cut
• The value proposition sharpens
• The pricing model changes

The product — which was already good — suddenly starts working. Not because it changed. Because the context changed.

A short CEO exercise (yes, right now)

Take a piece of paper. Not a deck. Write three sentences:

1. Our product solves the problem ___ for ___ 2. If we had to give up 50% of our features, we would keep ___ 3. If we had to double revenue tomorrow, the problem wouldn't be in the product — it would be in ___

If you got stuck in the middle, that isn't an accident. That's the area that needs a decision.

Hard questions a CEO has to ask

Answer honestly:

• Who is our product not for?
• Which one problem do we solve best?
• Can we explain our value in one sentence?
• Does the product serve a clear business goal?
• Where do we keep building to avoid making a choice?

These questions aren't meant for comfort. They're meant for direction.

How do you escape the trap?

Three simple steps. Not easy.

1. Stop building temporarily. 2. Redefine one sharp target audience. 3. Align product, sales, and strategy.

Only then do you go back to building. Not because the product isn't important. Because it's too important to be left without the right context.

FAQ

Is a great product enough to succeed? No. Quality is the price of admission — not success.

Why aren't customers buying my excellent product? Customers don't buy quality. They buy relevance.

What's the difference between product thinking and systems thinking? Product thinking asks how to do something better. Systems thinking asks whether it's the right thing to do at all.

What's the most dangerous pattern when a company stops growing? "A bit more product" — adding features instead of confronting focus, choice, and dropping audiences.

How do you escape the product-strategy trap? Stop building temporarily, redefine one sharp target audience, and align product, sales, and strategy.

Summary

A good product is an asset. Without a clear strategy, it's also a trap.

It gives a sense of progress. It provides an excuse to defer decisions. And it lets smart CEOs stay in their comfort zone.

But companies aren't built from quality alone. They're built from choices.

> And the hardest choices are almost never in the code. They're in the strategy.

Author: Lior Romanowsky (ליאור רומנובסקי) Published: 2026-08-05 URL: https://thrive.co.il/en/article/where-ai-does-not-belong Section: Strategy / AI

TL;DR

The first question about AI in an organization isn't where to start. It's where using it would do more damage than good. A simple traffic-light model sorts every use into green (AI executes), yellow (AI assists, a human decides), and red (AI does not decide), and five boundaries define the red zone: hard-to-reverse actions, human accountability, data the organization doesn't control, judging people on partial information, and domains with nobody able to check the output. Mature adoption is measured by the quality of judgment before deployment, not by the number of systems deployed.

Not every problem needs an AI solution

For the past few years I've been hearing almost the same request, over and over, in different wordings:

> We want to bring AI into the company. Where should we start?

It's a fair question. Sometimes it even leads to an excellent project. But it usually isn't the first question to ask.

The first question should be:

> Where can AI create value, and where would using it do more damage than good?

Small difference in wording. Large difference in thinking.

Once a new technology gets good enough, everyone runs the same cycle. First they dismiss it. Then they get excited about it. Then, in phase three, they try to put it everywhere.

AI is deep in phase three right now.

Every process needs an agent. Every department needs a smart assistant. Every product needs an AI layer. And every board deck needs at least one slide with the word "transformation" on it, or apparently we haven't made progress.

I'm a strong believer in AI. I build products, processes, and solutions around it for organizations. That's exactly why I don't think it belongs everywhere.

Mature AI adoption isn't measured by how many systems you deployed. It's measured by the quality of judgment you applied before deploying them.

"We can" is not a good enough reason

You can use AI to write copy.

• You can analyze calls.
• You can rank candidates.
• You can predict which employees are likely to leave.
• You can recommend a price.
• You can answer customers.
• You can approve or reject requests.
• You can let a system act autonomously.

But "we can" is a technology question.

"We should" is a business, human, legal, and sometimes moral question.

They are not the same question.

In every AI project I review, I try to understand not only what the system can do, but what happens on the day it gets something wrong.

Because it will.

Not every time. Maybe rarely. But it will get things wrong, exactly the way employees, managers, and other systems do. The question is whether the organization is built to absorb that error.

The traffic-light model: classify before you start

Before putting AI into a process, sort the use case into one of three zones.

Green — AI can execute

• Low cost of error
• The action is reversible
• The data isn't especially sensitive
• The output is relatively easy to check
• There's a clear definition of a good result

For example: summarizing documents, drafting copy, classifying inbound requests, searching a knowledge base, producing first versions, extracting action items from a meeting.

Here you can let AI work and leave people with spot-checking and correction when needed.

Yellow — AI assists, a person decides

There's meaningful business or human impact.

For example: candidate evaluation, pricing, quality checks, employee performance analysis, messages to sensitive customers, financial recommendations, risk detection.

AI can organize information, surface patterns, and recommend. It shouldn't make the call alone.

Red — AI does not make the decision

• High cost of error
• The action is hard or impossible to reverse
• The decision affects rights, health, money, or a career
• You can't explain how the decision was reached
• Nobody is qualified to genuinely supervise the system

For example: automated terminations, a medical decision without professional sign-off, cutting off an essential service, a legal determination, approving or denying credit with no appeal path, a material financial action without approval.

Once a process is classified red, the question is no longer how to improve the model. It's what part of the process should reach it at all.

This model is deliberately simple.

Organizations don't always need another complex framework. Sometimes they just need to stop and say out loud: this use is green, this one is yellow, and this is a zone where we don't let the system decide.

Boundary one: decisions that are hard to reverse

You can delete a draft email. You can fix an inaccurate summary.

You can even revisit a business recommendation before anyone acts on it.

But there are other decisions.

• Rejecting a candidate.
• Blocking a customer.
• A financial transfer.
• Ending a service.
• Changing employment terms.
• A medical determination.
• A legal action.

In these places, saving time is only a small part of the equation.

> What is the maximum damage the system can do before someone notices?

The more significant the action and the harder it is to reverse, the smaller AI's role should be. It can prepare, consolidate information, flag anomalies, raise questions, and suggest options. But a person needs to make the decision.

And not just a "human in the loop", because that phrase has become a magic fix in spec documents. You need someone who understands the subject, holds the authority, knows how to push back, and is willing to carry the responsibility.

Auto-approving an automated recommendation isn't human oversight. It's automation with one extra click.

Boundary two: human accountability

Some processes managers want to automate because they repeat. Others they want to automate because they're unpleasant.

Those are two different things.

• Negative feedback.
• Rejecting a candidate.
• Handling an angry customer.
• A conversation about weak performance.
• Announcing a significant change.
• Letting someone go.

AI can help a lot with preparing for conversations like these. It can organize the facts, sharpen the wording, catch aggressive phrasing, and help a manager show up better prepared. It shouldn't replace the human presence itself.

When someone receives significant news about their work, money, health, or future, they need more than information. They need to be able to ask, respond, understand context, and feel that someone across from them is taking responsibility.

There are moments where the person isn't a bottleneck. They're part of the product. Part of the service. Part of the decision.

There are also moments where "efficiency" is just a polite word for avoidance.

A manager who won't hold a hard conversation doesn't need a better bot. They need to become a better manager.

Boundary three: systems the organization doesn't control

One of the most common requests is to connect AI to "all the company's data": email, documents, calls, the CRM, HR systems, financial data, and internal messages.

Technically, a lot of that is possible. Managerially, it can be a serious mistake.

Before connecting data to AI, you need to know:

• Who owns the data
• Who is allowed to see it
• Why it was collected
• Whether it's accurate
• What consent was given for it
• How long you're allowed to keep it
• Whether it may be used for this new purpose
• What happens if it leaks or is exposed

If the organization can't answer those questions, it doesn't have an AI problem yet. It has a data governance problem.

AI doesn't tidy messy data just by showing up. Sometimes it only makes it faster to reach, easier to surface, and more dangerous.

The same is true for processes.

Service complaints come in, so the company adds a chatbot — but there's no clear service policy. Sales misses targets, so someone wires up lead scoring — but the target audience was never defined. Leadership struggles to decide, so a smart dashboard appears — but nobody knows who owns which number.

> A broken process with AI is still a broken process. It just runs faster.

Before putting AI into a process, check:

• Is the process clear?
• Does it have an owner?
• Do we know where it starts and where it ends?
• Is success measured?
• Is the problem really manual work, or weak management decisions?

Sometimes the most professional work in an AI project is stopping before you build. Not because the technology can't do it, but because the organization isn't ready to use it well.

Boundary four: judging a reality it can't actually see

One of the most tempting uses is AI that measures people.

• Who is more productive.
• Who is less engaged.
• Who is a flight risk.
• Who is ready for promotion.
• Who needs management intervention.

On paper it looks like a move from gut-feel management to data-driven management. But employee data is almost always partial.

Email volume doesn't measure contribution. Hours online don't measure impact. Ticket counts don't measure quality. Meeting attendance doesn't measure leadership. And Slack message volume, thankfully, is still not a measure of intelligence.

When a system receives partial data, it doesn't necessarily know the data is partial. It produces a complete conclusion from it, in confident, persuasive language. That's exactly what makes the output dangerous.

A weak data point in a table looks like a weak data point. A weak data point that passed through a model and came back as a well-written recommendation can look like the truth.

AI can help spot a change, flag an anomaly, and suggest a question a manager should look into. It shouldn't determine who's a good employee, who's loyal, or who deserves a promotion based on a partial picture.

> Don't let a system judge a person on information you wouldn't have been willing to judge them on yourself.

Boundary five: places where nobody can check it

One of the more dangerous illusions is that AI can replace expertise the organization doesn't have.

It can certainly extend existing capability. It can help a doctor summarize information, a lawyer locate clauses, a finance lead spot anomalies, and a product manager weigh options. It doesn't turn an organization without expertise into an expert one.

If nobody in the company understands regulation, you can't let AI manage regulation. If nobody understands security, you can't assume a system will identify what's risky on its own. If nobody can evaluate a medical, legal, or financial recommendation, nobody will catch it when it's wrong.

AI can produce a wrong answer that sounds highly professional. That's sometimes more dangerous than a weak answer, because linguistic confidence makes people stop checking.

> Don't use AI to do work nobody in the organization is able to evaluate.

You don't need to be able to perform every task by hand. But someone has to be able to recognize what a good result is, what a dangerous one is, and when to stop.

Without that, there's no oversight. There's faith.

And faith is a fairly poor management model for autonomous systems.

What responsible use looks like in practice

Say a company wants to use AI to improve hiring.

The irresponsible version is letting the system scan resumes, score candidates, and reject everyone below a threshold.

The more responsible version looks like this:

• AI consolidates information from the resume
• Flags missing details
• Compares the candidate's experience to the role requirements
• Suggests interview questions
• Identifies contradictions or points to verify
• A qualified person makes the next-step decision
• The reason for the decision is documented
• The outcome can be revisited

Same technology. Completely different level of accountability.

That's the point most people miss. The question isn't only whether you use AI. It's what role you give it inside the system: advisor, assistant, reviewer, recommender, or executor.

Not every role fits every process.

Autonomy is built, not granted

AI agents can perform more actions independently. They can read data, make intermediate decisions, update systems, send messages, and trigger processes.

That's real capability. But automation and autonomy aren't the same.

Automation runs inside defined rules. Autonomy makes decisions along the way.

> The more autonomous a system is, the more boundaries it needs, not fewer.

You need to define:

• Which actions it's allowed to take
• Which data it's allowed to access
• The maximum amount or risk involved
• Which actions require approval
• How you stop it
• How every action is logged
• Who reviews its performance
• Under what conditions permissions get narrowed

Instead of jumping straight to full autonomy, step up in stages. First AI suggests. Then a person approves. Then AI performs a limited action. Then you move to spot-checking. Only after the system has proven stable do you widen its scope.

Trust isn't a feature you switch on in a settings screen. It's the result of consistent performance under supervision.

Customer service: don't turn AI into a wall

Customer service is a natural place for automation. Customers want fast answers, service teams are overloaded, and a lot of the inbound repeats.

AI can resolve a large share of it. It can identify intent, retrieve information, explain a process, and point the customer to the next step. It shouldn't be the only channel.

A customer has to be able to reach a person when:

• They already tried and didn't get an answer
• The issue involves money
• There's a significant service failure
• The case is unusual
• The customer is in a sensitive situation
• There's a medical, legal, or safety implication

A company shouldn't only measure how many tickets closed without an agent. It should also measure how much frustration the system saved and how much it created.

A high automation rate looks good in a report. A customer who spends twenty minutes arguing with a bot is less impressed by the report.

Eight questions every management team should ask

Before approving a new AI use, answer eight questions:

• What decision or action does the system perform?
• What business value do we expect from it?
• Who could be harmed if it's wrong?
• Can the action be reversed?
• Can we explain how the result was reached?
• Who is able to check the quality of the output?
• Who is the business owner of the system?
• Under what conditions do we stop or shut it down?

No answer to question seven means no ownership.

No answer to question eight means no control.

And if you can't define the business value, there may not be a project here. There may just be enthusiasm.

How to say no to AI without stopping innovation

This is one of the political problems around AI. No manager wants to be the one saying no while everyone else is talking about the future.

So sharpen the language.

Instead of "we're not ready for AI", say: "we're not approving autonomy in this process until we have oversight".

Instead of "it's too risky", say: "the cost of error here is higher than the value we'd save right now".

Instead of "let's keep it manual", say: "we'll use AI for preparation and recommendation, and keep the decision with the role owner".

That isn't slowing innovation. It's an architecture of accountability.

The mark of an advanced organization

An organization doesn't become advanced by putting AI into every department.

It becomes advanced when it can tell the difference between:

• A task you can accelerate
• A decision you can improve
• An action that requires oversight
• Accountability you must not hand off
• A process that needs fixing before automation
• A situation where the person is still the most important part of the system

The future won't belong to the organizations using the most AI. It'll belong to the ones using it in the right place, at the right dose, with clear boundaries, and with people who keep taking responsibility after the system enters the room.

FAQ

How do I decide where to put AI in my organization? Sort every use into one of three zones. Green: low cost of error, reversible action, easy to check the output. Yellow: meaningful business or human impact — AI recommends, a person decides. Red: high cost of error, irreversible action, or impact on rights — AI does not make the call.

When should AI not make the decision? When the action is hard or impossible to reverse, when the decision affects rights, health, money, or a career, when you can't explain how it was reached, or when nobody can genuinely supervise the system. The deciding question: what is the maximum damage the system can do before someone notices.

Should we connect AI to all our company data? Technically you can. Managerially, usually not yet. First know who owns the data, who is allowed to see it, what consent was given, and what happens if it leaks. If you can't answer, you don't have an AI problem — you have a data governance problem. AI just makes messy data faster to reach and more dangerous.

Should we use AI to measure employees? Only with real care. Employee data is almost always partial. Email volume isn't contribution. Hours online isn't impact. A system fed partial data produces a complete-sounding conclusion in confident language, and that's what makes it dangerous. The rule: don't let a system judge a person on information you wouldn't judge them on yourself.

How do I say no to an AI project without stopping innovation? Sharpen the language. Instead of "we're not ready for AI", say "we're not approving autonomy in this process until we have oversight". Instead of "it's too risky", say "the cost of error here is higher than the value we'd save". That isn't blocking innovation. It's an architecture of accountability.

Summary

The most important question about AI in an organization isn't what it can do. We already know it can do a lot.

The question is which decisions we're willing to hand to it, which actions we let it take, and where we draw a clear line.

AI shouldn't be where:

• The cost of error is high
• The action is hard to reverse
• The decision can't be explained
• The data isn't controlled
• The process itself is broken
• Nobody owns it
• No expertise exists to check the output
• Or real human presence is required

Deciding not to use AI isn't necessarily fear of technology. Sometimes it's the clearest sign that leadership actually understands it.

Real innovation isn't putting the newest tool everywhere it fits. It's knowing where it creates value, where it creates risk, and when management responsibility requires leaving it outside the room.

---

© Thrive.co.il — Lior Romanowsky. https://thrive.co.il