Viktor Šmidák

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.

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

Alžbeta Ivanovičová

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. So 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.

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

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

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