Viktor Šmidák

Inquisitive mind? Subscribe for LB* Insight – stories that make you think.


Subscribe on LinkedIn



In the latest episode of our Minimum Viable Podcast we talked with Eva Šípková from Alza, one of the largest online retailers in Central Europe. Eva is the Head of Customer Experience and if you speak Slovak or Czech language, we highly recommend listening to the interview or reading the transcript on our website. If not, here’s the most important thought!

One of the topics we talked about was finding the common ground between CX and stakeholders / managers in each department. Eva’s approach is simple: "There are some things that helped me. First is the realization that it isn’t our website, logistics nor our developers that bring in cash. It is the customers."


Find common ground

Once everyone acknowledges and aligns with this crucial fact, the next step becomes much easier to navigate. Eva suggests allowing stakeholders and departments to identify a metric connected to customer satisfaction that holds relevance for them. By doing so, they take ownership of that metric and become responsible for achieving it while you gain a clear objective that can be measured and tracked.

Wondering what that looks like in real life? "Let’s say we have a finance department. They argue they shouldn’t be involved in the CX initiative since they have limited direct customer contact.

We thought hard about this and came up with a Money delay index metric. It represents the time it takes for money to reach the customer. Let’s say you’re returning something to an Alza box (note: self-service boxes for picking up / returning orders). The moment you close the box, you should have the money in your bank account.

But here comes the finance department and claims it’s not possible. They have to check the product is undamaged, the packaging is complete, which bank the customer used…"


Put yourself in their shoes

The best way to fight this resistance is through finding an overlap between their challenges and challenges of their customers. If you can prove that changing the process can fix the problem of both sides, they will see the value.

In this case, Eva reminded them it’s also in their interest to transfer the money to the customer faster. "In fact, our finance specialists don’t want pending payments. It creates problems for them too. In the end we made fantastic progress reducing the time it takes to receive the money to hours."

This is a great example of two seemingly unrelated things coming together for the greater good. By allowing stakeholders to select their own relevant metrics, you create a sense of ownership and enable them to contribute to the overall CX objectives.


Stars (and stakeholders) need to allign

Whether your company already started or is just embarking on its own CX journey, remember to seek out ambassadors, involve stakeholders in metric selection and foster a shared understanding of the value of customer experience design.

From our experience, it is a great practice to align all stakeholders on the design problem even before we jump to research and development. It allows us to come up with solutions that are better and more easily accepted across any organization. Check our Idea validation canvas and try it yourself at your next alignment with a resistant stakeholder.


Did you find this interesting? It's from our LB* Insights newsletter. Give it a try.

Resistant stakeholders? Use metrics they already rely on

Alžbeta Ivanovičová

Inquisitive mind? Subscribe to our LB* Insights newsletter. No fluff, just stories to make you think.

The basis of creating good products and services is a creative process called Product Discovery, also known as product exploration or discovery. The goal of the Discovery process is to deliver a working product or part of it to users as soon as possible, with the most tangible evidence that the product team will achieve the originally intended goal, and with the knowledge that the solution is technically feasible.

To make this happen, the product team seeks answers to the following questions:

 1. Will users want to use it?
 2. Will it bring business results to the company?
 3. Is it technically feasible?
 4. Will the interested parties support this solution?


How to start with exploration

In order to even start with Product Discovery, you need to have a lot of ideas at hand. Don’t be afraid of them, ideas are friends. Friends that need to be collected and categorized.

Ideas can come out of user interviews or research, your customer service or sales department. The insights of colleagues from the "first line" (branch employees) or other teams are also fantastic resources. Last but not least, you can also do data analysis and find patterns.

You can also find tips on where to look for opportunities in this article on exploration.

FOR DOWNLOAD: Product Discovery Guide


Prioritizing ideas

No matter where you get your ideas (opportunities, problems) from, it's good practice to store them in the Discovery backlog. You then have to choose the ones with the greatest potential. I recommend that you standardize the format by answering the following questions:

 * [What] What do we want to solve? What key problem or opportunity does the proposed idea address?
 * [Who] Who does it concern? Who is the target group in this case?
 * [Why] How will we know that we have solved the problem? What exactly do we expect and how could we measure it?

The selection of ideas or their prioritization can be done with the help of one of the prioritization techniques such as PIE, RICE, MoSCoW, etc. If more stakeholders are involved in decision making, the Bull’s Eye Diagram works well.

The prioritized ideas are then validated by the product team. They find out if these ideas make sense in terms of feasibility, demand and business performance, so you can decide which ideas make sense to invest in.

In Lighting Beetle*, we use the so-called Idea validation, but you may also be familiar with Business Problem Statement or Opportunity Canvas.


10 principles of Product Discovery

Before you start with the actual discovery, remember these 10 principles of the Product Discovery phase. I compiled them based on observation and research of successful and less successful exploration teams. They are inspired by the principles of exploration from SVPG from Marty Cagan's diary entries.

1. Customers don't tell us what they want. (As my colleague Michal Blažej says, you don't want the customer to design for you.)

2. The most important thing is to create value for the customer.

3. The goal is to validate ideas as soon as possible and as cheaply as possible.

4. We need to test ideas with real customers.

5. Development is hard, but UX is usually harder and even more crucial.

6. Functionality, design and technology are closely interconnected.

7. Technical feasibility must be verified during the Discovery phase.

8. Prototypes are a great tool in exploration.

9. During the Discovery phase, it is essential to involve all important stakeholders.

10. Most of our ideas won't work, and those that do need to be iterated.

These 10 principles should be the mantra of the product team in a Discovery phase, where a product manager, a UX researcher, an interaction designer and a data analyst should primarily be involved.

This team is tasked with constantly researching user behavior and trying to change it to generate results. For example, if Spotify users spend more time listening to music, their Spotify Premium retention will increase. The team's main goal is to eliminate the risk that the Product Delivery phase will be proposed a solution which will not work or perform as expected later on.

Do you want to find out if you need a product team and who should be in it? Read my previous article about building product teams and their impact on a company's customer experience level.

Looking for concrete steps to launch your product? Read our Product Discovery Guide first. It will walk you through a 7-step process that maximizes your chances for success.


Did you find this interesting? It's from our LB* Insights newsletter. Give it a try.

10 Commandments of Product Discovery

Inquisitive mind? Subscribe to our LB* Insights newsletter. No fluff, just stories to make you think.

The faster you experiment, the faster you learn, the faster you’re likely to succeed. That means abandoning the popular waterfall approach. Why?

Imagine a manager at a fictional company. He approves a strict budget for a new product, the design team then creates the experience, later the developers take over and release a perfectly usable product. Everyone is happy and success is achieved.

Sounds like a dream? It is. Reality is, in most cases, poles apart. This is because with waterfall approach, you’re not reducing the uncertainty whatsoever. But there is a way.

Fit between what a company offers and what a customer wants is the number one requirement of a successful value proposition. - Strategyzer

More and more companies nowadays are starting to work with an agile approach. And even though the word "agile" has become a buzzword over the years, this approach has many advantages. Let’s illustrate this methodology in the same made up story.

In this case, the manager starts with exploring a challenge, whether it is a usability issue or a business performance.

If the research team does find the problem worth solving (sometimes there might not even be a problem to begin with), the creation phase begins. And once hypotheses are validated, the budget can be progressively increased.

Designers start concepting, developers start coding and copywriters start writing. They do this in sprints and share their progress (and issues) throughout the whole project. This way, designers don’t design something that can’t be coded and vice versa. Releasing happens more often and so does validating.


When to validate?



Before spending weeks or months building a first version of your product or feature, validate the core (or riskiest) ideas with a few experiments. We dive deeper into the importance of validation and the whole process in our Validation Handbook.

Here are 4 main stages in which you should validate. It is a good practice to identify which stage you’re in so that you can pick adequate experiments to validate with. The stages are:

1. Problem validation

Here you test whether the problem you came up with is worth solving. Is there a room for your idea or is the market quite saturated already? In this stage, you can use desk research or picnic on the graveyard method.

2. Solution validation

Here you will validate your solution to the problem. Is your solution ideal? Can it make money? You can leverage experiments like solution interviews or comprehension tests.

3. Building the minimum solution

A focus on releasing a minimum solution means that you can potentially avoid lengthy and possibly unnecessary work. In this stage, techniques such as fake door or A/B testing are helpful.

4. Continous build & measure

Your product is never finished. Constant iteration is necessary to make sure you stay competitive. Usability testing and product-market fit survey are just some of the methods you can use.

You can find a list of 30 experimenting methods like these in our Experiment Toolbox guide.


Holy grail of validation



Companies that are at the forefront of agile development use a dual-track agile approach.

Dual-track agile allows both discovery and delivery to happen simultaneously. This approach doesn’t require the Discovery team to fully define all features before the Delivery team starts building. The entire process is collaborative and involves teams’ key members (designer, developer, product owner).


Getting out



Building a product that customers want requires you to switch from planning to experimenting. Anybody involved in developing your product needs to get out of the building to directly experiment with your customers. Only once you have proven your riskiest assumption true, you should start working on delivery.

Transformation from waterfall to agile approach is a big challenge that can take years. Therefore don’t be discouraged and persist. In the end, your company will become more efficient time and money-wise and you will get a deeper understanding of your customer.


Did you find this interesting? It's from our LB* Insights newsletter. Give it a try.

Shift from building to experimenting

Inquisitive mind? Subscribe to our LB* Insights newsletter. No fluff, just stories to make you think.

First, it’s good to settle the difference between project management and product management. As the name implies, project management operates on a project-to-project basis. Whether it’s a new feature being added or a research that needs to be carried out. All project-related tasks should meet the desired deadline, for example a release date.

Product management is a bit different. Take a bank as an example. One of the products a bank has can be a mobile app which the product team is responsible for. That means adding new features, researching customers’ needs etc. Everything the team does revolves around the product – the banking app.

And here is the key difference: While projects have deadlines or endings, developing a product is perpetuum mobile, a never-ending process. Deadlines are not as important. Making sure the app works from a business, usability and technology point of view is what matters more.


Do you need a product team?

If you have neither project nor product team right now, there is a chance you don’t need one yet. If you struggle with the points below though, you may want to reconsider.

 * Stakeholder driven roadmap – there is no one to oppose stakeholders + prioritization is in the hands of the HiPPO (highest paid person's opinion)
 * No product discovery process (or using single track agile)
 * Too much focus on dates / features
 * Not enough direct customer interaction – stakeholders are left in the dark, not involved in roadmaps or timelines
 * Not utilizing engineering or user experience early enough
 * Infrequent release cycles – development takes longer than expected, missing deadlines
 * Lack of focus, too many interruptions – struggling to prioritize tasks for developers or designers
 * Product architecture limitation / technical debt
 * Too many meetings / consensus culture
 * Poor developer morale

There are of course many things that indicate you need a product team. These are some I come across most often.


Product teams and customer experience

Apart from solving the issues listed above, a good product team is also beneficial for overall customer experience. How?

Nowadays, customers want consistent experiences. If they interact with one company, they expect the same behavior across all channels. If your product or service works differently offline and online, the customer becomes frustrated. This is mainly the role of CX departments but a good CX department should include product teams that work on this seamlessness.


Building an all-star product team

It’s important to note that a functional product team should be multidisciplinary. Building a good product team might be the toughest challenge. There is no universal rule or a formula but from my experience a good product team should include at least:

 * Product manager (responsible for managing tasks and priorities)
 * Developer
 * Designer
 * QA / Test engineer
 * Data analyst (optional, but highly recommended)


What’s next?

It is always a great idea to map your customer journeys. Once you have that, you can start thinking about assigning different products to different teams. One of the ways to do that is to assign one all products related to a particular customer journey to one team. This way, the team has a deeper understanding of the specific journey and can make relevant decisions.

Another great approach is to build teams based on related features. If you use the same or close to the same tech background for more products, you can use that to your advantage and build a team who will specialize in improving them.

And remember. Continuous product discovery and improvements should be the main responsibilities of your product team.

Did you find this interesting? It's from our LB* Insights newsletter. Give it a try.

Want better CX? Start building product teams

Michal Blažej

Inquisitive mind? Subscribe to our LB* Insights newsletter. No fluff, just stories to make you think.

Companies that haven’t started working with their customers (more in my previous article about CX maturity) usually don't believe in customer research. The argument is simple and almost always somehow related to a popular anecdote: if Henry Ford asked his customers about their wants, they would say "We want faster horses". No car would ever be made, and that’s why we shouldn’t ask our customers for their solutions.

I want to show you two opposite views in regard to this anecdote, because I believe it makes better sense that way.


Customer’s POV: Do this, because it'll serve me better


Every customer will tell you things they dislike about your product or service. They would want it to be cheaper, faster, more reliable… And it makes sense. Everyone wants what is best for them. That’s why we shouldn’t expect solutions from our customers. We shouldn’t expect them to design for us.

Whether the anecdote is right or not, it does UX disservice. Especially if UX researchers don’t ask the right questions, the same as Henry Ford.

I would advise Mr. Ford to discover the needs of his customers. He would then realize that customers don’t need faster horses (solution). They need to move from point A to point B faster. And exactly this correct identification and isolation of customer’s needs inspires us to provide creative and diverse solutions.

And maybe, if Henry Ford asked the right questions, he wouldn’t come up with the car to replace horses, but invent a hovercraft or skateboard. And the world would look completely different now.


Business POV: If we only listen to customer’s solutions, we will go broke


Yes. If a company tried to satisfy their customers and invest heavily in their vision of perfect products, it would go broke. By this logic, we shouldn’t ask the customers about their ideas, because their ideas are biased and don’t make sense businesswise.

And yet, customers need to be heard a lot more. But the designer should not act only as the customers’ voice. The designer is there to solve problems.

A good UX designer is the person trying to achieve equilibrium between customers and what the business wants. Their task is not simply to address the customer's need, but also the context in which the solution is created – and that is the investing company.

Besides, UX design preaches that we should start with the customer. Or else we will get stuck in our own beliefs that don’t necessarily reflect in our customers.

At Lighting Beetle*, we push our designers to always look for solutions that address customers' problems, bring value to the business and are viable in the business context. This way sustainable and good solutions are made.

And how about you? Do you ask for customers’ solutions or needs?

Did you find this interesting? It's from our LB* Insights newsletter. Give it a try.

Think customers have solutions? This will change your mind

Dominika Babulicová

Inquisitive mind? Subscribe to our LB* Insights newsletter. No fluff, just stories to make you think.

It always strikes me how creative people get when it comes to keeping time records. I’ve heard about filling double-the-time inputs, writing custom scripts, or even putting the optical mouse into a glass cup to generate fake activity so the corporate computer stays awake. But what surprises me the most, these stories usually come from my smartest, most lively friends. That’s how I realized it’s not about laziness. People just don’t believe the time records are worth anything.


The core problem with agility

When it comes to implementing agility, most companies think it’s about tools and processes. Breaking down silos into multidisciplinary teams, introducing kanban, training Scrum masters or having those beautifully tidied Jira boards... But imagine how many times you’ve found yourself or your team being late with the project deadline although you followed the process and used the tools with 100% accuracy. Still, the work got prolonged somehow or you realized the whole initial roadmap wasn’t estimated well.

Tools themselves are misleading. Often this is mistaken because organizations are more focused on iterating the visible elements of agile transformation, although the less visible are the ones that matter and have the real impact. Of course you’ll appreciate tools and processes, but becoming agile solely because of them is nonsense. Agility – as an ability to adapt to change – is less about specific practice, but rather about attitude.


Being agile starts with data

In Lighting Beetle*, we’re strong believers in data-informed decision making. And just like we can use it when analyzing a customer research, we can do that for work estimations, too. Being able to confidently say how long a certain task or project would take, was actually the very first step we took to transform into an agile studio.

Back in 2009 when LB* was established, we wanted to do every project that came our way. To deliver it in a record-breaking time and the highest of quality. But we quickly realized this is no easy feat. We struggled with resource estimations, faced tight deadlines and felt overloaded. And we put the pressure on ourselves by unconsciously agreeing to unrealistic commitments.

Only when we implemented time tracking into our workflow, we started to see patterns and the work became more predictable. The time tracking reports became an essential tool. Not just for account managers making invoices, but for any of our designers or developers deciding about how to invest their time to bring the highest contribution to overall value. We learned to work agile and it enabled us to deliver on time and in budget.


Measure time for better decisions

1. Start benchmarking time spent on tasks and regularly evaluate it. Not to boss around but to identify possible obstacles and collectively discuss how to overcome them. That’s what all the agile ceremonies exist for, as this article explains.

2. Gain confidence – yourself and in your team – by being aware of your efforts. Knowing how difficult a certain challenge was, enables you to plan the next one better. Data is useless if we don’t learn from it, so let people be conscious about their work and feel in control. At LB*, this awareness helped us implement the Lean UX process.

3. Once people feel confident about their knowledge and experience, they are ready to take over the responsibility. They start to make bold informed decisions and plan the most impactful work autonomously. And that’s the moment of agile transformation you’re so desperately aiming for.


Confidence is sexy

A client recently told me: “Agility is not a threat. It’s like a fire. It scared people until they learned how to tame it.” I bet you’ve heard this one before: The trick to boost agility is in the mindset change. For us, the trick was hidden in time tracking and you can read the whole story in the Toggl’s case study about Lighting Beetle*.

Data allowed us to gain confidence in decision making and taught us enormous learnings about running agile projects. We allocate resources better and deliver on time and within budget with almost zero scope creep. And thanks to agile decisions we also succeed in keeping our work and lives balanced. I highly recommend trying it yourself.

Did you find this interesting? It's from our LB* Insights newsletter. Give it a try.

Why time tracking is (not) useless in agile environments

Inquisitive mind? Subscribe to our LB* Insights newsletter. No fluff, just stories to make you think.

For experts like product managers, CX leaders or innovation managers, work can sometimes feel like living in a silo. Often, they are individuals missing counterparts within the same organization. And since our network as a customer experience studio is huge, we came up with the idea of organizing Circle of Trust events. The premise is simple. Up to 10 experts meet in one room to autopsy a CX-related challenge with a support of LB* facilitator who makes ground for a safe discussion.

Our June topic was exploration or discovery. We get feedback regularly from researchers and product owners in our partnered companies about their struggles exploring new ideas for better customer experience. So we decided to seat experts from telco, banking, retail and power engineering in the circle and “explore” the topic.

“Even when we didn’t achieve what we intended in the exploration phase, it is still a success. We now have more data on what the customer doesn’t consider important.” – participant

Discovery is a broad topic which can mean a lot of things, so we started off with settling on a definition. In the conclusion we came to, exploration includes:

 * Understanding the customer and discovering their needs
 * Coming up with new ideas and innovations to support company’s business
 * Looking at different industries and searching for benchmarks, working with data

Coming up with new features or product ideas from behind a closed door is the complete opposite of exploration. Before you start with discovery phase, we highly recommend reading 10 Commandments of Product Discovery too. If you already utilize the discovery phase, and find yourself in a similar struggle as our attendees, the fact is you are doing great.

According to the global research by NNg, only 32% percent of companies incorporate exploration in their product vision or business strategy, and our CX maturity research confirmed this applies to 30% of Slovak companies.

“Try to pitch your idea to two other people. If you can defend your point and you come to an agreement, then your idea is probably worth a try.” – participant

The most interesting topic to the majority of attendees turned out to be How to collect feedback from users and come up with new ideas? In just two hours, we identified and exchanged experiences with various ways to tackle the problem of collecting customer feedback and acting on it. These were used in real life cases by the participants:


1. Creating personas with different approaches

It allows you to step outside of the box and think about how they view different problems. For inspiration, here is a nice article about creating personas with templates.


2. Collecting feedback from customers through chat or customer support




3. Having an internal platform where employees can post their ideas and thoughts




4. Examining new ideas using A/B tests

Keep in mind that sometimes the results can be very close. It’s therefore important to have a sample that is big enough. To figure out the significance of data, you can use an A/B calculator.


5. Rapid idea validation with the fake door test

You show the users an option that doesn’t exist yet. After they take the action, the system lets them know that this feature or product / service is not yet available. By measuring how many of the potential users showed interest, we can gather proof it’s worth building. You can find 28 more proven tests like this one to validate your idea in our popular Experiment Toolbox handbook.


6. Doing a review of competition on both local and international level

Use what is already out there to gather data. It can also be a good way to cross-check insights you generated during interviews.


7. Knowledge sharing with stakeholders / product owners in different organizations

Get in touch and make a field visit to other companies, even in foreign countries. You can connect with them via LinkedIn, at local meetups or in professional groups on various social media. Or just become a member of our Circle of Trust and meet with your peers regularly. If you’re a fan of the concept, let us know, we get you a seat.

Hungry for more? Read our Product Discovery Guide next. It will walk you through a 7-step process that maximizes your chances for successful product launch.

Did you find this interesting? It's from our LB* Insights newsletter. Give it a try.

Exploration is a challenge. How to come up with ideas for better CX?

Adam Močkoř

Inquisitive mind? Subscribe to our LB* Insights newsletter. No fluff, just stories to make you think.

Most effective designers (and developers alike) dream of a robust design system. A design system that would include many components that can be used across many products. To achieve that, some companies rush to add new components to their design system even before testing them in live production.

It happened to us at Lighting Beetle* too. A client was developing multiple products and designers came up with the idea of implementing a new component to the design system that could be used in various applications.

Project first approach allows building a design system in sustainable way even with small teams.

And so we did. We designed the component, developed it and documented it in the design system. But during implementation we encountered technical requirements that were not compatible with our previous idea. While fixing the problem, design requirements on the products evolved, as is tradition in agile development. The end result was inefficiency. Neither the products, nor design system, nor developers, managers or team benefitted from this effort.

While building a design system, we recommend the “project first” approach. Let me explain it with the help of an analogy with cogs.



Design system like swiss watch


Similarly to swiss watches, a design system also relies on a perfectly functioning mechanism with cogs of different sizes.

The design system itself represents the center wheel. It’s the biggest, most stable cog, therefore turning slowly. Design system too should be a steady part of an organization that is only iterated, not rapidly changed. For a design system to work, it also requires detailed documentation that is understood by everyone involved.

Smaller cogs around the center wheel (design system) represent individual products (or projects) that are influenced by the design system. These cogs rotate at a faster pace, meaning they are more agile, and need to react to technology changes and users’ needs quicker.


Benefits of project first approach

Validation

When testing new design changes, we use the smaller cogs – projects. It allows us to promptly collect user feedback without worrying about affecting the whole ecosystem. Designers can experiment safely and only the components validated by real customers get implemented in the design system.

Efficiency

Once new components are validated and we can use them in multiple projects, it’s time to implement them into a design system. By doing this, we continually improve the robustness and usefulness of the system. Now, whenever we build a new project, we can use existing resources thus saving time it would otherwise take to design and develop new components.

Standardization is a lengthy and laborious process. The end result though is a consistent design across the portfolio that is not affected by constant changes. This can increase customer satisfaction as well as satisfaction of people involved in the project.

Did you find this interesting? It's from our LB* Insights newsletter. Give it a try.

What do design systems and cogwheels have in common?

Inquisitive mind? Subscribe to our LB* Insights newsletter. No fluff, just stories to make you think.

In my previous post I explained a system that you can use to assess to what extent your company is customer-oriented. I have noticed stakeholders inside companies oftentimes assess this stage by how much work is done on UX projects. In reality, it’s not about the amount of time dedicated to UX research but how the data from these activities are used and interpreted.


We do UX and that’s good enough for us

Overestimating customer orientation is usually noticed during transition from stage 3 to stage 4 (see Stages of customer orientation). Companies in stage 3 are characterized by using UX principles daily to design their products and services. They collect feedback from prototype testing and use that to improve the usability. That leaves them thinking they are customer oriented.

Yet, product decisions are still made behind closed doors by a small number of people, usually product managers, owners or stakeholders. UX methodologies are only a part of implementation, not really a part of project specification. It is not unusual that UX and PM professionals disagree on things which results in confusion and inefficiency.

UX research teams point out problems that cannot be solved by design change. They require changes to be made on product level or in business processes. Those insights are collected, usually repeatedly mentioned in presentations but have almost zero impact.


Heureka!

Heureka happens once the data from UX research finds its way to forums where business decisions are made. When product owners use customer data to make informed decisions about products and services, the company quickly transitions to stage 4 and becomes more focused on customer needs.


Change in company’s DNA

This process enables a shift in the company's priorities. Project or feature that seemed essential before can easily lose much of its importance because it is not that interesting for the user. This way the company becomes more customer-oriented and starts prioritizing different tasks.

Suddenly, product owners are more invested in customer needs and wants, hence they require more research capacities. Since customers’ needs are usually tied to online space, product owners that were used to the offline world now have to think digitally. This leads to change in organizational structure. Need for collaboration creates space for new multidisciplinary teams that involve different roles and stakeholders. Ultimately, this leads to fulfillment of customer needs.

Did you find this interesting? It's from our LB* Insights newsletter. Give it a try.

Here is why you don't fully utilize customer data

Inquisitive mind? Subscribe to our LB* Insights newsletter. No fluff, just stories to make you think.


Level 0: Prehistoric companies

There is no customer research or user testing in the company. This is the prehistoric period "before UX". Product design and service design is based on the feelings and expert views of a few key people. These organizations already have trouble retaining loyal customers and have poor performance in the digital environment.


Level 1-3: We do UX and it's fine

Level 1 companies find that testing prototypes of digital services will save them money that would be wasted on unnecessary development. After a while, they will understand that customer feedback really helps them. They will start demanding customer research to help adapt designs to customer needs.


Level 4-6: Customer data decides

Customer research is becoming much more important than testing. Customer data is used to make product decisions and often contradicts the status quo and the expert perspective of internal stakeholders. The work is no longer organized into projects, but looking through customer paths helps teams focus on customer needs and are less tied to the company's organizational structure. UX designers are appearing in companies.


Level 7-10: The customer is part of the strategy

Customer-conscious companies not only make decisions based on customer data, but customer values and needs become part of the company's strategy. Due to the sustainability of such a change in the company's thinking, the culture as well as the organizational structure is often redefined. Such companies are able to quickly adapt to the ever-changing needs of the customer.

So – at what level is your company?

Did you find this interesting? It's from our LB* Insights newsletter. Give it a try.

Get inspired!

All Stories

Podcasts

Events

Tools

Newsletter

Resistant stakeholders? Use metrics they already rely on

10 Commandments of Product Discovery

Shift from building to experimenting

Want better CX? Start building product teams

Think customers have solutions? This will change your mind

Why time tracking is (not) useless in agile environments

Exploration is a challenge. How to come up with ideas for better CX?

What do design systems and cogwheels have in common?

Here is why you don't fully utilize customer data

On a scale of 1 to 10, how customer-oriented is your business?

‌‌

‌‌

‌‌

‌‌

‌‌

‌‌

‌‌

‌‌

‌‌

‌‌

Your journey
starts here

Get inspired!

All Stories

Podcasts

Events

Tools

Newsletter

Insights from customer experience and business are brought to you by experts from Lighting Beetle.

Don’t miss out

Resistant stakeholders? Use metrics they already rely on

10 Commandments of Product Discovery

Shift from building to experimenting

Want better CX? Start building product teams

Think customers have solutions? This will change your mind

Why time tracking is (not) useless in agile environments

Exploration is a challenge. How to come up with ideas for better CX?

What do design systems and cogwheels have in common?

Here is why you don't fully utilize customer data

On a scale of 1 to 10, how customer-oriented is your business?

‌‌

‌‌

‌‌

‌‌

‌‌

‌‌

‌‌

‌‌

‌‌

‌‌

Your journey starts here

Your journey
starts here