Ilona: Cześć! Witaj w kolejnym odcinku podcastu Design i Biznes. Dzisiaj będziemy rozmawiać o problemach, które występują w startupach i scale-upach.

Skąd pomysł na taki odcinek?

Przez pierwsze pół roku 2023 zrobiliśmy analizę i tzw. reverse engineering, który polegał na przeanalizowaniu projektów, z którymi pracowaliśmy do tej pory w Zimie. Ale też spojrzeliśmy na nasze projekty, w których wcześniej pracowaliśmy jako freelancerzy, albo w kolaboracji.

I na podstawie tych danych stworzyliśmy listę najczęściej występujących problemów w startupach i scale-upach.

Radek: Dlaczego przeanalizowaliśmy sobie tę listę?

Otóż zauważyliśmy pewną właściwość. Nie jest tak, że zatrudnienie najlepszych specjalistów, programistów, projektantów, product ownerów… wystarczy, aby osiągnąć cel i efekt.

Zdarza się, że sam design nie wystarcza, żeby rozwiązać problemy. Albo nie wystarczy, aby skutecznie wyskalować produkt, aby został pokochany przez użytkowników.

Istotną częścią pracy, która musi zostać włożona poza projektowaniem i samym produktem jest działanie w obrębie tego co dzieje się w samym zespole produktowym, który wdraża i rozwija ten produkt.

Zespole, który jest odpowiedzialny za podejmowanie decyzji. Który ma kompetencje świadczące o tym, czy dany cel zostanie dowieziony, czy i jak produkt zostanie wdrożony.

Dlatego widząc to, my jako agencja troszeczkę inaczej podchodzimy do designu, projektowania i do wspierania biznesów.

‍

In today’s episode

In the first part, we’ll talk about the product-related problems Ilona mentioned. We’ll also discuss problems that are more closely related to the team—how the product is built and how it is managed. Finally, we’ll talk about services, meaning the approach we use at Zima, as specialists, to address challenges in both of these areas.

Ilona: One important thing to point out at the beginning…

This does not mean that you should take this list now and start ticking things off, saying: yes, I have all of these problems, or no, I don’t have any problems at all.

It is never the case that everything occurs at once. Usually, it is a complex combination of larger and smaller difficulties within the team or the product.

However, the list we created is based on our experience. It shows the issues we encounter most often.

Radek: Today, we’ll be talking specifically about the problems faced by startups and scale-ups. In a previous episode, we also discussed problems that arise in teams working on larger, more mature digital products. But today, we’ll focus particularly and specifically on startups.In today’s episode

Product-related problems

‍

Ilona: Let’s move on to the first problem we identified in the product area. The first problem that occurs in products developed by startups or scale-ups is that the entire product is one big MVP.

We get the sense that the product is held together with string and cable ties. We describe this problem as one big MVP. What does this involve, Radek?

Radek: You’ve already introduced a great metaphor: everything has a beautiful façade, but underneath, it is all held together with cable ties. And when one of those cable ties comes loose, the whole thing is about to fall apart.

What this really means is that whenever we want to make any changes—whenever we want to change that façade—we have to work with what lies underneath. So, if everything is connected in a disorganised and chaotic way, and sometimes we don’t even know how to untangle the knot, it takes a considerable amount of time before we can make any real changes. Before we can achieve the pace of change we need to maintain continuous growth.

Unfortunately, if we are a startup that has already been on the market for several years and we have become one big knot—one huge MVP held together with cable ties… then a significant amount of work and time is needed to organise and tidy everything up.

Otherwise, the pace of growth will be severely slowed down.

Ilona: Yes, another thing I notice in relation to this problem is that when we start working on a particular feature and want to improve something within that single feature, as soon as we touch it, we discover that it is connected to another feature. Once we change it, we also have to change something somewhere else. And that is precisely the moment when we realise that our product is one big MVP.

As you said, Radek, it is difficult to remain in this state in the long term because it slows down development considerably.

Radek: Let’s say that at the beginning of a startup’s development, it is perfectly fine to keep adding new things and end up with a kind of Frankenstein’s monster. We simply add another layer on top of something that already exists.

But once the startup becomes more established and starts turning into a fully functioning business that needs to generate revenue and introduce changes quickly… then this becomes a very serious problem and something that absolutely needs to be addressed. You have to make a conscious decision to invest time and budget in it.

‍

‍

A cluttered user interface

‍

Ilona: Exactly. Another thing we see in startups and scale-ups is clutter within the product, which is highly visible in the user interface and affects how users perceive the product.

Radek: And this problem stems, once again, from the fact that if we want to become more professional and be perceived on the market as a serious product—as something worth trusting… then we cannot afford to have certain imperfections on our façade, which is the interface.

These imperfections can take the form of different graphic elements, such as buttons. Because things like that happen as well. Of course, this is only the tip of the iceberg because it is just the interface.

‍

‍

Design debt

‍

Radek: But this results from a deeper underlying problem—a kind of technical debt. In this particular case, we could even call it design debt, such as the lack of a shared component library… A unified set of components that would help solve problems related to the consistency and visual appeal of the interface, while also supporting the creation of new interface elements. A library like this, known as a design system, helps achieve that.

And there is one more important point here.

‍

‍

Technical debt

‍

Radek: We’ve talked about design debt, but there is also something known as technical debt.

It is closely related to what we discussed earlier: building a Frankenstein’s monster—one huge MVP held together with cable ties. We also need to remember that the debts we take on while developing a product… if they are not repaid at some point, the debt collectors will eventually come knocking.

Of course, I’m joking here, but these “debt collectors” take the form of limitations we impose on ourselves, restricting the freedom we need to continue developing the product.

Ilona: We also discussed clutter within a product in one of our previous episodes, which focused on a solution to this clutter—a design system. We won’t explore this topic any further here, but we encourage you to listen to the episode dedicated specifically to clutter within a product.

‍

‍

An individual client vs. the product as a whole

‍

Ilona: Moving on to the next problem we identified… this is something very specific that we see mainly in B2B products. Namely, a lack of balance between developing features for an individual client—with whom we have a very close relationship in B2B—and developing the product as a whole.

Radek: Could you elaborate on that? It is a very interesting topic and perhaps not such a simple or obvious one.

Ilona: With B2B products, where one business sells to another, we communicate directly with decision-makers and users. This relationship is very close. They can give us feedback very quickly.

The person responsible for implementing our product on the client’s side can quickly send us an email explaining what isn’t working or what they don’t like. They may also share feedback from users.

There are simply fewer users, and they have relationships with one another—they work together. The way our product works has a direct impact on their work. Therefore, it is in their best interest for our product to keep improving and to be adapted as closely as possible to the way they work.

Because of this dynamic and the fact that we are so close to our clients, we tend to listen to the client who is the loudest. The one who sends us the most emails. Perhaps those emails are the most aggressive. Or perhaps it is simply the client we like the most…

And we start slipping features into our roadmap that may be useful only to that one client rather than to everyone.

In this situation, it is very easy to fall into the trap of becoming a software house. Instead of developing a product—such as a SaaS product—designed for a very large number of users and built to be scalable… we begin developing software for one specific client. As a result, we begin to lose sight of our business model.

In the case of B2C products, this risk is lower because we don’t have direct contact with the client. If one customer leaves, it does not have as significant an impact as it would in the case of a B2B client.

So, this is something we need to pay attention to. We need to remember to maintain a balance between creating features for individual clients and developing the product as a whole—adding items to the roadmap that will be useful to the wider audience and benefit everyone.
‍

‍

‍

Bags full of features

‍

Radek: This connects to the next problem for me. It is different, but also somewhat similar, because in my opinion, many products—or perhaps even more so, many roadmaps that are never fully delivered—are like bags full of features. Everyone can throw something into them, and it is not always properly thought through.

There are so many ideas surrounding a given product that they begin to blur the focus on its main value proposition. For example, the core feature that initially brought users to our product is pushed to the sidelines and overwhelmed by numerous additional bells and whistles that do not actually contribute anything. They are merely unnecessary embellishments or improvements.

Unfortunately, what I see as a major challenge is how to extract the essence of that core value. The value that often differentiates us in some way. The very reason users came to us in the first place.

What is important is to take care of that value and avoid adding too many things that often do not get delivered during the implementation of the roadmap anyway. Later, everyone is left wondering: how have we still not completed this? When, in fact, people probably would not even use it.

So, it is definitely worth prioritising the product’s core features first.

‍

Too much is never good

‍

Ilona: Yes, the features that deliver real value rather than blur the image of what our product actually is, making it more difficult to communicate later. Eventually, we no longer know which feature we should develop. The product also becomes more expensive to maintain because it contains more features.

This reminds me of the story of a startup that no longer operates. It had an idea for solving the problem of parking in cities by marking available spaces where drivers could park.

The idea itself was great. When I first heard that something like this was going to be created, I knew that the product addressed a real need of mine as a driver, as well as the problems associated with parking in Warsaw.

But when I heard that it would also include a loyalty programme, points, and gamification… I thought: oh no, that is too much. I am not going to drive around the city marking available parking spaces just to earn points.

That was not the point at all, yet the product was adding all of these things to its first release. They wanted to launch an app that was essentially one huge all-in-one package.

And, as you can probably tell from my story, it did not succeed.

Radek: The cases we are discussing are stories of companies that understood that focusing sharply on one value and on the MVP was extremely important. That is probably one of the reasons they succeeded. But later, I feel that they begin to lose this perspective.

Before properly focusing on fixing or improving that core value, many people become starry-eyed about new technologies, for example. They begin developing features based on those technologies, even though those features do not solve any problems or add any value to the product’s core.

‍

Every coin has two sides

‍

Ilona: On the other hand, I understand this because they do not want to fall behind or become irrelevant. And perhaps the horse they are betting on will turn out to be the winner.

As we have said, these are problems that we observe, but every situation has two sides. Although this is a problem in many cases and does not produce the expected results, in a certain percentage of cases, it may lead to something valuable.

Nevertheless, the problem we see is the dilution of the original value proposition. It is losing sight of the benefit and the need we originally set out to address.

On the other hand, it is also what you mentioned at the beginning—the bells and whistles, right? On the one hand, we forget about our core and where we came from. On the other hand, we keep adding various bells and whistles to the product, partly to conceal the fact that its main feature is no longer working.

‍

A lack of objectivity towards the product

‍

Radek: Another significant issue I see and would like to discuss here lies somewhere between the team and the product itself. I mean the lack of distance and objectivity that product owners and project teams have towards their own product.

This has a team-related aspect, but it also has an enormous impact on how the product itself is shaped. For example, opinions circulating among the owner’s colleagues or friends—or even looking at other markets and thinking that we do not measure up and that our product is imperfect—can unfortunately lead to spontaneous changes being made to the product.

These changes are not based on an analysis of the target audience’s preferences or on a proper market analysis. It is precisely the lack of this analysis and the lack of competitor monitoring that unfortunately cause some decisions to be made spontaneously.

Some decisions are made emotionally, and unfortunately, the product suffers as a result. I mean a genuine lack of proper analysis because there are several key factors that distinguish proper monitoring and analysis from poorly conducted research, but I will not discuss them now.

‍

A lack of professional processes

‍

Ilona: Yes, absolutely. And this leads to another problem—a lack of professional processes.

That may sound intimidating, but having, for example, an approval process is extremely important. Or a process establishing that once the product owner has approved a change and it is already being implemented—or, let’s say, it has been approved during the initial UX stage—we do not reverse that decision. We also do not continue iterating during the development stage once everything has already been defined.

Of course, different situations can occur. I do leave some room for exceptions. However, this lack of objectivity towards the product means that these processes are either not followed or do not exist at all because there is a reluctance to create them.
‍

Ultimately, both the product and its users suffer as a result.
‍

Radek: There are many problems of this kind. For example, when building a startup, fixed costs are not desirable and are completely incompatible with the dynamics and development needs of the startup.

Another major problem is that the pace of growth does not match investors’ expectations. A startup is not the kind of project that can be executed exactly according to plan. It is not a building. It is very delicate and highly sensitive to what is happening in the market. It is also highly sensitive to the various things happening internally.

So, I think a major problem is that there are certain growth expectations that are not always met—particularly in the context of what investors expect.

And, of course, let’s remember another problem that will probably only become more serious: the increasing difficulty of standing out in the market. There is more and more competition, and the number of startups continues to grow. Technology makes it possible to launch an increasing number of new products in the digital world.

As a result, it will become increasingly difficult for startups and products to stand out from the crowd.

‍

What is happening within the team?

‍

Radek: And there are more problems like these. If you recognise some of them in your own organisation, we would be very happy to examine your situation. Perhaps there is something that deserves immediate attention?

Even if a product analysis suggests that everything within the startup is fine, it is still worth taking a closer look at what is happening within the team itself.

This is where we, as an agency, have a slightly different perspective. We have learned that unless we examine problems not only at different levels—small, medium, and large—but also across different areas, including the product and the team, we will never be able to determine how to make meaningful changes.

We always begin with an in-depth analysis of these two areas.

‍

Check whether anyone has been left behind

‍

Ilona: Moving on to the problems within startup and scale-up teams… one issue that stands out very clearly is that the team, employees, or freelancers cannot keep up with the pace at which the product is developing.

At the beginning of a product’s development, we usually hire so-called generalists who can wear different hats depending on what is needed at a given moment. Someone may work partly in marketing, partly in design, and perhaps also a little in sales. We have full-stack developers. We have one designer who takes care of everything.

At some point, however, we begin to need specialised knowledge or deep expertise in a particular area.

This is particularly easy to see in UX. We may have one person responsible for UX/UI, but later it turns out that we need to conduct proper research. That requires a somewhat different set of skills. We may want to run an A/B test, which also requires different expertise—for example, analytical skills.

It turns out that the team that was ideal for developing the startup in its early stages can no longer fully keep up with where we are now as a product.

‍

Delegating tasks

‍

Ilona: The second thing we identified is that founders do not always fully trust their teams and are not always able to hand over certain tasks that they previously performed themselves. This brings us to the issue of delegation.

Radek: And that is hardly surprising. If someone founded a startup and spent a very long time doing these things and handling most of the tasks themselves, it is not only about knowing how to do them. There is probably an emotional attachment as well. It is very difficult to place your own child in someone else’s hands.

Ilona: But startup founders have to do it because—and this brings us to the next problem, which is the constant lack of time—they are no longer able to do everything the way they used to. At the same time, they are not yet entirely comfortable with delegating tasks and trusting their team. As a result, the startup does not grow at the pace we would like it to.

Radek: Exactly. I also think that another major problem is the tension caused by stress. It first emerges between investors and the founder, and then turns into tension between the founder and the team.

As we said earlier… delivering the expected results in a startup can be difficult. It does not always work out, and that stress begins to spill over.

This probably happens partly because there are no processes that would allow us to understand where certain shortcomings come from. When goals are not fully achieved, founders may resort to different measures. Sometimes data is manipulated, or arguments are presented at all costs to convince others that particular decisions will produce the expected results.

It is a very difficult job, but unfortunately, sometimes it feels like the only way to survive.

‍

Dialogue is essential

‍

Ilona: And the tension you mentioned runs through the entire company. We have tension between the investor and the CEO, followed by tension between the CEO and the team.

But this does not happen without a reason. Once again, our analysis shows that startup founders, owners, CEOs, and CTOs often have negative experiences with people who…

Radek: With UX agencies…

Ilona: Yes, with UX agencies, designers, marketers, or researchers. First of all, these people do not always fully understand what the product is because they did not come up with it or create it from the beginning.

They may also lack business knowledge. Perhaps they have never worked in similar areas or industries before. Or perhaps they are not entirely willing to understand the business. They want to remain within their own area of marketing or design and are unwilling to go beyond it.

Radek: They want to create a great project without taking responsibility for whether it succeeds or fails.

Let me talk about external support for a moment. You can feel that when you work on a project as an external partner, you do not carry the same level of responsibility as someone working internally. That is one issue. You are not concerned with all the nuances surrounding the product, its business context, the team, and so on. You simply complete the project.

The second issue is that even when someone works internally, there can still be a sense of conflict: I am a marketer or a designer, so I will fight against the business because I know best how to do my job. My work is the best it can be, and the business side does not understand it.

This is a common narrative, but it is not a healthy one. What is essential is genuine dialogue between these areas.

The most important thing is for the business to make sense. Of course, a business needs to deliver goods, services, or whatever else it offers, and it needs to solve real problems. But there are so many nuances surrounding design—such as whether something should be beautiful or usable. It is not always worth fighting over details like these. Sometimes, you need to engage deeply with the business.

You need to understand that the user’s need is more important and accept that, in a particular context, we may not be creating something beautiful because there is no time for it or because it is simply unnecessary.

Ilona: We create something we are not ashamed of and ensure that it meets an appropriate standard. However, spending an additional 10, 20, or 30 hours on it will not generate proportionally higher revenue.

Radek: In that case, we will actually lose money.

‍

Where should you look for experts?

‍

Ilona: This brings us to the next problem—hiring experts. We have already talked about delegation and the lack of time. All these things are connected.

Another challenge and common pain point in project teams—and startup teams in general—is finding good experts. Where should we look for them?

Radek: Among people we know. I feel that the situation is somewhat different in large digital products and bigger companies. In startups, we have the founder, who relies heavily on recommendations from colleagues and other people within the industry. They look for recommended specialists.

Unfortunately, this source of candidates is quickly exhausted. This also results from the very low initial level of trust in people’s competence. Now imagine trying to hire in this environment, with these needs and this mindset. That is the first barrier.

The second issue is that there are very few experienced UX and UI experts or researchers who can simply be recruited from the market.

I can also see that startups primarily need people who can take on leadership roles. They usually do not have large departments, and their structures are not particularly hierarchical. They need people who know what they are doing and are capable of making decisions. They need leaders, and such people are very difficult to hire.

Once you have people like that, things become easier. A leader—whether a designer or lead designer—can take ownership and drive the work forward. But reaching that point requires a considerable amount of effort.

‍

A word of caution about hiring juniors

‍

Ilona: This brings me to another issue that is not actually on our list. It may occur less frequently, but it fits this topic perfectly: hiring juniors instead of leaders.

We have a startup and are struggling to find leaders, so eventually, we give up and hire someone less experienced. That person cannot manage the work on their own, but we are unable to dedicate enough time to supporting them. We do not have the time to guide them, correct their work, sit with them every day, and give them advice.

As a result, we become reluctant to delegate because we believe we can do the work better ourselves. And the cycle begins again.

Radek: It is all one enormous vicious circle.

When I think about juniors, I believe it is very difficult to understand the value a particular designer can bring. People are very often hired based on what they show in their portfolios. Their work may look attractive, but it is not necessarily functional or what we need as a startup and a digital product.

Ilona: Or they may not even be able to justify their decisions—to explain why they designed something in a particular way.

Radek: I think it is very difficult to verify whether someone can justify those decisions. If you do not have a leader or anyone with genuine expertise in this field, you end up hiring someone who simply churns out attractive screens. And yes, those screens look good.

But then, why does none of it work? Why is everything moving so slowly?

I have seen so many situations where we enter a startup as Zima and begin working, and suddenly, everyone thinks: wow. The founders finally begin to understand their own product because someone has helped them untangle the situation they found themselves in.

Ilona: All of this falls under one label: the problem of assessing the qualifications of these experts. We do not fully understand which competencies we need or how to verify their skills.

Radek: There are many problems like these within teams as well. And, as I mentioned at the beginning, we try to look at them holistically—across both the product and the team.

‍

‍

How Zima solves startup problems

‍

Radek: Perhaps now we can move on to how we work and which services we use to address these problems.

If someone only wanted to hear about the problems and is not interested in Zima’s offer or how we work, they can safely stop listening now. But if you recognise similar problems in your own organisation and would like to find out how we could solve them, I invite you to keep listening.

Ilona: Following the structure we introduced, there are two sides to the coin. On the product side, we have product-related problems—and product services designed to address them. The other side of the coin involves team-related problems, and we also offer a range of services for teams.

As an agency that understands business and the problems we have discussed today, we know that there is no point in coming in and saying: “We’ll create an amazing interface for you, full of bells and whistles.”

That is what everyone does, and it does not work. In fact, this approach leads to the very problems we discussed a moment ago.

We take a more holistic approach. We know that every company faces at least one of these problems, whether smaller or larger and whether related to the product or the team.

‍

Workshop Zero

‍

That is why we always begin our work with Workshop Zero. We do not start a project without it. Only by looking at the bigger picture and meeting during a workshop like this can we analyse the current situation of both the product and the team.

Radek: Very often, clients come to us and say: “Listen, we need to do this and that.”

But it may turn out that by completing the requested task, we would be doing something that would not have any real impact or solve the actual problem.

Clients often come to us with a very specific request. They have clear expectations and say: “Here is the problem, and solving it should have an impact on X.” But it turns out that even if we solve that problem, the solution will not help them achieve the intended goal. The client simply does not realise what actually needs to be fixed to achieve it.

That is why we use Workshop Zero to identify and explore these problem areas in greater depth. We determine which of them will have a genuine impact on achieving a particular goal or at least moving closer to it.

‍

Creating an action plan

‍

Ilona: Based on this, we create an action plan. Between preparing the plan and implementing it, there is a series of activities and services we provide.

On the product side, this may include building a design system. Creating a design system addresses the problem of design inconsistency and technical debt.

We also conduct UX audits, which address problems related to the value proposition. They help when a company is building bells and whistles instead of developing the features users need most.

This is also connected to our core service: improving the UX and UI design processes themselves.

Radek: So, on the one hand, we examine the process through which the product is created. On the other hand, we look at the final result—what the user ultimately sees and the shape the product takes in terms of the experience it delivers.

Ilona: Yes. To prevent companies from losing sight of the market or becoming disconnected from what is happening within it, we offer recurring reports on what competitors are planning and what they are currently doing.

Radek: I realise that we all monitor our competitors, but this is often done without maintaining continuity. And the market is constantly changing. Digital products are particularly sensitive to these changes.

We need to conduct this monitoring at regular intervals. We need to examine what competitors did with the decisions they made at the beginning of the year and how those decisions evolved throughout the year.

We also use a research method called Buy a Feature, which helps us determine which features customers would genuinely be willing to pay for. We also research the needs of existing customers through traditional studies that allow us to get closer to users and speak with them directly.

Ilona: We offer workshops that help companies make specific product decisions.

Sometimes, a company is unable to create a clear roadmap or keeps adding items to its roadmap that are never delivered. We address this through workshops.

We also work with trends. We analyse them and determine how they can strategically support the company.

‍

Team mentoring

‍

Ilona: When it comes to services for teams, the first is team mentoring. We support and mentor junior designers. We onboard new team members and help them develop their skills so that they can gain knowledge, understand the business, and understand the purpose behind their work.

Radek: So that this knowledge remains within the organisation.

Ilona: Yes, but having designers on board is not always possible. That is why we offer a Design Lead by the Hour service.

We provide an experienced leader who acts as a manager for a particular project or service. They create and execute an action plan and serve as a manager—for example, on a part-time basis.

Radek: This is very useful for startups, particularly when they need design leadership—someone who can communicate with senior management, discuss strategic matters, and translate them into design decisions.

‍

Recruitment support

‍

Ilona: We also help recruit experts in our areas of expertise, including UX designers, researchers, and UI designers.

We help map their competencies and effectively hire the right person with the right skills. We can also identify which competencies a candidate is missing and determine the direction in which they need to develop.

We also organise workshops for teams. How should teams be structured? How should responsibilities be assigned? Who is responsible for what and for which part of the work?

Radek: We also analyse how your team works. We use a kind of diagnostic tool to determine whether the right processes and competencies are in the right places and how they can be used effectively.

Ilona: So, if you recognise any of the problems we have discussed within your product or team and would like to address them, visit our website at designzima.com.

In the upper-right corner, you will find the “Ask an Expert” button. Leave your details, and we will contact you and guide you through the process leading up to Workshop Zero.

Radek: Thank you very much for listening to this episode of Design and Business. We invite you to join us for the next one.

Did you enjoy this episode?

‍