Every Product Manager knows the tension between competing goals. Sometimes it’s user segments pulling in different directions. Sometimes, the real conflict isn’t between users, it’s between competing business priorities at the core, like Conversion vs. Retention.

In my case, as the product leader for Fiverr’s freelancer experience, it was a conflict between Monetization and Growth.

As PMs, a big part of our job is to spot and solve these conflicts. We do this by turning them into clear hypotheses and figuring out the best way to test them. It’s all about getting to the right results faster and, yes, failing fast.

In this post, we’ll look at how a smoke test helped us not only solve a strategic conflict but also validate the riskiest hypothesis behind a product and distill its long-term value proposition.

Finding the WIN-WIN

The strategic conflict

As the Product Manager for Freelancers Growth and Monetization at Fiverr, I faced a strategic deadlock between two strategic priorities. One aimed to monetize the top of the funnel of freelancers who join Fiverr. The other prioritized Fiverr’s ability to identify high-potential new freelancers early and roll out the red carpet for them.

At first glance, this seemed like a conflict of interest, raising valid concerns, like:
• Would the “friction” of an optional or mandatory payment alienate high-potential freelancers during onboarding and hurt supply growth?
• Could a paid option drive enough engagement without overpromising and compromising client satisfaction (“first sale guaranteed!”)?

The Product Manager role

What is my role in that case? Isn’t it simply a business trade-off? As a product leader, I believe one-sided wins are not sustainable, and that my role is to find the right path to balance these interests and show they can work together, even create synergy if done right. Finding the win-win is the path to sustainable long-term growth.

My hypothesis was bold: payment is not a barrier, it is a filter. I assumed that a paid option — positioned not as a guarantee of success but as the right move if you’re serious — would help us identify the highest-potential freelancers amidst the noise. Over time, this would enable us to create a VIP track for them. In other words, the willingness to pay itself would become an early signal of quality and commitment.

But how could we know? There was a lot to validate.

Taking “Working Backwards” One Step Further With a Smoke Test

Amazon’s Working Backwards framework

Amazon’s Working Backwards approach starts with the customer experience, rather than the technology or ideas, to define and build new products. Before development begins, teams write a mock press release and FAQ (PR/FAQ) describing the final product and the value it delivers, ensuring it solves a real customer problem.

Smoke test as a validation methodology

Going back to our payment-as-a-filter hypothesis, we took the Working Backwards framework one step further. We wrote the press release, but instead of building and launching a full product or an MVP, we built a smoke test (AKA fake door), distilling the whole value proposition into one pop-up.

A smoke test creates the visual appearance of a feature, such as a button, menu item, or landing page, and measures how many users click on it. The ideal hypothesis to validate using a smoke test is your riskiest assumption — the one that, if proven wrong, would make developing the product pointless.

This is particularly relevant for B2B products and startups. Smoke tests are often associated with high-traffic B2C environments, where scale accelerates learning. But scale is not the prerequisite for value. Even with limited traffic, small samples can provide directional insight and help de-risk decisions before committing significant resources. In lean environments, clarity matters more than statistical perfection.

The Kickstart smoke test

At first, we considered using email marketing for the smoke test and redirecting users to a landing page. We quickly realized that the validation we were looking for was unlikely to come from email, due to low engagement and, more importantly, the lack of in-product context.

Instead, we decided to launch a smoke test within the existing product, as part of the freelancers’ onboarding flow. The goal was to validate the riskiest assumption behind the whole initiative. In our case, the question wasn’t just “Will they click?” but also “Will high-quality freelancers be willing to pay?”

Working closely with our Product Marketing Manager, Gil Markman, we distilled the unique value proposition — “Get to your first order faster with Kickstart” — , unique selling points (e.g., “Get up and running”: Enjoy step-by-step guidance, including live sessions to set your business up for success.), core features and pricing mode, into a single pop-up within the existing freelancer onboarding flow.

We developed it quickly and launched an A/B/C/D test (a privilege when you have high traffic, but not a reason to avoid smoke testing; you can always choose one variant and iterate) to provide early validation and give stakeholders confidence that we were on the right path.

That single small button (“I’m interested”) taught us who clicks, what they are looking at, and which business model is worth building.

It’s also worth noting that the screen originally designed for the smoke test has remained in production and continues to represent our value proposition successfully. In several instances where we tried to adapt this screen for other products or experiences, we saw a significant drop in program adoption, which led us back to the winning baseline created for the smoke test.

The thorough work of distilling user value, originally done for validation, continues to pay off today.

The advantages of a smoke test

Unlike Working Backwards with PR/FAQ, a well-designed smoke test exposes your value proposition to real users. They can show their interest and even provide feedback, collected in product and in context.

We all know that the most important validation is not of the solution — but of the problem, the real need, and the actual opportunity. Smoke testing lets you test early while avoiding the biases inherent in other validation methods, such as interviews, surveys, and prototype-based user research.

Beyond the Click

Mitigating the risks of a smoke test

So yes, freelancers couldn’t actually pay to get what they showed interest in. This was a source of frustration, as it is unnatural for PMs to compromise on the user journeys they own.

There are some best practices to mitigate the risks:
• Do not break the existing flow, or prevent what the user needs to complete to progress
• Add immediate value (e.g., a benefit) and future value tied to the promise (e.g., “You’ll be the first to know”).

Measuring the results

We saw a Click-Through Rate (CTR) that was significantly higher than the benchmark, indicating strong interest and willingness to pay. But even in a smoke test, you can measure more than just engagement (via heatmaps and CTR) and more than willingness to pay by comparing variants with different business models (one-time vs. subscription; higher and lower prices).

Post-click behavior (like the time freelancers spend creating a Gig, the service they sell on Fiverr) can be a stronger signal than CTR alone. We discovered that engaged users weren’t the fastest. Quite the opposite — it took them much longer to create their first Gig. One might have thought the feature broke the funnel, but in reality, it signaled seriousness and investment — exactly the audience we wanted.

The users who expressed interest tended to be of higher quality, a signal we later validated with additional tools like surveys, user interviews, and manual evaluation, and ultimately acted upon by shipping the product.

Reducing Risk Before Building

When done right, smoke tests force you to be precise about what you’re actually offering, who it’s really for, and which assumption you’re most afraid to test.

In our case, the smoke test helped us understand which freelancers were willing to commit, how they interpreted the value, and which signal actually mattered.

With shorter production cycles, it’s tempting to move straight to building. But speed doesn’t replace judgment. Smoke tests let you learn early, reduce risk, and make better decisions before you invest in a full solution.

Smoke Tests Take the “Working Backwards” Framework One Step Further was originally published in Fiverr Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

We often plan a test, and only when it is done, do we realize it had no impact.

The experiment ran smoothly. We had clean allocation, complete data, and no technical issues. And yet, when the results came in, our reaction was: “That told us nothing.”

The main metrics didn’t meaningfully change. There was no clear decision we felt confident making. After 14 days, we were left with a well-executed test — and no real insight.

This isn’t a rare outcome. Many product and growth teams run experiments that are technically correct but strategically useless.

After running enough “boring” tests, I’ve come to a simple conclusion: most low-impact experiments fail long before they’re launched, during planning. In this article, I’ll explain how I reached that conclusion, highlight common planning mistakes that lead to flat results, and show how small changes to the hypothesis, population, or framing can dramatically increase impact.

What to look for before you launch a test

Your product manager comes to you with an idea: a test that will change the world, make an impact, and increase revenue. Take this as an opportunity — as a data analyst — to be critical, set the tone, and adjust the plan so your team can maximize impact.

Think about the following:

• Decide on the impact you are looking to achieve in this test
  Are you looking to move the needle and impact a main metric, or are you looking for learnings that will help you make future decisions and adjust the next A/B test?
• Clarify the population
  Not just the size of the population, but also its impact. For example, in e-commerce, some buyers are very experienced on the platform and have their own habits, making them harder to influence.
• Understand what the expected outcome is
  What metrics will increase? What are the trade-offs? Who benefits from this test?
• Before the test, understand the next step of each optional outcome
  If the test fails, what do we do? If the test shows mixed signals, what do we do? This will help you think of options and opportunities you might not come up with after the test is closed and you already have the results.

An example of a doomed flat test (and what we’d change)

Imagine a team planned the following test: adding a CTA to search results that encourages buyers to message the seller before purchasing, assuming it will lead to better conversions and higher satisfaction.

It feels like a safe and reasonable test. Search has a lot of traffic and plenty of diversity in buyer types, meaning we can learn from it, but we also expect real impact. The change is easy to roll back if we lose, and conversion is a metric that moves the needle.

The test goes live, and the results come back flat. Why?

At this point, we need to go back to the steps we established and ask ourselves what went wrong.

When thinking deeper, a few things come to mind:

• Search includes mixed buyer types with mixed intent
  Some buyers arrive with a clear vision and are ready to purchase now. Others are exploring, and some have complex requirements that require more context. That mix can produce mixed results. If we’d focused on a specific population, we might have seen a clearer outcome — and potentially more impact.
• In some marketplace areas, conversations are unnecessary
  The service is simple and immediate, and encouraging a conversation might create friction. Focusing on a specific area and planning ahead would allow us to achieve better results.
• Experienced buyers know exactly when a conversation is needed
  They make up the majority of the buyer base. But it is the less experienced buyers who need more guidance and encouragement, and the larger group absorbs this effect.
• Placement is key
  Users usually need more context before starting a conversation. Showing a CTA in search might be a bit early in the road.
• “Success” in such tests may be defined differently from conversion
  Conversations are meant to improve decision quality, not necessarily speed. In a test like this, satisfaction, cancellations, revisions, disputes, or repeat behavior may be better success criteria than immediate conversion.

This wasn’t a hypothetical example. It was a real test we ran as a team at Fiverr, and it actually helped surface something useful.
Once the results came in, the gaps were pretty clear. You could see where better coordination between sides could have made the test more focused, and where we could have been more precise in the way we framed the questions. A few sharper questions upfront probably would have saved us time.
The test itself didn’t teach us anything new about our users or the marketplace, but it did push us to think more carefully about how we plan these tests. If we slow down a bit at the beginning and make sure we’re aligned, we’ll run more accurate tests and get better answers out of them.

The questions we should have asked

Looking back, there were a couple of questions we could have answered during planning that would have made the risk of a flat result much clearer.

1. Whose behavior do we actually expect to change — and who will likely be unaffected?
   This forces you to think beyond traffic size and ask whether the population you’re testing on is sensitive to the change at all. In this case, experienced buyers and buyers with simple needs were unlikely to benefit from a conversation.
2. How variable is this behavior today across users, segments, or contexts?Before testing, we can look at existing data to understand whether the behavior already varies meaningfully across populations. For example, are there segments, categories, price points, or entry paths where this behavior is already more common or more successful? Or is it relatively flat everywhere? This can point directly to where a test is most likely to produce impact.

None of these insights required new experiments or complex analysis. They were available to us through questions we could have asked and data we already had.

As analysts, our impact doesn’t come from running more experiments — it comes from shaping better questions upfront. The difference between a forgettable test and a meaningful one is often a few deliberate decisions made early.

If this article helps you pause before the next test and rethink how it’s planned, it has already done its job.

Why So Many Tests End Up Changing Nothing was originally published in Fiverr Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Half a year ago, my manager told me that there’s an AI tool called Cursor. She gave me a task: explore it and see how it can benefit your day-to-day work.

In our world today, as AI tools are constantly built and updated, it’s important for us to know how to approach and adopt the tools that are relevant to us so we can work faster and focus on our main tasks.

If you feel overwhelmed by the amount of tools out there and are not sure how to even begin examining them, this post is for you!

AI Overload Is the New Normal

The world is moving fast, and new AI tools are popping up all the time. You hear about them everywhere.

At the same time, the tools we use keep evolving too, with new features and improvements rolling out all the time. Different tools serve different purposes - one might be great for daily monitoring, while another works better for deep-dive analysis. Our goal is to understand each tool’s strengths and limits so we can choose the right one for the job.

Of course, we don’t want to be left behind - we want to be part of the game, and these evolving technologies will hopefully help us focus on our core tasks and goals: to provide insights to our stakeholders.

How to Approach Working With a New AI Tool

My journey with Cursor

With Cursor, I didn’t really know where to begin: I wasn’t that familiar with the tool and had only heard of devs using it for coding. I’ll admit, I started to panic a little bit - exploring something new isn’t easy and can be intimidating, especially when you’re not quite sure how it works, and it seems like a “black box”.

I started by looking up videos online of analysts who used Cursor. The videos I watched were more instructive, teaching users how to use the tool in general, and didn’t include input on how they used it for a deep-dive analysis.

I then ditched the videos and tried to find someone I know who had already started using it. I didn’t mind if they were an analyst or not; I just wanted someone I could explain my needs to and who could guide me on how to get started and what to expect. I wanted someone to tell me, “Ok, you want to do X, Y, Z; I believe that X and Y are doable, but Z is not quite possible in Cursor, so try to attack it from a different angle.”

One of the developers on the Fiverr team was willing to help me, and we sat down to talk. It gave me the foundation for what Cursor is capable of, and even hearing how he was using it helped me adjust my thinking and understand how to approach it.

I wanted to start working with it and get my hands dirty. I downloaded it, opened it, and then a question popped into my head: “Ok, now what?”

That’s when I realized the best way to explore a new tool is to start with a real problem. If you know exactly what you’re trying to solve, the steps to get there, and the outcome you’re aiming for, you have a much clearer vision of how the tool can help you.

So I took a real analysis as a case study and started playing with it. I tried two different approaches. First, I gave it a doc with all the relevant data, already aggregated and ready for investigation. Then I wanted to test its SQL abilities, so I gave it only background context and our tables and asked it to query the data on its own.

Trying both approaches helped me examine different abilities each time - analysis vs. SQL querying - and decide whether I liked the way it created an analysis or the way it wrote SQL code.

A step-by-step approach to testing a new AI tool

Next time that you need to examine a new AI tool, this is what I recommend you do:

1. Brainstorm with colleagues: try to find someone who is already using the tool. Understand what they liked, disliked, and how it impacted their work. Try to translate their experience into your own world and workflow.
2. Start with a real problem that you want to solve: be clear about what you’re trying to solve, what steps are involved, and what a good outcome looks like. When you define the target upfront, it becomes much easier to evaluate whether the tool is actually helping you move faster or think better.
3. Divide the problem into small tasks, where each task checks a different ability. This helps you see where the tool performs well and where it needs more guidance. For example, let it generate the SQL queries first and evaluate the logic. Then give it the data and see how it analyzes the results and translates them into meaningful conclusions.
4. Keep an open mind. Once the tool handles the problem, push it further. Ask it to approach the same problem from a different angle, automate additional steps, or suggest alternative methods. By experimenting creatively, you might discover capabilities you hadn’t considered.

The Takeaway: Test Tools Like You Test Hypotheses

AI tools allow us to move faster and can save us a lot of time. It can be intimidating at first, but once you get to know the tool, you can learn how to benefit from it.

We need to take into consideration the fact that the tool we’re exploring may not be able to solve the entire problem from A to Z. When getting our hands dirty, we’ll be able to identify the pros and cons of the tool, and decide along the way if we want to use it for a specific part of the task, for the entire task, or maybe not use it at all.

We must use our critical thinking and not trust everything the tool does, because as we all have already learned, it can and it will make mistakes.

From Curiosity to Confidence - Testing AI Tools for Analysts was originally published in Fiverr Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the years, working as a data analyst in product teams, including at Fiverr, I’ve learned how critical it is to continuously invest in data-driven ways of working.

This isn’t a skill owned by a specific role, squad, or function — it’s something that requires constant care, reinforcement, and improvement.

Being truly data-driven takes effort. It slows things down, forces uncomfortable conversations, and sometimes challenges decisions people already feel confident about. But when teams commit to it, they make better decisions, prioritize more effectively, and waste far fewer resources on the wrong bets.

That’s why the effort is worth it.

In the sections below, I’ll walk through a few practical ways teams, and especially data analysts, can help build and maintain a data-driven way of working.

Being data-driven is not just the analyst’s job

As a data analyst, one of your core responsibilities is to support data-driven decision-making and methodologies within your team.

But this responsibility doesn’t rest solely with the analyst; it belongs to every member of the squad.

Data-driven teams don’t rely on gut feeling as a default. They strive for measurable outcomes, learn from what actually happens, and adjust their actions accordingly. This mindset applies to every role, every industry, and even outside of work.

At the end of the day, data is the most honest mirror a company has for understanding what’s really happening with its products and services.

Planning a milestone with a clear north-star KPI

Every development cycle starts with planning, deciding where the team will focus in the coming weeks or months. At this stage, every meaningful effort should be mapped to a clear north-star KPI.

That KPI should represent the outcome you care about, not the mechanism that might help you get there.

For example, if a milestone includes implementing a new search algorithm, the KPI you want to move is the conversion rate from search to purchase.

Metrics like recall or relevance are important, but they’re supporting indicators. Improving them only matters if they ultimately improve conversion.

Optimizing a metric just because it’s easy to measure, without impact on the actual business outcome, is a common and costly mistake.

At the end of the milestone, success should be evaluated by the KPI’s movement, while supporting metrics help explain why it moved (or didn’t).

Estimating impact before committing effort

Planning shouldn’t stop at defining a KPI. Whenever possible, teams should also estimate the expected impact of the planned work.

Using the same example, it’s worth asking: how much could this new algorithm realistically move conversion? This can be done using statistical methods (like sample size calculations) or even rough directional analysis.

For the search algorithm example, we can use a sample size calculation for comparing two proportions.

From there, we can estimate the required sample size for an A/B test, meaning the number of users who would actually be exposed to the new algorithm. The key question then becomes practical: Is this sample size achievable within a reasonable timeframe?

We can also look at it the other way around. Based on current traffic (for example, all users who perform searches), we can calculate the minimum detectable effect, the smallest conversion uplift that would be statistically significant given the expected sample size.

If that minimum uplift is unrealistic or doesn’t justify the effort, that’s already a strong signal. It may mean the feature is not worth prioritizing, at least not now.

This step plays a huge role in decision-making. If the expected impact doesn’t justify the investment, it’s often better to pause and explore alternatives before time and resources are already spent.

Implementing product changes with monitoring in mind

Any product change should be monitored from the moment it’s released. Whether it’s a gradual rollout or an A/B test, a data-driven approach always includes tracking the relevant KPIs and digging into user behavior to ensure the change works as intended.

Even small, seemingly harmless changes can be destructive if they’re shipped without monitoring.

I’ve seen cases where teams launched changes without a clear plan for measurement. This is where a data analyst or any team member should step in to help define how the change will be tracked, so the team always has visibility into what’s happening.

Data-driven work needs proper infrastructure

A data-driven mindset can’t survive without the right infrastructure.

Teams need reliable BI tools, well-defined events, clear documentation, and a data warehouse that people can actually trust and understand. Maintaining this setup requires continuous effort and collaboration, and it only works when everyone understands why it matters.

Good infrastructure doesn’t just support analysis, it enables better conversations and faster, more confident decisions.

Knowing your numbers through constant monitoring

Truly data-driven teams are curious about their numbers. If you’re working on a feature, say, an inbox, you should know the daily volume of messages and conversations, the conversion rate from conversations to orders, and other core metrics by heart.

This level of familiarity comes from strong monitoring: daily reports, well-designed dashboards, and accessible data for the entire team.

Beyond visibility, this habit creates opportunity. New ideas emerge from understanding the current state of the product, rather than from gut feelings or untested assumptions about the future.

Correlation is tempting, causation is hard

One of the biggest challenges when working with data is connecting numbers to reality.

Spotting trends, correlations, anomalies in dashboards, alerts, or A/B test results is only the first step. The real work starts when you try to explain why something happened.

That usually means breaking the data into segments, examining different user populations, sampling sessions, comparing current behavior to historical trends, and questioning your own assumptions along the way.

Poor analysis can easily lead to misleading conclusions.
For example, seeing an uplift in group B during an A/B test might look promising, but it could be driven by a few outliers, imbalanced groups, or even something like Simpson’s paradox.

Jumping too quickly to interpret results can be dangerous.

This is where experience matters. Proper investigation takes time, statistical understanding, and business context. In many cases, that responsibility falls on the data analyst or data scientist, not because others can’t look at data, but because deep causal reasoning requires focus and expertise.

Good questions beat good dashboards

Working with data should start with a question or a hypothesis, not with a dashboard.

Exploring data without a clear direction can easily lead to false conclusions. The more metrics you look at, the higher the chance you’ll find something that looks significant just by chance, the classic multiple testing problem.

That’s why analysis should begin with a clear question:
What are we trying to understand? What would prove or disprove our assumption?

Data should help explain a phenomenon, not be forced to justify a decision that has already been made.

Democratizing data access is important and healthy for a data-driven team. But access alone is not enough. Data must always be interpreted within a business context, with clear reasoning behind the conclusions.

Good dashboards are helpful.
Good questions are essential.

The harsh truth — there is no short way

Being data-driven isn’t about dashboards, tools, or frameworks; it’s about discipline.

It’s the discipline to define outcomes before acting, to measure changes even when it’s inconvenient, and to let data challenge decisions instead of just validating them.

Teams that build this discipline don’t just make better decisions; they learn faster, adapt quicker, and compound their advantages over time.

Why Most Teams Think They’re Data-Driven and Aren’t was originally published in Fiverr Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

I used to believe the sentence “knowledge is power” without questioning it. That made sense in a world where information was hard to get.

But that world has changed.

Think about this for a second: historically, being overweight was a status symbol. If you were heavy, it meant you were rich enough to eat in a starving world. Today, that logic has completely flipped.

The same shift happened with information.

We don’t live in a world where knowledge is rare. We live in a world where it’s constant. Endless. Pushing itself at us.

In the past, if someone wanted to hide the truth, they burned the books. Today, no one burns anything. They drown you in information.

And when everything is available, clarity becomes harder, not easier.

I’ve been working as a Data Analyst at Fiverr for the past year, and I see a smaller version of this every day. People assume my job is about collecting information. It isn’t. Most of the time, it’s about deciding what to ignore, questioning what a number truly represents, and slowing things down when urgency pushes for speed.

This isn’t about knowing more.

It’s about thinking better.

If you’ve ever felt informed but not wiser, this is for you.

Because the real outcome of overload isn’t ignorance- it’s exhaustion.
And when you’re exhausted, you don’t choose. You react.

The comfort of noise

What surprised me most in my work isn’t how often numbers are wrong, but how flexible they are. The same dataset can justify opposite decisions depending on what you highlight, what you ignore, and what you quietly redefine as “success.”

I’ve been in meetings where everyone agreed on the numbers and still walked away with completely different conclusions. The problem wasn’t bad data. It was too much of it. Too many metrics. Too many angles. Too many ways to defend a position.

And here’s the uncomfortable part: when everything can be defended, nothing has to be owned.

We hide by adding. Another metric. Another breakdown. Another “just to be thorough” slide. It feels responsible. It feels careful. But at some point, you realize the extra information isn’t helping anyone decide. It’s just making it easier not to.

Standing behind a chart is easier than standing behind a decision.

The missing ingredient: Friction

That’s when I started noticing something else: too much information doesn’t just overwhelm us, it removes resistance.

When answers are always available, instantly generated, endlessly backed by data, you don’t have to sit with uncertainty. You can always pull another input, another perspective, another graph, another summary. And slowly, everything gets smoother. Too smooth.

That’s where friction comes in, a small resistance, a pause before you act.

In physics, friction is something engineers try to reduce. It slows movement. But without it, nothing works. You can’t walk. You can’t stop. You can’t even stand still without slipping.

AI moves in the opposite direction. It removes friction. You ask a question and get a clean answer immediately. It feels efficient. Productive. Sometimes it is. But sometimes it replaces the struggle that would have made the understanding deeper.

In my work, sometimes the most valuable thing I can say is, “We don’t know yet.” Not because we lack data, but because we haven’t sat with it long enough. That pause is uncomfortable. People want resolution. But that small friction often leads to better thinking.

Still, friction alone isn’t enough.

Friction creates space. Filtering protects it

You can pause and still consume everything. That’s where filtering matters.

Friction buys you space. Filtering decides what fills it.

Think about your phone. At some point, you’ve seen the message: Storage almost full. You can delete photos, clean things up, and decide what still matters. Or you can just upgrade your storage. One click and the problem disappears.

Deleting takes effort. Expanding takes almost none.

Our digital world follows the same pattern. It’s easier to add space than to choose what to remove.

That’s the difference. Friction is the pause before you act. Filtering is what you decide in that pause.

Without friction, you react to everything. Without filtering, you let everything in.

Filtering isn’t dramatic. It’s small. It’s closing tabs. Ignoring dashboards that don’t change real decisions. Unfollowing accounts that add noise instead of insight. Deciding that not every opinion deserves space in your head.

It’s not anti-information. It’s selective attention.

The real advantage now

We live in a world built for speed and volume. Slowness starts to look like its own kind of intelligence.

The amount of information around us isn’t going down. The systems competing for your attention are only getting better at their job.

So, trying to win by consuming more won’t work.

Clarity doesn’t come from collecting everything. It comes from choosing what to carry.

The next time you feel the urge to react immediately, to answer, to click, to form a strong opinion just because one is available, try something small.

Pause. Let the friction exist for a moment. Then filter.

Choose what actually deserves your attention. And let the rest go.

In a starving world, food meant power. In an overloaded world, control over your attention does.

TMI is Dangerous was originally published in Fiverr Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Humans were not born into code, and our consciousness did not evolve around algorithms. Most of human history took place without computers, screens, or digital systems. The way humans understand reality was built in a physical, multi-layered, and limited world. Human structures survive technological shifts. This is not an ideological choice, but a historical fact: hierarchy, coordination, decision-making, operations, control, and debriefing existed long before computers, engines, and AI.

And yet, in the era of AI, a fundamental question arises: Does the emergence of smart technology require us to assume that everything is changing, that we must reinvent the human and the way decisions are made? Or should we look instead for the human structures that continue to exist even when the tools change?

In this post, I offer a starting point for thinking, designing, and building systems in the age of AI. Not only by focusing on what the next tool might be, but also by identifying the human structures that are likely to remain stable even through radical technological change, structures that shape how people understand interfaces and move through digital systems.

What Remains When Tools Change?

Tools change, but the essence need not. The horse was replaced by the car, the car by the drone. But the need to understand who directs action, who executes it, how outcomes are evaluated, and how to improve remains almost unchanged.

Humans have never operated on flat information. The way we understand the world is built from layers of context, order, belonging, and scale. We need to know where something belongs and how the part relates to the whole. When something is disconnected from its context, it loses meaning, even if it is accurate.

Throughout history, humans have tried to reduce cognitive load by organizing information into architectures and cognitive chunks, allowing them to process complexity and understand their place within a system. The human mind seeks structure: categories, groups, subgroups, and the distinction between rule and exception. The ability to zoom in on detail and zoom out to the broader picture is not an advanced feature but a basic condition for understanding. Fixing a bolt without understanding that it is part of an airplane creates action, but not a sense of meaning and control.

Yet each reduction of effort enables new layers of complexity, which in turn require new structures to hold them. A system that floods possibilities without structure does not feel smart; it feels exhausting.

We see this in design: in a recent digital onboarding exploration at Fiverr, we replaced a structured profile creation flow with a conversational experience. In theory, the conversational format felt smarter and more flexible, but in practice, it disrupted users’ sense of structure. Users consistently preferred the structured format, finding it clearer and easier to understand. AI was valued mainly when it reduced effort within the structured workflow, for example, by automating document uploads that saved users’ time. Much like physical onboarding processes, users expect visible stages and orientation within the flow. This raises questions about the growing trend to insert conversational interfaces into every AI experience, assuming that openness necessarily creates clarity.

Users don’t approach a system as a blank page. They bring years of lived experience with them.

Coordination has not disappeared either. Coordination between humans has always required shared language, clear signs, and timing. This was true in group hunting, in building cities, and it remains true in complex digital systems.

Human pain has hardly changed. Lack of clarity, lack of control, overwhelm, fear of mistakes, and loss of meaning. The root remains similar, even if the triggers have evolved, from fear of hunger, disease, and survival to fear of career loss, data exposure, and digital attention.
The interface changes, but the structure remains very similar to what it was decades and centuries ago.

There is almost always someone who decides, someone who executes, and someone who bears responsibility. This remains true in the military, the family, the tribe, society, and modern organizations. The tool can be an AI that recommends or executes, but decisions almost always seek a source of authority.

Learning, too, has not changed in its essence. People learn through repetition, imitation, mistakes, and feedback. This is how hunters, carpenters, pilots, and programmers learned. AI can streamline processes, but it does not eliminate the need for a gradual developmental path. Trust, then as now, is built through consistency, transparency, and the ability to understand why something happened. A system that does not allow such understanding breaks trust, even if it is very smart.

Many of the principles that guide digital interfaces are based on these real-world patterns. Cause and effect must be visible; actions require immediate feedback. Movement through a system must feel spatial and continuous, and rules must remain consistent, so users can predict outcomes rather than guess them.

The Real Challenge in the Era of AI

In a world of AI, the real challenge is not to reinvent the human. The challenge is to build smart systems that respect the layers of context through which humans understand the world. It is similar to claiming that a city cannot be planned because we don’t know if there will be cars in the future, instead of recognizing that people will always need to move, gather, transport, and understand where they are within the system.

True innovation is not measured by how far we have distanced ourselves from the past. It is measured by how well we managed to connect new technology to a human consciousness that has not changed at the same pace.

Historically, users have almost always asked for improvement within the existing model. Faster, easier, less friction, like asking for faster horses rather than imagining the car. They almost never ask to dismantle the hierarchy or replace the operational model. And this is not because they lack imagination or understanding; it is simply not their job. The user expresses a need within the framework they already understand.

Our role is different. Not just to ask what the user wants now, but to understand what fundamental need they are expressing, and then choose the tool, the structure, and the interaction that will answer it. This choice involves a conscious risk of being perceived as conservative or less radical. It is a choice to ensure that innovation remains deeply aligned
with human structure. Because at the end of the day, a system that does not understand these foundations simply will not work.

Where the Future Should Begin

Of course, even this could change one day. There is no law of nature that guarantees human structures will remain as they are forever. AI diffuses authority and blurs responsibility at a superhuman scale, possibly reshaping structures rather than replacing them. I do not underestimate technology’s ability to reshape human instincts over time. There were times when people believed no one would ever feel comfortable entering credit card details into a computer or creating relationships through a screen. And yet, both became normalized.

But when certain patterns hold for thousands of years, crossing cultures, technologies, and organizational forms, it is reasonable to assume they do not disappear all at once. My claim is not that everything is fixed. The claim is that when thinking about AI, the correct starting point is not only the tool itself, but the human needs and structures the tool must serve as it evolves.

There are foundational patterns that do not change easily. In fields such as war, planning, training, operations, and debriefing, we can see a clear continuity throughout history. There is always a process of decision-making, execution, control, and backward learning. The tools have changed dramatically, but the essence of the process has remained similar.

Take, for example, an operational debriefing: once, it was a commander sitting with soldiers around a campfire, trying to understand why the maneuver failed. Later, it was paper maps and aerial photographs. Today, AI systems can fuse data from a million sensors to reconstruct a battle in seconds.

The tool has changed from end to end, from the human memory of the soldier to computerized data processing. Still, the human structure of the debriefing remains the same: the need to understand what happened, why it happened, and how to improve tomorrow. AI did not abolish the debriefing; it simply made this old foundation much more powerful.

Therefore, in addition to trying to imagine the future, I am trying to understand what will likely remain and build the next experiences on that foundation. If we try to skip straight to solutions without understanding which human needs and structures remain stable, we will build systems that are broken, confusing, or dangerous.

Good UX does not teach users how the system works — it builds on how they already understand the world.

AI, Humans, and the Connection That Never Disappears was originally published in Fiverr Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

As data analysts, we have been increasingly leveraging AI to our benefit, from writing and ideation, all the way to coding and bug fixing. Recently, as a data analyst at Fiverr, I took a significant step forward by using AI IDEs like Cursor and Antigravity for entire analysis processes.
While this presented the opportunity to significantly speed up and improve our output, it disconnected the analyst from the process, leading to a wide range of issues.

In this article, I will discuss my AI journey to date, and the challenges & pitfalls I’ve come across when using these tools. I will also discuss how I’m overcoming these challenges, even if it’s still a work in progress.

AI Works Faster, but We Lose Control of the Process

Recently, I started using Cursor for the first time, and I immediately realized there was no way back.

No more need for writing queries, building Python scripts, grappling with Tableau to create charts, or “copy-pasting” images into long and ugly analysis documents. The agent does the process end-to-end, and all I would need is a (good) prompt.

At this point, I assumed that my main effort would go into validating the SQL queries. However, while that’s a must, it’s not the biggest issue.

After the first analysis I ran, it became obvious that there were bigger issues. In one case, I completed an analysis in approximately 5 hours instead of 1.5 weeks, but then spent days on fixes and methodology changes. This shouldn’t have happened.

So, let’s discuss the 2 main issues I encountered.

1. Although I defined the KPIs and the structure, I didn’t spend enough time thinking them through. The business question wasn’t polished, and the agent made its own decisions about how to implement it, when to use it, and how it was defined. This left me with an output that, even when accurate, gave little to no business value. In one case, I had a complex Conversion metric, and I didn’t even realize how complex it was until the end. The agent didn’t make good calls.
2. I was disconnected from the process. I had no idea what the agent did along the way, and to change things later was extremely time-consuming and ineffective. This also made verification of the SQL difficult, as it was extremely long, and validating a complex query I didn’t write is very time-consuming.

The attempted fix

I realized I needed to spend more time on planning.

If you’ve already used Cursor, here comes the “plan” mode. The agent doesn’t start working. You put in a prompt, it creates a plan, asks clarifying questions, and only once all is good do we click “build,” and off it goes.

Sounds good, right?

No. This simply didn’t work. In fact, it made things worse.

I was also giving the planning over to AI, not using the contextual knowledge I have, not asking the right questions, and honestly, it’s easy to just scan the plan and say “ya, that looks great”. This meant I was even less involved than before, and the output, while pretty and breathtaking, had very little business impact.

The Blueprint to an Analysis — The 5 Steps Before Agents

I realized I need to take a step back, figure out exactly what the stakeholders need, how I think it should be achieved, and create a proper plan. This was always essential as analysts, but we could get away with “winging it” when we controlled the entire process. No more.

I created a phased plan that I would need to go through before even touching an AI agent for execution.

If I thought this process was small, it was not. After a few attempts at different analyses, I realized this was where the analyst’s main effort should be.

Step 1 — Stakeholder ideation & challenging

When an analysis was needed, I had to first sit down with the stakeholders and ask them to explain exactly what they wanted. Why did they need this? What did they expect to get? Was this question going to get us there? This was an open discussion.

Step 2 — Definitions & KPIs

I needed to decide which KPIs I needed for this analysis and which definitions would help me answer the questions. If, for example, I wanted to measure Revenue and Conversion Rate, how would those be defined? What timeframe was relevant? What population did I want? Were there any dimensions that were a must? Which statistical tests did I want or need?

Step 3 — Planning the scope of the analysis and E2E framework

In any analysis, it’s easy to get lost. This is especially true when technical limitations have been lifted. The agent can run anything I want.

I realized I needed to create an outline of what we were looking at, the steps I wanted, and the stages at which I wanted to pause to review what we had. Additionally, I needed to decide how I expected the analysis to be done. What parts are SQL, and what was done in Python? How did I want the final product to be presented?

There was no right or wrong answer to these questions — it was simply about knowing what I wanted, who I needed to present this to, and what was best for each specific scenario.

Step 4 — Define the structure of the analysis doc

Even if I ended up making the insights myself, I realized I wanted the file to “look good”, and AI could do that for me. But the same data and insights could be presented in many different ways. I needed to decide what story I was trying to tell, and how I wanted it told. Did I want to open with the opportunity found? With the challenges? The current state? This was flexible and didn’t need to happen so early on, but it would save plenty of time later.

Step 5 — Review and document

Once I had the entire structure and plan, I put all the information in a document and had the agent read it. I had to make final reviews, send them to stakeholders for feedback, and yes, even ask an LLM to improve the document for me.

Once I completed these steps properly, I referenced this file to the agent in build mode, clarified that it should stick to the plan, and asked the agent to bring up any potential issues.

My next analysis took a few hours, and I still needed to validate the queries and make a few changes.

But that was it.

The analysis answered exactly what we needed. It was scalable, easy to read, and there was no need for endless back and forth.

There Are Many Ways to Plan — Not Planning Isn’t One of Them

This system isn’t foolproof and might not work for everyone. You need to find what works for you. But, for a good output, although it takes time, it’s time well spent. As analysts, planning is really where our analytical thinking, contextual knowledge, and insights really shine.

Things will evolve, and tech will improve, but at least for now, analysts are still needed, maybe more than ever before. There are tools that hallucinate, make up facts to please stakeholders. This makes our expertise and knowledge even more important. Without it, we won’t be able to add value and drive data-driven decision-making.

Why Great AI Analysis Starts With Planning, Not Prompting was originally published in Fiverr Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

In a world where security breaches are repeatedly discovered, running critical production workloads on EC2 instances has become a significant business concern. But what if you could update the servers with the latest security patches and eliminate those system downtime headaches with cluster-aware patching automation? Here’s how we built it into Fiverr’s infrastructure

Base Point

At Fiverr, we use Terraform to provision an EC2 ASG that deploys the instances.

We grouped our EC2 instances into three types of workloads, Because each workload had different requirements, we couldn’t use a one-size-fits-all patching flow.

Each group will get a different approach to the patching process.

1. Clusters: MongoDB, Elasticsearch, Tableau, etc. Nodes are aware of each other and need to be in sync, elect a primary node, etc.
2. Standalone applications with redundancy by a load balancer Nodes are unaware of other nodes, and each one can be handled independently
3. Stateless server & non-production instances, not a critical application: can be rebooted and reinstalled at any time

Exploring Ideas

We started by looking for tools that could simplify the process, given that each has its own strengths and weaknesses, which I will detail in this article.

With the awareness that we had to combine multiple solutions, we looked into:

• AWS SSM patch manager — native AWS solution
• Kubernetes Migration — A relevant DevOps strategy that can be gained as “quick wins” for several workloads.
• In-house scripts (no reporting and continuous monitoring for compliance)

AWS Patch Manager:

Pros:

• Scans the servers automatically as long as you have the SSM agent installed.
• Creates reports and submits them to AWS Security Hub for audits to review. Can save time on yearly compliance audits
• Allows you to customise the patches and approve/deny specific patches in case of misalignment with the applications running on the servers
• PRE/POST patch actions

Cons:

• Doesn’t support third party application updates
• Backup and rollback (but can be achieved with pre/post scripts)
• Orchestrating a workflow for a cluster is cumbersome
• Harder to integrate into our IAC pipelines

Ansible:

Pros:

• Great orchestration capabilities
• Fine-grained grouping and application awareness flows
• You can write the code to run anything you like
• We already use it, and we have roles to update Git or reinstall the instance

Cons:

• It’s not a security or patching tool, and will require manual maintenance for patches or using additional third-party tools.
• Reporting and compliance will require in-house coding and integration with other tools.

Golden image approach

Our approach is to patch the AMIs and update the ASG launch template. Patching running machines keeps the AMI out of date and vulnerable, in addition when applying patches at boot takes time and that time will grow with time as more patches need to be installed.

Patching the AMI makes sure our instances are aligned with the patch baseline, and no need to add patch installation to the boot process.

Reliable Patch Flow

As both tools lack the ability to provide a full solution, we decided to combine the two.

AWS SSM Patch Manager will be responsible for monitoring the missing security patches and providing compliance reports.

Ansible will be responsible for orchestrating and testing the application failover.

Let’s dive into it:

1. Scheduled automation with AWS Patch Manager — Ansible runs at a scheduled time for each AMI. It checks the AWS SSMs compliance report and determines whether security patches are missing. If none are needed, the process is done.
2. Updating AMIs using GitOps methodology — If patches have to be installed, Ansible will get the AMI from Terraform in GitHub, launch an instance from that AMI in a staging subnet, apply security patches, and create a new AMI.
   Once the new AMI is ready to be deployed, Ansible updates Terraform in GitHub with the new patched AMI.
3. Maintenance window and approval — we’re using Env0 to control our infrastructure deployment. When the AMI patch is done a DevOps is making sure that Terraform was updated correctly. After confirmation, the second Ansible phase proceeds to its second phase.
4. Automation second phase — Ansible workflow splits into multiple runs to handle each cluster individually. Each application is handled differently. For MongoDB, we need to determine which node is primary and ensure that all nodes are healthy, for ElasticSearch, there is no master node, and we need to repeatedly verify that the whole cluster is healthy. It is crucial that no downtime will occur.
5. Stateful applications — When updating clustered applications such as MongoDB, Ansible is performing a rolling update on the cluster and verifying the cluster and node healths after each node replacement, saving the primary node to be the last one to be replaced. Each node has to be verified that it was fully joined to the cluster, and on the other hand, every old replica has to be removed gracefully, without leaving traces.
6. Stateless Applications — Stateless applications such as bastion hosts or API gateways, are handled pretty straightforwardly. We simply deploy a new instance, verify its health, and then terminate the older ones. This “easy win” is possible because these instances don’t have frequent data changes on their local volumes.

Achievements:

Following several months of development, we have achieved the following successes:

Secure Environment — Daily scans for new patches provide good visibility and compliance reporting.

When an instance needs to get the latest security updates, Ansible can run and create a new AMI without interfering with the production servers.

New instances (with the patched AMI) will launch and replace the old instances at the next maintenance window of each cluster

Compliance — AWS Patch Manager provides a default patch baseline that usually includes only critical security updates

To make sure servers are compliant, we can create a custom patch baseline. This way, we can decide which updates to install and comply with our company’s specific requirements and needs.

Resiliency (Bonus) — With this approach, configuration management code must be up to date and work correctly.

After fixing all issues found due to configuration drifts, etc, we can handle HW crashes, instance terminations, etc, with more confidence.

Conclusion

Installing patches on our environment might seem like just another routine task that we do regularly to keep our environment fresh with new tools, but under the surface it drives broader processes. While at first glance we just installed patches on our machine, on a deeper level we mapped all our services and understood which ones can be upgraded from its legacy technologies. In some cases we upgraded machines from their legacy Ubuntu versions to latest versions (this was also important because patches are not being released in the same phase for legacy operating systems compared to the latest versions).

We postponed these upgrades for a long time because we weren’t certain how the company’s legacy systems would respond to these changes, and had to test and research it before deploying. We found many services that could be migrated from its outdated configuration into Kubernetes pods, which not only better control the patch updates but also provide improved availability and performance. In the end, installing a patch manager on our system wasn’t just to maintain our systems, but also reclaiming control over our infrastructure.

Bulletproof Patching for Highly Available AWS Systems was originally published in Fiverr Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

How we rebuilt Fiverr’s Design System

In an industry that evolves every day, design systems play a crucial role in ensuring consistency, velocity, and quality. But building one, especially within a fast-moving organization, is not a small task.

About three years ago, the Raptors team was created with a main goal — to lead the design system of Fiverr. The entire team (TL + two developers) was involved in the brainstorming process to select a new styling solution, which would serve as the foundation of the design system.

After reaching a styling solution that was agreed upon by R&D, along with the successful POCs using our new styling solution, we had the freedom to bring our vision to life.

In this article, I’ll try to tell you the story of Penta — Fiverr’s Design System, along with our starting point, tech considerations along the way, and how Penta became a key product in our R&D.

What is a design system?

A design system is a collection of components and guidelines, implemented in design and code libraries, for creating products within organizations.

Existing (old) design system

We started the process with an existing design system, on both design and code, which includes the following:

• A set of utility classes that can be reused to avoid duplicating CSS
• A bunch of UI components that were created by different developers in the Org
• Supporting CSS / SCSS / CSS modules for writing custom CSS by us or by the R&D teams

The Problems with the old Penta

• Lack of consistency and standards: The UI components were built through the contributions of different teams, and it showed — Penta felt more like a collection of components and utilities, rather than a cohesive product. It lacked the underlying structure, relationships between components, and a clear guiding framework to steer development.
• Lack of responsiveness and selectors support — The utility classes were limited since they did not support responsive design or selectors (hover, active, etc). While most Fiverr experiences are designed to be mobile-friendly, they often require a significant amount of custom CSS written by developers.
• Limited flexibility — The design system components were not flexible enough to our standards. For every small change on the design side, we had to develop a new feature for the relevant component, which created a bottleneck in every project.
• Too many styling solutions in use — CSS / SCSS / CSS modules for custom CSS and our utility classes — resulting in four different ways to do the same thing, writing styles.

Our journey

Picking a styling solution

Our first goal was to determine a robust styling solution that would serve as the foundation of the new design system, addressing existing problems and integrating seamlessly into our existing infrastructure.

We investigated various alternatives, including Tailwind, Stitches, and Vanilla Extract, among others, while utilizing Shopify’s research, which also considered rewriting their design system foundation on the same day.
We needed something flexible, stable and SSR-compatible that can serve both the

Design system code and Product teams code and willing to solve the problems we had with our old design system.

After the investigation, we came up with two alternatives:

• Tailwind — very popular framework (88k git stars while writing this post)
• Vanilla Extract — less popular framework (10k git stars), but more powerful, especially for building a design system.

We chose Vanilla Extract which is less popular in the community compared to TW. This was because , we found that TW loses some of its core advantages when applied to design systems or in the context of large and complex applications (like the JIT compiler and styles readability; this article explains it pretty well). And we found that Vanilla Extract covers our needs:

• CSS compiled in build time — same as we did so far on our architecture, and supporting SSR (server-side rendering)
• Provides flexibility in defining a token-based API
• Supporting conditions (responsiveness, selectors) out of the box with full control
• With some extra setup, it allows for integration into our complex architecture — the decoupling of Layout service (header, footer etc) vs. Perseus (Fiverr microfrontend) makes our architecture not trivial.
• Provides a flexible API for writing custom CSS — our goal was to have 90% of CSS written using our CSS boilerplate, allowing freedom where needed.
• Stylesheet in typescript — a nice bonus
• The author of vanilla-extract is Mark Delglish, who has a high reputation and built “CSS Modules” with great success.

As for implementation, we chose the well-known pattern of a Box component, which serves as the base of every React component and supports all necessary CSS attributes as props. The props are divided into three types:

• Atomic props — props that are supporting a close set of values, either props that are restricted for design purposes, like fonts, borders, spacings, colors, etc, or regular CSS attributes with closed sets of values like display, position, etc.
• Dynamic props — supporting any valid CSS value — props with unlimited or very large amounts of options — dimensions (width, height, etc), positions (top, right, bottom, left), flex, flexBasis, etc.
• Native props — HTML attributes like id, className, etc.

While we had to decide which CSS selectors are supported by every prop to optimize the generated CSS chunk, either supporting responsiveness or other selectors (hover, focus, etc).

As part of this, we worked closely with the design team to define the foundation layer tokens, which align with the design team’s patterns and requirements, including fonts, color palette, spacing, borders, and more.

The main technical obstacle of the initial integration of the styling solution was to reach a reasonable CSS bundle size (our goal was less than 10kb — the size of old Penta utility classes), given our goal of 90% of CSS using our boilerplate while still providing full flexibility for the R&D.

We have managed to reach our goals by deeply understanding our design patterns, gathering feedback from our customers, fine-tuning between dynamic props to atomic props, and specifying the common CSS selectors supported on each prop.

Building the new design system

After implementing the styling solution and foundation layer, we started building the layout and typography components:

1. Layout — Card, Stack, Grid, Container, AspectRatio etc

• We researched and defined the core patterns we are using, and established a set of layout components that cover most of the use-cases.
• Each component has strong defaults and a variety of options that are derived from the most common design patterns.

2. Typography — Heading, Text, Link

• We defined, along with design, the font families, colors and sizes we would like to allow, and created few components for that purpose.

At this phase, we could develop any UI component on top of the existing building blocks. And started to rebuild the old Penta components one by one, in parallel to the addition of new components to support the product needs:

• For Core components — like buttons, popovers, inputs, etc. — we aligned them with today’s design patterns and ensured high-quality components
• For complex components, such as modals and dropdowns, we focused on providing a flexible API that will not require changes with every new requirement. We did that by utilizing a compound components approach (read more)

During the refactoring of each component, we have considered design changes, supported animations and accessibility by design, and aligned to the current state of our product, while keeping in mind the potential evolution of Penta and our product.

That process required tight communication with the design team, creating Figma components that reflected the supported options by code, defining contribution workflows for designers, and enforcing adherence to the design system components and best practices.

POC & Adoption

After completing the core development, it was time to check our new design system in reality.

Our team had another ownership, the internal CMS services, allowing marketing teams to build landing pages with no code and utilize design system components. It was a great product for experimenting with our design system, as it was new and had not been developed yet, and it contained less sensitive pages — specifically, marketing pages that are not top of the funnel.

We have integrated the new Penta as the base of the CMS platform, which was a great success and stands as the core of the platform to this day.

After that, we reached the next phase of integrating the new design system into new products and features. At the same time, we had a new cross-org project — Fiverr Neo, which was a great opportunity to gather feedback from the R&D and prove the benefits of the new Penta.

It was another great success, with ~30 developers using our new Penta for the first time and implementing a large, fast-paced project. We gathered feedback from the devs post-project, and improved Penta accordingly.

We have proven our theory, seen how the design system serves our R&D in practice, reduced development time, and ensured a unified experience. Which took us to the next phase of pushing for adoption across the organization:

• Implementing the new Penta into every new project
• Migrating all legacy code to the new Penta

Where are we today?

1. Penta became the exclusive library for developing UI components, every new project or feature is using Penta, and many of Fiverr products have been migrated already, and keep going.
2. Component Coverage — Penta includes all the components from the deprecated old design system and way beyond that, with components working together in harmony.
3. We are getting great feedback from the R&D developers about the new Penta and styling solution. They are engaged in the development processes, raising the design gaps they have and contributing significantly to the Penta codebase.
4. Monitoring CSS usage — every custom CSS rule being added by the R&D teams (not using our CSS boilerplate) is being reviewed by the FE guild, it has few benefits:

• Guide new developers about using Penta and our best practices
• Address common patterns that are not covered by the css boilerplate
• Ensure we are not deviating from the goal of 90% of CSS using our boilerplate.

5. Tightening design-dev handoff processes, to ensure full coverage by Penta in the first place and build the ground for implementing designs by AI agents.

What’s next?

Leveraging AI to speed up our development processes:

• Implementing Figma designs by AI using Penta components
• Refactoring of legacy code to Penta by AI
• Maintaining the design system foundation and components by AI and Figma Webhooks

How we overcame obstacles while still supporting scale

We had a few bumps along the way, but we overcame each of them:

1. A small team with laser focus on priorities — We were a relatively small team, and had to develop both Penta and CMS products from scratch in a short period

1.1 Focus on priority — always work on the most important task, which enables other tasks to be completed.

1.2 Define a contribution model when a ticket arrives (by external devs)

• Understand if the new design/feature is needed and we do not have existing patterns that fit the case, by Penta Design Lead.
• When requirements are clear and align with the design vision, the developers can contribute the new components/features to Penta.
• When requirements are unique or the use-cases are not clear enough or not defined yet by design, suggest the developer to implement as a custom component, which later on can be converted to a design system component.

2. Development processes disruption due to an innovative styling solution — as the solution proposed a new way of writing styles (CSS), it requires a learning curve and a change in the state of mind when writing styles

2.1 Engage the R&D team — we’ve introduced a new approach of writing styles, a day to day task assigned to every FE developer.

• Tech design review, which demonstrates the benefits of the new system on different aspects like Performance, Development Velocity, and Adaptivity
• Feedback sessions and workshops
• Documentation — a key factor of success

2.2 Overcome the CSS Bundle size issue by keeping the total CSS size at ~10kb (gzipped and minified), the same as the CSS size shipped with the old design system.

3. Defining workflows and cutting dev-design friction — the contribution model as described above comes to manage it, but making it a success is not easy. It requires active participation in every design discussion where the phrase “Penta doesn’t support this” comes up. To be involved in these talks, your customers (developers & designers) need to be engaged in the process, they must see that Penta helps them. Otherwise, when something does not fit, they’ll simply implement the component either by design or code by themselves without informing us — and that defeats the purpose of having a design system.

Takeaways

For Developers -

• Strong foundation, best practices and repeated patterns, makes your design system consistent, easy to expand and easy to use.
• Using a compound components approach allows implementing flexible and versatile components while keeping the API simple.
• Vanilla extract library is underestimated, especially for building a design system.

For Organizations -

• When your product and R&D size scale up, a design system becomes essential — the boost in development velocity it provides outweighs the cost of maintaining it.
• Creating a design system starting in the design department. Every component should be implemented in both design and code, with the contribution process beginning at the design stage.
• Clear documentation, gradual adoption, and continuous feedback loops are essential when introducing significant changes to a developer’s daily workflow. These elements helped us build a design system that developers actually want to use.

The Journey of Penta was originally published in Fiverr Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

With the emerging AI revolution, tech companies are looking for different ways to quickly adopt and find winning strategies. These solutions usually need to be delivered fast, and we, as engineering managers, need to make it happen.

I was given the task of leading a project that redefined our processes and R&D culture. The project, Fiverr Go, is an open platform for personalized AI tools. Its goal is simply to help freelancers scale their businesses, enhance their productivity, and retain full control over their creative identity in the era of AI.

In this article, I will share the managerial challenges and the adjustments made to make this never-before-seen project possible. How we completely changed our working mode, how we doubled our efficiency using AI development tools, and how we found certainty in the unknown.

Background

Let’s start by breaking it down — what are the challenges we usually face as tech managers while leading big projects? I would like to give an example from real life, specifically in competitive sport.

As sports fans, we usually look at the players and judge their performance — why they did that play, how they can improve in the next game, and how bad their coach is. But let’s think about the coach for a sec. He not only manages the players, but he also needs to control every aspect of the team’s game strategy, training sessions, player development, motivation, player roles, fitness, external communication, and other staff managers. Usually, a coach must adopt most of these aspects between every other game to succeed.

Back to our ‘sport’ team, when we manage big projects, we have to act as coaches — collect the right engineers, set clear ownership, develop communication skills, understand the requirements, see the big picture, set deadlines, and build the right processes. We should be in control of shifting and changing what’s not working.

Taking Control of The Unknowns

When I first heard about Fiverr Go, the vision was clear, but not the product, and definitely not the design. I knew it was something big, not something we could face in regular, day-to-day work. That’s when I had to flex the most important muscle: dealing with the unknown. Understanding the next steps was critical, as the deadline was already set (2.5 months from that point).

So, the first action was building the right team from what we knew — we figured out it was going to be a 30–40 developer effort, and we had to kick off the brainstorming phase. Our goal was to visualize what we knew, and with the project’s leaders, we stopped everything we did and took two full days to focus and think differently.

Looking back, that was the cornerstone of the project’s success.

We ended up with clear team ownership, some new teams were formed, and a high-level Gantt was in our hands. This timeline visualization always provided clarity within uncertainty. Try it; it is a confidence booster.

Without getting into the implementation phase, being organized was key in such an unclear situation. Just like making your bed in the morning gives you confidence (try it, it really does), so does setting up your Gantt chart, document processes, listing the project resources, or any other data visualizations. It will make it easier for you to control the situation.

Turning On Startup Mode

From this point, and with the short timeline we had, we knew it was time to take risks — and fast. Whether it’s technical decisions like Kafka vs. SQS or choosing a half-baked product to implement while hoping it won’t change, each decision was made with a clear understanding that it would probably need to change later on, just like the early days of any startup. Taking risks is part of the game; of course, you need some luck to go with you.

Companies like us, with 15 years of experience and mature infrastructure, can not turn into startups overnight. We have our own history. And then, right when we thought we were starting to figure it out, we had to face another big challenge that was new to us all — adding a non-Fiverr engineering team to our project. Their goal was to bring AI magic and create what we called ‘the brain’ of Fiverr Go.

Integrating a non-Fiverr codebase into a 15-year-old infrastructure is a real challenge. How can the different microservices communicate? How can we share data? How can we quickly onboard the engineers to Fiverr’s workflow?

For this, we decided to take an existing Fiverr engineering team that will wrap the brain’s services and communication. We decided to keep the problem small, having only one team that would bridge the gaps. The idea was that for the majority of the project teams, everything would work just as they know it.

This decision was actually fast, even though it was mainly a hunch, and yet was backed by the full technical requirements. There were a lot of other voices, obviously, but in such complex projects, when you have so many things to face and solve, you should count on yourself and take such decisions fast and with confidence.

The Shift to a New Way of Working

As time went by, and as we couldn’t catch up with the upcoming deadline, we knew we had to speed up the development phase. Our thinking was on how to remove blockers or time-consuming aspects that hurt our velocity within our daily routines. We deep-dived into the processes that were actually the root cause of our culture’s success over the years.

For this, we started to break down the big problem into smaller, manageable issues. We listed together our current development cycle and one by one, we came up with a DIFFERENT process, changing what we used to do for so many years. This is where flexibility matters. We came up with a new operation mode:

• Decisions should be made quickly, and the results documented clearly and concisely for the sake of transparency.
• The number of meetings should be minimized; our time is precious.
• Direct communication with zero wait time should be promoted (no Slack or WhatsApp)
• SCRUM processes and other ceremonies were removed entirely.
• Selected engineers were given the freedom to skip code reviews when possible, in specific areas.

Oh, and yes, we leveraged AI-driven development. We adopted Cursor and took a risk, as it was the early days of this amazing service. We had to find a way to code faster. Retrospectively, we identified that the engineers who used Cursor wrote 50% less code, which made this move a game changer!

With all the challenges, stress, unknowns, and culture changes, the one thing you can not do is forget your employees — in our case, the engineers. Executing at such a high cadence for a relatively long period of time can have a negative impact.

To prevent that, and with the backing of management, we took many actions and took care of the surroundings of the employees ‘ accommodation, transportation, food, and fun nights to enjoy it all. After all, the people are the most valuable asset we have.

Communication

As the project progressed, we accumulated more and more engineers to compensate for the time that was missing. If you asked how many, around 50 engineers, similar to a growing startup.

Fiverr Go was not just another project but a company vision that was directly led by the Fiverr CEO. My biggest challenge was controlling every day of the project, from reporting to management what would be on time to what we needed to postpone. At the same time, I had to support my engineering team and leaders, working together to make technical decisions.

Every day, we ended up with a management meeting (just like the team’s daily meeting, but at night 🙂) to make decisions for the next few days. Being transparent and communicating our situation to the team was key to ensuring the project’s velocity would not be hurt. I would add that what helped me was simply being available — whether it’s for a product or tech question, HR arrangement, or marketing. I felt like these were quick wins for the projects.

Conclusion

As you can see, my experience was, for the most part, positive, and I hope I helped you organize your management style. Obviously, we should always remember that with these types of projects, bad decisions will also be made. Some of them will have a larger impact after the release date, but that’s totally fine. Nothing is perfect. It’s part of the process.

You should always remember your main goal, what you can change to meet your deadlines, and what you can fix later.

How We Rethought Culture While Facing the Unknown was originally published in Fiverr Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.