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 business policy.
They're really the guidelines of the business. Either born of a. Yeah, decades long operating in a
space, or maybe it's a brand new vision, a purpose that the [
00:09:00] company has now, where
we get to is the third level of getting the logic right inside your product. And that's the business
rules. Now the business rules are very different to policies.
Business rules are actionable. Uh, there, yes, no. On, off, uh, compliant, noncompliant. These
are hard and fast rules that need to get baked in your product. For example, if you say that we
only talk to customers who have a minimum two year credit history, then this becomes a very
clear rule that goes into your product.
And when the user uploads their credit history or answers a survey and says that they only have
one year, your business rule says. I'm sorry at products or services not available for you. So
these are really important. These are three definitions, law policy and rules. Make sure you
know those. And as a [
00:10:00] design thinking, you might be thinking, geez, Mike, that sounds
a bit intense.
You should be familiar enough with them. And if your project of building a brand new product is
big enough, you actually have. A full time business analyst who actually map a lot of this, but
that's not always in every project. So it's important that you understand what you're dealing with
it because they will affect your product.
Now I want to talk about how we can make this, all this, uh, legal, legal, mumbo, jumbo, and
policies and guidelines, a little bit more relatable. I would definitely map the user journey, um, to
the different business. Logic filters criteria. And one really interesting exercise can be, is to
actually bring it together.
The user's preferred journey, and then map that to your business flows, um, where you have
business rules, business policies, maybe legal constraints, [
00:11:00] and you. Bring them
together. You compare it and you can trust these two flows and this becomes. An amazing
opportunity for a design thinker to compare contrast, and to refine around the common ground
around the solution space.
Now, this is the art of a great product. So it's really important that you have the capacity to talk
apples and apples. What does the business require and what does the user need? And I can tell
you if you're able to bring these two together. And create a harmony and a common ground
between the two of them.
You will be in a very special place because to be quite Frank, a lot of products that we interact
with are dominated by business rules. They're dominated by business requirements and they
neglect. The user needs. Sorry. If you can map these, bring them together and find the common
ground test and learn and make sure the customers are satisfied [
00:12:00] with this product
experience.
Then you've gone a long way because it's a fine balancing act. What we need to be able to do is
to serve not only those user needs and business requirements, but we have to do so within
technical constraints as well. And that's a whole nother thing. Uh, working out the technical
constraints, we have architectural questions, uh, all sorts of scalability issues.
Um, Common language, data, interfacing, data modeling, all sorts of stuff. We won't go there for
now. Really a great UX designer or strategist will sit between these, because if you can actually
find the meeting point. Between all of this business logic and the human needs and make sure
you can bring it to life in the best emerging technology possible.
I think you've really arrived at that special place where tannics things happen, where things are
so much better than what's on offer today. And I think as a design thing that you [
00:13:00]
really need to know your tech, but as we've talked about today, you also, in addition to that, to
know what users need. Is you need to understand the business and creating mapping business
logic is essential to that.
Well, I hope you've enjoyed this episode of the bottom up skills podcast. We've really gone into
a quick fire round on business logic and how you can do it. Don't forget the big three legal
policies and rules. They're the real engine of understanding what the business needs, bring
them all together. And if you'd like to know more about how to bring great products to market,
whether you're a designer, creator, entrepreneur, just head over to baltimore.io where you'll find.
The design thinking master class, and you can get a whole bunch of other free goodies there as
well. So thanks for being part of the journey of the bottom up skills podcast. That's a wrap.