Checking session availability…
Hang tight while we load the latest updates.
You are not the protagonist of the products you design, product manage or develop.
Fabiola explores ideas and tricks to stay humble when creating meaningful and impactful products for people.
Stay Humble!
Fabiola Rodriguez at UXDX Community: Stockholm. Video: https://youtu.be/RCQNFx1c7GI
Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.
Five principles for staying humble
[00:00:06] This is not about me, and I will not be talking about Voi directly either. I'm here to talk about you, and how you can help create meaningful and impactful products for people. My honest belief is that it all comes down to one fundamental mindset, which is how to stay humble when building products. I will break it down into five principles, which are a combination of ideas and tricks for you to think about, regardless if you are a product manager or a designer or a developer or an entrepreneur.
[00:00:47] So the first principle that we'll touch upon, and now you can change the slide, is the one that is don't be dogmatic. And I couldn't avoid putting a dog there, just too easy. Product development, as you all know, is like a machine. You put something in and then you will get something out. It means that it is a systematic set of processes, frameworks and tools to help bring an idea to market. But it is important that you don't corner yourself with only the methods that you're familiar with, and don't be completely against tools that didn't work in previous experiences. I think we're very much learning that today, from the previous talks that I heard.
[00:01:35] New frameworks, processes and new tools should always be welcome. The bigger question should always be, will these methods help me create products that are easy to use, that people need and want, in a faster way? How can we avoid flops? It is these types of questions that really are driving the evolution of new ways of work. When it comes to product development, nobody really wants to spend time working on a product only to learn at the end that nobody really wanted it.
Twenty years of product practice getting better
[00:02:12] So if we take a quick look into what happened in the last 20 years of product development, a lot has happened. In the early 2000s, for example, a bunch of people started asking, what can we do differently? Waterfall methods had too long cycles. Professionals were frustrated. It took forever to fix problems, not to even mention bring new products to market. A lot of these frustrations culminated in the release of the Agile Manifesto, which I'm pretty sure you are very aware of.
[00:02:52] When working in a waterfall way, we often spent months, if not years, building products, and from time to time we would tell our business stakeholders how things were going. Normally months would pass by and then often we would learn that we were on the wrong track, that we were not building what they wanted. Product requirements documents were terrible at communicating, I don't know if you've been around when those existed. We misunderstood them, we got further and further away from what our business stakeholders wanted.
[00:03:34] On the other hand, agile encouraged us to do two things, and one was to develop in much smaller batch sizes. So don't design or write code for months and months, instead build something for a couple of weeks and then show it to your stakeholders and see if you are on the right track. That helped us know if we were working on what the business stakeholders want, and it was a good step forward.
[00:04:00] But around the same time we saw another trend, a trend that was pushing on another dimension. It was asking a different question. It was not only about building what stakeholders wanted, but instead it was about building products that our customers knew how to use. So that was the rise of interaction design, for example, and design thinking. In the early 2000s we started to see companies hire interaction designers, and the popularity of this really helped put customers, humans, at the center of product development.
[00:04:39] So the conversation started to be about the importance of empathy for our customers. Then all of a sudden it was no longer about building for our stakeholders, we got to focus more on building for people. These two trends were very good at working together, agile methods and design thinking. It really helped us take a giant step forward in informing how we decide what to build.
[00:05:04] After that we saw another step forward. The Lean Startup came about, and then we were not just asking, are we building something that people can use? We started to ask an even deeper question: are we building things that people want? By then user experience designers came about and UX as a discipline started to evolve, and they were also asking this question, which meant we were eager to learn even earlier in the product development process.
[00:05:40] And then we also saw the rise in popularity of yet another tool, and that is the jobs to be done framework, which asks a different question even. We were not asking, do our customers want our products, but, are we solving the right problems for our customers? Are we solving a problem people care about? We moved from focusing on solutions to asking, are we solving the important problems for people?
[00:06:07] And then later came about design sprints, which is a fantastic way of introducing human-centered, experiment-driven product management to a smaller team during a week. This is also a fantastic tool, and I'm pretty sure that most of you are starting to think about how to use it. Another popular trend is the use of objectives and key results, popularized by Google, which is a great way of aligning a whole company towards common goals and outcomes instead of output.
[00:06:49] So if you are not familiar with these different methods and frameworks I just mentioned, that's completely fine. What matters in this principle of not being dogmatic is not the details about these methodologies. What matters is the realization that our product practices continue to get better. It has become very clear that people need to be at the center of these processes.
[00:07:19] So now what I want you to take with you from the don't be dogmatic principle is that even when it comes to processes, frameworks and methods, we need to be humble. There will never be the ultimate method out there, and rarely will you be able to just be business as usual when you work in product development. So be humble when learning new frameworks, and be humble when teaching new methods to other peers, because only together will you be able to further evolve our product development best practices. So stay humble and don't be dogmatic, it is not a religion.
Principle two: be dogmatic
[00:08:02] So now we can go to the next principle, which is, be dogmatic. If you ended up in a company where you feel most of your peers are not being as humble as they should be[?], be dogmatic. Because when stakeholders are only thinking about business goals, when for example product managers are treating UX designers as visual designers, when developers are not involved in the discovery phase, or when everybody just cares about output and nobody's talking about outcome, then it is the time to be dogmatic and strong. Not only because it will ultimately harm the product and will not bring any value to the customer, but also because it will suck to work there. A work environment where people are not humble enough to challenge business as usual does not provide a meaningful work environment, much less encourage meaningful product development. Thank you.
[00:09:20] So in that case, just don't give up. Trust the processes and work hard to show in a humble way the why. Trying new methods and new tools, unquestioningly, is the right thing to do, and that actually is what the industry has been doing for over 20 years, so it shouldn't be a problem. So start small but be consistent. Run pilots of different frameworks, and be inclusive, because you will never be able to carry out proper product development by yourself. You need your peers to buy in to these new tools and new ways of thinking. So run your pilots together, and once you have shown the value behind it make sure it is standardized. So be dogmatic about trusting the process, but take others' perspective. Be dogmatic in a humble way.
Principle three: be bold, but be humble
[00:10:22] So if we go to the next principle, it is, be bold but be humble. And humble, humble, humble it comes. This principle is mostly directed to designers, but it can be applied to other roles as well. When designing or building products or solutions, be bold, but only in combination with humility. So be bold enough to believe that the things that you're making are something that people want and need, and be humble enough to understand that as a designer, or for that matter any other role, it is not about you or your portfolio or your set of features or your product role. It's about the people that you are designing for and how you might just help them have a better life somehow.
[00:11:17] Now unfortunately this means that you will never be the protagonist of your products. Of course these decisions are highly nuanced. You need to rely on research, on iteration, on testing, but last but not least, intuition. Because human empathy, we could say, is both art and science. Especially now that data-driven methods are so powerful. But data analytics will never be a substitute for product and design intuition. Data can help us make a good product great, but it will never make a bad product good. So I encourage you to work on your product or design intuition.
[00:12:15] These methods are of course very helpful, they are good product practices, but they don't mean anything if you don't understand something much more fundamental. You have to understand who you are creating for. If you don't, at some point you will run into the walls of your own experiences and opinions. When you design products for mass consumption you need to consider age, culture, socioeconomic status, and sometimes even physical and mental disabilities.
[00:12:50] So finding the boldness and the humility to do right by your customers can be sometimes hard, because it can take a longer time to come up with what it is that they need, but it is completely necessary if you want to create long-lasting solutions for others than yourself. In that sense the principle of being bold but humble can apply to many roles. So trust your expertise, but always remember that it's not about you. You're not the user, and you are not all the kinds of people that are out there. It is about mastering the balance between excelling at your craft and profession, but in a humble way.
Principle four: designing for change
[00:13:43] We can go to the next. So the next principle I'd like to talk about is designing for change. This one is about not clinging to brilliant visions about what your product was going to be in the future. I would even encourage you to intentionally design for more open-ended usage of your products. You will be surprised by the unforeseen directions people take your product.
[00:14:17] If we look back to when we were children, for example, open-ended toys were the ones that had the longest lifespan and also were the most fun. A good example of this kind of toy is a ball, for example. These toys told children in an indirect way, I believe in you, in your needs, in your fantasies, and I'm here to serve you, because probably you know better what you need, what you want to do, than I do. That is a very powerful message to give and to own.
[00:14:54] As makers, I hope we create products that intentionally leave them open. Just imagine how user empowerment will play itself out in the marketplace, for example. While open systems can seem a little bit risky, they also allow innovation in the way people relate to those products, to content, and also to each other.
[00:15:24] So many of the high-impact products today didn't end up being used in the way they were envisioned, because they were left for the community to innovate upon. A very good example of this is Twitter, which started as a service for bike messengers. To their credit, the creators of these products put their concepts out there and the product took unexpected turns, and to their credit they did adapt and they learned from what people thought their products should be about, instead of sticking to their original idea.
[00:16:12] So by creating open-ended products we can, to say it bluntly, capitalize on the creativity and innovation of thousands if not millions of people, and we don't need to only rely on the expertise of a few of us. So we can instead work on removing barriers for them to enter the product and let people dictate what they need.
[00:16:45] Now this doesn't mean that your entire product needs to be completely open-ended. You can start with small features that are enablers of user empowerment and see what happens. You will be surprised by how quickly people meet their needs with flexible platforms, because at the end of the day we are all problem solvers. So in short, what this principle highlights is the importance of humility in finding the purpose of your product. So be humble enough to trust that your customers know best what their needs are and how they will change, and help them by providing a platform.
Principle five: building for a better future
[00:17:36] Yes, we can go to the next principle. So the next and last principle is building for a better future. What does this mean in terms of what we as an industry, or as professionals, have been doing and working for? We've done a very good job at focusing on the top section of the Maslow hierarchy of needs. If you're not familiar with Maslow's theory, I can give you a very short explanation.
[00:18:15] Maslow explained that human needs could be described as levels in a pyramid, and working from the bottom up you move from basic needs such as food, shelter, safety, health, to psychological needs such as, for example, family, respect, self-esteem, freedom, all the way to the top, which he called self-actualization, such as for example comfort, creativity, self-expression, problem-solving. And the challenge is that humans have a very hard time addressing their needs on the top of the pyramid if their basic needs at the bottom are not being met.
[00:19:09] We must spend much more time using our expertise and practices as designers, as product managers, as developers, and especially as entrepreneurs, to address the bottom part of the pyramid. We need to somehow have a better focus on addressing the not very sexy issues related to, for example, reinventing governments or healthcare systems, education, and of course climate change, or at least not to make it worse.
[00:19:48] Remember that the majority of the world are actually still stuck at the bottom of the pyramid. Even if there are rebel companies such as, for example, here in Scandinavia, Karma, Just Trade[?], and I actually like to think that Voi is also among them, these companies still feel like exceptions. So where do the roles of designers, developers and product managers fit within government, healthcare, education, or many other underserved areas? That's something I will leave you to think about. But to do so you have to be an optimist.
[00:20:30] So when deciding on which products, or in which direction your career will take, be humble and realize that you are part of something bigger, and that all of your actions and decisions have an impact on people's lives and the planet, especially if you work in product development. We have to let go of the notion of us as makers of beautiful and fun products only, and choose also meaningful roles as facilitators of people problem solving, big and small. Hopefully in the future it won't just be about business and consumers, it will hopefully be about humankind, the planet and the greater good. So be humble and be responsible.
[00:21:25] With that being said, I want to thank you. You can go to the next slide. I want to thank you for listening, and I hope some of these principles taught you something, or at least I hope they were a reminder of what to strive for when building meaningful products for people in our ever-changing world. You are welcome to add me on LinkedIn and send me a message in case you want to connect further. Also, the reminder is that we are currently recruiting at Voi, and if you're looking for a new opportunity don't hesitate in contacting me. Thank you once again.

