BottomUp - Skills for Innovators

Hello, and welcome to the bottom up skills podcast. I'm Mike passings. I'm the. Chief
executive officer at QualityNet and it is great to have you at our next installment of design
thinking. Now, the previous show told a lot about getting the features or the user stories, right.
For your product, but those have to live in harmony with something.

And generally speaking, you could refer further to that as the business logic. All the business
rules. And that's what we're going to talk about in this episode of the bottom up skills podcast.
Now, remember everything that we're going to talk about is from our design thinking
masterclass, which you can grab at bottom-up dot IO.

Now you might be thinking to yourself, Oh, I can't. I thought we were going to be creative and
talk about design. Well, We're talking about that and much more [00:01:00] because design
thinking is not just about classic creative and art direction. It's way more than that. And actually
the best design not only feels good, uh, for the end user, someone might say that the products
that we make a desirable, um, but you know, a lot of the products we make.
Have to work with technology so that technology has to work or said differently. It needs to be
feasible. And in particular, when we talk about the business rules, the logic and so forth, what
we're really talking about is a viability and actually great design thinkers, build products that are
not only desirable, not only feasible, but wait for this.

Just when you're like, Mike, this is getting pretty hard. They have to be viable to. And so we're
going to talk a lot about business rules and processes and business requirements, but I'm going
to do this through a product lens, through a design thinking lens. The key points about
[00:02:00] design thinking. You must consider the business too.

This is just not about making something that's beautiful. It's gotta be beautiful and profitable.
And that's what we're going to talk about. Okay. So let's get a couple of definitions, um, done
right up front and there's probably three layers of business rules, business processes, business
requirements, policies, um, that all get mishmashed and confused and so forth.
Um, so what I want to do is I want to give you a three layer approach to understanding. What's
really required of our product. If we know what users want, we need to make sure that the
business is doing the right thing. And there is absolutely no point building a product that. Uses
love. Um, let's take a Limewire, um, and all of the peer to peer downloading software that came
out [00:03:00] 15 years ago or so, and it was great for users, but it had no business integrity
because it was illegal and they got shut down and so forth.

So what we're going to talk about. Is how you can avoid, um, making a product that's not
compliant with the different business requirements, um, and how you can, uh, trade off what
users desire, what the businesses need and what technology allows us to do. So here are the
three definitions. I want you to think about these three levels of what a business is required to
do when it builds a product.
Now, the first one is, um, The highest, uh, it's probably the coolest, first of all, and it's the law.
This is, uh, so differently. This is an external constraint imposed upon the product and we have
no choice, but to adopt these practices. Okay. So it's an external constraint. It's fixed. It is what
it is. [00:04:00] You have to comply.

Now, this is the first level of logic that has to exist inside your app. For example, if you have an
app European union, you must be compliant with GDPR and this protects the rights of
individuals to privacy. And that personal information. So this is a constraint that is put upon a
business and therefore your product.
So anyone publishing a product in Europe, or I would just say it's a pretty good guideline to how,
how to take good care of your customers. You should launch a product that is GDPR compliant
now. Um, That would be just a very good baseline on understanding some of the business rules
that you would need to follow.

For example, if you were going to be compliant with GDPR, GDPR, how you collect and opt in
for a newsletter has very specific requirements and you have to outline the different types of
[00:05:00] use that they are allowed to select. And so this is like a very specific. Product
requirement, it would be in your user stories.
Um, but it actually is born of the business requirements. So if we want to get the business logic,
right, we need to, uh, adhere to the laws. Now there are overarching laws like GDPR, uh,
California also has a very, uh, high level privacy protection. So you. If you're going to operate

your business there, you need to adhere to those, but it goes a level deeper with the legal
compliance and legal obligations.
Because if you're in the health industry, you might be subject to HIPAA. If you're in banking
industry, you might be exposed to KYC, know your customer, both of these would be in addition
to GDPR requirements. So what you can see here is on this first level, there's a whole bunch of
requirements. All of your product that would affect your themes, your epics, your user [00:06:00]
stories.
You would have to be specific on how you well opting people in, in that user story. You'd need
to have all the right fields in there. And in addition to that, the way you process data, the way
you provide information back to customers. May also be affected by healthcare policies, set at a
government level or know your customer, uh, for, for the banking industry.
So this is level one of understanding, kind of what kind of logic should be inside of your product.
The second one is you need to understand your, your business policies. Now these may or may
not. Directly interact into your product, but they will certainly affect the business rules that you
set inside of your product.

So I want to talk a little bit about what, uh, the differences between a business policy and a
business rule. Okay. So let's get into that. So policies are very important, um, because the
policy could [00:07:00] be. Um, said differently. It's like a guideline that the company has on how
it might govern employees, personal equipment, um, how it frames its view of the customer.
What is a customer, or if you want to look in a really strategic perspective, it may be the
principles, but which you do business. So if your, um, Business policy is to do no evil, um, or
your company vision is to do no evil. Then your business policies would have to reflect, uh, that
if your, uh, vision yeah.
Uh, is like Airbnbs and it's all about belonging and bringing people together, then you can
imagine that some of their principles and guidelines and governance would be a mirror reflection
of that vision differently. If let's say you notice, start up. Or scale up in the case of Airbnb, let's
say you're a really big organization.
[00:08:00] Well, then you're gonna have a lot of policies, a lot of guidelines, a lot of checks and
balances will be born out of those. Was really important to us and what those are, because they
may directly affect what you're able to provide as a business inside of your product. So whether
you're a small or a big company, new, old, the point here is you need to understand your policy
because they may affect.

Um, not only the tone of voice by which you deliver information and services, but they may be
significant constraints that affect your product. And maybe you need to go back to people inside
of the organization and say, Hey, this is a real blocker. We'd like to do things a little differently.
So that's like a busines...

Hello. Hi, and welcome to the bottom up skills podcast. I might pass on the CEO of quality lens. And today we're going to talk details. We are going to talk user stories. They are the micro micro, the smallest of the small little elements. That referred to what we're going to build in a product. And these little things have such a big impact on how we work when we're building a product.

So we use a story which is, you know, It is a clearly defined interaction in the product is so important because what it does is it is a point of reference that creates clarity for all the members of a team about what should happen in the product or service. Now. The important thing is that they are written in a simple, easy to understand nontechnical non-strategic.

Uh, language so that it means everybody can make sense of it. And as you're moving fast and you know, you want to build this amazing product because possible making sure that you've got absolute crystal clear standing of what needs to be made means that you, then when you have your user story, you can assign it to a person that you can.

Looking confluence, uh, to find all the backup data and they know when they have to make it. And so user stories, we often, uh, we'll put into a tool, uh, like JIRA and it helps us organize them prioritizing, but user stories are fantastic because what they effectively do is they would enable a engineer. And someone who's an executive sponsor to sit down and discuss the product in a simple language.

And I think that this is really important because. Too often now our products are involving really sophisticated, uh, technology. Uh, I mean, I think the biggest, uh, some of the biggest drivers of this is we're getting a lot more data. And because of that, we start to incorporate machine learning, maybe a little bit of AI.

Certainly at least some sort of our rhythms that starts to get pretty complex. And then on the other hand, hardware right. Is changing so much as well. So, you know, our mobile, uh, smartphones are just so powerful. I can do so many things because of all of the, the hardware features. So you can get lost in complexity.

And that's where the user story comes to save the day. It helps us organize the product into a system, um, enabling everybody else to talk about it and for actions to happen off the back of it. Now, you know, people will listening to this will formally, uh, say, wow, you know, this is quite an agile thing.

This idea of user stories, the reason that I'm including it in a design thinking, uh, series is this, is that. Crucial handoff and interaction between a UX specialist and a business analyst or similar roles. And this is where you have the real integration between user needs and business needs. And it becomes also a reference point for engineers to understand what sort of code, what sort of architecture needs to be created in order to make this experience.

Come to life. So user stories are so damn powerful when we think about how to make an inventory of what needs to be in the product. The beauty of this is that all your user stories can be born of all the design thinking practices that you've been using, your ideation, your research, or testing and prototyping.

So anything that gets in as a user story, you should have a high degree of confidence. That, what you tested already with users looks, feels, and you've got good proof, strong evidence. That that user story is a great way to build the product. So I want to talk a little bit now about how user stories get organized and there's this sort of a, kind of a simple hierarchy where you have, I want you to imagine, um, right at the very top is themes.

These themes tend to be. Really big, uh, features, big bucket areas within a product or a service. Um, and they, they tend to be, um, look maybe in a, in a first generation product, you might have half a dozen themes. These are the organizing principles. So if you think about your Uber app, uh, for example, the account section, uh, is.

A theme. And inside of that theme, you will have lots of epics. So when we talk about epics, we're now going down a level and we're getting a bit more specific. So when I look in my, uh, in my account settings, um, inside of that theme, there's all sorts of epics setting favorites would be an Epic, um, managing trusted context.

That's another one verifying my ride. And so on, those are all epics, but if we continue along this a little path or user story would be setting a new address as the default, I felt home address and that might have several micro interactions, buttons, elements, features, filters, you name it. Um, these are the user stories.

So they have it. We got big themes, medium-sized epics and really little stories. This is such a great way to make an inventory of your. Products. And you will find that maybe each theme has a user journey map. And we talked about user journey maps in the last episode. So if you want to go back and grab some more of the back catalog of the bottom up podcast, you can just go to bottom up.io.

Where you can not only find the user story. Goodness. In our design thinking masterclass, you can also get lots of episodes from the podcast. So back to user stories. These things are the essential language. They become a way. If you remember, in that last, we last episode, we talked about the big picture of design thinking, which is the unit and unit user journey map.

Or now we're in the small details. But again, the beauty I've used, the stories is they provide Ventas from talking too much high tech, engineering, or strategy. We talk in really simple terms about what the user would be doing. Sometimes what I've found is putting in. Acceptance criteria. Um, you might have off the back of this technical requirements, all sorts of good stuff will come off these user stories, but the user stories become the essential unit of work that builds a backlog.

So not only we know what's to get done, we know how much time it's going to take and we can start prioritizing and organizing them. So as you think about. Creating your product. And at this stage you've mapped it. You've chosen your primary feature. User journeys are essential in the big picture, but user stories are the essential micro element of the product.

And I can only give you this last thought, this last advice on how to get the most out of them. You need to make sure that your user stories are complete and are detailed. This is something that I would never gloss over because so much of a user story is suggesting the interaction, the data, the rules, if this, then that it is at the heart of how things will be, hard-coded engineered into the product.

So. If you've got someone in your team, who's really good on details. You should give them the user story in a traditional team. You probably have a business analyst write these, but here's the key thing. I great user story written by a business analyst will have been co-created coauthored with technical engineers.

Designers and any other members of the group strategists business experts, because there is no use in just one person writing a user story. The best user stories are ones that have been co-created amongst your core product team. So they have it user stories ever so small. Ever so big when it comes to their power, they will help you organize this entire system.

So if you're really ready to rock and roll, jump into JIRA, that's J I R a by Atlassian. And that is a great place where you can write up store and manage. You'll use the stories and they will, without a doubt, help you build a product. Which is why we're all here on this podcast to share not only user stories and user journeys, but the overall practice of design thinking.

And as you can see, what's so fun, is it interacts with all sorts of other practices, such as r...

Hello, and welcome to the bottom up skills podcast. Once again, we are flying through the world of design thinking and today we're going to discuss mapping the user journey and boy, Oh boy. When you create a user journey or sometimes they could use the maps. I can tell you that this file will become one of the most visited most used, most reopened and wait for it.

Most edited documents that you will have in the adventure of building a product. Now, what is so fabulous about user journeys and mapping out the user of the journey is number one. It forces you once again, as design thinking, well, to go back to the user. So instead of thinking about yourself and how you might enjoy an experience, this forces us back once again, to imagine, to understand.

And here's the key word to empathize with our users to understand how they would move from a, to Z through a product experience. Now I'd want to. Tell you why this matters so much. Why, why a user journey is so essential? Well, they often come into the process in the early to mid stages, and this is really essential, particularly on brand new products, because fairly early stages, everyone's just imagining.

A possible product or service. We don't have an existing product to refer to. So having a user user journey is such a powerful way of, of seeing every single step that we imagine a user would go through in our product and use it. Journeys are uniquely powerful in capturing the big picture. Um, if you think about something I've mentioned on this series, and if you jump over to bottom up.io, you'll see there's a whole agile masterclass built around using it stories which have the smallest micro a part of a product.

Then the user journey is the opposite. It's all big picture, baby. This is what is the overall experience it might be made up of three, four, five. Maybe up to 10 big stages going from one through 10 of the overall user experience. And what's so useful about having this in the early stages is it allows them, us to literally point on the board at what we imagine the product will be doing, what they user will be doing to kind of frame the experience before we've actually built it.

Now what's particularly interesting now is just to point out a huge insight for existing products now. I'm going to share with you a little secret of the product world, which is particularly in the digital app space, whether it's a browser based app, a local install or a mobile app is over time. The, both the interaction and the whole operation texture of a piece of software can get a bit messy and out of control.

And what tends to happen is that. We originally, we had an idea about what uses need and, but then all the business requirements came in and then we started doing, uh, what, uh, people in the business wanted. And sometimes we actually juice the quality of the experience for the users. So if you were to. Have a, you know, a gen two, maybe a third version, fourth version of your product.

You might find that it's got a little bit out of control. So coming in and doing a fresh user journey of what you have, and then asking yourself from a to Z. How could we improve this or user journey is like a really great big picture way of improving an existing user experience too. So whether it's brand new or something that you've been working on for years, your product will absolutely ne need our user journey.

So let's dig in now, uh, into what that looks and feels like. And. You know, we are in the magic, uh, medium channel of voice right now. So if you would like a visual companion head over to  dot IO and you can download the free master class on design thinking and, uh, you can enjoy, uh, all the slides and templates there.

But I use a journey as a series of steps and it represents. You know, the scenarios in which you're using my interact with the product that you're designing. So traditionally we might have, you know, a user journey that hat points out, sort of maybe a login or sign up in the early stages. Then maybe a number of key feature steps before.

During the key feature and after the key feature. And in addition to that, there may be moments where they have to dip into their account page settings page. And these can get pretty elaborate when you work on some serious sort of, um, deep consumer interaction products or a similarly, I think a lot of enterprise products can get pretty, pretty complex as well now.

So you've got. A series of steps. That's the essence of a user journey. Now what is particularly powerful is this idea of mapping the things, the actions that a user would do, the thinking that's in their mind. Whilst they do that in the particular state. Yeah. And lastly, how they're feeling, because what's quite interesting, uh, as people get onboarded and do things for the first time or they make a high involvement decision around purchase, there can be.

All sorts of emotions, people could be excited, confident, or often they might be apprehensive, anxious, unsure. Um, so if you map those feelings, you can also map it to the thoughts that are in the user's mind, and then the actual things they would be doing, um, in order to complete the task. This is at its essence.

A user journey. So what I quite like is this idea of, you know, you map the essence of what are they doing? What are they thinking? What are they feeling now? What's also, we want to kind of go next level and you want to get pretty elaborate with your journey maps. You can start doing things like this. So let's imagine that the general flow of your.

Journey map goes from awareness. So they kind of come, I mean, uh, to your given product service, um, they might be doing some orientation and consideration, then they have to decide, uh, then they actually maybe make a point or an action or maybe they could content. And then after the experience, there's all sorts of sharing of experiences, loyalty.

Yeah. Applicacy all that kind of good stuff. Now what's particularly, um, powerful if you want to do right. Really extensive customer journey map is you can start to map not only the things that the user is thinking, doing, and feeling, but you can also go deeper and say, how will we measure. This stage, like what are the moments, uh, inside of the product that would suggest success?

So what can you measure some form of task, uh, or stage completion, uh, that shows in your funnel and in your map, people are moving through, but then you could also have business logic. Business rules that apply. You could even have a reference to different parts of the technical architecture that actually generates this now for really complex complex products.

Um, what comes to my mind immediately is the work that we do with a lot of banks. Um, You can have not just one, two, three, four, five, you can have over a dozen systems generating data throughout the customer journey map. And, um, if you're, if you've got high accountability in your phone and you've got all of those, uh, architectural systems mapped up, you can even have the people or the, the leads within the team that are responsible.

So, this is really, really powerful having these maps, particularly in that early to mid stage of building a product. And the last tip I want to give you around how you might think about user journey mapping is one of the most exciting and personally, what I really love doing is to pick out like the really.

Magic moments, the wow moments that are in that and start wireframing them. Now, now frame is, is literally a low-fidelity sketch of the experience. It's not like a fancy finished design. It looks fantastic. Look, if it's done in pencil and paper, All the more power to you. I love it. But then you can start sketching what the interactions, what these user stories inside of the map might look like these little magic moments, and th...

Hello, and welcome to the bottom up skills podcast. We are back again, and we are setting ourselves into a world of design thinking. And as part of our design thinking series today, we're going to be asking how do we define the most important the primary feature? Of your new product. And the funny thing about this is you might think to yourself that that is often a very obvious choice.

And what actually turns out is that it is it's been really hard. Thing, because you know, you've done heaps of research. You've got a lot of data there's maybe competing ideas for, what's going to be the killer app in this new product or service. So what we're going to do together today is I'm going to take you on a journey on how you might just pick one.

And, um, we'll really kind of use some different models and different techniques to learn how to make a better feature choice. And the last thing I'll do with you is just share with you my thoughts, why this it's so damn important, because if you don't do it, the consequences. They can actually be pretty dire.

So particularly if you're building a large scale product, that's going to serve a lot of users. So let's take a little journey into choosing the primary feature. And what we mean is the killer app. What is the thing that is going to make this product or service unique? What is its point of difference?

Where inherently is the core value? Because let's be honest. I log in screen. Yes. It's an important feature. It's maybe even. An important user story made up of some different tasks and elements, but we all know that that's a pretty standardized feature, so we need to get, so the thing that is most important, because when you choose that, and this is really, really important, it should be the first thing that you start building.

Yeah. So you don't start with the login. You don't start with the admin tools, you start with your primary feature and I'll explain what happens when you don't do that a bit later on. So. How do we choose? How do we know what the primary feature is? Now? This is particularly powerful when you're building a first generation product, something brand new, because if you've already got a product, chances are you've started to really work out, uh, where users, uh, value your product or service, where they perceive, uh, the most important parts.

But these questions you can ask of an existing product, but they are on their own. They're super special when you're starting from scratch on a gen one product. And, um, I'm going to give you four questions that you can ask of yourself and of your team. And I'm going to give you some models, uh, that kind of take it next level if you want to do so.

And, um, I want to start with, uh, I'm going to give you the full questions and then we're going to break them down. Okay. So you want to know the primary feature? Well, if you've been tuning into any of these podcasts or if you've done any of the master classes on bottom up.io, you know, we always start with the user that is at the heart of design thinking.

It's at the heart of our bottom up methodology. And we ask ourselves this question, Of all the features that are on our list of all the possibilities, which feature creates the most value for the user. The second one you could ask, which feature creates the most value for the business. Third, which high value feature is the simplest to build, which I value feature is the cheapest to build.

Now for the top students of this podcast, you'll notice that I am using what is essentially an architecture of desirability, feasibility, um, and viability. Yeah. But I want to get into each of these simple questions. And by the way, you can get all of these in a PDF form. Just head over to bottom up.io grabbed the mass class.

It's all free, but let's talk about each of these on their own, which feature creates the most value for the user. Now, if you, as a team are having trouble answering that question. Whilst that's a bit of a concern. Don't worry. Cause you need to go back and test more with your prototypes that we talked about.

In the previous episode, you need to go back to your users because your work on user insights. Through interviews through surveys through actually building a prototype should clearly resolve which feature creates the most value for users. Now you could be in a situation where you have two features. I'm actually working on a product right now.

Um, and we've got two features that are. Really unique. And we're very attached to one of these features in particular, but there's a companion feature, uh, which is all around education, which might be the dark horse. Now, when you have a situation like that, where there's, you know, two features that rise above all the other features or user stories that you have, that's a luxury problem.

And, uh, you can, um, You can start with either of those. But I think my most important advice here is if you're not clearly to discuss as a team objectively based on data and insights from quantum qual research, if you can't articulate and agree, which value creates the most value for the user, I would pause right now and I would actually go back a step and test again.

So that's first thing you can do to work out which feature matters most. The other one you can do is work out, which one creates the most value for the business. Now, the only caution I would say with this is don't go building features for the business and neglect the user. But what I like about this question is it often helps.

Create a balance in the features or user stories that you build so that you are creating value, um, that strikes. A balance, a balance between the business requirements and the user needs. And this is often a very subtle, very sophisticated thing that happens on a bigger, more enterprise, um, products, but it's a very, very important balance to find.

So that one is which feature creates the most value for the business. Now the last two, which high value feature is simplest to build, and which is cheapest to build are very important. Now I know that we're doing a deep dive on design thinking, but I want to run in parallel some insights here around.

Agile development and the implications, these moments where design thinking and agile work together. Cause they're very cool. The reason that these questions are really important is we can sometimes paralyze ourselves by trying to build something incredibly complex, something that. In modern, uh, language has maybe a dozen web services or micro services, uh, that has a hybrid cloud environment.

You know, people start doing things like that, and that is complex and we know complexity equals time. So when you're building a brand new product, there is nothing more important than going. Fast because you need my mentum and you want to ship product to customers as quick as possible because you want their feedback.

And that's really at the heart of design thinking. Now another important one, and this will probably be working for a lot of you folks that are in startups, which is which high value features the cheapest to build now. This can be very important. Let's say you're a startup and you've got a funding horizon.

Maybe there are features that are really how awful in the hands of uses, but they require a significant investment and perhaps you can solve some smaller problems. Um, important problems, but you can solve those demonstrate value for the user, which creates value for investors. And you can do a really good raise, um, in your seed rounds, uh, maybe even in your angel rounds so that you can ramp up to go after a bigger prize down the track, these four questions.

I mean, if you're stretched for time, Just use these full, simple, powerful questions. And if you struggle to. Answer them. If you don't know what is cheaper to build, ...

Hello, and welcome to the bottom up skills podcast I might pass since I'm the chief executive officer at quality assurance, and we continue this wonderful adventure into the world of design thinking. And today it's all about rapid. Prototyping and boy, am I like the number one fan of rapid prototyping?

And I'm so glad to have this moment to share with you. What is for me, one of the most powerful things I've ever learned in my career, and I'll tell you why it was so powerful when I discovered it. And first of all, shout out to mr. Tom Chi, who. Really just blew my mind. Uh, some 10 years ago when he induced, introduced me to rapid prototyping and the work that he'd been doing at Google X, it was like a light bulb moment because rapid prototyping is the thing you can do before you build your product or service too.

Work out what exactly. Your users, like what they hate and to understand far far better, what really should be in the first release of your product. But I think it goes a bit further than that. I think what rapid prototyping really does is it shifts us from guessing what should be in our product to knowing you might not know completely and wholly, you know, let's be honest, you don't really know until the product's live.

But what rapid prototyping does is radically shift, uh, your understanding of what should be in your product, through testing and learning with customers. So let's talk a little bit about what rapid prototyping really use. It's a very powerful way to test and validate, and it's very important. Because it will help you understand, have you created enough value in your product?

Are you solving a big enough problem from the user's perspective? And you'll hear this so much in a design thinking and in terms of my experience with design thinking, I cannot emphasize enough. An obsession and like a complete focus upon the user and their well, because it's so easy as creators builders and entrepreneurs to guess what might be a cool product or feature, but that's so often ends in failure.

It's all about testing, learning and validating and rapid prototyping is the thing. So let's take a moment. To actually define what it is. Let's make sure we are all on the same page about rapid prototyping. So what it is is it's this idea of creating a light version of your product or service. Um, and it can be, I mean, you could sketch it on a whiteboard.

You could draw it up on paper or. If you're a bit more later stage, you can actually get out some tools such as Adobe XD or an envision to actually build a clickable version of your prototype. Right now what's essential here is that. Whatever you choose as the form of your prototype. You want to move to a material form that is very light quick and easy because speed is of the essence when you're prototyping, hence rapid prototyping.

The bar that you're looking for is to choose. A form of prototyping and material, um, that is sufficient in generating what we call sensory stimulus. Because if you generate the senses, if you create an approximation of your idea and you can actually trigger a sensory response, you will get. True feedback from your user.

So rather than an a focus group, we say, Hey, would you guys like, does this idea sound cool? If you're just asking the question, you're only taking a very early stage kind of measure or response of what people want. If you move them. Into direct experience where they touch, feel, smell, hear what this product might be.

You shift them from guessing how they would like this product to actually giving you a more visceral response. And that I can tell you is magic. Now rapid prototyping comes in a couple of different forms. I've tried to break it down into three major types of rapid prototyping. Um, that's very applicable to creating brand new first-generation products.

The first thing you could do is you can do what I call a diagnostic prototype. Um, and you know, that could be something like card sorting. Um, you know, you could even, uh, you know, do some shadowing of the customers. They try and get a job done. That that can be very helpful. If you've got a complex, a product or service, or you feel like all of them, the surveys and interviews you did still haven't given you enough, go for more of a diagnostic prototype.

The next thing you could do is you could create yeah. Um, a moment or a little journey. Um, and do you. Mike just choose maybe onboard, uh, our, into you experience. You might try the moment of truth, like the key moment in your given product or service, or you might try customer service support. You might just choose a little moment and try and sketch it and build it.

To see if this would be a viable and feasible solution. Now, lastly, the third type. So the first two diagnostic, uh, type of prototype, uh, then you've got like a moment or journey prototype the third, the one. And you, you would probably do these in order. The third one is where you get out your Adobe XD, your envision.

And you will actually start moving pixels around and creating something that's clickable, but also starts to really take shape and feel like the end product. So these are the sort of three ways you could bucket your activities, uh, organize your activities in, in rapid prototyping, diagnostic moments in digital experiences.

Now, at this point, I do want to let you know that we have a full. Dedicated masterclass to rapid prototyping. It's that important and just pop over to bottom up.io. It's all free. Grab the masterclass and the slice. Cause we go into way more detail than this. I'm just giving you a primer just to lay the seed, if you will.

Okay. Back to rapid prototyping. So, you know, I've given you a kind of a frame of what it is and some of the dimensions of it. Now I want to move into how you might do it. And there's a kind of four very essential ideas that will make your prototyping successful. First of all, we talked about this before, create the direct experience, create a prototype that stimulates a sensory experience.

So if you've got a product for college students, That they would use in the dorm either test in their dorm or create an environment, uh, like their dome so that you can create the direct visceral sensory experience. This will help you so much. Okay. Number two. Validate the prototype by asking questions of the user.

Okay. And what, so you actually have asked a few questions then what you can do with the next round of users, you test with, give them a task and see if they are able to complete the task. This is the essential mechanic to measure what you've achieved in the testing and what you've learned now. You've created the direct experience you're giving the users task so they can test so you can test and learn about their task completion to more fundamental funding, really important guys, two more things.

Number one, compound effects. When you do these things. Yes. In rapid prototyping, try and do as many tests as possible over the shortest period of time. I love to do two days, so you can just. Plow through maybe eight to 10 sprints, hundreds of tests, you will be blown away by the level of empathy, understanding knowledge, and frankly, you will be blown away by the confidence that you can now have in your product.

Once you've seen that many tests with users, and frankly, just a quick aside here, I made a ton of people who always say, Hey, Mike, I'm working on this new thing. I want your help. I want your advice. And the first thing I will always ask, how many times have you tested this with your audience? And invariably, if they're stuck, they've done insufficient amount of user tests.

They've done insufficient, rapid prototyping. Okay. So quick recap. Four key things to meet rapid prototyping it's success. Number one, create the direct experience. Then put to test and learn...

Hello, and welcome to the bottom up skills podcast. I might pass into the C E O of quality science, and we are so deep into our special edition. Our wide ranging a series on design. Thinking, and today we're getting into the idea of design challenges and these turn up at this really important moment when you're using design thinking to create a new product or service design challenges are all about the moment when you've done lots and lots of research.

You've got a clear map of the pains and the gains. You've got a value proposition, canvas. You can sort of match your face with the jobs to be done of your use, and you're ready to really get creative and what this product or service could be. And it's at this moment that you want to write design challenges.

And so what I want to do is I want to take you through the world of design challenges and explain how incredibly valuable they are and how they really bridge the gap. And this gap is. Sometimes people just want to jump straight into building their product or service, and they've never taken any sort of prototypes or test versions, uh, really, really light, uh, MVPs of their product.

To their user. And frankly, that's a jump that's too big for me. I would never want to do that. Having discovered not only design thinking, but also the practice of rapid prototyping. So these design challenges are bridge. You've done all your research. You've done quantum qual and we talked a lot about that in the last episode.

But before you go and build an engineering team of 10 people to go build a product first. Really explore these design challenges and put them into a design sprint. And we'll talk about that later and you'll be able to use your best rapid prototyping skills, and we'll have a whole episode on that. So let's talk about how we can use design thinking and particularly design challenges to create a product.

Now, the first thing is when you have design challenges, there's kind of two major ways. These can go. One can be a very early stage design thinking, a challenge that you might set yourself, which is particularly important when it's a first generation product, uh, you will have no idea of the sorts of. User behaviors, uh, that you're gonna have to understand, uh, all the blockers to switching and adopting a new behavior.

So that generally falls in the bucket of a, sort of a general more exploratory kind of design challenge. I'm all. What I call later stage a design challenge is when you already have a product and you might be sitting there saying, Hey, we need to build a next generation, a widget. Um, we need to, um, really, uh, take what we have and give it a major refresh, uh, significant, uh, version two, version three.

Uh, what we're not talking about is using this kind of approach for day to day, um, you know, product improvements we're talking about when you want a significant upgrade or as I said, Earlier, if it's a brand new product, you really need to experiment with all these sorts of possibilities and early stage product insights.

And the design challenge is the perfect thing. It's the perfect, I think, to give a small team of people and say, guys, go and ideate, go test and learn and validate around this design specific to our product. So what I'm going to do now, Is, I'm going to take you through these design challenges. I'm going to explain how to use, I'm going to give you an example of one.

I'm going to show you how this builds a bridge into the practice of rapid prototyping. So get ready, get all of your, uh, envision Adobe XDS already, because this will be your mission. Yeah. To go and prototype. Okay. So a design challenge is. Based on all the insights that you learnt from your research phase.

And if you'd like to know more about that, just go and grab one of our older episodes at bottom-up dot IO. And that's there that you'll find all the things you need to know about how to research and find out what customers actually might want. We're now moving into a challenge that will. Be based on the assumption that people are going to build a prototype and test it.

That's very important for the design challenge. And we'll talk more about that in a moment, but let's think what could a design challenge sound like? So what I've done is I've looked at all the disease challenges I've written and, um, I've kind of created a template. And I want you to imagine what I'm going to walk you through now is something you'd have maybe five or six people who are going to spend a day prototyping.

And what's also important is to remember that when they are prototyping, it's not a brainstorm. It's quite different. This is about iterative ideation and the. Key traffic light system is, did the user like enjoy, engage, comprehend this product. So remember anything that you build throughout the design thinking process, any insight should be tested and validated with real users.

So if your, if you're building a product for gym junkies, Go down to the gym and test it with gym guys and girls. If this is for master chefs, go into a kitchen and test it with chefs, do not. And I cannot stress this enough, do not get stuck, making beautiful PowerPoint decks that are all a fantasy land of your creation that has no basis of proof or evidence.

This design challenge is what you're going to take to the customer. You're going to build, create, learn, and it will be tough and it will be hard, but it will be so invaluable in giving you some signal on how to create a great product. Okay. Let me take you through a design challenge. So I want you to imagine that you're sitting there and you're about to receive a mission from me, and you're going to go prototype, sketch, build, uh, some sort of light form of prototype to test with your users.

So here we go. Our product is going to be called product X, Y, Z. I'm sorry that that's not the most creative name, but you'll kind of get the drift. All right, here we go. Imagine if product XYZ was your ultimate. Now it could be a guide or tool or inspiration for a particular activity, maybe it's to learn or to work out, to cook, whatever you're looking to discover about this given activity, product X, X, Y, Z will be your number one choice.

So, what we're doing here is we're saying we want you to do imagine if our product is the ultimate guide is the ultimate tool for getting a job done. So it can be any range of those. So it's going to be a comprehensive service that really frames. Really frames the activity and helps create value for the user.

Now you can be very specific. So maybe it could be, uh, an app about the ultimate pasta app, whatever past do you want to cook? This is the ultimate one. Imagine if is a really key framing of this. So what you're deliberately doing is saying, imagine this is just. Amazing in a given category and what you want to do.

And we'll talk about this in a moment as you follow it up with some inspiration, some references, some possible starting points for the team to go and build against that. Now it's really important that we use the word. Imagine if, because what you want to do is you want to encourage the team to discover not only best practices, but maybe some delightful, um, maybe some.

Uh, unexpected ways to approach the category. Now this first one that I gave you this, imagine if one was really sort of front end inspirational way that, uh, people come to the product. The next one, I'm going to give you as a, what if one? And this one is just imagining more of we've onboarded the customer, and now they're an active customer.

So this one is more about the support services experience. Here we go. What if contacting product XYZ support was like talking to an expert or a genius calling customer support and using support websites can be deeply frustrating. Let's turn that moment where they reach out into ...

Hello, and welcome to the bottom up skills podcast I might pass since I'm the chief executive officer. At quality events and I am so happy to have you back for the seventh installment of our design thinking series. And today we're going to delve into problem solution fit and how we achieve that through getting really into the pains and the gains of our.

Users. And in the last episode, we sort of defined who those users were and how we can kind of share that story. Now we're going to start making our way to the product or service that we might build. And today I get to introduce to you this idea of a value proposition canvas, and that is a fantastic. Uh, two that kind of forces us to really simplify all of the potential, uh, product ideas that we have.

It's sort of a forcing factor structures and organizes our thinking and becomes a reference point. Um, when we really work on the pains and gains, um, we then have to ask ourselves, are we relieving them and are we creating the gains? So let's. Delve into the value proposition canvas, and let's see, not only what it does to help us finding out the problem solution fit for our product or a service.

Let's see how this helps us launch product and build a team to do it. How to build a great company. All right, let's stop. Let's go right back to basics. The value proposition canvas effectively has. I want you to imagine it's got two parts and it's all about balancing them together. The first side, it's all about the customer and their wealth.

And on the other side, it's all about the proposition of without given product or service. Now, remember we're in the really early days of our entrepreneurial journey. So it really is. The product really is just a proposition. You know, we don't have, um, a fully working product. We're not servicing hundreds and hundreds of customers.

It's an idea. And so. The first thing we do is we frame this as a proposition and this proposition is, Hey, we're out here to solve the weld. And if we go back onto the other side, it's all about weighing up whether that actually helps the customer. So I want you to think of the value proposition. Canvas is essentially weighing up what the customer wants, what we want to build as a product and trying to actually create fit.

To create harmony and synergy between these two things, because frankly, the reason most products fail. Is that they don't solve a problem worth solving. And so this is a critical step in making sure hang on. We want to go build this big, fancy, exciting, exhilarating product or service, but let's just check in and make sure it's the right thing.

Something that delights and satisfies. Yeah. Customer and importantly, it's something that's doing a job that they're willing to pay to get some help getting done. So. At the core of this, we define on the customer side, we define the customer's pains and the customer's gains. Now the pains are said differently.

What are the things that block me? Or cause friction, when I'm trying to get a job done. Now this is introduced, introducing another part of the customer. So we've got the pain, but importantly, it's a pain that is related to getting a job done. Now, the jobs to be done would be getting the kids to school.

Um, a job to be done could be, uh, learning a new skill, a job to be done could be paying the mortgage. Whatever, whatever is irrelevant for your product is the jobs to be done. That are related, uh, to this area, uh, of the given product or service. What are the jobs that the user is trying to get done? And then what pains?

What blockers, what humps, what, what hurdles do they face trying to get it done? And you'll often, uh, find that it's related to specific pains around time. Around money around effort and convenience. And you will often find that these are where the pains are framed. Now, the gains that they're looking for would be, be essentially the benefits.

In their life when the pains are removed and when the job is completed, having a clear reference point, um, what gains they're looking for, what pains, um, do they currently, uh, encounter when they try and get this job done is a fantastic world, too. A way to zoom in on the customer's universe. As it pertains to the product or service that you have in mind.

Okay. So the jobs should be very specific to the category, the area, the industry, or wherever you're working within, it should be inside of it. Okay. And then you simply look at what are the blockers and what are the benefits, um, that, uh, they experience or desire. So this is the customer world. And then over on the other side, What is the connective tissue here is what are the pain relievers that the user requires and what are the gain creators that they're looking for?

And then you have these as reference to the given product services and features that are inside of your offering. So you have to make sure that a given feature of your product or service either creates again or relieves pain. And so what you then do is you have framed your product and said, okay, here's our product.

It's got three main features and it has certain gain creators because. And helps people enjoy more of this, uh, more of these lifestyle benefits, all of these wonderful things they get to enjoy. But on the other hand, there's also the pain relievers, which is specifically how our product or service addresses the pains of time, effort, and money.

I mean, those are your classics. You can, you can add a lot more, but these are really important. Cornerstones that you need to create. So what I want you to imagine, you've got your list of features in your product, but then the, the job you have to do is ask yourself, how's it creating a game or how's it relieving a pain, and then you have to match those with the gains that your customers.

Desire and the pains that they actually experience, and you need to be able to map these. You need to be able to literally draw a line between those and say, this given feature in our product, we're going to go, you know what we'll do, we'll go left from left to right. In in the canvas right now. So you've got your given product with its features.

A particular feature has to have a pain relieving characteristic. You draw a line across and make sure that relates to specifically if your customers have an issue with time that you have to a, be able to connect those two together and that when you actually address and relieve that pain, this enables going right to the far right side, this enables the customer, the user to get the job done.

Now, just because you've met to this day actually mean that we're finished our job here because yeah. Do you have to test and validate the date that the assumption that said feature relieves the pain for the customer. Who's trying to get a job done and they would be satisfied. This is something that you have to go back to our surveys.

You have to go back to our interviews and what's really exciting is going forward. This hypothesis is something that you would prototype in real life in situation in order to actually have the highest form of the problem solution fit what we've done here by weighing out what the customer needs and what we're offering as a proposition in our product or service.

If we test and experiment and we validate these assumptions, we can then say, you know what? Guys we've got problem solution fit. We know the pains and gains. We're able to address them. This is a product worth building. Now, once you get there, this is something that I have learned, um, from years and years of work, when you know the pains and gains of the customer, you can then go and create some use cases of different features, products, and services, build them into user stories, epics, and themes, and then you prototype them.

Once you validate your prototype, you the...

Hello, and welcome to the bottom up skills podcast I might pass since I'm the chief executive officer at quality assurance. And welcome to our sixth installment of our design thinking series. And today we're really going to get stuck into a really neat part of the design thinking process, which is really understanding our users, really understanding and defining the different segments within our users and bringing that story to life in personas because.

If you're listening at this six installment about design thinking podcast, you'll notice that previously we've talked a lot about all the quote unquote research where you can just go really deep into the world of, of customers, of users. Um, you can even survey employees. It doesn't matter who the end user is.

Uh, you know, the classic survey and interview combination reveal so much. But at a certain point, you've got to bring it all together. You've got to make sense of it all and defining the user and the user segmentation. Okay. Is a key step in the journey for designers, entrepreneurs, builders, executives.

It's all part of your journey. As you go to build a brand new product and let's face it building brand new products. Wow. That's the fun stuff. Uh, that's going where nobody has gone before. So if you're going to take on such a bold challenge, then it is super, super important that you have a really good grasp on the user.

So I'm going to show you how to do that. Using some design thinking best practices and, um, the more rigor you put into defining the user, the crazy thing is everything. Down the track, what you designed, what you develop, what you build, whether it's digital, analog, how you launch it. What's really interesting is.

It always just comes back to for whom are we building this product? Whom for whom are we building this service? Um, this business, no matter what it is, if you always anchor yourself in the user, the customer and having an enormous understanding and empathy. For the world that they live in rather than the world, or you as a creator live in the world, your customer, the world, your user lives in.

If you know that you can always just come back to that and get yourself back on track. If you get lost on this big adventure of building brands, okay, I'm going to give you a. Two real powerful goodies today, a bit later on, we're going to get into personas. Um, but we're gonna start with this idea of segmentation and there's actually four pillars of segmentation.

And the thing that strikes me so much about small and large, old and new businesses, invariably. I am struck by how much more work they could do to know their customer. And so if you really tune into these four pillars that I'm going to give you, I'm going to give you lots of examples. Um, you can spend a lot of time.

Refining defining, getting to know your customer through these. And this is like an ultimate checklist. And if you know this, uh, if you feel this, understand this about your user, you will, you will intuitively you'll subconsciously start building something to address their problems. And the reason I believe this, so I think end a vast majority of us all want to build a product.

That's great. We all want to build a product that's solving a problem, and we all take enormous pride. When we know the products that we've built can really serve the customer. So let's get to know who that person is. Four buckets here. They are the demographic bucket, the psychographic bucket, the behavioral bucket, and the geographic bucket.

These are all ways to segment your user group. This is a forensic checklist, and I'm going to take you through on how you need to know your customer. Now, um, when you hear, you know, demographics and geographics, I think those are pretty common and pretty straightforward. Invariably, this will be where most companies understand their customer.

Val, generally, no, let's say if we're talking about a consumer brand, a consumer product, then invariably, they're going to know roughly a core age demographic that is. Sort of the pillar, like what age are our customer, uh, dial obviously with that know the gender. So those are the two primary things that sit within the demographics.

The other things that you can add to that is income. You can add location. Um, you can explore education, cultural and ethnic diversity, uh, the family environment and so on and so forth. These are the general demographics by which you know, customers and the classic thing that we often see when we kind of get into demographic segmentation is, um, quite a lot of variants between if it's a consumer brand.

Again. We tend to see quite a lot of variants based on age. Um, if I'm a consumer brand, invariably OTA customers have made a lot of, uh, brand decisions, uh, for marketeers. So they've, they've chosen their favorite brands and it's pretty hard to shift them there. They've also got pretty strongly built rituals, habits, routines.

So it's hard, really hard to get behavior change, whereas younger, uh, younger customers often, you know, A lot of brands spend a lot of time to capture customers in the early days, age demographic, because they know that might be able to build a customer for life. They also tend to, to be a little bit more open to switching and to jumping around and trying and experimenting with different things.

So this is the demographic bucket now. Um, I'm going to jump over to geographic. Yeah, because that's also a factor, the common way of segmenting, um, The obvious one is like, what city, what country? But zip code, what postal code are they in? And that that's, uh, the classics there. Now what's interesting is one of the emerging, uh, sort of filters in geographic customer definition, geographic user segmentation is defining, um, some more contextual geographic items.

The first one is do they live in an urban environment or a suburban or rural environment. So that can be a really interesting. Filter, particularly when we think about lifestyle products. When we think about products that are attached either to living in impoverishment in a more rural setting, I'm sorry, in a more urban setting or whether they have a larger freestanding house, single family home, that would be an example of where you start to get some insights around the geography and the type of urban environment.

Okay, so we've got these two. Now, what I'm going to do later is to show you how these all inter relate first let's continue mapping. We've got the first two demographic and geographic. These are great checklists to go through on how much we know our customer. And I think if you're a consumer brand, you you'll love it.

So, you know, the age and gender, but I challenge you like. How good. Do you understand your customers in terms of either cultural and ethnic diversity or education, um, or household income? Those might give you a richer story as to who your user is and what pains and gains they experience. Just to jump over on the other side, geographically.

Yes. You want to know city country, zip code and so forth. But let's go a little bit deeper next time. Let's see. Um, you know, do they live in urban or rural suburban environments? Um, try and get into those contexts. So they have it. So that's the first two, their third and fourth. This is where it gets really, really good.

And I'll tell you why. This is where you start to get in  from what products, um, they might like and what stories might be. The perfect proposition, uh, for them to purchase a new product and to start a new behavior, let's start with the behavioral segmentation. Behavioral segmentation is so great. It's um, I think it's a little bit new.

Well, in terms of understanding, uh, users, there's a lot of behavioral psychologists, behavioral, economic, uh, experts trying to really unravel this...

Hello, and welcome to the bottom up skills podcast I might pass. And I'm the CEO of quality tents, and we are on a journey of design thinking. And I hope you're enjoying the series thus far, because today we've got another goodie for you. We're going to be talking about how research. Can help you build empathy for understanding who your customer is.

And it will all be inspired by design thinking. And, uh, I'm just actually in the middle of conducting an enormous global research, uh, for a consumer product. And so I'm living this right now, so I'm hoping that I can share with you, um, all sorts of insights and tips and tricks on how to get the most out of this because.

Frankly research, you can just, you can just get lost in, in research data and then, you know, arguing about the insights and then arguing and tossing up between the recommendations. And it's a kind of, I can get very swampy when you do your research. So what I'm hoping to do is to give you sort of the fast track, if you will.

On how to really validate a phone generation product or service, um, and how you can really have what I hope is right. Confidence in your idea, because really that's what it's all about. We don't want to be guessing anymore. We want to know what our users need. We want problem solution fit. Okay. So we're talking research and there's primarily two types of research that I've very powerful in early stage ideas.

And in particular for brand new products and services, we can get into all the other variations and permutations of research that. Maybe more relevant for an existing product or service. Um, we can talk about NPS and all that sort of stuff, but we're focusing on creating something brand new and between you and me, that's kind of the exciting stuff.

So let's talk about these two types of research. One is quantitative and the other is. Qualitative. Now you might hear these referred to very often wanting qual, um, cause they're kind of like a mouthful. They self help things, but let me make it even simpler. You know, quantum research, um, is very much based on numbers and statistics and it's all, uh, largely conducted in the form of a survey.

Okay. Now qual research is much more about opinions. Um, the sample sizes, the number of people participating in the research is much smaller because if you think about it, you know, you can get hundreds of people to take a survey. That's fine. Particularly taking the, uh, the survey online, but if you're going to do really good work in your interviews, You only want to conduct five or 10 in a batch before you actually need to reflect on them.

So it's a much smaller number of people. And, um, it's all about the interview when you do a qual research program and, um, these interviews are really essential ways for you to gain a better understanding, a deeper understanding than what you had in the qual. In the Kwan. Sorry. So let's talk about, let's go back to and talk about that.

Um, I think that the output that you might expect from a quantitative survey is you really want some clear stats, so it's quite okay just to ask, uh, do you like this, or which of these do you prefer? Cause you weren't real stats and data, so yeah, you can do the key thing here is to compare and contrast now.

The reason that I like Kwan is, uh, it gives you sort of a baseline. It gives you a context. It gives a little bit of tangibility. I like the idea of just knowing we surveyed a ton of people and actually a majority of them have this really big problem. That would be an example of a piece of data. Um, that came out of a survey that would be really instructional because you'd be able to say, well, geez, Hey, it seems like a lot of people have this problem.

Um, and this is a confirmation that if we could solve that, that this has a clickability to a large amount of people. In fact, it's a majority of our sample size. So. That's really, really good. Now, when you, you get really fancy with your conservation, you can do a lot of filtering comparing, contrasting, and, um, Really, this is where you can do all sorts of interesting things, uh, where you can, for example, compare the entry points on your screen are people who answered your survey by age.

So you could compare younger versus more mature. Customers, you could do it on geography, those from East coast to West coast USA, um, perhaps you even have some other screen is, um, is really interesting, you know, really basic, uh, users or premium users. You can see all sorts of permutations, you can compare them and contrast them.

So that's, that's really the world of Kwan. And, uh, to wrap that up, If you're thinking about doing a survey, uh, I would encourage you just to go largely molded in your questions and maybe one or two open ones. They're always good, but don't do too many because you'll just be like working like crazy to try and process all those open questions.

What's interesting. Is we back to the call? So this is an interview. You know, the researcher sitting opposite the customer, just having a chat, asking the questions, obviously, please, please, please record the interview because you'll want to refer back to it and do some other things. But the output of this is some in depth research and analysis.

If you talk to 10 people and they all, haven't had a significant problem, trying to get a particular job or tasks done in this given area, then the big thing is why. And that's where you want to use your, your discussion guide, get some context, probe understand, and, you know, generally I wouldn't go into, um, uh, like a discussion guide with 20 questions.

Cause that feels pretty exhausting. So good measure. Once again, 10 to 12 would be good, uh, for our 30 to 60 minute interview now. So both of those are gonna give you, um, Great insights. Now, I really want to give you a bit of a gift. I want to explain how you can use them together. So once you to imagine that you did your first survey and you've got your baseline, you know, generally who the user is and what their pains and gains are in the first round of, uh, discussion, uh, and interviews that would come after that.

You really want to understand the motivations and be asking why a lot here, you want to know why is this, why is that a lot of people have this problem? Why is time such a big issue? Why is the cost such an issue and really dig in and get some context around not only some of the behaviors associated with the task, but motivations as well.

Now at this point, this is gonna sound a bit crazy. I want you to go back to doing some more quant. I want you to go and do another survey, but what I want you to do now is to start propose to propose those and validate not only the problem, but the solution to what if we did this? How might this work and really start to maybe use some stimulus?

Yeah. Posters, videos, sketches, whatever you want to do. You use that in your next round of Quentin. See what feedback you can get in order to distill from the user, what the problem solution model looks like. Lastly. Go back and sneaking a few more user interviews, a last round of qual here. And in that what you really want to do is understand what it would take for them to adopt this new product or service.

Now, if you do this four part approach, you will get enormous levels of validation. And this is really key to design thinking. This is why I love it so much. It has a test and learn ethos at the heart of it. So we don't do guessing we only do knowing. And so by doing Kwan qual Kwan qual in that order, what you distill is.

A very strong, uh, you know, signal through the noise, uh, validation of where you might go with your given product or service. So I really encourage you to run all of these together. One of my favorites. A quick tip here would be do a survey one week interviews, the next s...

hello and welcome to the bottom up skills podcast I might pass. And I am the chief executive officer at quality science, and we are well on our way into a series dedicated to design. Thinking, and in this episode, we're going to dig into where we can find inspiration and look as creative and wonderful as we all naturally are.

Sometimes we get a little stuck and, uh, what's so great about design thinking is that there's lots of really, uh, practical ways that we can generate some new insights, new ideas and inspiration, um, and they can lead us to uncovering some really. Powerful product insights, but more so than that, that might lead to a new product and your service.

Maybe, maybe it's just a feature, but Hey, adding yeah. A new feature to an existing product could lead to some great things and Hey, who knows, maybe these inspiration techniques might lead us to a whole new. Company. So where, uh, into the fourth of our 14 part series on design thinking. So make sure that if you're interested in anything we discussed today, jump over to bottom up.io, where you can pick up a free master class on design thinking.

You can download the slides. We go a lot deeper into some of these topics, but the aim today is really bite-size inspiration for you to get ideas that could really change products, services, and businesses, but more than anything can change the world of your customers and of your users. Okay. So I mentioned that I'd have eight tips for you, eight tips on how to get inspiration.

That would be very inline with a design thinking methodology. So let's get straight into them. Number one, you're a little stuck. You've got an existing business and you're like, Hmm, I'm not sure what we should do next. Well, here is my go to do a quick survey of your exams, assisting customers now. Um, there's very little barriers to entry trying to do that very few blockers.

Yeah. You could do it on your Facebook page. Um, you could post something onto your website or maybe you have a newsletter where you can invite people. To answer your survey. Now in this podcast series, we're going to do a lot, um, around how to do research and, and in particular, the quantity of part, which is what surveys are all connected to.

So I don't want to get too much into how to do a survey, but let me tell you some of my experiences. Um, number one, if you have one or two open questions to your existing customers, you can really. You can really get some interesting inspiration. You can get some interesting feedback that you might not have expected.

And secondly, one of the things that I find is really powerful about surveying your existing customers is that you can discover the, the picture you have of who your customer is. Um, might be a little different to reality, and this can create a really interesting opportunity for you to provide new services.

Based on this insight. So look, number one, if you're a bit stuck on inspiration for creating a new product service or business, reach out, survey your customers, make it 10, 12 questions, max, but get out there and talk to them and challenge yourself. Not to assume too much about them and see what answers you get back.

Okay. So that's number one for a little bit of inspiration sent out. A survey to your existing customers, if you want to take things next level. And I know for some of you, you may have done, uh, at home interviews, uh, with customers, um, or in office interviews. This is a lot more effort than a survey, but I think there's a lot more, uh, opportunity as well.

Uh, I think that the, the most powerful thing you can do is to go and see your customer. Uh, whether they're in a business or at a home to see them in context and whether it's a home or the office, or maybe they're at college or school to see them trying to get jobs done in there. Native environment, so to speak, it's, it's a really powerful, uh, uh, technique.

So you do a home visit, you have a discussion guide, but it also gives you the opportunity to understand the context and in particularly, uh, the greater context. So the world is bigger than just your product and service and seeing customers at home or in the office can be really powerful. These first two are slam dunk real straight on target design thinking approaches.

And later on, we'll talk about how to filter ideas out of those. Um, so that's the first two. Third one is a really, really. A curious minded person, we'll go out and we'll read an industry report or a customer trends report. You might get that from your industry, buddy, that you're in, or you might go to something like e-marketer or any of the trend watching, uh, services out there.

If you just put TrendWatching into Google, you'll get a ton now. That's perhaps not the most, uh, powerful advice I can give here. I would encourage you. If you read one of these reports or websites is ask yourself this simple question. Is this trend an opportunity? Or a threat. Now this trend may be directly related to your business, or maybe it's indirect, maybe you're in the fashion business and you see something happening in the sports business.

Maybe you could ask yourself, well, what's the opportunity in the sports business that I can leverage into fashion, a really good exercise to do so opportunity first threat key question to ask yourself when looking at a trend and it can be outside of your given practice area or industry. Um, another, uh, one number for, uh, a bit of inspiration can be conducting a review of your competition.

And, uh, for this one, I would focus on pricing and value creation. So you could do an analysis of pricing in your industry between yourself and others, and, um, ask yourself who's creating the most. Value really interesting exercise might lead to a few debates in the boardroom, but it's a very, very good exercise for inspiration because maybe you see that your competition have actually found new, different, or better value than how you think about it.

And that might lead to some inspiration. So that's the first four were halfway through. So just a quick recap survey, your existing customers. Number one. Number two, do an at home in depth, home into interview. Super powerful. Number three, ask yourself where's the opportunity or threat in a new trend or industry report, and then do a pricing and value comparison amongst yourself in your competition.

I mean, that could keep you very busy. I would already bet that you will find some. Some wonderful insight in those first four, but let's keep going. Cause I've got another four for you and I hope they are as equally powerful for you. Another place to get inspiration is your customer themselves. So you can invite users to cocreate with you.

And there's no better example of that than Lego. Lego has been inviting customers to create designs with their Lego pieces for years. And this was really central to the turnaround of their business because people got involved reengaged with Allego, maybe a little bit of Stavo sponsorship helped as well, but this cocreation piece has been huge in the Renaissance of Lego.

Okay. So cocreation with your customers. That's number five, number six. Uh, this one is it's roll up the sleeves and getting into some icky stuff. Review customer feedback and complaints. Now, particularly if you're at a larger organization, there'll be a log of all of the customer feedback or even complaints.

It's natural. Can can't please, everybody. What would be really interesting to do with your customer feedback is to cluster it in themes. So let's see, uh, what are some compare, contrast and trend analysis looks like, and maybe we see as an unmet need for customers and Venezuela, new service, new feature in your offering.

Okay. Number seven. Now we're going to get a little quotes, uh, right here and we're going to dive into...