Stay Humble!

So, I will not be talking about me, I will not be talking about Voy directly either. I'm here to talk about you, and how you can help create meaningful and impactful products for people. And my honest belief is that it all comes down to one fundamental mindset, which is how to stay humble when building products. And I will break it down into five principles, which are a combination of ideas, tricks for you to think about, regardless if you're a product manager, a designer, a developer, or an entrepreneur.

So, the first principle that we will touch upon and now you can change slide, is the one that is don't be dogmatic. And I could not avoid putting a dog there, just too easy. So, product development, as you all know, is like a machine, you put something, and then you will get something. It means that it is a systematic set of processes from work frames 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. And I think we're very learning in that matter, according to the previous talks that I heard. So 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? Right? So 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. So, if we take a quick look into what happened in the last 20 years of product development, a lot has happened. And 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. Also, it took forever to fix problems, not to even mention bring new products to market. And a lot of these frustrations culminated in the release of the Agile Manifesto, which I'm pretty sure you are very aware of. And so, when working in a waterfall way, we often spend months, if not years, building products. And from time to time, we will 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, you know, 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, further away from what our business stakeholders wanted. And on the other hand, agile encouraged us to do two things. One, 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're on the right track. So that helped us know if we were working on what the business stakeholders wanted. And it was a good step forward. But around the same time, we saw another trend, a trend that was pushing on another dimension. It was asking different questions. It was not only about building what our 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. So early 2000, we started to see companies hire interaction designers, the popularity of design thinking really helped put customers human at the centre of product development. And so, the conversation started to be about the importance of empathy for our customers. And then it was no longer about building for our stakeholders. We got to focus more on building for people. So, these two trends were very good at working together - agile methods and design thinking. It really helped. It helped us take a giant step forward in informing how we decide what to build.

And so, after that, we saw another step forward. The Lean Start-up 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? Now 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 process and the product development process. And then we also saw the rising popularity of yet another tool. And that is the Jobs to be Done framework, which asks a different question even, we were not asking 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, and then later came about Design Sprints, which is a fantastic way of introducing human-centred, experiment-driven product management to a smaller team during a week. And 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 popularised by Google, which is a great way of aligning a whole company towards common goals and outcomes instead of output. So, if you're not familiar with these different methods and frameworks I just mentioned, that's completely fine.

What matters in this principle of being not dogmatic, is not the details about these methodologies, what matters is the realisation that our product practices continue to get better, has become very clear that people need to be at the centre of this process. So now, what I want you to take with you from the drumbeat of my principle is that even when it comes to processes, frameworks, or methods, we need to be humble. There will never be the ultimate method out there. And rarely, you will be able to just be business as usual when you work in product development. So be humble when learning new frameworks, be humble when teaching new methods to other peers. Because only together you will be able to further evolve our product development best practices, so stay humble, and don't be dogmatic. It is not a religion.

So, now we can go to the next principle, which is Be Dogmatic. And so if you ended up in a company where you feel most of your peers have not, are not being as humble as they should be, be dogmatic. Because when stakeholders are not only thinking about 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 or nobody's talking about the outcome, then is the time to be dogmatic and strong. So, 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 encouraged meaningful product development.

So, yeah, so, in that case, just don't give up, trust the processes and work hard to show in a humble way. Why try new methods and new tools and questioning is the right thing to do. And that actually, it is what the industry has been doing for over 20 years. So, it should not be a problem. So, start small but be consistent, run pilots of different frameworks and be inclusive. So, 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 standardised.

So, be dogmatic about trusting the process, but taking others' perspectives. So be dogmatic in a humble way. So, if we go to the next principle, it is Be bold but be Humble, and humble, humble, humble it comes. So, this principle is mostly directed to designers, but it can be applied to other roles as well, when designing or building products and 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 roadmap, this is about the people that you are designing for, and how you might just help them have better life somehow. So 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 that is both art and science. So, especially now that data-driven methods are so powerful, 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.

So, these methods are, of course, very helpful. There 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. So, when you design products for mass consumption, you need to consider age, culture, socioeconomic status, sometimes even physical, mental disabilities.

So, finding the boldness and the humility to do right, by your customers can be sometimes hard because it can take a longer, longer, time to come up with what is it that they need. But it is necessary if you want to create long-lasting solutions for others than yourself. So, 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 kind of people that that is out there. It is about mastering the balance between excelling at your craft and profession. But in a humble way.

So, the next principle I'd like to talk about is Designing for change. And 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. And if we look back to when we were children, for example, open-ended toys were the ones that had the longest lifespan and also the most fun and a good example of these kinds of toys is a bowl for example. So, 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 want to do than I do. And that is a very powerful message to give and to own. And as makers, I hope we create products intentionally leave them open. Just imagine how user empowerment will play itself out in the marketplace, for example. And while open systems can seem a little bit risky, they also allow innovation in the way people relate to those products, to content, also to each other.

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, for example, Twitter, which started as a service for bike messengers. And to the credit of, the creators of these products, their concepts, they put their concepts out there, and the products took unexpected turns. And to their credit, they did adapt, and they learn from what people thought their product should be about, instead of sticking to their original idea. So, by creating open products, open-ended products, we can to say it bluntly, capitalise 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 their product, and let people dictate what they need. 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 bridge 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 your customers might know best, what their needs are, and how they will change and help them by providing a platform.

Yes, so then the next and the last principle is building for our better future. And so, what does this mean, in terms of what we as industries or as professionals have been doing and working for? We've done a very good job by focusing on the top session of the Maslow Hierarchy of Needs. If you're not familiar with Maslow's theory, I can give you a very short explanation. 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, healthy to psychological needs, such as, for example, family, respect, self-esteem, freedom, all the way to the top, which he called self-actuation. So, such as, for example, comfort, creativity, self-expression, problem-solving. And the challenge is that humans have a very hard time addressing their needs at the top of the pyramid if their basic needs at the bottom are not being met.

And we must spend much more time using our expertise and practices as designers as product managers, as developers, 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 health care systems, education, and of course, climate change, or at least not to make it worse. And so, remember, the majority of the world is actually still stuck at the bottom of the pyramid. Even if they are they are rebel companies such as for example here in Scandinavia, Karma, J trade and I actually like to think that Voy 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. So, when deciding on which products or on which direction your career will take, be humble, and realise 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’s, especially if you work within product development. So, 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. And 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. So, with that being said, I want to thank you for listening, and I hope some of these principles got you something or at least I hope they were a reminder of, what to strive for when building meaningful products for people in an ever-changing world. Yes, you are welcome to add me on LinkedIn and send me a message in case you want to connect further. Also, a good reminder is that we are currently recruiting, if you're looking for new opportunities, don't hesitate in contacting me. Thank you once again.