In most jobs, you can get fired for failure. However, when you work in an exploratory department, failures are served for breakfast, lunch, and dinner. And they even consider it a success.
In the 17th episode of Minimum Viable Podcast, Michal Blažej discusses Exploration with Tomáš Ulej, Head of the Exploration Team at Martinus. Tomáš and his colleagues at Martinus discover new opportunities that offer space for business growth or have the potential to improve the Customer Experience.
To see this content on our site, you need to agree to usage of 3rd party cookies. Or you can follow a link that will redirect you to following address: https://open.spotify.com/episode/4tYj1fjQcAbbCBMevWyY7c
Minimum Viable Podcast is brought to you by the CX design studio Lighting Beetle*. It's usually recorded in the Slovak language, however, you can read an English transcription of this episode below. For more content in English, including case studies and handouts, visit our Journal.
You can find Minimum Viable Podcast on:
- Spotify
- Apple Podcasts
- Google Podcasts
- Anchor
- Castbox
- or below in full transcription.
In the beginning, I would like to ask what the Explore team actually is?
We were established about a year and a half ago as a part of Martinus' effort to embrace innovations, ideas and search for new directions under our mission of connecting people with books. As a company grows and finds its own business, its cash cow, it sometimes starts to forget about exploration because it simply tries to milk that cash cow for all it's worth.
We found ourselves in situations where we had twenty ideas on the table, and now how do we differentiate between them? So we started to seek a balance between being the heart of discovery, those who always want to search for something new, and at the same time developing and improving the business we already have.
One way companies do it is by dedicating a department specifically to exploration. This Exploit versus Explore model led us to creating a separate department that would focus solely on the ideas and directions we haven't explored yet.
You mentioned Exploit vs. Explore. Can you explain it to us?
In essence, exploitation is about developing the company in what it already does. So, speeding up logistics, improving eshop conversion rate, enhancing the existing customer journey, and so on.
Explore, on the other hand, seeks new customer paths. Discovering the unknown or looking for new approaches to what we already do. I always mention the example that around 2010 our first physical bookstores could have been an exploration, which is peculiar because traditional bookstores are what generally existed way before eshops, but Martinus had it the other way around.
Every company has its cycles. Sometimes it's in the phase of growth, discovering new opportunities, but then it gets more stable and a need for new impulses arises. Companies use R&D departments for that. Is that what you are in Martinus?
Yes, partially. But sometimes, in my opinion, we are also in the discovery phase, and sometimes elsewhere. For example, during Christmas, we did a gamification project directly at our headquarters, where orders are packaged.
We created a game for our employees where they select books from the warehouse, and it's a game where they earn badges and praises for lifting 500 kilograms or reaching a high shelf, etc.
We collaborated on the Martinus website redesign. At that time, you were more involved in that project. You say you've been running for about a year and a half. What was the journey to the Explore team?
In the beginning, there were debates within the company about how we perceive it. Some people simply love developing what already exists, and then there are many of us crazy ones who love exploration.
So, if I had to choose between increasing conversion by a tiny fraction or trying out new toys and new things, there are people who would say, 'Let's try the toys too.'
There are only three of us who dedicate ourselves to it, but our goal is to gradually teach and involve teams, finding the balance when eventually all departments will have exploration as a permanent component.
Let's talk more about your business role.
There are no straightforward business expectations from the exploration team, and that's actually part of the team's assignment. We have our budget we need to spend to identify the best ideas and opportunities. But honestly, most of them fail.
So theoretically, our success can be measured by how many bad ideas we discard. The second criterion can be that we actually bring something, a new project that Martinus can implement. And the third thing, which I believe is the most common and valuable, is that we always bring knowledge.
One of the success criteria, in our case, can be how many bad ideas we discard.
And that should be at the core of all exploration departments, in my opinion. They shouldn't have a goal like 'At the end of the year, I want to see four successful projects that earn the company 1.2 million.' Because what happens then? You create another department that is very result-oriented, so it stops taking risks, stops playing, stops seeking.
We did something similar for companies where a lot of research was done. Organizing that research and publishing it internally is something that the company can work with and accelerate its understanding and perhaps not focus on things that don't make as much sense.
We specifically write concise summaries where we document the entire process and knowledge gained from projects, most of which actually failed. But how do you then quantify our value, how much has the explore team brought to the company? That's why we don't do that.
Can you give us an example of a project that didn't work out?
One project from last year called 'Little Prince'. From our research, we found that the most common problem people face while reading is a lack of time. And of course, smartphones play a role in that.
So we tried to come up with a magical bookmark that had a chip in it. When you placed your phone on it, an app would launch. In the app then Little Prince would plant roses in his yard and for every X number of roses you 'planted' we would support the organization 'Reading Country' which helps children from marginalized communities gain access to books.
First, we tested it within the team, and then we let people test the app prototype for a month. That's when we found out that only people who already read a lot were interested in the app, and it didn't actually help them read more because they didn't need it.
You said you can do this within a month. So tell me, how is your team structured to be able to build such a prototype in a month?
We always need some external help, but internally we have people with diverse skills. There's Matúš Marcin, who is originally a great developer but with strong overlaps into other business areas and technology fields so he can represent us in various aspects.
Then there's Petra Lebiedzi, who is amazing and has experience with various surveys and questionnaire design. She's also the most organized person among the three of us. And I'm the one who should primarily be an idea maker, but also has a bit of knowledge in every area.
I've noticed around me that there are people who enjoy starting new things and are always full of ideas and ideals. Then there are people who are more focused on operations.
And that's precisely the divide between exploit and explore. A beautiful separation.
Now let's talk about quantity. In a year and a half, how many projects can three people cover?
We set a rule that we won't spend more than 60 days on anything. But sometimes when something is big, it can be just a phase with a learning goal we want to achieve. So one project can have for example even three phases, when the first one shows promising, and we decide to proceed to the next one.
I don't have the exact count, but let's say it's around 20 or 25 different things. All the literature told us that all three of us should focus on one thing at a time. But we quickly realized that it's quite the opposite. We need to work on multiple projects simultaneously to be efficient and fast.
And that's related to the fact that every project is completely different. Sometimes you have a solution to which you need to find the problem. Sometimes you only have a topic and need to do the research, and sometimes you have something that is perfectly documented and you need to test it. Often we are also influenced by external circumstances.
You mentioned the areas where you operate, such as the bookstore and the warehouse. Where do you see the limits of your influence?
A few years ago, Martinus defined its mission as connecting people with books to foster personal growth and goodness within individuals. So there are certain aspects you can highlight, such as books, reading, and the development of something positive within people. These are our boundaries.
I like the idea of time limitation so that you don't spend too much time on projects and therefore you don't have to ponder excessively about the potential added value.
Yes, but we always have success criteria for each project. We ask, what does it mean for this project to be successful. For example, 'What do you want to see so that our acquired knowledge can be immediately implemented as a new service?' And the response might be, 'Well, it should have a certain click-through rate or a specific success rate.'
We always define these criteria firmly, and we strive to adhere to them because it often happens in projects that people become infatuated with wrong ideas. Then the results come in, which may not be anything special, and they start convincing themselves that it's sufficient. By establishing the project's goals and objectives from the outset, one cannot deceive oneself.
Part of the projects you do is also made public. What is your goal in publishing these things? What do you hope to achieve?
One thing we realized last year is that we already have a well-oiled machine, and we need new inspiration. We need inspiration not only from within the company but also from external sources.
So that we can gain inspiration from the outside, we need to integrate ourselves more into the public sphere and not just confine our activities within the company. As a result, companies and individuals have started reaching out to us, offering various collaborations and sharing their ideas. It has become one of our sources for what we need to do.
'Knihovrátok' is a project that I feel has worked quite well. Can you tell us something more about it, what it actually is?
There are various marketplaces where people can exchange books with each other, but the whole process is quite inconvenient. You take photos of your books and then wait, hoping someone will show interest, pay you, and that you won't be deceived or receive a stone instead of a book in the package, and so on.
So on the one hand, you have people with full bookshelves, many of whom don't want their books anymore, and on the other hand, you have people who would like to have those books. And we realized that we're in a unique position to facilitate this process. We can sell used books, purchase books from people, and act as an intermediary.
Therefore, we can offer slightly cheaper books to people who may be price-sensitive and help others clear their bookshelves in exchange for buying new books.
What kind of feedback have you received from people? You mentioned that it's progressing nicely, but has it already become a separate business model?
I can't say it has become a large, standalone business unit for Martinus at the moment, but it is indeed a rapidly growing area that aligns beautifully with the vision we want to fulfill in Slovakia.
The second project we haven't discussed yet is 'Poradca detských kníh' (Children's Book Advisor). Is it purely the result of the explore team effort, or is it something that already existed before?
Sometime in October last year, we attended a lecture by Viki Marcinova, and she showed us how difficult it is to choose books for children. You see when you select books, you do it based on someone's age. For example, if a child is 7 years old, you choose a book for 7-year-olds.
However, apart from the child's physical age, there is something called reading age. Viki explained it to us very professionally. She said that if someone is 12 but has never read before, and you give them a book meant for 12-year-olds, it won't work. The letters might be too small or the content too challenging, and the child just won't be able to read it. She presented this theory and then showed us a case study where they took children one-on-one, asked them a few questions, and based on the result they gave each child a book saying, 'This is the book for you.' It was a resounding success.
We looked at it and thought we have to implement it on our web. All parents struggle with how to choose the right book for their children. And here was someone who can ask four questions and recommend the perfect book.
So we decided to digitize their brains. We sat down with them and drew spider diagrams, listing the questions we could ask, and picking books we could recommend based on their answers.
Based on that, we created an advisor where you receive five questions and then get advice on how to choose books. Plus, you end up with a selection of only five or six books that we recommend, along with tips on choosing additional books.
That's the prototype we developed in a few weeks. Currently, we're running tests to verify whether the books people bought based on our recommendations actually worked for their children, making sure nothing was missed.
What are all the sources of ideas for your projects, and where do people submit them? What's the mechanism?
In Martinus, we use Workplace, which is like a company's Facebook. We have a group called Nápadovník (Idea Generator) where people can submit their ideas. That's one source.
The second source is people coming up to us and saying, 'Hey, guys, listen, I have this idea,' and we write everything down. Then, at some point, we discuss what to do with it. Now we want to proactively start engaging different departments, talking to them about their problems, and so on.
Another part comes from outside, from conferences or reading a great book. Some ideas come from our own heads as well, we steal many things. But what we really want to focus on now is that we have hundreds of people interacting with customers and seeing their problems. We want to teach them how to identify those problems. It's part of our mission.
Do you have a list of ideas? How do you approach and prioritize them?
We try to plan things a bit on a three-month basis. We're always agile and capable of canceling everything and focusing on one topic if we think the others aren't worth it.
Regarding the selection process, the foundation is how much we believe it will impact people. We can never be sure it will have the desired impact, but we always try to make a qualified estimate.
We've also realized that in order to maintain the flow, we need to have different categories. One category is 'ňuňu' projects (projects that don't have a business impact and their goal is to please the customer). Then we have a category of big impactful topics purely for research, but many times we don't even know what are the problems there.
And then we have projects that are almost fully developed and need testing. So, it's not just about the impact, it's also about the topics. We aim to function without any delays, constantly developing and creating something.
We'll move on to my favorite topic: work methodology. What is your approach? Where do you draw inspiration from, and what are the steps you go through?
I have to say that we are already a big mix of various things we've seen. So when we talk about the framework, I can't even tell you anymore what we stole from which framework.
Our framework heavily depends on what material you have and whether it's actually a solution. And that's the most common case, that you have a solution, but you're asking, what is the problem attachable to it?
That's when we try to do what we call pre-research. What are the problem hypotheses? What must hold true for that problem to even exist? And then we brainstorm solutions together. There we ask ourselves, what is the smallest experiment through which we can prove or disprove the solution?
The Fakedoor test is our favorite test because it has allowed us to bury so many bad ideas.
For example, when we were working on some super-sophisticated mobile solution for our stores, we could have developed something with chips, where people could directly place their mobiles on the book, and it would show them more about the book or allow them to buy it directly from their phones without paying at the counter.
And there we asked ourselves, are people even willing to take out their phones in the store? Isn't it a moment when they want to look at the book? So we covered one of our stores with big posters containing large QR codes - Free Book, scan it or enter this code here - and we tracked how many people were willing to take out their phones and scan it.
We found out that despite the Free Book and eye-catching posters, over several days only five people did it. This led us to believe that it didn't make sense to proceed to further stages because obviously, people don't want to work with their phones in the stores.
And what about those projects where you may not have a solution, but you need to explore? You mentioned the topics you put in a shared pot. What activities do you do?
Basically, from observation to some qualitative research, that we select for example five parents with children of a certain age and ask them how they live and what their day is like through various questionnaires. We also approach it quantitatively, where we quickly ask questions online, like how full their bookshelves are, how many books they would give away, and how many they would sell. This way, we can quickly map people.
We have also tried observation, but it's difficult to do in the physical world in that design-thinking way, where you would have to go to someone's home and spend a day with them, or do diary studies. So mostly, it's really qualitative interviews with people where we ask them how they approach these things, how they typically do it, and have them show us something, and so on.
You mentioned the Fakedoor tests...
The fakedoor test is our favorite test because it has allowed us to bury so many bad ideas, as it's a very quick process. Someone comes up with an idea like, let's start accepting cryptocurrency payments at Martinus. It takes 10 minutes to add cryptocurrency as a payment method, and then we inform people that, sorry, cryptocurrency payments are not available yet, but leave us your email, and we'll notify you when it becomes possible. And then we find out that four people clicked on it within two days. Solved, idea discarded.
Diary studies caught my attention. Why doesn't it work? Is it too time-consuming?
I have to admit that we haven't done that at all. Exactly because even qualitative interviews are time-consuming for us. I feel that in the Slovak environment, there is still a certain limit to it. Telling someone, 'Hey, I'll be following you around, or asking you to write this down' is something we haven't tried yet.
Some of those projects turn out to be successful, reasonable, and interesting. Then comes the moment of making them sustainable. How do you transfer these ideas into operation?
As I see it, we sprint, and now comes the delivery phase, but the rest of the company has completely different goals and operates in a different mode. What we do is we try to involve stakeholders during the project to make them adopt the project.
And then provide extensive support. It works much better when we can really support the project and spend some time with the other team, showing them how everything works.
Our goal is not to develop it in a way that they immediately take over it. Theoretically, after each experiment, we should throw away the code, and they would develop it from scratch because we don't think about long-term sustainability and such. We want to test it quickly, and it doesn't have to align with the development team's standards and culture.
Of course, we take that into account to some extent, but that's exactly the contradiction between exploit and explore. We're not interested in the long-term and sustainable aspect; we need to do it quickly. On the other hand, they're not concerned about speed; they need to do it sustainably.
How do you integrate your ideas and thoughts into a holistic customer journey? Do you have it mapped out in any way?
Mapping the customer journey is something we're currently working on at Martinus. I don't think we're completely off when it comes to customer journeys. The problem is that our project, for example, addresses a 'nice to have' aspect of the customer journey, which is not essential at the moment.
The most important thing for a customer in an eshop is that they can get the product quickly, it's available at a nearby location, the range of offer is wide, and so on. Those are the basic things we often don't address. We don't come up with something like super-fast delivery, which means we can end up lower in the department's list of priorities.
We've talked about your exploration, but how does exploration or discovery work in other digital products at Martinus?
I think it's very similar. We have a digital department dedicated precisely to product ownership at Martinus as such. They have a system, and a part of it is also discovery, which reinforces, so sometimes it is really on the verge.
They have their own projects, and a few times in the past, we've also helped with their discovery because we have a vital skill in testing things. We're good at A/B testing, quick experiments, Fakedoor testing... We can do it quickly. So sometimes, we help them a bit, but they can already function independently in this regard.
Let's imagine, I'm someone in another organization and I would like to start with exploration. What are your tips on how to begin, and perhaps some literature that could be interesting?
Recently, I read a great book called 'Always Day One.' And that I think is a good starting point when asking about books. It beautifully explains why big companies like Google, Facebook, and others manage to innovate even when they're large.
When you're in a small company, my advice is to use common sense and start small by trying out ideas alongside your regular operations. Ideas are always there, even if the company is focused on business goals, but you always discard them because they're not a priority at the moment.
One of the things a person must have is the mindset that failure is good.
So the initial collection of ideas is always about finding many of them and just playing around with them, trying things out. But yes, it's important to acknowledge that out of a hundred things, only five might work. One thing a person must have is the mindset that failure is good. Because that's what sets us apart from other departments; we simply keep fighting with a mindset of 'fail, fail, fail, fail, fail.' But the best path to the best solutions is through fails.
That brings me to the last question I ask every guest. What is your biggest design challenge that you would like to solve in your life?
I have two. I have one problem for which there is no solution and one solution for which I have no problem. The biggest problem, which I already mentioned, is that we know people love reading. We know it benefits them tremendously, but they struggle to find time for it. How can we help them with that? It's an incredibly challenging thing, and I don't have a solution for it.
And the solution without a problem is that since I became interested in books, I've always wanted to create a social network about books. In reality, there is no demand for it because reading is a very solitary activity. Even Goodreads, which is the biggest in the world, is actually small, with low user engagement, and it doesn't work well.
Readers probably don't want a social network, but I would love to create one, and we've tried it many times. At Martinus, you can find all sorts of badges, labels, and features, and only a very small fraction of users actually use them. But maybe one day it will change.
The full interview with Tomáš Ulej in Slovak:
To see this content on our site, you need to agree to usage of 3rd party cookies. Or you can follow a link that will redirect you to following address: https://open.spotify.com/episode/4tYj1fjQcAbbCBMevWyY7c
Minimum Viable Podcast is brought to you every two months by the design studio Lighting Beetle*, which focuses on creating an exceptional customer experience.
Design is all around us. Minimum Viable Podcast explores design with a small “d” – the one that looks for solutions to people's problems. In it, together with our guests, we address topics that are related to design, but we normally do not associate with it. Thanks to the Zeldeo production studio and our production manager Mojmír Procházka for the cooperation.
We are looking forward to every listen, follow, share, and suggestion for improvement. You can send us your tips for interesting personalities with whom we can talk about design to podcast@lbstudio.sk.
Enjoy!
