Buzzpot is a canvas for coding agents. Every task you hand to Claude Code, Codex, or Grok sits as a card on a single canvas. You can see who's working on what, what's done, and what depends on what. Across several projects at once, locally and privately. The video at the end of this post shows all of this much better than I can describe it.

I built it for myself. At some point I had a pile of terminal tabs open across all my projects, and I kept losing time trying to remember which agent was doing what and where it had stopped. I'd forget what was already done and what to do next. Now I open the canvas and within a minute I know what's going on. The longer version of that story is in How Buzzpot came to be.

Fun fact: I built Buzzpot inside Buzzpot (recursion, yes). And about three weeks in, I broke it badly. While I spent several days fixing it, I had to move back to the terminal. It hurt, and I was very happy to return to my canvas :)

It's a beta, so to be honest: branches and worktrees sometimes stumble, remote access from the phone is rough, and there are plenty of places in the interface where you have to guess. I'm fixing things as fast as I can. On the upside, it's free until the end of January. After that it becomes paid: a one-time purchase, with an optional renewal if you want updates for the following year. Without the renewal it keeps working just as it did.

It runs on macOS, and you need your own Claude, Codex, or Grok subscription. Buzzpot runs their CLIs, it doesn't replace them.

You can download it at buzzpot.app. I'm building this solo, and feedback would help me a lot right now: bugs, ideas, "I have no idea what I'm supposed to do here". Email me at skorobogatkonn@gmail.com or open an issue straight from the app. I read and reply to everything myself.

That's it. Hugs to everyone, back to building.

–

Until roughly the end of last year, yes, you did. I still remember building prototypes at Yandex Games in mid-2025, when I was still telling the LLM which JS functions to write and how to fix the CSS. But between October and December, Anthropic and OpenAI released models that are so good that looking at, reading and understanding code became completely unnecessary. And when I say "completely," I really mean it.

Today, the vast majority of developers on the vast majority of projects program in English. Not in Python or TypeScript, but in plain human language. Of course, there are corner cases and nuances. But even there, what matters is deep knowledge of the product, not writing code by hand. If you can frame the task and explain those nuances to the model, it will very likely handle it without you.

What you need instead of code

Understanding the logic is enough. Understanding architecture and testing is highly desirable. Or at least use skills that tell the model HOW it should work.

Your job is to describe the properties of the system: what it's made of and how it works. In case A, the product does B, and that must always hold. The product's logic must match your own product logic.

If the code is covered by tests and does what you intended, but some corner case was missed, it will surface and get fixed. If anyone hopes to write bug-free code, I have bad news for them: bug-free code doesn't exist. Reading code doesn't protect you from bugs. Tests and fixes do.

What it takes to build a product

1. Know what you're building. Or be ready to walk this path for a long time, figuring things out and correcting course as you go.
2. Be able to describe the product. How it should look and work. What rules it follows. Be prepared to write or talk a lot. A. Lot. All the code the model writes comes from your description.
3. Understand the architecture. Backend, frontend, database, how they connect and how it all gets deployed to the server. Which external services you depend on: payments, cloud, email.
4. The bigger the product, the deeper the layer. What objects and modules make up the backend and frontend, where the sources of truth live, how to test it all properly. You need this so the model doesn't invent a new solution every time in key parts of the product, doesn't spawn new data stores that later drift apart, and covers all cases with tests, not just the ones that came to mind. Otherwise, as the product grows, everything starts falling apart.
5. Documentation the model maintains itself. The model reads code brilliantly, but it doesn't know about past decisions, sources of truth or object boundaries. That isn't always visible in the code, so it needs to live in documentation. Then the model knows where to look. By default, models write documentation for themselves, in technical language. I ask the model to keep a separate, up-to-date file describing the architecture in plain words, at the level of a product manager or designer.

Notice: none of these points says "read the code," "debug" or "figure out how it works."

You don't need to know everything above right away. If you're building something big enough, you'll run into all of it yourself and realize what you're missing. That said, understanding it up front will save you a lot of time along the way. That's why developers have a huge advantage here: they know what a well-built system looks like.

What about design?

This is trickier: models see design only through the abstraction of code. But they already handle it surprisingly well, especially with a ready-made design system. In almost all my projects I use shadcn as the foundation: it scales well and looks good. If design isn't your strength, or you just want to save time, try Claude Design. Given an existing structure and a couple of finished screens, it builds new ones quickly and neatly. Provided, of course, that you describe exactly what you want. Ideally in full detail.

But in design, taste and empathy for the user are what matter, and designers have an obvious advantage here. The code inside can be ugly and still work, and no one will ever see it. But everyone sees the landing page and the interface. People judge a book by its cover, and the audience's standards here are very high. Develop your taste, look at good design. Developing taste and making good design with an LLM is much faster than learning to make the same design with your own hands. It doesn't take years of practice.

Bottom line

Try building. Become the Builders of your own products, or of the products you work on. To me, this already looks like a pretty obvious future.

A few months from now, this post may well be completely outdated. New models will come out that are smarter and more autonomous. You won't need to think about the system's internals even at the level of architecture and details. It will be enough to understand how it should work and what problems it should solve. Only your product vision and your drive to build it will matter.

The product trio is giving way to the product solo.

–

The sun is shining, birds are singing, rainbows are pouring from the sky and unicorns are frolicking on the lawn outside my window. Something like that, anyway.

Problem 1. Too many chats to keep track of

At first, while I was working on Leaflo and Plainline (a couple of my products), that's exactly how it went. I'd open VSCode, start a task, and watch, mesmerized, as Claude's or Codex's spinners spun and the chat spat out chunks of code and lines of text.

But after a while the magic started to fade. I realized that instead of endlessly staring at a running chat, I could be doing other things. And being a chronic overachiever, I didn't use that time to rest. I used it to prepare the next tasks for the LLM.

After the first task, I'd start writing a second, then a third, because waiting for one to finish could take a long time. Half an hour, an hour, two. Eventually I had so many tasks that a queue formed.

Let me be clear: the speed of LLMs doesn't bother me (almost). Even the slowest one writes code faster and better than I do. What bothered me was something else. I could have run 2–3 chats in parallel, but there was no convenient tool to monitor tasks and switch between them. No notifications when work was done or when the chat had a question, either.

On top of my main project, side tasks kept popping up: tweaks to skills, other pet projects, research. By evening I'd have 3–4 VSCode windows open, 2–5 chats in each, and a mini ADHD attack from jumping between them.

Problem 2. No way to run chats in the right order

When I had 3–5 tasks ready to go one after another, I had to track the queue by hand: what finishes when, and what to start next. This matters, because some tasks assume the previous one's functionality is already in place.

I had to keep all of it in my head. Turns out my head isn't really built for that. So I tried a different strategy: ignore the queue and launch everything at once.

Problem 3. Parallel work is hard

First I tried branches. You can probably guess what happened next. The agents pulled branches out from under each other, put code in the wrong places, and it all turned into chaos very quickly.

It was even worse than working in a single repository. There, at least, the agents could get work done. They just kept losing their rhythm: they had to watch for other agents' edits and then commit their own changes without touching anyone else's. That's how I first learned what committing hunks means.

Problem 4. Working at night

Five-hour limits are a story of their own. Yes, Claude, I'm looking right at you.

I start work around 10 a.m. That means limits reset at 3 p.m., then 8 p.m., and then at 2 a.m.! Of course I don't stay up until 2 a.m. And that's a shame, because Claude could be working through the night. After all, nobody's protecting models' working hours.

Enter Buzzpot

At some point I realized I needed a tool that would solve these problems. So, out of curiosity and a love of optimization, a project codenamed Topic was born. It's now called Buzzpot.

In short, it's a canvas with agents. You create a project card and add the folders you need. Then you add task cards and arrange them into the chain you want. Tasks run automatically from Start to Done, and then the next one kicks off.

You control the sequence, and which providers and models each task uses. For example, Claude Fable writes the plan and GLM or Grok does the implementation. That makes sense now that subscription limits from the big providers shrink by the day and there are good, affordable executors out there.

You can also run tasks in parallel. In auto-integration mode, each card creates its own separate tree where the agent works safely on its own, then merges the results back into the main track.

You don't have to lay tasks out on the canvas by hand. We're not cavemen. I almost never do it myself. Buzzpot has an MCP you can enable in any card, and the agent will lay out the tasks for you.

Since then, Claude and the other providers can burn through their compute and drain my wallet practically around the clock. And once tasks start automatically after a limit reset (I haven't gotten around to it yet), it'll be even more efficient.

The product itself is a local desktop app, Mac-only for now. Alongside it, I'm working on a mobile web version of the canvas. You know the feeling: you give the LLM a task, head out for lunch or to the store, come back, and the agent has been waiting two hours for an answer to a question. Meh. At first, the mobile web version will cover the basics: replying to an agent, starting something, reacting somehow. Later I plan to add much broader remote control of the canvas.

The product won't be free. Even though every other person is vibe-coding apps these days, it's not as simple as it looks at first glance, and there's a lot of machinery under the hood.

What my day looks like now

My mornings still start with coffee. I keep all my tasks in GitHub Issues. I have prompts that, with a single command, lay out the tasks that are ready for development, or ready for research and spec writing, on the canvas. Then I start the first one, and everything else comes down to answering questions and checking statuses. I just glance at the canvas every 30–60 minutes and get back to other work.

I've been using Buzzpot myself for several weeks now and have no desire to switch back. That's probably a good sign.

Do you need this?

I asked myself the same question while building the landing page. If you do one task after another and you're happy with how things are, Buzzpot probably won't help you much. On one or two tasks, it works just as well as regular terminals.

But it might come in handy if:

• you have many projects or juggle a varying number of tasks;
• you want to run things in parallel and have intense LLM work sessions;
• you use several providers and want an easy way to manage them across tasks;
• you want to monitor and respond remotely.

Why a canvas

I'm a designer, and I've worked with canvases my whole life: Sketch, Figma, Miro, ComfyUI. So when the question came up of how to keep an eye on projects, agents and the connections between them, I immediately voted for a canvas. My vote won, since it was the only one.

Seriously though, I did consider lists and a kanban board. I've always loved kanban. I was one of the early adopters of the original, cozy Trello. But neither kanban nor lists let you quickly see how tasks are connected, where they branch off in parallel, where they merge, and in what order they'll run. That said, a kanban view for cards still appeals to me.

How it was built

I vibe-coded the first version in two or three days, and for a prototype it worked surprisingly well. From that, I drew the foolish conclusion that I could build a solid product in a month. Oh, how wrong I was.

In almost three months, I've gone through a couple of concepts and a major refactor, because I took the wrong architectural path. Originally, when the first card started, I locked the entire task graph. It seemed logical, but the system turned out to be fragile: any failure in any card blocked the whole flow. The codebase ballooned, and early on I'd neglected architectural oversight. In short, don't do this.

In the end, I changed the approach completely. Now only one card gets locked: when it starts, it creates its own worktree, and when it's done, it merges the result into the shared branch and cleans up after itself. This let me delete many thousands of lines of code and tests, and the logic boiled down to a manageable, easy-to-observe single-card cycle.

What's next

Right now the product is about 90% done. All that's left is the other 90%. But I decided not to wait and have already launched the landing page: buzzpot.app. Drop by and subscribe.

By the way, this time I decided not to hide that I'm building the product alone. Everyone tries to hide it and writes "we" instead of "I" on their product sites. I get it, it's a vulnerable position when it comes to trust. But first, I don't want to pretend, and second, I think we'll see more and more products made by one "I" rather than a "we". Simply because it's easier now.

P.S. For those following me (hi, Oleg and Tanya, my loyal subscribers): Plainline hasn't gone anywhere. It's alive and well, waiting for me to finally ship Buzzpot. And yes, I promise that next time I won't show up with yet another new product instead of progress on the current one. Probably :)

Cheers!

–

I'm doing a lot of indie development right now, so my costs are essentially token costs. Running every task on Sol High or Opus High stopped being an option.

For reviews and genuinely hard tasks, the answer is simple: use whatever your budget allows. I stay on Sol High or Opus High, and they crack something like 95% of what I throw at them.

Routine work is the harder question, because it needs a balance. The model has to be much cheaper than a big model at high effort, otherwise there's no point switching. But it can't be too dumb either — then it starts making mistakes even on small, decomposed pieces, creates more work for the reviewer, and wipes out the savings.

So I wanted a way to compare cost against quality instead of going on impressions. And not just across models — across providers, and across effort levels of the same model.

The internet is full of benchmark charts ranking models by intelligence. But when price is what you care about, the smartest kid on the block isn't the question. The ratio is.

That's how I ended up on Artificial Analysis. One chart there does what I need: Cost per Task against Intelligence, for coding agents specifically.

The numbers were more interesting than I expected. On the left is the average cost of completing a task for this model and effort, on the right is its level of intelligence:

• Luna Max — $1.51 · 57
• Terra High — $1.56 · 55
• Sol Low — $1.66 · 55
• Terra xHigh — $1.88 · 56
• Sol Medium — $2.81 · 62
• Sol High — $3.85 · 64

Terra turns out to be a useless middle. For roughly the same money you can take Luna Max, which is both slightly smarter and slightly cheaper, or move up to Sol Low. And Sol Low has an extra advantage if you already run Sol High on the hard tasks: switching models resets the cache, so every switch also costs you the savings on cached tokens.

There's one more number, though — how long a model takes to finish a task.

• Sol Low — 3.5 min per task
• Luna Max — 8 min per task

Here Sol Low wins outright, and everyone has to decide for themselves which they'd rather have: the couple of extra intelligence points, or the time back.

I've spent some time staring at these charts. It's the only way I've found so far to get a real sense of what the models can do and how to work with them.

I expect subagents will eventually pick models and effort levels themselves, faster and better than I can, and then none of this will matter. For now we read charts.

–

You may have never thought about this. That's fine. I thought about it for you.

The quick answer: of course, get the tool, your 3 hours are worth more. That's true. But only if you actually spend those three hours on something useful that creates additional value and pays back the investment.

But what if, say, you're an indie developer and you're not earning money yet? You only have potential income that can't be calculated. Or you do earn money, but instead of working you now spend those free three hours scrolling TikTok? Then that $20 just becomes an extra burden on your wallet and a reason to feed a brainrot video addiction :)

Add uncertainty on top of that. For example, potential losses if you invested your effort and time into setting up the tool, and it turned out not to be as useful and convenient as expected. Add constraints on both time and money — this is usually relevant for anyone doing things on their own.

It gets complicated.

For myself, I concluded this. The decision comes down to answering the question — do I feel better and am I getting closer to my goal? If the tool makes me more productive and I enjoy that, if it makes work more comfortable and life more pleasant — that's already reason enough to buy it.

–

I gave ChatGPT the same brief for both and let it write the code. Cavalry has scripting built right into a visual editor, so a rough cut lands fast. Remotion turns animation into React, HTML, CSS and JS, so every small change means writing and re-checking code — and that alone made it five times slower.

Video keeps mattering more for products: it sells, explains, documents. There's no obvious best tool for it yet, but between code-first and visual-first, I'm betting on a hybrid — html/css/js as the engine, a real visual editor on top.

–

The main organic channels are ASO, SEO, and social media. The main paid channels are advertising in all its forms and influencers.

Organic distribution is a long game.

You shouldn’t expect ASO to be some kind of magic button: results come gradually, and there may be no fireworks at all. The App Store doesn’t seem to give you any guaranteed launch boost either — at least I didn’t get one.

I’m still waiting to see any meaningful results from SEO. People usually talk in terms of months, often 4–6 months, before you can really start drawing conclusions.

Social media is a roulette game with a huge amount of testing. I haven’t won once yet, but I also don’t have much experience with it.

TikTok carousels turned out to be surprisingly interesting — for me, they get pretty decent reach compared with videos. Instagram has been the opposite so far: if you don’t have followers, carousels barely go anywhere, while videos at least get some exposure to new audiences.

Geography is another significant limitation. TikTok takes into account the country you’re posting from, your location, language, and other similar signals. If you’re sitting in Serbia but want your content to reach people in the US, doing that organically is noticeably harder. Or you can pay to boost the post. Maybe there are some gray-area ways around this that I don’t know about.

As for post boosts, my impression at this early stage is this: either you’re very talented and can consistently make content that the algorithm distributes on its own, or you pay for boosts. Otherwise, getting any meaningful reach is very difficult. I still haven’t figured out where exactly that talent threshold is — or maybe I just haven’t cracked it yet.

Threads didn’t work for me at all. Possibly because of the same locality issue. I haven’t tried Twitter/X yet; maybe it’s worth a shot.

With advertising, pricing tends to bring you back to product economics pretty quickly. If you want to consistently acquire users profitably, it helps to already have a proven business model and understand your unit economics. Especially in expensive markets like the US and EU.

The other option is to have enough funding to keep growing at a loss for a long time, but for a small business that’s usually not much of an option.

I haven’t tried influencers yet.

I haven’t launched on Product Hunt either. From what I’ve heard from people who have, it rarely changes the overall picture completely: you may get a nice short-term spike in traffic and downloads, and then things drop back to their usual level pretty quickly. But we’ll see.

Reddit is a real channel, but almost everyone recommends the same approach: go to communities where people have the problem you’re solving and simply help them. No self-promotion unless they specifically ask you to share more.

It hasn’t worked for me so far. Maybe there are niches where it works extremely well. Or maybe I’m simply doing something wrong.

My conclusion at this point is this: if you don’t already have your own distribution channel, don’t expect your app to somehow start getting reach on its own.

Especially if you’re in a highly competitive, crowded niche and your app isn’t so unusual that people naturally start spreading it for you.

Be prepared to dance on TikTok just to get at least some views and visits to your App Store page or landing page :)

Half joking, half not.

Have a good week. I’m off to dance.

–

I used to think of them as discipline for designers alone. But a structured layout also helps a language model. It does not have to guess what works and how.

When elements are positioned manually with coordinates, it is unclear what stretches, what keeps its size, and how blocks should rearrange. In a layout with auto layouts and grids, those rules are visible. As a result, the model makes fewer mistakes with sizes, line breaks, and responsiveness.

I only started working this way recently. The difference was too noticeable to consider structure in Figma optional.

–

It’s a tool that turns text into presentations and makes them easy to edit, without having to deal with a slide canvas.

I’ve briefly explained how it works on the landing page.

The product is about 80% complete. Its scope has grown quite a bit along the way, but I like where it’s heading.

If you often find yourself putting presentations together, join the waitlist.

–

We’re already moving fast, and AI is making us move even faster. That’s great, but I’ve noticed a problem in myself.

Sitting in Figma and working on a design for two or three hours straight has become difficult. Writing something entirely by myself has too.

When you can get a mediocre result almost instantly, it becomes tempting to accept it and move on. Then improving it starts to feel harder and harder. Your quality bar drops. The effort required begins to seem disproportionate.

And just like that, you’re a shit maker.

With AI, the ratio between effort and output really is incredible. But that doesn’t mean the output itself is incredible.

I’m learning to slow down because I’m not as fast as AI. I need time to think. Sometimes a full day to make a design in Figma. Or an hour to formulate a post like this by hand.

To preserve taste, quality, and authenticity.

Try slowing down.

–

I do not think this is because the result is necessarily bad. AI has simply become a signal that little effort went into the work. And if the author did not spend time on it, why should the reader?

–

That does not mean fixing everything at once. Improvements can be made gradually, based on impact, urgency, and cost.

–

According to benchmarks, it comes close to the leaders across many tasks. But it does not have to be the best. It only needs to be good enough that users always have an alternative, and that OpenAI and Anthropic have a reason not to raise prices or make their products worse.

–

I think it is impossible to treat a product as your own if you have never tried to build your own product. It changes how you look at everything. So if you want to better understand product responsibility, I would suggest not reading another article, but building your own project of any size.

The difference becomes clear quickly.

–

I gave AI the positioning framework from April Dunford’s book "Obviously Awesome" and asked it to interview me about Leaflo.

I knew Leaflo should be a CBT journal. But that definition still left a lot of questions unanswered. The product had guides, a mood check, a journal, and meditations, and I did not really understand what was supposed to make Leaflo stand out from its competitors.

During the interview, I defined Leaflo as a "one-button app."

The most important part of the product sits behind a single entry point. A person chooses their emotions and gets a questionnaire that takes those choices into account.

Leaflo gives people a clear structure for moments when they are dealing with a difficult emotion and do not know what to do next.

The next step is to use the same input to suggest techniques that may help them feel better. That layer does not exist yet. But now I understand what should be at the center of the product and where it should go next.

AI structured the sequence of questions and did not let me stop at the first answer. I decided which answers I believed in and which ideas I was ready to build. The responsibility for the quality and direction remained with me.

That matters to me. I once let AI pull Leaflo away from its original idea, and then spent time bringing the product back.

In general, I want to use AI in this role more often: a strong framework based on books written by smart people, and a sequence of questions that leads to insights.

–

The practical goal was to move several experiments one step closer to real use.

For Leaflo, most of the marketing time went into quality control. AI helps with content drafts and Reddit tests. Then I sit down and decide where the result sounds weak, generic, or careless.

Manual review slows the process down and makes the materials better. One day I should write about how this whole setup works.

Leaflo onboarding moved into testing. The goal is to show new users why the app is useful before they have to guess it from the interface.

Plainline took the largest time block.

For a while, the work was about testing the core promise: text goes in, a presentation structure comes out, and the flow holds. This week I started building the product around that: account flows, backend, and places where presentations live.

Plainline needed work on UI, style, animation, and the overall feeling of the product. The landing page needs that too. Before Plainline goes public, the product has to show a clear direction.

A personal newsletter appeared somewhere in the middle.

Posts from LinkedIn also go on my blog. You can subscribe through good old RSS, and now through email too.

The format is unclear. For now, it is an empty room with a sign on the door.

Professional, yes.

Next week I want to launch the Plainline landing page and bring the product to something like 80% functionality.

Then spend another 80% of the time finishing the remaining 20%.

As usual.

–

So now I start almost every new feature the same way.

I create a "docs/backlog/feature" file in the project repo and write something like this:

I want to build feature X. Here's how it should work. Ask me every question that needs to be answered before implementation in the following format:

Question

1. Option 1
2. Option 2
3. ...

Answer:

After I reply, generate a complete specification based on my answers, then remove the questions and answers section.

What happens next:

• AI reviews the codebase and asks questions I wouldn't have thought of.
• It suggests possible answers for each question.
• Most of the time I just reply with 1, 2, or 3.
• Then AI turns everything into a complete specification that's ready to implement.

I like this workflow because it turns writing a spec into a simple 10-minute interview.

If you aren't doing this already, give it a try.

–

I came across this phrase. Usually this kind of thing annoys me, but here I agree.

I should say right away that there is an important boundary here. If you are sick, weak, have no energy, and your body is clearly asking you to stop, that is normal physiology, and it is better not to ignore it.

But more often there is another state. Just a bad mood, disbelief in yourself, doubts about your choice, a desire to drop what matters and go do something more understandable and pleasant.

With work, this happens to me regularly. There are days when I really do not want to start some task. I have not even sat down to work yet, and I am already "tired".

Then you start anyway. You do a small piece. And by the end, you are almost always glad that you did not listen to the first version of yourself.

Very banal, of course. But I still run into this regularly.

By the way, ACT therapy helped me a lot with this state. There is a simple but strong idea there: thoughts and actions are different things.

Thoughts are just words in your head. Sometimes useful. Sometimes it is just internal slop.

For this to help, you first need to notice the thought, for example: "I am having the thought that everything is pointless". This turns it from an internal "instruction" into a "set of words" that just passed through your head.

Then you need to ask yourself: does this "set of words" in my head help me or not? If not, put the thought aside and go do what matters to you. Because thoughts cannot control actions. Unless you let them, of course.

That is the very simplified version. It does not always work, but it still works more often than not.

So this is one of the most useful skills for now: not arguing with every thought in your head, but checking whether it helps you act in the direction of what matters.

The truth is, I cannot do this with sports yet. Which is the perfect, ironic ending for this post about discipline.

By the way, I almost forgot: Leaflo has many different guides with good questions for different emotional swings. Do not swing — Leaflo

–

Before that, most of the work was built around one question: can a model create a decent presentation with a stable layout from text at all? This week, it became clearer that this approach has limits. So I changed direction a bit and started working on my own render engine instead of simply using AI for that part.

I marked up around 5,000 slides for it, kept researching the "text -> presentation" pipeline, and started building the foundation of the editor. Not just a preview screen, but a system with slide cards, editing forms, navigation, and so on. By the way, during all of this, I almost never opened Figma, as sad as that may sound. Or maybe not sad. I still haven't decided.

In parallel, I kept moving Leaflo forward.

I made the FAQ section in the app, fixed a couple of bugs, went through the guide questions again, and finally put together my marketing and product analytics dashboards. Yay.

The main conclusion of the week is simple: when you build an AI product, it is easy to move too quickly into the magic of the model. But the product does not start where the model generates something. It starts where a person gets a clear way to control the result.

That is what I was trying to find this week.

Next week, I want to bring Plainline closer to one complete flow: paste text, structure it, preview it, edit it, and get a presentation in one scenario.

Let's see where it starts to break.

–

This copies the file path to your clipboard. Paste that path into your Codex prompt, and Codex can find the file directly.

It is faster and clearer than dragging in screenshots or trying to describe where something lives in words.

This is useful when you want to:

• Share a folder of media files, plus another folder where those files should be moved.
• Add a local file to a brief or task description you are writing for Codex.
• Give Codex quick context from a spec, log, screenshot, spreadsheet, config file, reference, or older draft.
• Point Codex to design source files, exports, videos, audio, or assets outside the project folder.
• Share a requirements document without pasting a long brief into chat.
• Select several files, copy all their paths at once, and paste them into Codex with a short note. For example: take screenshots of bugs in an app, move them to your laptop, select all screenshots, copy their paths, then paste them into Codex with the bug descriptions.

Tiny shortcut. But every time I use it, it feels weirdly satisfying (:

–

With AI, it is now much faster to make a landing page, ship a feature, fix a bug, generate copy, or test a small idea. That is useful, but it also makes the uncomfortable part more visible.

If nobody sees what you shipped, the product has not really moved. The important part is connecting the work to real conversations with real people. Each shipped thing should create a reason to talk. Each conversation should create the next small change.

Sounds obvious, but I still fall into the trap of hiding inside the product. It feels productive and measurable.

Distribution is less comfortable because it shows reality before I feel ready for it.

There is also a simpler reason: distribution feels cringe. Posting, promoting, asking people to look at your thing.

Nobody taught me how to do this. I learned how to design and build, not how to repeatedly make the same project visible without feeling like I am bothering everyone.

So I guess this is the part I am learning now: getting used to being visible, one slightly awkward post at a time.

–

This week, I started intentionally slowing down my activity on Leaflo.

1. The updated positioning of Leaflo as a CBT self-help app is gradually making its way across all touchpoints. I updated the copy, some landing page materials, and a bunch of small details.

2. I added a place to collect feedback inside the app. This should have been there a while ago, but I never got around to it.

3. I created a new Reels format for Instagram and TikTok, where Leaflo already has accounts. It is a dialogue between a kind girl and a sarcastic parrot. I’ll see how this format performs. The first videos are already out.

I also started working more actively on my second product. It will be called Plainline. Of course, the first thing I did was buy the domain, but there is nothing there yet. Once something appears, I’ll share it.

Plainline will be a service for creating presentations. Not for designers, but for regular people who want to turn text into slides without thinking about builders, layouts, and visual design.

The main difference with Plainline will be a different approach to the presentation workflow: more focus on meaning and text, less focus on assembling the slides themselves.

Right now, I’m doing a lot of research to see whether the idea can actually be built. I’m tuning prompts, testing different APIs, and debugging code generators. At the moment, I’m about 70% confident that it should work. I’ll try to gain another 20% this week.

To be continued.

–

But while building Leaflo, I decided there will be no streaks in the app.

First, a mental health app should not create pressure.

Leaflo is an app for situations when a person feels tired, anxious, overwhelmed, scattered, or emotionally stuck. In moments like that, there are few things worse than being told that you have also lost your streak.

A person in a difficult state is often already dealing with guilt, self-criticism, and the feeling that they are "not coping well enough." If an app adds one more small obligation on top of that, it can stop being supportive and become another source of pressure.

A mental health product should reduce the load, not create a new one.

The second problem with streaks is that they quietly replace the meaning of the action.

The user opens the app not because they need to understand what is going on inside, but because they do not want to lose the streak. From the outside, it looks like retention. But inside, the scenario changes from "I feel bad and want to understand what is happening" to "I need to open the app so I do not break the streak."

The goal is not to make a person mechanically open the app every day.

The goal is to give them a safe and non-judgmental way to return to themselves when they actually need it. A missed day should not be interpreted as a failure.

Returning matters more than continuity.

–

I recently wrote about how ChatGPT had, in some ways, pulled me away from Leaflo’s original positioning.

So I spent the past week bringing the product closer to where it probably should have started.

First of all, Leaflo is now a CBT journal.

The daily ritual has become a guided check-in. The mood check has turned into a more powerful selection of specific emotions.

Inside the check-in, each emotion now has its own set of questions. This part still needs more work, but the direction is already much clearer.

The prompts changed too. They are now more thoughtful, more structured, and more closely based on CBT practices and guides.

They are also grouped by the areas where they can help.

Meditations have turned into breathing exercises.

I also changed the keywords, title, and description in the App Store.

And the cherry on top: localizations finally arrived.

This is still a first version, with plenty of rough edges, but the app and the App Store page are now translated into seven languages: English, German, French, Russian, Serbian, Spanish, and Portuguese.

I translated everything with ChatGPT, so I’m sure there is a small mountain of cringe in places I can’t see yet.

But it is still better than keeping everything in English for people who do not speak it. I’ll keep improving it from here.

Overall, this turned into a pretty big release.

Now I’m curious to see what it leads to over the next two or three months.

In the meantime, I’ll keep working on Leaflo’s marketing channels and start researching a second product. It looks like it might be something related to presentations.

Stay tuned, as they say.

–

I released an update for Leaflo with monetization, new themes, icons, meditation audio, PDF export, and several export options, including manual note selection and date ranges.

Preparing the release took about half of the week because there were quite a few scenarios to test. As I wrote earlier, this is one of the most time-consuming stages for a solo developer.

On top of that, it was my first time figuring out how monetization works in the App Store. So far, everything seems to have gone smoothly.

On the distribution side, I'm continuing to publish content to grow SEO and social media. I do not expect any serious short-term effect here. My guess is that it will take at least six months before the first noticeable results show up.

The plan for this week is to continue publishing, work on the design of future Leaflo features, and start thinking about a second app.

The active development stage of Leaflo is gradually coming to an end, so the main focus will now shift more toward marketing.

Once I have a more concrete idea, I will definitely share what kind of app it will be.

–

I want to share a bit about the motivation behind this positioning.

First, CBT is one of the most evidence-based approaches in therapy. Not all therapy methods are studied equally well, and that matters to me.

Second, I’ve been through therapy several times myself, read books and articles on the topic, and tried different techniques in practice.

I’m not a therapist, but I understand the basic logic fairly well: how thoughts, emotions, and behavior are connected, and why the right question can be more useful than another page of free writing.

Third, I think it’s important to make these methods more accessible. Not in a “fix yourself in 5 minutes” kind of way, but in a more honest way: here is a tool. It’s not magic, but it can help you better understand what’s going on inside.

And most importantly, it simply makes the product more useful.

A regular journal helps you record an experience. A CBT journal helps you work through a situation.

It’s not a replacement for therapy, and I don’t want to sell Leaflo as a replacement for therapy. But a journal can be a useful support: before therapy, alongside it, or after it, when you want to keep the habit of self-reflection.

That’s why Leaflo is gradually becoming not just a place where you can write about your day, but a more structured CBT journal that helps you not only record your state, but also work with it a little better.

–

I started building Leaflo about a year and a half ago or so. Back then, I thought through the feature set, the rough positioning, did a competitor analysis, and after building about half of the product, I put it aside for different reasons. It happens.

When I came back to it, I started discussing the product with ChatGPT more often. And somehow, over time, I drifted into a completely different positioning — one that moved me away from my original idea.

Originally, I was planning to build a CBT journal that helps a person during therapy, and also before and after it. Because journaling is a common practice in therapy.

But in the end, I drifted into a wellness-style personal journal. And the product itself became a bit split.

On one hand, it had simple personal diary features. On the other hand, it had a library of prompts, which belongs more to a focused, goal-oriented writing format.

At some point, I realized I had moved in the wrong direction. And now I’m spending time and energy trying to get back to the starting point.

The conclusion is simple:

When you discuss your tasks and projects with AI, don’t forget your own ideas and intentions. Most likely, they are more valuable than anything AI will suggest to you.

Don’t switch off your own thinking. Use AI for specific tasks and specific requests, but try not to trust it with anything strategic.

It should not make conclusions for you or pull you away from your direction.

Sounds obvious — but I still fell into this trap.

–

Writing specs is not the hard part for me. Neither is design.

But testing? Testing is slow, repetitive, and surprisingly difficult to make efficient.

I try to cover everything that can reasonably be covered with automated tests. But that still doesn’t remove the need for manual testing.

There are always flows, edge cases, small UI details, real-device checks, and other things that tests don’t fully catch.

Right now, I’m trying to stay disciplined and go through my test cases properly, because app quality matters to me. But as the product grows, this takes more and more time.

I’ve also tried to think about automation, but UI tests often feel too fragile to fully rely on.

So I’m curious: how do you optimize QA for small products or indie apps?

–

I still do not have a ritual for these notes. Starting is the hardest part. It rarely feels like "sit down and write." It quickly turns into a small product problem of its own: what should I write about, when should I do it, where should I publish it, how polished should it be, and how personal do I want to make it.

So instead of overthinking the format, I will start with a simple snapshot of what I am building right now.

The main bet is Leaflo.

That is where most of my focus goes now. The product is already live on the App Store, but that does not feel like a finish line. It feels more like the start of the next stage: improving the product, testing the positioning, finding users, figuring out distribution, and getting to the first sales.

Then there is Pilekeeper.

I quietly launched it, but I have barely talked about it publicly. It is still an alpha, it has plenty of bugs, and I still do not fully understand how to position it or whether the market really needs it. But I use it myself every day.

I also have a couple of Figma plugins, Commentor and Grider.

I made them a while ago and, to be honest, I did not give them enough time or care. Commentor had some interesting ideas for future development, but right now I am not sure whether it makes sense to keep pushing it forward.

And of course, there is a pool of other ideas in different stages of readiness.

The main problem is that most of my current projects started as things I made for fun. I built them because I liked the idea. At that point, I was not thinking enough about the market, the niche, sales, or monetization potential.

Now the situation is different.

It is no longer enough for me to make interesting things. I need to learn how to bring products to market, find customers, validate demand, and turn ideas into an actual business.

That is why I am concentrating on Leaflo.

Right now, it is the project with the clearest path to monetization. At the same time, the journaling app market is crowded. The competition is strong, the products are good, and many of them already have very clear positioning.

So we will see how it goes.

My plan for the near future is simple.

The first goal is to make the first dollar in sales.

Even that is not a small step. I need to improve the important parts of the product, package it better, explain the value clearly, bring people in, and convince someone to pay.

The second goal is to get to a point where the product can at least cover my basic expenses.

The third, more distant goal is to make it sustainably profitable.

The rough horizon I have in mind is 12 to 18 months.

At the same time, I do not plan to keep betting on one product forever no matter what. I will watch what actually moves, switch when needed, test hypotheses, and focus on the things that show real signs of life.

–

I wanted to test this in practice.

So I ran my own experiment and tried, in many tasks, to stop using Figma and use code-based prototyping instead. Not as a nice weekend demo, but inside a real product, in parallel with my normal work.

One important clarification first. This is not about a designer moving into production engineering. And it is not about writing code that later ships to production. In my case, a coded prototype is a separate design artifact. Its job is to help me build, show, discuss, and test a solution in a more realistic way than a static mockup can.

My hypotheses

I started with fairly simple expectations. I thought code prototyping would:

• speed up design creation;
• make handoff to engineering easier;
• make demos clearer for stakeholders;
• help me iterate faster;
• give me a more native artifact for UX research;
• help me feel the product more strongly than static screens;
• be more convenient than Figma in some types of tasks.

Looking back, I can say that some of these hypotheses were confirmed, but not where I expected. The main value was not really in drawing faster. It was in the type of artifact and in the quality of testing interface behavior.

Conditions of the experiment

I am not a programmer, but I am also not someone who saw code for the first time yesterday. I can read code, I understand the basic frontend and backend infrastructure, I know HTML/CSS, I wrote simple Figma plugins in the past, and I have always built and maintained my own portfolio myself. So, in short, code was not a foreign environment for me.

At the same time, the product I work on is not the easiest one, but it is very revealing for this kind of experiment. It is a mobile AI app. That means I somehow need to prototype a non-deterministic system. In interfaces like this, UX does not live only in the screen itself. It also lives in what the user typed, how the system interpreted it, and what kind of answer it showed next. Static screens do a poor job of showing that.

On top of that, a mobile interface prototype needs to be shown on desktop, on a phone, and sometimes on desktop while emulating a phone.

To make the prototype feel at least a bit like a real product, I had to connect it to a live ChatGPT. Not in a full product form, of course, but as a simplified chat simulation.

The team is also not small: several designers, many product managers, and two platforms — iOS and Android. I did not announce any official move to a new process. I ran the experiment more in stealth mode. That was intentional. First I wanted to understand whether this model worked at all before committing to anything.

The first attempt.
Failed. And that was useful

The first serious attempt ended badly. But that attempt gave me almost all of the important observations.

The first and most obvious problem — Figma is often faster. if you have three small edits in different places and you need the result in 10 minutes, Figma is almost always faster. This is especially noticeable before meetings, when you need to urgently fix something, move something around, or show several variations.

In practice, it looked very simple. For example, you are discussing a prototype with a product manager and want to freely move elements around, tweak them, swap them live during the conversation. Some things can be adjusted quickly through devtools, but far from everything. In the end, you hurriedly rebuild parts in Figma from screenshots of the prototype. It is awkward and slow. And obviously, in the middle of a discussion, nobody is going to write a prompt for an LLM and wait for it to carefully rework something.

The second problem is overview.
In Figma, you see screens side by side, quickly compare versions, stay on an in-between state, and show links between flows. In a coded prototype, everything is different: to understand what is implemented, where you can click, and what state the screen is in, you often have to literally “poke through” the interface. Flow transparency drops sharply.

The third problem is handoff.
When you give a developer a mockup, that is one communication model. When you give them a working app prototype, the model changes completely. You now also have to explain how to get to the right screen, how to reproduce the state, where the needed branch of the flow lives, and why it exists in the first place.

The fourth problem is versions and alternatives.
In Figma, you can easily place two, three, or four variants of the same flow side by side. In code, this is no longer “four frames.” It is almost four separate branches. Any cross-cutting change quickly turns into pain.

The fifth problem is data.
If you can put it all into one JSON file and load it into the prototype, it is still manageable. If not, you get generation, parsing, APIs, changing contracts, and constant maintenance of a temporary construction. As soon as the data is no longer a simple mock JSON, the prototype starts needing almost engineering-level support.

The sixth problem is the gap between web and native.
A PWA on a smartphone is still not a native app. For many tasks, that is good enough. For some, it is not. And building a real native prototype is harder and more expensive — both in terms of setup and team access. The simplest example is: “Can you please add haptics when the button is tapped?”

Finding 1.
The thinking process itself barely changed

This is important to say clearly, because there is too much confusion around “vibe coding.” Design thinking did not disappear. The need to think through scenarios, data, logic, states, and system behavior did not go away. All of that still has to be thought through in advance.

Yes, LLMs make it easier to discuss an idea, explore more hypotheses, build a rough version, and see it live. But if the logic of the solution is bad, a coded prototype will not save it. It will simply materialize a bad solution.

Finding 2.
A prototype needs an overview layer on top of it

The most important insight of the whole experiment was not about code generation and not about speed.

I realized that a coded prototype almost inevitably needs a second interface on top of the prototype itself. Some kind of overview layer — a separate canvas where you can see screens, states, versions, and entry points, and from which you can open the needed screen. Because a live interface by itself is bad for overview.

To solve this, I built a small service that takes a markdown file and turns it into a layout of screenshots. In other words, it is a canvas of versions and states. You can zoom it like in Figma, quickly switch between sets of screens, and open the real prototype by clicking on a screenshot.

For me, this was the turning point. At that moment, the coded prototype stopped being a black box and became a convenient discussion object again. A developer and a PM could see all the key states on a canvas, quickly open the needed scenario, compare versions, and understand what exactly they were being shown.

In other words, I came to a strange but logical conclusion: if a coded prototype really wants to compete with Figma as a communication environment, it needs its own Figma-like overview layer.

Finding 3.
For prototypes copy-per-use is useful

Another important thing became clear at the infrastructure level.

At first I thought about the usual ways of organizing variants: flags, branches, some more “correct” architecture. But very quickly it became obvious that this is inconvenient for a prototype. Flags spread across dozens of places and start affecting each other in hidden ways. Branches are more reliable, but too heavy for use, comparison, and deployment.

In the end, I came to an approach that would look like a bad idea for production, but turned out to be almost perfect for prototyping: copy-per-use. That means a separate copy for each specific experiment, without trying to build an ideal architecture too early. A separate folder for every scenario or group of scenarios, with all changes for that experiment inside it. Yes, the number of files grows. Yes, there is duplication. But experiments become fully isolated, do not break each other, and do not infect the main structure.

For prototyping, this turned out to be much more practical than trying to build a “clean” engineering system too early.

Finding 4.
Code prototypes most useful for UX research

Interesting things happened exactly where the product itself does not fit well into a static mockup.

For research, it is sometimes important that a user types a real question and gets an answer page in return. The problem is that the same intent can be phrased in ten different ways. In static screens, this quickly becomes fake: either you hardcode a very narrow scenario, or you show a generic placeholder that does not really test much.

Here a classifier helped me. It mapped differently worded user queries to the right prebuilt page, even when the answer itself was still hardcoded. Because of that, it became possible to run quantitative research for prototypes of non-deterministic systems without the whole thing feeling completely fake. Even though it was still a bit fake, because the returned page was static 🫠

There was another useful case too — onboarding testing. When a user selected several interests, the chat automatically generated relevant follow-up suggestions. I did not have to hardcode those manually for every possible set of interests. It already felt much closer to a real product than a normal static scenario. And for both research and stakeholder discussion, this kind of prototype worked noticeably better.

These were the moments when I started to understand why I was doing all of this in the first place. Not to “draw in code,” but to test UX where the UX actually lives in system behavior, not in one frozen screen.

Second attempt.
More successful. But there are still a lot of things to care about

Once the first wave of infrastructure problems was partly solved, more fundamental things appeared.

First, not everyone on the team needs a coded prototype at all.
Sometimes a product manager does not need an “almost live interface.” They need a familiar mockup that can be opened quickly, reviewed, and discussed in the usual way. This is also true for part of engineering.

Second, if the design team does not agree on one working model, the value of this approach drops fast.
Because supporting both code and Figma at the same time is just dumb double work. And there is still no reliable bridge between the two worlds.

Third, speed becomes an issue again.
Some bigger things in code really can produce a stronger and more mature artifact. But quick small edits, sudden “show it one more way” requests, and dozens of micro-variants still live much more naturally in Figma.

Fourth, the design system becomes critical.
Not in the sense of “you need a set of buttons,” but in the sense of a component library, understandable documentation, and a proper way to reuse things. Otherwise every new screen starts being assembled almost from scratch again. In my case, the problem was not the lack of a design system as such. The problem was that the existing one was heavy, full of legacy, and poorly prepared for agent-based assembly.

And finally, after some time, you stop remembering which components, flows, and screens even exist inside your prototype. That means you need at least a simple component showcase. And after that, probably something more systematic. So the prototype itself starts demanding its own mini-infrastructure. On the other hand, that infrastructure may turn out to be much more flexible and adaptable than Figma.

Conclusion 1.
Code is better for behavior-heavy tasks, not just screens

A coded prototype works better in tasks where the main thing is behavior, not visual layout alone. It is more useful when you need to show logic, navigation, transitions, data handling, complex states, real delays, AI interface dynamics, and scenarios. In these cases, it helps discuss not only how the interface looks, but how it actually works and feels.

In some situations, it can also be faster in practice. For example, when building a large set of screens, flows, states, tables, diagrams, and components for a major sports event, code made it possible to assemble a clickable and scrollable artifact in two or three days. In Figma, creating the same amount of realistic mockups with data would likely have taken more time.

Conclusion 2.
Figma is better for quick iteration and team routine

Figma is still stronger when the task is about speed, simplicity, and existing team workflow. It is better for small fixes, quick exploration, comparing several options side by side, leaving comments on a canvas, showing intermediate states, and syncing fast with a team that already works in that environment.

If designers and engineers are clearly separated by role, if the coded prototype is not reused later, and if stakeholders do not need that level of realism, then code will most likely just slow the work down. In those cases, the overhead is simply not worth it.

Conclusion 3.
It’s a separate mode of work, not a replacement for Figma

A coded prototype should not be treated as a universal replacement for Figma. The experiment did not prove that code is simply faster, and at early stages it often does the opposite, especially when there is no agreed process and no shared understanding of why this artifact is needed.

Its main value is not that the designer now “draws faster,” but that it produces a different kind of artifact, one that can be more honest and useful for certain UX problems.

So for me, code-based prototyping is not a new default. It is a separate working mode for a specific class of tasks, mainly where static screens fail to communicate the essence of the product. Without that understanding, it quickly turns into an expensive technical exercise.

What happens next

I do not think big teams will move from Figma to pure code any time soon without intermediate models. Too many processes depend on overview, collaboration, and a low entry barrier.

But I can absolutely believe in another scenario: a team has a shared prototyping layer connected to the component base, people have personal sandboxes for experiments, and on top of all of that there is a convenient overview interface that brings back the transparency people are used to in Figma.

This experiment was useful to me for exactly that reason. It did not prove that Figma is no longer needed. It showed where a coded prototype is truly stronger, and where the talk about “we do everything directly in code now” is still far from reality.

Appendix.
What the process looks like

Of course, a new tool changed the design process. The flow ended up looking roughly like this:

1. A task comes in.
2. Discussion with the product manager to clarify all details.
3. Research, task analysis, and solution design. Understanding the needed data, components, screen structure, and flow. Whether this is done with sketches, in Figma, or just by collecting screenshots is not that important. The main thing is to reach clarity. Reworking things is usually longer and harder, even with AI (or especially with AI).
4. Collecting, parsing, or generating the data needed for the first version of the task: images, headlines, texts, metadata, data for charts or tables, and so on. You can improve the data later, but you need a basic foundation first, so you can build components against some contract.
5. Writing prompts for new components or component variations needed to assemble the screens.
6. Building the components. In this process I actively use the Figma MCP server to get higher quality implementation, if the components were originally designed in Figma. If not, you can try building from screenshots or sketches. Or describe the elements, sizes, and rough spacing in text and then adjust everything in devtools.
7. Assembling screens and flow navigation. This is the final stage, where we build screens almost like from a constructor and connect data.
8. My personal extra step: assembling flow from screenshots, so different screen states can be shown more clearly through the service I built.
9. Discussion → research → next iteration.

So the thinking stage did not disappear. But the final artifact became closer to the product.

–

But there is a problem with principles. People often understand them in a vague way and replace them with slogans that sound nice but work badly in real discussions.

This is a short reminder of what a principle means in practice.

Principles are not a set of nice phrases about all the good things. They are not about choosing between good and bad.

If you are choosing between good and bad, that is not a principle. That is basic common sense. “Do good quality work,” “care about the user,” “do not make nonsense,” “aim for the best” — these are not principles. This is pop management language that costs nothing and helps with nothing in a real argument.

A principle starts where two good options collide. Not good and bad, but good and good. Or at least acceptable and acceptable. For example, speed or quality, consistency or local exceptions, simplicity or flexibility, one shared approach or freedom.

If you are choosing between good and bad, that is not a principle. That is basic common sense. A principle starts where two good options collide.

This is where the real conversation starts. Because now the choice has a cost: you choose one thing and cut off the other. That is why a principle is not a slogan. It is a fixed limitation that helps reduce chaos.

A principle written in a populist way is useless exactly where it is needed most. It does not help when both sides are right in their own way and both have real arguments. It does not reduce discussion and it does not make the decision easier. It only creates the feeling that the team has clarity.

That is why a real principle should almost always sound a bit uncomfortable. You should feel the tradeoff. The limit. The tilt. The cost.

Not “we choose quality,” but “in the current market we more often choose speed over perfectionism, because being late hurts us more than shipping something imperfect.” Not “we value flexibility,” but “we are ready to lose some consistency to get faster local decisions.” Not “we love simplicity,” but “we would rather leave out rare scenarios than make the main experience harder for everyone.”

That is already a principle. Someone will clearly be unhappy with it. And if nobody can feel any discomfort from your wording, then most likely you did not write a principle. You wrote safe nonsense.

Another uncomfortable truth: do not create principles where there is no friction. If there is no disagreement on an issue, then there is no need for a principle. Do not turn everything in advance into “our approach,” “our philosophy,” or “our decision culture.” That is just filling the space with words.

A principle makes sense when the same discussion happens for at least the second time. Because at that point the team is again spending energy not on solving the problem, but on repeating the same argument about the rules behind the decision.

A principle is not a law of nature and not the truth. It is a chosen tilt. It exists not to be objectively right, but to make repeated crossroads cheaper to pass.

A principle is not “we are for all good things.” It is a choice about which of two normal options we will cut more often so we do not have to go through the same fork in the road again and again. If that is not present in the wording, then it is most likely not a principle. It is noise.

–

We throw around terms like revenue, metrics, data-driven, PLG, quality, vision, mission. But in reality, Care is the essence of our work. We strive to take care of people, and in return, we receive their gratitude. In that order.

I often think about beauty, aesthetics, and functionality, about their balance. Care transcends both beauty and functionality. It is a deep human motivation that gives birth to both function as a desire to help, and beauty as a desire to inspire or make human experience enjoyable.

A person who truly cares is like a hospitable host: they welcome, nourish, sustain, and delight their guests. They do everything to make them feel comfortable, warm, and cherished. In this way, they forge and maintain an important connection with these people, showing how truly valued they are.

Transferring this idea to business, we can say that our work is aimed at the same thing. We meet people, help them, reduce their anxiety and doubts, improve their lives, and in return receive sincere gratitude for this experience. This is the main ethical path.

It seems to me that a lot could change if, when working on any project, we first asked ourselves questions not about metrics and money, but looked at it from a different position:

Is there care for the person who will interact with this?

Are we really caring now, or are we just solving someone's technical problem?

Will the person feel that someone cared about him, or will he feel manipulation and indifference?

How much sincere care have we brought to people this month?

How to make this project with care?

Of course, it may sound naive, like, business is not done that way. My opinion is different. A company will be in constant "survival mode" if its only value is the benefit it brings. Because benefit is a function, it is easy to copy. Even if it is a breakthrough technology, there will always be someone who will do the same, but perhaps cheaper or with more resources.

However, a business flourishes and gains loyal followers when its main value becomes Сare. Yes, you can and should still monitor profitability, conversion, and retention, it is just that the main key to decision-making becomes the thought of care. Then metrics will cease to dominate, and will take their modest and logical position as ordinary indicators of how successfully your care resonates with people and helps your business.

–

I'll approach this question from two angles. First, I believe that design is a form of art. This includes product design, interactive design, motion design, graphic design, and so on. Second, I am confident that art does solve problems. And it does so no less effectively than design.

When we contrast one with the other, we diminish both concepts. Design loses its depth of meaning and emotional resonance. Art loses its real practical impact. I want to show that this separation is a false dichotomy. It has no solid foundation.

Thesis 1
In art, the artist sets their task, while in design, someone else does

One common argument goes like this: in art, the artist formulates the task themselves, but in design, it's set by someone else. From this, they conclude that design is a mere craft that serves others, while art is free self-expression. But this is a rather weak distinction.

A designer can be an independent author and create a product based on their vision, without considering the market or audience. Or they can consciously abandon broad universality and create something for a narrow group of people. Conversely, try to appeal to everyone at once. This isn't a mistake, but a conscious strategy. Many indie designers work this way, creating utilities, apps, and websites for a community of like-minded individuals. And in this, they are no different from an artist who paints in their style and finds people who appreciate that style and are willing to pay for it.

Conversely, an artist can work based on a brief, paint portraits, illustrations, design books, or posters. This doesn't make them any less of an artist. What's important is not who sets the task, but how the person approaches it. How much effort is put into expressing something more than just meeting technical requirements. How much a personal perspective, a sense of form, time, and emotion can be felt in it.

Thesis 2
Art does not solve problems

Let's forget about the logic of conversions and retention for a moment and ask a simple question: why do people continue to create art, buy it, go to museums, hang paintings on walls, write music, and make films? The answer is simple: because it responds to specific internal and external needs. It solves problems: aesthetic, emotional, cultural, and social.

Art helps cope with anxiety, loneliness, gives a sense of beauty and meaning. It shapes perception, evokes feelings, raises important topics — from personal to political. It can point to a problem more accurately than analytics, faster than news, deeper than statistics. There are countless examples: Picasso's "Guernica," the works of Ai Weiwei, Rodchenko's posters, photographs from the Vietnam War. This is not just aesthetics. This is work aimed at specific goals: to attract attention, express protest, change opinion, create an effect.

Incidentally, the same can be said about design. Many techniques we currently use in UI and UX came from art. The Bauhaus in the 20th century blurred the line between artist and engineer, and we continue along this path. A designer creates not just an interface, but also meaning and form. Their work influences the user's thinking, behavior, and mood. This is the connection with art, just with different tools and on a different scale.

Thesis 3
Art is about self-expression, while design is about the user

This argument is also heard often, but it's false. Of course, there are works created by artists only for themselves, "for the drawer," without considering the audience. But in most cases, art is directed at the viewer. It expects a dialogue. It wants to evoke an emotion, a reaction, a thought. Sometimes even provocation.

At the same time, design can also be subjective, authorial, not obligated to please everyone. If you go beyond purely applied design, you'll find that a large amount of design work is not done for the user. It's created for oneself, for research, for experiments.

By the way, I often recommend myself, when working on a task, to first imagine how I would want to solve it for myself. Without considering the brief. Without accounting for the "average user." This is something between curiosity and the egoism of self-expression. But that's where the power lies. It is precisely this approach that often gives birth to unique, vibrant solutions in which the author's personality is revealed.

Thesis 4
Art is timeless, while design becomes outdated

Sometimes people say that art is "for the ages," while design exists within the framework of trends, technologies, and the tasks of its time. This argument easily falls apart when we look at what is currently called art, and how many real products created with both functional and aesthetic value have turned into art. This includes classic typefaces, Bauhaus objects, Scandinavian chairs, and much more.

At the same time, a vast amount of art "dies" within the context of its era. A colossal number of artworks have been created in the last 100 years. However, we still remember and consider truly valuable only a small portion of them. I am sure that if you calculate it, this proportion is no more than 1% of all works that could claim "timelessness."

Conversely, many works of art intentionally engage with the current context, as a reaction to the here and now, as an attempt to draw attention to a social problem. Take the works of performance artists, for example. Of course, we will remember their actions, but as a historical fact, not as an act of art that we could observe in its original context.

Thesis 5
Art has no metrics, design does

This argument sounds like, "design can be measured, but art cannot, so they are fundamentally different." Let's be honest. Scientists still don't fully understand how the human brain works. Scientists still don't understand how and why certain decisions are made. Until we decipher how the brain works, many things in design cannot be measured: emotions, the "wow" effect, style, memorability, associations.

We can only measure the consequences of this influence in the form of conversions or other business metrics. But we cannot measure the influence itself, or why it has a certain effect, or whether it affects everyone the same way or differently.

It's the same with art. Many metrics assess the popularity or importance of an object after the fact: criticism, reaction, value, market, popularity. Especially in the modern world with likes, comments, auction values, and price lists for paintings on Wikipedia. Many things can be measured. But all these assessments are given as a societal reaction to art, not as an assessment of the influence of art on each viewer individually.

Thesis 6
Art creates value in itself, while design creates it through function

This thesis largely overlaps with Thesis 2. Here too, it all boils down to what we consider valuable.

In my opinion, value can take different forms. A thoughtful and meaningful film can change a person's life and views. Kind, well-chosen words can ease emotional suffering. A magnificent painting can carry aesthetic value. And well-executed design can carry both aesthetic and functional value.

Sometimes the aesthetic value of a design object is so great that we want to have it in our home solely because of that, not because of its functional part. At the same time, functional but soulless things bring us no pleasure.

It is said that in design, only solutions that can be tested and proven work. But practical experience shows that everything that truly has an impact doesn't always fit neatly into a funnel. An emotional interface is perceived as more convenient. Aesthetics build trust. Form is not decoration; it is the language through which a product speaks to a person. If design starts to lose its artistic quality, this language is also lost. Design becomes dead, grey, flat. It becomes just a utility. And nobody loves utilities; they are merely used.

Thesis 7
Design is about business

This is a trend. In some companies and teams, design, especially product UI/UX design, has indeed started to serve one purpose: to extract as much money as possible from users, including by using any available manipulations bordering on dark patterns. The very concepts of dark patterns are also becoming increasingly blurred.

I recently asked a colleague, a product manager, how many story points he would be willing to spend to achieve beauty. He replied — zero. Do we agree to such a future for design?

When we try to "sit at the table with business," we sacrifice emotionality, aesthetics, feelings. We are essentially saying, "Look, look! We — designers — are just like you! We are like the CEO, CPO, CTO, CMO, CRO, CFO! We are calculating, pragmatic, cold! We are about metrics, business, and money! We disregard beauty if it brings more cash! We ignore the user if the metrics go up!"

This looks pathetic. And it's a trap. The designer's strength lies precisely in being different, not in being similar. In empathy. In the ability to create something unique, convenient, expressive, emotional. Something that is not visible on charts but is felt. The strength lies in the ability to create balance within the team, to balance the corporate race for money with something more humanistic.

In fact, this last thesis, if allowed to develop, is truly capable of destroying design as a form of art. It can turn it into a dry set of psychological manipulations aimed at achieving business goals: FOMO, Scarcity, Hidden Costs, Confirmshaming, and even Social Proof, which has become quite innocent over the years.

People get tired of such design; they lose their receptiveness to it. In response to this fatigue, design becomes increasingly pushy, aggressive, and refined each year. Notification bells ring and shake more and more fiercely. Boxes and chests with "gifts" are thrust upon people more aggressively. We are increasingly moving away from being user advocates and creating aesthetic functionality.

Yes, I know I sound naive. I have been working as a product UI/UX designer for the last 14 years, and I understand everything. My last project was about nudging people towards a choice using Social Proof. This project helped business metrics. Yay.

Design is art

Nevertheless, to summarize everything that has been said, I believe that art and design should not be contrasted. They should not be pushed to opposite poles. They are one and the same force of creative vision. We solve different problems, but the essence of these problems is the same. We are trying to respond meaningfully and beautifully to the challenge of society, the market, the inner world, or the technical environment. In this sense, design is art, albeit more utilitarian, more applied, and more scalable.

I think our task as designers is to remember this. Not to lose our artistic essence. Not to be afraid to say that we are also artists, that we create meaning, the beauty of forms, and emotions, that we have a voice. That we have the ability not just to "fix scenarios," but also to propose something new, expressive, and have an emotional impact. To be authors. Because as soon as we agree to the role of applied craftsmen, we lose a part of what makes it worth doing.

–

In 2017 she wrote the book "Design Systems". This book is often referenced as a practical source of information on organizing work around a design system. Eight years have passed, but the book is still very relevant. Below, I provide a summary of the chapters, which I hope will help you form a general impression.

The book mainly targets small teams, though it often mentions Airbnb. At that time, Airbnb had more than 60 designers, which is hardly a small team. Still, the foundations described in the book are exactly what a small, starting team needs to lay the groundwork for a design system without making too many mistakes.

The book is divided into two parts. Foundations mostly cover the theory of design systems and their guiding principles. The process focuses on how to start creating the system and organize processes around it.

Chapter 1
Design systems

In this chapter, the author defines a design system as a collection of interconnected patterns and shared practices organized to serve a product. Patterns are the recurring elements that make up the interface. Practices are how we create, use those patterns, and organize teamwork.

A product’s domain influences the functional side of patterns. For example, a trading app needs charts, data visualization, various inputs, and tables. A course website needs articles, videos, progress indicators, etc.

A product’s brand language mostly influences the visual side of patterns. It forms the basis for what are called perceptual patterns: colors, typography, and so on.

These patterns together create the interface design language. To keep the language consistent, it’s important to document the patterns, explain them, and share them with the entire team – or even involve the whole team in that work. This depends on how the design system is organized.

Language is fundamental for collaboration. Every team member needs a clear understanding of each pattern, how and why it’s used, and why it was created that way. The more effectively this knowledge is shared, the higher the chance that patterns will be used correctly. Of course, the user also needs to understand the patterns well.

An effective design system reduces the cost of design and development while meeting user needs and achieving product goals. However, it has limits. A design system can’t fix poor design or poor UX/UI.

Chapter 2
Design principles

The basis of any working system is its principles. They express the value and purpose of the product.

Qualities of good principles include:

1. Authenticity. Principles shouldn’t be too generic or vague – they need to be specific and applicable. For example, instead of “Simple,” try “Timeless.”
2. They’re practical and actionable. They should guide and direct decisions. “Make it simple” is too broad, but “No needless parts” is clearer. Think of advising on how to do things.
3. They have a point of view. Although design principles shouldn’t apply to every situation, they can help in complex or ambiguous scenarios.
4. They’re relatable and memorable. Having 3–5 principles works best.

To define principles, start with the product’s purpose. One good exercise is asking team members to propose principles and then looking for common themes. Focus on principles for your team and related groups. Keep developing principles and using them in your work. If they’re not applicable, iterate again. Principles may need adjusting as you implement them.

One of the hardest things is applying principles to UI/UX in practice. Use your principles when choosing a direction or making tough decisions. For instance, if you have 10 different options for a text editor or any other pattern, ask yourself which best reflects your design principles and why.

Chapter 3
Functional patterns

Functional patterns are the building blocks of the interface: buttons, banners, pop-ups, and so on. The product type and its needs can affect which patterns are necessary. Patterns evolve over a product’s lifetime, but their behavior and purpose usually remain the same.

Often in a product’s early stages, patterns aren’t defined, named, or shared within the team. This leads to recreating the same patterns many times. Over time, you need to organize these patterns. To do this:

1. Create a map of patterns grouped by their shared meaning. For example, group them by the user’s steps.
2. Audit your interface and gather all variations of the same element in one place. Ideally, do this regularly as the product grows.
3. Pick the necessary set of patterns and remove duplicates. Name the patterns based on their purpose, not just their appearance. For example, “Billboard” suggests a more action-focused, promotional role than a modest name like “Course Banner.”

Break down each pattern into its parts: text, graphics, etc. This helps combine several elements into one pattern. For example, if you have a few patterns in different sizes or shapes but with the same elements, it might be worth merging them into one component with size variations. It’s also a good way to clarify a pattern’s essence and confirm it with the team.

Sometimes you have to design a pattern that includes content (text or images) but you don’t have that real content yet. In this case, you can create it while imagining possible content. (However, it’s better to set content boundaries in advance and agree on them with the team.)

Chapter 4
Perceptual patterns

Perceptual patterns include typography, iconography, color, shape, spacing, grid, animation, tone of voice, etc. These patterns communicate the brand both on their own and in how they work together. If functional patterns reflect what people want or need, perceptual patterns reflect how they feel.

There are a few ways to explore these patterns: Mood boards, Style tiles, and Element collages (which are basically a variation of style tiles).

It’s important to find a balance between conformity and exceptions in brand perception. Too many exceptions weaken the brand. But if there are too few, things can feel too uniform and rigid.

When you’re fully focused on consistency, some of the important subtleties of what makes a product feel a certain way can be lost. Lucy Blackwell, creative director at FutureLearn

When you add new elements to the design, especially if business requirements demand them, always check if those elements reflect the brand. The more often an element is used, the more it either supports or weakens the brand.

Chapter 5
Shared language

Building a consistent, unified design system requires a shared language everyone on the team uses and understands.

First, accept that naming design system components is important. The easier they are to remember and the more inspiring they are for new ideas, the more reusable the pattern will be.

The name shouldn’t only describe what the object looks like but also its purpose. Good names often use metaphors and have their own identity. Examples might be “Brackets,” “Spotlight,” “Minions,” or “Boss-button.”

It’s best to name components together. You can create a separate chat and invite your coworkers and users for naming discussions.

Naming components isn’t enough to make the design system a daily tool for everyone. You need to immerse the entire team in all kinds of ways. For instance, you could create a special area in the office with all the styles printed out. You can also make posters or cards for each pattern.

Use the names of design system elements all the time, even if it feels awkward at first.

It’s good when learning about the design system is part of onboarding new team members. Regular meetings about the design system are also helpful. You can discuss changes, new components, and modules at these meetings.

Create and maintain your glossary of terms. This is valuable not just for explaining words to everyone on the team, but also for reinforcing a culture where words and shared language matter.

Part II

Chapter 6
Parameters of your system

Three main parameters define how a company manages a design system:

1. Rules: strict or flexible
2. Design system parts: modular or integrated
3. Organization of the work: centralized or distributed

These parameters are not binary. Each company can be somewhere in between. Below are descriptions of the extremes for each scale.

Rules

1. They can be strict, documented, and clearly described. Everyone must follow them at all times. Any exceptions are examined closely to confirm if they are needed.
2. On the other side, they can be flexible, leaving room for improvisation. In this case, rules are more like principles rather than strict guidelines.

Elements of the system

1. They can be modular. In this situation, the system is broken into small pieces that are used to build other pieces and so on. Everything is carefully adjusted and constantly reused. This approach is typical for standard digital products and apps.

2. Or they can be integrated. In this case, the chunks are larger and reused less often. The structure is less flexible. The main consistency might be the color palette, typography, and other basic elements. This format is more common in promo products and landing pages.

Organization

1. Centralized, where designated people are responsible for the design system. This format is more common for large design teams, where designers work in different areas and do not always interact closely.

2. Distributed, where everyone on the team is partially responsible for the design system and its growth.

As mentioned before, these parameters are not binary. Each team can find the balance that works best for them.

(For example, a small team might have a distributed format. Each team member contributes to the design system independently. However, one or two people might pay closer attention to consistency and focus on developing the system.)

Chapter 7
Planning and practicalities

A design system cannot be built by a few people without dedicated resources. To get resources assigned, you need to show the business how it will be useful. There are several ways to do this, but all involve showing clear, measurable value in business terms.

1. Saving time on designing and developing modules. Reusing design system elements pays off over the long term. The larger the team, the more beneficial it becomes.
2. Saving time on large-scale product changes. Without a design system, any complex change becomes a huge task. Many hidden bugs show up, and the team gets bogged down in testing and fixes. With a design system, such changes appear everywhere automatically if a component is used in multiple places. (Of course, this can still cause issues, but much less often.)
3. Faster product launches. Having a library of patterns can let you build new pages up to 10–20 times faster.

If your enterprise has 25 teams each making buttons, then it costs your enterprise $1,000,000 to have good buttons. Nathan Curtis

Besides these, there are less tangible but strategically important benefits: brand consistency, unified pattern use, collaboration, and teamwork.

Where to start when you have resources

1. Agree on your goals. Start by systematizing the interface. This includes defining design principles, identifying patterns, and building a pattern library. Also, think about how to maintain the library. You’ll likely need to refactor code and front-end architecture.
2. At the same time, set up processes. How will you share information with the team? Promote the pattern library and the shared design language within the team and encourage their use. Make sure onboarding includes an introduction to the design system.
3. Make the system’s progress visible to the entire team.
4. Create a culture of knowledge sharing. You can do this through dedicated Slack channels, newsletters, regular syncs, or workshops.

Chapter 8
Systemizing functional patterns

Systemizing starts with an audit of the patterns that exist in your product. You can do this in different ways, but the author suggests grouping them by their purpose.

It’s better to do an audit when the interface won’t change drastically shortly and there are no obvious UX problems. Such issues can interfere and distract.

To begin, identify your main screens. Then list the elements on those screens and group them by the function they serve. Keep the level of detail roughly the same for each. From these groups, you can pick out patterns. Some things can be combined into one pattern; others can be standardized into a single style.

Name the patterns. When choosing names, think about whether a pattern will be reused in different contexts. For example, “Button” is used everywhere, many times. However, a content card for a book, movie, or exhibit is a more specific component. The more often a pattern is reused, the more general its name can be. The more specific it is, the more the name should hint at its uniqueness.

The content structure of a pattern is the set of items it contains — text, images, labels, tags, and so on. Several patterns with a similar structure can be turned into a single component with variations. By looking at this structure, you can decide if a pattern should exist as a separate part of the system or not.

During this process, you need to keep deciding which patterns serve which tasks. You also need to decide how many variations each component can or should have. This is a team effort that sets important differences and usage rules for the system.

Chapter 9
Systemizing perceptual patterns

Perceptual patterns, as the author calls them, include colors, typography, spacings, corner radiuses, tone of voice (TOV), iconography, illustrations, photos, and sounds. All these elements shape how users perceive the brand in the product. They are the foundation on which all components are built.

The most effective systems match the team’s core design principles – for example, “timeless, not cutting-edge.” A good exercise is to think about how a pattern aligns with your chosen principles.

For each perceptual pattern, start with its purpose. Collect and group usage examples. Then identify patterns and write guidelines. The approach is the same as with functional patterns.

Example: Color palette. Start by seeing how colors are used in your product. Break them into logical categories: buttons, links, text, backgrounds, and dividers. After that, define the main patterns for using color. Remove shades that have no real meaning. Check colors for accessibility. In the end, write guidelines for using color in the interface.

Example: Animations. Do the same by auditing all animations in the product. Make a table of screenshots, animation types, timings, and motion settings. Then define the patterns for different uses – timings, animation types — and document them in guidelines.

Example: Tone of Voice. TOV is how the product talks to the user every step of the way. Again, start with an audit. Gather important text from the interface and determine the communication patterns that match your brand. Then describe principles and guidelines for writing text. It’s a great idea to include lots of real text examples for different situations.

Chapter 10
Pattern libraries

As already mentioned, a pattern library is not the design system itself but a way of documenting patterns. Still, it’s a crucial part of the system. In this chapter, the author looks at different ways to organize a pattern library.

Content. Focus on the content. Gather an MVP version of your design system and its documentation as soon as possible. If collecting the entire system at once takes too long, start with screenshots and gradually build components from there.

Organizing patterns. At first, how you group and organize your library is not that important because you will likely change it later. You just need to agree on a basic approach. Some common methods are:

1. Abstracting Perceptual Patterns. Separating functional patterns (components) from styles is a common approach in many design systems.
2. There are also a few ways to organize functional patterns. The simplest is alphabetical order. A slightly more complex option is by purpose — for example, forms, promo elements, cards, controls, etc. Another option is a hierarchical approach. A classic structure breaks system elements down by complexity: Atoms — styles; Molecules — basic components; Organisms — large components made of molecules; Templates — layouts for interface blocks or even complete pages made of organisms and molecules.

Documenting patterns and styles. Keep it simple to start: the component or style name, its purpose, an example, and variations. Later on, you might add versioning, contributors, related components, dos and don’ts, components parts, and so on. Many existing design systems can give you ideas for documenting components.

Workflow. Here are a few points to consider:

1. Set up a process for adding new patterns and define criteria for adding them. One example of a criterion might be reuse: a pattern is added only when it’s reused a second or third time. Of course, you can also consider potential reuse. The key is to keep the process balanced.
2. Decide who is responsible for the design system. In a distributed team, you need a process so that incoming changes don’t lead to inconsistency. With a dedicated team, there are usually curator and producer roles who share responsibility for decision-making.
3. Keep the design library and codebase for the design system aligned. Ideally, they should be as synchronized as possible, including their content and naming.
4. Make sure all elements, documentation, and master design files stay up to date.
5. The component library should be the single source of truth for everyone — developers, designers, QA, and product managers.

–

In the context of this article, by "vision," I mean how the product should work, look, and bring value in the long run. This is not about business strategy but about understanding how that strategy translates into the product itself.

Building a product without a vision is like constructing a house without knowing what it should look like in the end or endlessly rearranging furniture in an apartment without a clear idea of the overall interior design.

Metrics are numbers that reflect how users behave within the product. They are important, but they have limitations.

First, user behavior is not always easy to explain and is often subject to misinterpretation. Teams tend to come up with rational explanations for any change, even when the real reasons might be completely different. Here are two completely opposite conclusions that could be drawn from the same fact:

• We made the video larger → users got stuck watching it, which caused button clicks to drop.
• We made the video larger → users understood the content better, which led to an increase in button clicks.

Which one is correct? Maybe both? Maybe neither? That’s the problem.

Second, metrics are not the most reliable tool in the short term (up to six months). In most products, experiment results are evaluated around 14 days after launch. Unfortunately, such short time frames often lead to situations where a follow-up experiment in 3–6 months shows that the initial effect has either disappeared or even reversed.

Shopify has found that 30% to 40% of experiments that show positive short-term results have no long-term impact. Initial lifts can be misleading, and some of your “losers” might actually yield unexpected long-term value. Lenny’s Podcast, Archie Abrams (VP Product, Head of Growth at Shopify)

And here’s the problem. A vision is rarely implemented all at once; it usually happens step by step. In this case, if you only focus on numbers, the first step might look like a "failure" without the second. The team gets stuck in endless discussions and analysis, and in the end, the business decides that the idea doesn’t work, causing the entire concept to collapse.

An obsession with metrics leads companies to fear temporary dips. This is especially true if your time-to-market is long, but you’re still operating under the pressure of quarterly reports to investors, where any drop in numbers is seen as a disaster.

In response, product teams come up with hacks. One of the funniest things I’ve seen is when a complex experiment that initially showed a statistically significant negative result is split into three smaller steps, each of which is "gray"—meaning not statistically significant. Since none of them alone show a clear negative impact, the experiment is considered acceptable. Voilà! The team still implements the change they wanted, but without an "official" failure—although they’ve now spent three times as much time on it.

Vision is more than just metrics. Implementing a vision should create new opportunities and growth points, and that’s a good thing — even if metrics temporarily decline. Metrics are there to ensure you’re not making a catastrophic mistake, but if they fluctuate by ±2–5%, that’s normal. Newness, habit changes, and user adaptation — there could be many reasons for small shifts.

Ideally, a vision should be launched as a complete update rather than in small pieces. That’s how companies like Airbnb, Figma, or Sketch do it — releasing updates once a quarter or every six months. This helps avoid pointless analysis of intermediate metrics and saves teams from stressing over every number.

At the end of the day, metrics are a tool, not a goal. A product doesn’t thrive on numbers — it thrives on how it improves users’ lives.

Additional links

Lenny’s Podcast. Archie Abrams, VP Product, Head of Growth at Shopify

Companies should step off the quarterly report treadmill. Nicolai Tangen

Airbnb 2024 Winter Release

Karri Saarinen’s 10 rules for crafting products that stand out

–

How Many People Do You Need to See Trip on Your Carpet Before Fixing It?
Jim Lewis, PhD and Jeff Sauro, PhD

In general, this article is about how to make decisions about eliminating problems based on research, and it emphasizes that even knowing about a problem—without direct research evidence—is already a reason to fix it. However, it also made me think a bit differently.

From time to time in my work, I come across debates about the effectiveness and reliability of UX research. The main argument is that it’s impossible to interview just five people and then draw reliable mathematical conclusions about existing issues, so why waste time on UX research?

UX researchers bear some responsibility here because they often avoid numbers and forecasts. They even write in their recommendations, “Don’t say how many respondents experienced the problem,” since everything gets complicated by the purity of the experiment, sampling, and so on. You can understand their caution, but it doesn’t always foster trust.

That’s why it’s important to remind ourselves and others, from time to time, that any research result comes with its confidence interval and is mathematically supported.

For example, if a study shows two problem triggers in a sample of just five people, then the confidence interval, according to the Clopper-Pearson method (with 95% confidence), ranges from 5.27% to 85.34%. In other words, if we extend the study to the entire audience for which this sample is relevant, with a 95% probability at least 5.27% of users will encounter the problem.

Have you ever seen a business dismiss issues affecting 5% of its core audience? It’s hard to imagine, yet I’ve seen exactly this kind of attitude toward research in conference rooms. If you ever run into the same thing, send them this article.

Balancing Text In CSS
Ahmad Shadeed

This article covers an important improvement in CSS that allows you to balance lines of text when they wrap.

First of all, I can’t help but say how much I admire the people who put together such in-depth articles, complete with interactive examples and all kinds of different content blocks. On top of that, they do it regularly and with impressive consistency.

As for the article itself, from a designer’s perspective, I’m really looking forward to text-wrap: pretty moving from “Limited availability” to “Baseline” so we can finally use it by default in all projects and basic settings.

I’d only recommend using text-wrap: balance if you have a clear reason to do so because the breaks it introduces often look worse than those slightly odd hyphenations.

The rise of the generalist
Carly Ayres

The main idea of the article is that the rise of AI will increasingly lead to the emergence of generalists across different professions. One of the first signs of this trend is the appearance of so-called “Design Engineers.”

I completely agree with the article’s message. In fact, I notice these same shifts in myself, moving right toward that well-known “design engineering.” And I have three main points on this topic.

First. The product trio will fall. If I’m a product designer with plenty of experience who’s gained developer skills through AI, the purpose of product management also starts to blur for me. I can build the strategy, come up with the design, create working prototypes, present them, groom with the development team, oversee implementation, and evaluate the results—all on my own.

Second. We’ve come full circle back to engineer-inventors. In the past, these were the people who did the entire process: drawing up blueprints, building prototypes of their inventions, and launching them into production. Later, as technology got more complex and economic processes sped up, this profession broke down into specialized parts. The product trio is one such piece. Now AI is bringing it all back together. The future of indie hacking and one-person companies is already here.

Third. Inside modern ultra-capitalist companies that focus on efficiency, I don’t see a bright future for these people. These new engineers will end up doing the work of three, yet still receive the same salary plus maybe a small 10–20% bonus. The problem is that even with AI, our brains have limitations, and switching contexts isn’t easy. I predict a push to learn new skills just to stay “in the market,” which in turn will lead to more burnout, depression, and rough transitions between professions.

Design artifacts
Robin Rendle

I see two main ideas in the article:

Create design artifacts only when they help move the design forward and support decision-making.

Producing artifacts that nobody cares about—just out of habit or because of some process—is pointless.

I fully agree with the first point. It reflects the classic understanding of any research: the goal is to influence a decision. If we already know that, no matter the result, it won’t have an impact, then the research itself is pointless.

The second point isn’t so straightforward. You can’t always predict what effect these artifacts might have. Every task is unique. Sometimes, the outcome ends up being useful, even if it’s not obvious at first. Moreover, an artifact might be underestimated not because it’s weak, but because the company’s decision-making process is broken.

So here’s how I’d put it: If your artifacts aren’t getting the attention they deserve but you have the resources, the interest, and the belief in their importance, don’t stop creating them. Keep presenting them to colleagues and stakeholders every time. Gradually, you can change how these materials are perceived, show their value, and possibly influence a shift in the decision-making approach.

User Research Myths
Jon Yablonski

The article covers five myths about user research. Overall, I agree with them, but the very first myth: “It takes too much time,” caught my attention.

Of course, we need to clarify what exactly “too much time” implies. But from my point of view, this isn’t a myth.

Qualitative research involving real interactions—like interviews and UX testing—does take a significant amount of time. For instance, if you’re recruiting a suitable sample from a B2B startup’s audience, you probably wouldn’t say it’s quick or cheap to find even five respondents.

With today’s “democratization” of UX, research often gets handed off to designers who might not always have the skills or experience of a professional UX researcher. This slows down an already time-consuming process. In addition, many designers aren’t comfortable doing calls “in the background,” especially given that many of us are introverts.

If by “research” we mean “just chatting with a handful of people,” then sure, that’s quick. But if you don’t follow the proper guidelines for conducting user research, the results will at least be invalid, and at worst they can be harmful, misleading, and even discredit the design team due to mistakes.

–

This is understandable. Beauty can’t be measured. You can’t easily sell it to stakeholders. You can’t be objective about Beauty. It’s hard to create, and in today’s world, it often costs almost nothing. Every CEO, CPO, and product manager will ask how it makes money. How much? What’s the ROI? Who knows.

Secondly, we live in a world where designers must serve business needs. Over time, we start evaluating each other by how much revenue we’ve generated. You’re told not to be like those ’Dribbblers’ creating ’useless’ pictures. But after a long day, we find ourselves looking at those very pictures and concepts, searching for inspiration. And somewhere inside, we ask, ’Why not?’ or ’What if?’

It’s like an internal trauma. We can’t quantify Beauty, so we retreat into the safety of our functional, efficient swamp. We hold ourselves back, we censor our creativity. We stifle everyone entering the profession, pushing them to follow the same current of conformity. Everything measured in dollars and green metrics feels straightforward — explainable, mathematical, statistical.

Designers like to think that it’s not about how it looks. It’s about how it works, or how it communicates, or how it changes the world. All true, except it’s also about how it looks. The artifacts we make are the Trojan horses that deliver our ideas to an unsuspecting public. Making them look beautiful — or engaging, or funny, or provocative — is anything but a superficial exercise. Michael Bierut. Now You See It and Other Essays on Design

Yet people don’t engage with metrics or calculations; they experience the product. People want to feel cared for, they want to play and experience positive emotions again and again. And when they only see functionality, they feel bored.

When creating products, especially large ones aimed at a broad audience evaluate your projects, screens, and elements. Ask yourself: are they beautiful or ugly from an aesthetic perspective? Don’t forget the emotions. Think of screens as buildings on the streets where people constantly walk. You wouldn’t want to live in a dull building, despite all its functionality. You’d like to see quality architecture every day and cultivate your taste. This is how we push our future beyond mere functionality, to create products that are not just effective but aesthetically pleasing.

His priority seemed always to be the creation of objects that were beautiful rather than simply functional. He was constantly questioning how things should be. “He hated ugly, black and tacky electronics,” recalled Grinyer. “He hated computers having names like ZX75 and numbers of megabytes. He hated technology as it was in the 1990s.” Leander Kahney. Jony Ive: The Genius Behind Apple’s Greatest Products

I don’t claim to be a super expert or a designer who can create exceptionally beautiful things. But I try because I want to see a world that’s beautiful, not just efficient. Of course, I’m not dismissing business needs, user needs, or functionality. I see them as a foundation or a trampoline, not the final solution.

We need a balance — it’s time to reclaim space for Beauty.

Additional links

“Beauty”. Stefan Sagmeister, Jessica Walsh

“Now You See It and Other Essays on Design”. Michael Bierut

“Jony Ive: The Genius Behind Apple’s Greatest Products”. Leander Kahney

“The obsession over craft” post from David Hoang

–

Intercom's application of the Jobs to Be Done framework shifts the focus to the motivations and outcomes that drive user behavior. Unlike traditional user stories, which often ignore context and concerns, JTBD uncovers deeper insights by asking the right questions.

The book shares how the company uses this method and how it can lead a product team to exceptional results

Criticism of the persons method

We never use personas in Intercom. They artificially segment audiences and focus on audience attributes rather than on their motivations and the results they want to achieve. In other words, personas talk about who does what, but they don’t talk about why someone does something. And that’s much more important.

Personas work well if the product's user base can be broken down into specific segments. In this case, personas need to be carefully crafted. Each line in the description should serve a purpose, and the entire team, including stakeholders, should be involved in their development.

For the same reason, the persona method can be good for advertising. However, in product development, personas work poorly because products do not match people; they match problems.

User stories have three big problems: 1. They use personas. 2. They couple implementation with motivations and outcomes. 3. They ignore context, situations and anxieties.

Job stories and team around JTBD

That's why we invented Job Stories: [When __][I want to __][so I can __]. “When __” focuses on the situation, “I want to __” focuses on the motivation, and “so I can ____” focuses on the outcome.

Before each project starts, we create a one-page project brief that explains what we are doing from the user's perspective and focuses the team.

Here's a step-by-step plan for how to implement this approach:

1. Start with the high-level job;
2. Identify smaller jobs that help resolve the high-level jobs;
3. Observe how people solve the problem (the job they are currently using);
4. Come up with a Job Story to investigate the causality, anxieties, and motivations of what they do now;
5. Create a solution that resolves that Job Story.

About JTBD research

Everyone on the team should talk to customers. Designing successful products involves researching how people solve problems now, in what context, and understanding causality, anxiety, and motivation.

It’s helpful to find out what tools a person uses, what their experience is like, and how the process works. Asking your customers “Why?” is the best way to learn their deepest needs. With each new question, you may discover new insights.

One of the important parts of JTBD research is identifying the first thought that started the search for a solution or the recognition of an existing problem. This is easy to track in the example of physical products, but with software, it is not so simple, because there can be many different factors that influence the buyer. JTBD research helps you to uncover something deep — motivation, and real problems of people. This is something more than simple user research.

It is important to look for the person who is directly affected by the problem and decides to fix it. Talking to users of the product is useful, but only by talking to the decision maker can you understand the motivation and true reasons.

You’re really looking for the right people to talk to, the main decision maker

Typically, when researching the value of a product, the first three layers are important: Usefulness (why do you need a drill?), Usability (why do you need holes in the wall?), Desirability (what does it give you?).

Focusing on how people use a feature or product, without regard to categories, can quickly reveal how to improve the product or feature. JTBD also helps you better understand the competitive landscape. Ask yourself, “Who else is trying to solve the same job my product is trying to solve?”

The book also provides sample questions that can be used to conduct a JTBD study. For example, “Once you figured out you wanted to buy a new solution, did you do much research to figure out which tool was right for your company?”, “Were you the only one who was looking for something else at that time?” , “Where did you first hear about the tool you picked?”, “Can you recall how you came to purchase the specific tool you did?”, “When you were looking around, did you (or anyone else) try out any other tools?, What were they?”, “How long did you look around before you clicked “buy” on the website?”

About switching to a new product

People don't buy a product. They switch from something old to something new. That's why it's easier to make things people want than it is to make people want things. But to reduce the fear, anxiety, and doubt of switching to a new product, it's worth building an argument around the struggling moments your customers are experiencing.

ReWired Group identified four forces that influence the purchasing decision process: The push of what is happening currently. The pull of a new solution. The anxiety of what could happen. The attachment to what you currently have. Accordingly, product advertising should be built around these forces.

Many purchases are made out of habit without considering alternatives. For example, people buy the same coffee at the same cafe every morning out of habit. People are not against progress, they just prefer inertia.

What should a product be like and how to integrate the product into the user flow

If a product does too little, there is no point in buying it. If a product does too much, it will most likely collide with other products that do some of the work better. Finding the right balance is an important task for the team.

That said, compared to physical products, it's much easier for digital products to go off the rails and quietly turn into a feature-packed monster, but if the product doesn't do its job well at its core, adding new features will only make things worse.

Any new products need to be 10 times better to get mainstream adoption. It’s only at that point switching becomes a no-brainer.

The product should be as simple and effective as possible. However, you should be wary of MVPs with limited functionality, which can be called “a feature, not a product” or a narrowly specialized product.

Products are built into the user's workflow. This means they have a beginning and an end of use. You can only determine these points if you know the entire buyer's workflow.

The product should stop when one of the following is true: the next step overlaps with the work of large, well-known services and you don’t want to compete with them, the next step can be done in many different ways, the next step is done by other users, you can’t bring any value to the next step. It’s worth remembering that if there is no decision-making or insights in a series of steps, these steps may also need to be removed.

–

Below is a set of theses from the book, divided into chapters by meaning.

On innovation, causality, user progress and JTBD

Progress Theory. Customers don’t buy products or services. They hire them to make some progress in their lives or work. They have some job to do and they hire a product to solve the problem. The job is some progress that a person is trying to make in certain circumstances. It’s not always a problem.

The engine of innovation that makes companies great works by understanding causality, not guesswork. The theory of disruptive innovations won’t lead you to where to look for new opportunities. But the theory of Jobs to be Done does because it’s based on the causality of human behavior. And so it can predict behavior, not explain success.

Causality is the foundation, not the data. Despite huge amounts of data, if companies do not understand the reasons why users hire their products under certain conditions and choose other products under other conditions, this data is unlikely to help create innovation. The fact is that when analyzing data, without understanding causality, we are prone to assumptions, approximations, and extrapolations, and can misinterpret the data. A good example is that based on micro-assumptions, people in the 18th century misinterpreted the changing positions of celestial bodies, thinking that everything revolves around the Earth.

“What job are you hiring this product to do?” is the best question to ask a business. For example, you might buy a magazine to pass the time in a doctor’s office or because you are a sports fan and want to read sports news. But in one case or another, you have some job that you want to hire this magazine to do.

JTBD stories. Buyers won’t be able to tell you what they want, but they can describe their struggles well. They can be written in the format: “Because of this, we did that ...”

A job can only be defined and decided on in relation to specific circumstances. Therefore, a job is inextricably linked to the user’s context: where is he, what did he do before, what will he do after, what is he doing in the process, who is he with, what are the social, cultural, or political frameworks around him? It can also be a period of life: retirement, graduation from college, marriage, or the birth of a child. These circumstances are a fundamental part of the concept of a job.

About the importance of social and emotional. We often focus our efforts on the functional and practical side of a product. But emotions and the social side often outweigh functionality.

Needs, like values, are not a job. Needs are too general, they do not include circumstances and context. Our values are also too abstract.

It’s not who did what, but why that matters.

We do not create jobs. Jobs themselves are constant, but the ways to solve them change dramatically with the development of technology. For example, look at how our communication with each other has changed from spoken language to letters, telegraph, telephone, email, and messengers.

Job theory is not suitable when current products work perfectly. And also when solutions lie in the area of mathematical analysis, and not in the area of social, emotional, and functional needs.

About data

Substituting Excel tables for user understanding. A separate problem with data is that while there is no data, product managers tend to ask the question “Why does something happen the way it does” and look for an answer in user responses. But as soon as data appears, it becomes much easier to look at Excel tables than to talk to people. As a result, managers begin to manage numbers, especially in large companies, where managers may never even meet customers. If a company enters the stock market, then the numbers begin to manage the company. This makes the company vulnerable to those who think first and foremost about users.

The fundamental problem with data is that quantitative data is more credible than qualitative data. But is quantitative data objective? For example, many studies are based on data from companies’ financial statements. Is this objective?

Data is not a phenomenon. The main function of data is to explain a phenomenon. Considering quantitative data to be objective is wrong, if only because data does not exist initially. All data is collected by people. People decide how to organize it, how to present it, and how to extract information from it. And all this can easily introduce errors in interpretation.

The same managers can make a company great and lead it to destruction. The question is what approach is used in working with innovations. Unfortunately, the pressure that innovators are under often leads to decisions that please investors and rapid growth, and not users.

Businesses focus on data on how their product sells in different markets, to different audiences, and with what margins. However, all this data does not provide an idea of what kind of job the product does for users and how well.

About metrics

Causality leads to The Right Metrics. It’s tempting to think that we recognize patterns in data, but too often businesses feel comfortable with correlations rather than casualities. However, it’s the shift from guesswork and correlations to understanding the causal mechanism that changes everything about how we solve problems and prevents new ones from arising. A properly described job will lead to the right process that will generate the right data that answers the question: “How are we doing?”

The right metrics are user-oriented. Instead of focusing on internal business financial and production metrics, it is better to think about external customer-benefit metrics. Think about what is important to the user and formulate metrics from his side. Conversions and retentions are very simple clear and tempting, but you cannot confuse business efficiency with user effectiveness.

About features

Features are not the main thing. By focusing on the parameters of the product, for example, its features, we think that we are improving the product. However, only by understanding for what job people hire the product and in what specific circumstances can we achieve an a-ha moment. These insights are fragile, they are more like stories than statistics. But through them, you understand the user, look at the world through his eyes.

About the feature race. If you ask users about features in a product, they can suggest hundreds of changes, which will lead to a false feature race. But you should ask not about features, but about experience, about deep problems or progress that the user needs in life.

About the company and the processes around work

When the product job is revealed, experiments are conducted and guides for developing the product or service are formed. And then the company culture is formed around JTBD. This leads to the fact that even if a competitor can copy the product, he will not be able to copy the processes that allow you to implement innovations.

Purpose Brand. This is a brand created to become a synonym for the job user. When you hear the names of such brands, you immediately understand what they were created for. Purpose brands provide remarkable clarity. A well-developed purpose brand will stop a consumer from even considering looking for another option. They want that product.

Process as a competitive advantage. Resources can be bought or sold. Products can be copied, but through integrated processes, companies create an ideal experience and competitive advantage. Processes are created from hundreds of small decisions and cannot be easily copied.

Structure companies around jobs. Companies can be built not around artificial departments or divisions but around users’ jobs. If you don’t focus on users’ jobs, the organization will sooner or later become bogged down in individual opinions and politics.

The company’s mission is usually vague and does not help in making daily decisions. But a clear job spec helps. It helps both high-level managers and each employee understand what to do.

Amazon’s Press Release Framework. Innovation at Amazon often starts with a mockup of a “press release” that is presented to the team that will work on it. The press release contains all the details, user experience, and processes.

About competition

When a customer decides which product to hire for a job, they have something like a resume in their head for your product and for any other competitor. Moreover, people can hire the same product for different jobs in different circumstances.

The product does not define the customer’s job. The product solves it. As a rule, jobs, especially widespread ones, can be solved in different ways. If you concentrate on your product and not on solving the user’s job, sooner or later you can lose the initiative, because someone else will solve the problem better, perhaps in a completely different area and with different tools.

Competitive landscape. By studying jobs in detail, you can understand that competition often goes beyond the usual understanding. For example, products from different categories, such as Facebook and cigarettes, can compete with each other in certain circumstances. For example, Netflix competes with everything that helps people relax, and Uber competes with the subway, the bus, or calling a friend. So if you don’t know what and who you are competing with, how can you know that you are better than other alternatives and create something innovative regularly?

Competition with inaction. Some companies can compete not only with other companies or activities but also with nothing. Because the status quo is also a strong competitor because you can always choose to do nothing.

Companies become vulnerable to disruptors when they start spreading themselves thin and creating many products for different users. Because a disruptor focuses on a small number of jobs and does them well.

Ways to detect jobs

• Take jobs in your own life
• Find jobs uncovered by-products. People often don’t hire a product for a job
• Where a problem is so upsetting and frustrating that they try to solve it themselves
• Negative jobs. Where people don’t want to do something
• When products aren’t used for their intended purpose

The moments of struggle, nagging tradeoffs, imperfect experiences, and frustrations in peoples’ lives—those are what you’re looking for. You’re looking for recurring episodes in which consumers seek progress but are thwarted by the limitations of available solutions.

About people and their behavior

Negative feedback. If the product does not satisfy the user’s work, it’s not so bad. The problem is that there is always a risk of being forever entrenched in a person’s mind as an unsuitable product, or even getting negative feedback and ruining their reputation. Research confirms that 95% of people read reviews, and for 86%, reviews are the main factor in making a purchase decision.

People sometimes speak and act in direct opposition. If you ask people if they consider it important to take care of nature, everyone will answer positively.

To hire something, a person will most likely have to fire something. What to fire and why this should happen are important questions.

Forces of change. When a person switches to a new solution, two pairs of opposing forces fight. The first pair is the fight against the problem and the attractiveness of the new solution. The second pair is the habit of the existing solution and the anxiety to try something new.

About theories

Good theories lead to insights. You can produce insights if you have a set of good theories. A good theory is the best way to work with problems because it is like a universal key that allows you to solve a variety of problems by formulating questions correctly. Good theories are not meant to teach us what to think. Rather, they teach us how to think.

–

The book is divided into two parts. The first part, “The Method” provides an overview of the process and how to organize Growth Teams.

The second part, “The Growth Hacking Playbook” offers detailed tactics for implementing the method, including separate chapters on user acquisition, activation, retention, and monetization, as well as how to maintain and accelerate growth once achieved.

Problem formulation

One of the most popular illusions is the “Fallacy of the Field of Dreams” when entrepreneurs believe that creating an outstanding product is enough, and customers will come to it themselves. However, this is far from reality. Many startups face high churn rates. Traditional marketing methods, including print and TV advertising and new online formats, are losing their effectiveness.

69.8 million Internet users in the US (up 34 percent year over year), including nearly two out of three millennials, report using ad blocking software.

At the same time, a significant portion of companies continue to focus on so-called “vanity metrics” that look good on paper but do not reflect real growth in product usage or revenue. For example, the number of visits to a site may impress but does not indicate the quality of user engagement.

The lack of focus on data analysis leads to companies relying on Google Analytics, which cannot effectively integrate various data sources, such as sales and customer service. This limits their ability to make valuable discoveries that could lead to growth.

In most product companies, the task of increasing user activation and retention falls not on marketers but on product and engineering teams that focus on building features that help users fall in love with the product. However, these groups rarely collaborate, creating additional barriers to successful growth.

Growth hacking helps overcome these challenges by combining data, cross-functional teams, and innovative methods to achieve real results in customer acquisition and retention.

What is growth hacking

Growth Hacking is a method that can be easily adapted to the specific needs of any team or company, regardless of their size or stage of growth. It allows you to extract specific, relevant insights into user behavior in real time from data. These insights can be used to shape growth strategies.

This approach has become the basis for a methodology aimed at accelerating market growth through high-velocity experimentation. The philosophy is similar to that of Agile or Lean Startup. Both have transformed business models and product development, while Growth Hacking focuses on customer acquisition, retention, and revenue growth.

The most significant successes in this area are achieved through a combination of programming knowledge, data analytics skills, and a strong marketing background. Key elements include creating a cross-functional team that breaks down traditional barriers between marketing and product development and using both qualitative research and quantitative data analysis to deeply understand user behavior and preferences.

Growth hacking is not about throwing ideas against the wall as fast as you can to see what sticks, it’s about applying rapid experimentation to find and then optimize the most promising areas of opportunity.

The key aspect of Growth Hacking is the rapid generation and testing of ideas using rigorous metrics to evaluate results and make further decisions. This method allows companies to grow fast without spending money on outdated and expensive marketing campaigns with questionable business value.

About processes in growth teams

One of the important rules for starting high-speed experimentation is to understand that the product has reached the Must-Have state. For this, it is useful to conduct a so-called Must-Have Survey. If 40% of users answer that they will be “very disappointed” if the product is not available, we can assume that the product has sufficient must-have status. However, if the product is already far beyond the initial development stage, such a survey is not recommended. Imagine if Facebook publishes a survey tomorrow and asks about disappointment from its absence.

As the product develops, it is important to regularly monitor Retention metrics to notice problems in time and not relax, even if a stable base of loyal users has been achieved.

Analysis of user behavior helps to understand what exactly they do but does not always reveal why they do it. Therefore, for successful growth, it is critical to understand what the main value of the product is, who its target audience is, and why it is irreplaceable for them. You need to communicate with users to study their true needs. To do this, you need to “get out of the building” and find out what customers want from the product.

Even the most sophisticated analysis can really only tell you definitively what users are doing, not why they’re behaving that way.

Growth teams play an important role in experimenting with new features and collecting feedback, whether through prototypes or beta versions. Experiments to validate ideas should be low-cost, in the form of a “Minimum Viable Test” (MVT). This could be a prototype or demo that can be used to see how users react. It is important to record the results of experiments in a report and store them in a knowledge base so that future teams can refer to past experiences.

Effective analysis requires creating what’s often called a data lake or data warehouse, where all customer information is collected to identify distinct user groups and their unique behavior patterns. An example of the importance of good data is the Facebook team’s decision in 2009 to pause all experiments for a month to focus on improving data collection and processing processes, highlighting the key role of accurate data for product growth.

Now a little about prioritization and hypothesis generation. Prioritization of ideas for testing is carried out according to the ICE (Impact, Confidence, Ease) system, where each idea is assessed based on its impact, confidence in success, and ease of implementation. During prioritization, it is also worth paying attention to the impact of the experiment per unit of time. For example, you should not “move buttons”, especially at the initial stages, when traffic is low. Such experiments will require a lot of time for testing and will most likely have little impact. It is better to postpone them to a later stage.

When generating hypotheses, it is worth sticking to a standard form and description, which should contain information about what you want to test, why it should have an impact, and how to measure it.

Based on the results of the tests, if the results are equal, preference should be given to the control option in order to avoid potential risks.

Growth teams should also periodically switch to different stages of the funnel — from user acquisition to activation, and then to retention. Many of the best ideas arise unexpectedly, and their implementation requires flexibility.

About the structure and organization of growth teams

Effective Growth Teams require a multidisciplinary approach, bringing together specialists from different departments, such as marketing, product, engineering, and analytics. This facilitates collaboration and helps teams share knowledge and better understand each other’s views and challenges. This interaction is especially useful for generating new ideas, where, for example, engineering and marketing can work together to create interesting “hacks” to experiment with.

Growth teams should bring together staff who have a deep understanding of the strategy and business goals, those with the expertise to conduct data analysis, and those with the engineering chops to implement changes in the design, functionality, or marketing of the product and program experiments to test those changes.

Typically, product teams follow a clear roadmap for updates, including feature or onboarding process improvements, but as the company grows and processes become more complex, such teams may work less flexibly.

Creating a separate Growth Team with its leader allows you to focus on specific tasks necessary for growth. This leader, combining the roles of manager, product owner, and analyst, is responsible for choosing priorities and key metrics that the team will strive to improve.

There are two main organizational models for Growth Teams. Within the first, functional structure, teams report to product management and focus on experiments to improve all stages of the growth funnel.

The second model involves the allocation of an independent growth team that reports directly to the VP of Growth or even directly to the CEO. Such independent teams are easier to form in the early stages of the company, while organizational structures are not yet fixed.

It is worth mentioning separately the involvement of external experts. These individuals can help the team think outside the box and offer new perspectives. However, handing over key growth responsibilities to outsiders carries risks—they may not have the authority or motivation to drive long-term, sustainable growth. Growth Teams also need support from senior management to avoid bureaucracy, conflict, and inertia that can slow down growth. External teams will have a hard time getting that support.

Fundamental growth equation

To grow, it’s important to boil down complex business operations to a simple formula that captures the key drivers of growth. This allows growth teams to focus on key signals, separating them from the data deluge.

A key element of the formula is the so-called North Star metric — a metric that most accurately reflects the core value delivered to customers. It helps the team stay on track and not get distracted by irrelevant metrics that may be attractive, but do not contribute to real growth.

Creating visual reports and dashboards that reflect progress on North Stars and key growth levers is important. This makes the data more accessible and visible to everyone in the company, helping to ensure that data-driven thinking becomes part of the culture at all levels of the organization, not just the growth team.

Marketing channels

Successful marketing requires taking into account the specifics of your business model and user behavior, such as types of Google queries, preferred stores, and social networks.

One method of prioritizing channels is to rank them by six factors, assigning each channel a high, medium, or low score, and then calculate the average to prioritize channels for experiments:

1. Cost — how much do you expect to spend to run the experiment
2. Targeting — how easily can you reach your target audience in the experiment
3. Control — can you make changes to the experiment after it runs, or stop and adjust it
4. Time to run — how much time and resources will it take your team to run the experiment
5. Time to exit — how long will it take to see results from the experiment after it runs

You should also consider the cost of customer acquisition — if it exceeds your potential revenue, that’s a problem. Growth Hacking is about finding the most cost-effective methods of acquiring new customers and optimizing them for sustainable growth.

When changing focus to a new growth driver, it’s important to re-analyze the data to find unique insights for the new goal. Even if you have already found working channels, it is always worth looking for innovative methods for testing.

Aha moment

Aha moment is the moment when users begin to understand the value of the product for themselves. Why they might need it, and what benefit they can get from using it.

98 percent of traffic to websites does not lead to activation, and most mobile apps lose up to 80 percent of their users within three days.

To understand whether a product has “aha” potential, find loyal users by collecting data and feedback, and then understand how these people use the product, and what value it gives them. It can also be very useful to compare data on how users who tried the product and became regular users differ from those who tried it and left.

Analyze each point of the user’s path to reaching the aha moment. Build a funnel report measuring conversions at each stage. Even if you think you already know everything, after this exercise you can find many surprises.

A simple formula worth remembering: DESIRE — FRICTION = CONVERSION RATE

Language

Sometimes achieving growth results requires not a change in the product, but an adjustment in the communication of value to potential and current customers. Even small changes can have a significant impact.

Simply changing the language from “Sign Up for Free Trial” to “See Plans and Pricing” netted 200 percent more sign-ups.

The initial phase of customer growth involves achieving two key fits:

1. Language/market fit, where the language used to describe the product resonates with the target audience
2. Channel/product fit, where the chosen channels, such as search advertising or content marketing, effectively deliver the product to the right audience. This covers all aspects of communication, from emails and notifications to promotional materials and text on product interfaces.

The key requirement for language is that it answers the customer’s question: “How will this improve my life?” Successful headlines and copy can have a significant impact on reach and perception. Therefore, when testing growth strategies, you should focus on the language and style of communication and then move on to other aspects.

“A good headline can be the difference between 1,000 people and 1,000,000 people reading,”

New user experience

The basic principles of creating and optimizing the New User Experience (NUX) include an approach in which this stage is perceived as a separate product, requiring a unique design. The first landing page should clearly reflect the relevance of the product to the query, show its value to the user, and contain a clear call to action.

The value of the product should quickly answer the question: “What will I get?”, and the call to action should encourage the user to take the next step. Sometimes it is useful to immediately let the user try the product, before signing up, to reduce friction and get to the “aha” moment faster.

This is your moment. You have more attention than you ever will have again, from that user, to try to teach them what your product is really about. To really help them learn the product in a meaningful way.

However, not all friction is bad — adding “positive friction” (e.g. gradual steps) helps users understand the product better and is achieved through experimentation. Methods based on Mihaly Csikszentmihalyi’s “flow” theory and the principle of gradual involvement are also effective. Such methods are constantly used in the Game industry to gradually introduce the player to the game world and the main mechanics.

The team also tested adding more text around the call to action to encourage sign-ups, inserting a testimonial from a happy Airbnb customer. This additional text actually hurt sign-ups. This is an example of a more subtle type of friction, which isn’t actually experienced as annoying, yet still deters visitors or users from taking the action you want them to. You can really only discover whether this kind of friction exists—and how it is impacting your activation rates—through experimentation.

If you decide to experiment with positive friction, it is useful to use questionnaires and gamification elements. Questionnaires with several questions aimed at the interests and problems of users create a sense of involvement and strengthen the connection with the product. Neil Patel advises limiting the number of questions to five and making them with a choice of up to four answer options, as well as adding visual elements to increase engagement.

Now users were first shown just one screen, which asked them to select five topics that they were interested in. After they made their selections, the app delivered them to a feed made up solely of that type of content, where they could practice pinning and saving items. The change resulted in a 20 percent increase in activation rate, a massive win.

The principles of forming “stored value” are also actively used: the more information users enter into the product, the higher their involvement. Useful techniques include surveys and gamification, for example, welcome questionnaires with short questions about the user’s preferences and goals.

Virality

For most products, getting users to send and accept invites requires significant initial experimentation and ongoing optimization. Successful virality is achieved through a balance between how well the product is “packaged” and its value. Finding words that will grab users’ attention is important, but true value is essential to achieving viral growth.

There are several types of virality: traditional (word of mouth) and instrumental — when the product includes features that help users invite new participants. In this case, the experience of the sharing product itself should be intuitive and enjoyable.

A product is considered truly viral if the virality coefficient (K-factor) is greater than 1, i.e. each new user attracts at least one more. The main factors of virality are payload (the number of invitations sent), the conversion of invitations, and the frequency with which people receive invitations. This formula should be taken into account when creating viral engagement cycles.

The choice of invitation delivery method is important for the formation of a natural flow of new users. The best viral engagement loops are created when invitations are integrated into the product and emerge naturally through use.

Often, you want to motivate users through a two-way reward, where both the sender and the recipient benefit. The reward must be related to the product: the closer the value of the incentive is to the product, the more effective it will be. Effective viral loops motivate users to invite others because it improves their own experience with the product.

A common mistake is not optimizing enough for the invited users. When an invitee accepts an invitation, it is important not to immediately ask them to sign up, but first to show the value of the product so that they understand why they should join.

Gamification

Gamification should be viewed as a toolkit rather than a fixed set of tactics that work for all businesses.

The key aspects of gamification include providing meaningful rewards, creating surprise and enjoyment by changing the way rewards are received and presented, and adding an element of instant gratification. Effective rewards in a gamified environment include status, access, power, and tangible rewards (such as financial incentives or gifts).

Triggers work best when they both motivate the user to take the desired action and make it as easy as possible to do so when the trigger is given. The best approach to using triggers is to provide users with information about an opportunity that is useful to them. Triggers fall into three categories based on the user’s motivation and ability:

• Facilitator — helps highly motivated but low-skilled users take action.
• Signal Trigger — targets highly motivated and low-skilled users, helping them stay on track for repeat actions.
• Spark — motivates high-skill, low-motivation users to take action.

It is also useful to consider Robert Cialdini’s six principles of persuasion:

1. Reciprocity — people tend to reciprocate favors, even if the reciprocal action is different from the original.
2. Commitment and Consistency — people who have done one action are more likely to take another, regardless of the magnitude.
3. Social Proof — people rely on the actions of others when faced with uncertainty.
4. Authority — users are more likely to follow the recommendations of authority figures.
5. Liking — people are more likely to engage with companies and people they like.
6. Scarcity — people are willing to act faster if they fear missing out on future opportunities.

Retention

To effectively retain users, companies need to find the right balance in communication: successful messages and their frequency directly affect the loyalty of the audience. In digital products, retention also increases if users find value in the product that only strengthens over the years — as in the case of Evernote, where the likelihood of users returning increases over time due to “stored value”.

Retention can be divided into three phases.

In the initial phase, the main goal is to help the user quickly understand the main benefit of the product so that he decides to stay.

Creating a deeper level of attachment can be achieved through so-called “continuous learning”. The better users master the product, the higher the likelihood of their return. An approach called “continuous onboarding” can be useful, which guides the user along the learning curve of new functionality. This approach is similar to learning to play a musical instrument or to learn a language — the product always offers something new.

According to data published by mobile intelligence company Quettra, most mobile apps, for example, retain just 10 percent of their audience after one month, while the best mobile apps retain more than 60 percent of their users one month after installation.

An important aspect is the perception of the value of rewards. Interestingly, intangible rewards (such as status or access to exclusive features) are often more effective than financial incentives. In the long term, such rewards can become habitual and valuable to users.

Finally, in the long-term phase, it is necessary to continuously maintain the feeling of value of the product, ensuring its relevance and usefulness to the user. To do this, it is useful to update the perception of the product as something “indispensable”.

A long-term retention strategy also involves a combination of improvements to current features and notifications about regular launches of new functionality. These updates and innovations (especially for SaaS products, video games, and content platforms) create a sense of upcoming improvements in users. However, messages about such innovations need to be balanced so as not to irritate with a long wait.

If a user’s activity gradually fades, they can be re-engaged through a process called “resurrection,” which is typically done through targeted advertising and emails that remind them of products or new features designed to meet their needs. When users stop interacting with the product, they can be added to the “resurrection” flow by sending them a series of messages with offers that are likely to pique their interest.

When analyzing retention rates, it’s worth comparing them to industry averages and competitor data to establish objective benchmarks and develop a retention strategy.

Accurate analysis often requires breaking the audience into cohorts — subgroups that can be analyzed based on different retention metrics. Specialized tools (such as Mixpanel, Kissmetrics, and Amplitude) can help with this process, especially if you don’t have a dedicated data analyst on your team.

Business products, such as software as a service, fare much better, with annual retention rates north of 90 percent, according to a study of private SaaS companies done by Pacific Crest in 2013. A 2013 study concluded that credit card companies in the US see annual churn rates of roughly 20 percent, while European cellphone carriers see churn of anywhere between 20 and 40 percent.

Monetization

To successfully monetize a company, it is important to conduct a deep analysis of the data to identify experiments with the greatest potential.

You need to start by building a customer journey map, which will allow you to see at what stages the client brings in the most revenue and where losses occur. After that, it is important to divide customers into cohorts, focusing on which groups bring in the most revenue. This division can be supplemented with other criteria: location, age, gender, acquisition sources, device type, first visit or purchase, etc. Instead of analyzing retention, at this stage, it is worth looking for correlations with revenue, which will give ideas for new experiments.

In some countries, for example, in the US, subscription models are perceived better than in others. This creates an opportunity to test different monetization models by region. One of the proven ways to increase profits is to offer users additional products or features.

Personalization also works for monetization: recommendations can be built, for example, using the Jaccard coefficient. What the equation says is that the similarity between two items, A and B, is equal to the size of the intersection of A and B divided by the union of A and B. However, excessive personalization can cause discomfort for users.

Another common mistake companies make is setting fixed prices, which can and should be tested like other elements of the business. It is important to conduct such experiments at least once a quarter. Dynamic pricing that takes into account factors such as seasonality, purchase history, and device type can also significantly improve profits.

The comparison pricing effect can be managed by offering intermediate options that lead users to more expensive products. For example, companies sometimes introduce a decoy product with limited functionality and a price slightly lower than the main one, which encourages users to choose more expensive offers. This is because users tend to see a high price as an indicator of quality, especially in areas such as technology and professional services. To maintain the customer experience, users must see the same version of the pricing page on repeat visits.

In some cases, such as digital products, even small payments can scare away users, and therefore offering a free tier can be more profitable. An example is the limitations of the free version: Spotify clearly shows its free users the possibilities of a premium account, pushing them to buy it.

Most freemium product conversion rates, [...] hover around 1 percent.

To increase revenue, companies can experiment with subscriptions for upgrades, virtual goods, and in-game currency. Understanding consumer psychology can also help monetize a product. The core principles discussed earlier, such as reciprocity (the desire to reciprocate a benefit provided), consistency (the tendency to repeat an action), social proof (the influence of others’ opinions), authority, likability, and scarcity, are important tools for increasing sales.

Applying these principles, for example by adding testimonials and logos of famous customers, can increase customers’ desire to make a purchase. The principle of scarcity, which creates a sense of “missed opportunity,” is also effective in pushing for action.

Finally, for growth, it is important to overcome the local maximum effect, when the result of improvements ceases to increase. Switching to a new approach, such as changing the structure of the pricing page, can open the way to higher results.

Continuous cycle of growth

Business growth is often achieved through many small successes that accumulate over time. This process can be described as a continuous cycle consisting of four main stages: first, analyzing data and collecting insights, then generating ideas, then prioritizing experiments, and finally executing them. Once the experiments are complete, the cycle returns to the analysis stage, where the results are reviewed and next steps are determined.

One of the key aspects of successful growth is the ability to increase the average revenue per customer. This allows more resources to be directed toward growth, creating a so-called “virtuous cycle” where growth itself contributes to further growth.

All growth hackers must always keep in mind that, as the growth team at Airbnb says, “love creates growth, not the other way around.”

However, companies often face the problem of “feature overload,” where the rush to add many new features results in a product that is inferior in quality. Rather than improving, feature overload can confuse users and distract them from the core value the product offers.

Research shows that having too many features can have a negative impact on long-term customer retention. For example, in a study conducted for the Marketing Science Institute, researchers concluded that companies should focus on creating more, more focused products with a limited set of features, rather than trying to include every possible feature in a single product. In this context, reducing the excess can lead to more successful results than constantly adding new features.

The right approach to growth, then, involves not only innovation and experimentation but also paying close attention to what already exists, so as not to lose the value the product brings to its users.

–