The first step in understanding, how to solve our business problems, is to
declare our assumptions and to build hypotheses based
on those assumptions. And the reason we write hypotheses
is that we are essentially stating what we know,
stating what we assume and how will determine success right.
Again, moving from doubt to certainty. And a video that I
want to share with you that embodies this is Richard, Fineman
from
1864 talking about how science comes up
with a new law because essentially, this is applying the same thing as scientific
method to solving business problems. So this is Richard. Fineman
in 1964, explaining to a room of young
people. How science comes up with a
new law.
How we would look for a new law. In general. We look for new
law by the following process. First we death it.
Then we can don't laugh. That's the only truth. Then we compute the consequences
of the guests.
To see what if this is right, if this law, that we guess is, right, we see what it would
imply. And then we compare those computation results
through nature always say compared to experiment or experience.
Compare it directly with observation to see if it works.
If it disagrees with experiment.
It's wrong.
In that simple statement is the key to science. It doesn't make a difference. How
beautiful your guest is it doesn't make you believe how smart you are, who made the get or
what his name is. If it disagrees with experiment
wrong, that's all there is to it.
So that's dr. Fineman talking about how
science comes up with a new law and essentially, this translates directly
into how we solve business problems.
We take a guess we declare our
assumptions.
It could be a very well educated guess but it is a gues, nonetheless, until we
get direct feedback from the market that says this was
right or this was wrong or it was somewhere in between we don't know if it was the right
thing to build and so the experiments that we run
help us determine the validity of our assumptions and our hypotheses.
And if our results disagree with our guests, then our guess was
wrong. And so it's an objective way to have
conversations with your peers, your colleagues and your managers to say,
that's an interesting idea, let's test it and then, let's figure out
whether it's right or wrong. Now, Fineman says a lot of interesting things he says it doesn't
matter how smart you are, absolutely, right? You can make a guess and you could still be wrong.
It doesn't matter how beautiful your guesses.
So you could design the most beautiful solution to something,
but it could absolutely not work. Now he also says it
doesn't matter who made the guess now in science, that's true
in corporate reality. That may not be so true. Sometimes it
does matter who made the guess and you need to have
a deeper conversation about it. But at least
with this framework, you have an objective
conversation and objective success.
That you can say, okay, you've made this, guess you've made this this
request, we've run some experiments and we don't believe that it will
work as well as you think it will. And then at least you can have an objective conversation about that
around ideas whether it's a good idea or a bad idea, but it does actually matter who made
the guest in our reality. And so the way we structure our hypotheses is that we
declare our assumptions. And so we sit down together as a team as a
cross-functional team and we ask ourselves what assumptions. Do we
have about?
Our customers and their pain points, and our
solutions that have proven false will
cause us to fail.
In other words, what do we need to know to move forward to take those
incremental steps from doubt to certainty. For example, if you're building
a solution that's going to live on a tablet,
will people be able to use a
tablet in the situation that your service Works in?
That's a fundamental assumption that you need to make. For example, if
you'd like to use a tablet in an early childhood education context,
is there an opportunity for a teacher or a student to engage with a tablet
during class if they're five years old? That's a fundamental assumption
that, we need to ask ourselves because if not, we're going to fail right out of the gate building a
tablet solution.
Now what's interesting is that when you start to apply lean to business, you start to
focus on the design of business in the design of your assumptions.
And when you dig deeper, you realize that every decision that you make about your product offering
about your service is a design decision is a customer
experience, design decision,
It's not just what the button says, or where, to put the button or how many form
fields we have, it's does the service cost money. Where is the pay
wall? How do people tell their friends about it? How do we get people to the
service? What if they have a problem with the service? One of the examples of like
to use very often is the New York Times iPhone app,
the New York Times iPhone app has terrific design, terrific
typography. And if you like the content that the New York Times publishes,
It has great content.
And yet, if you look up the New York Times app in the, in the app
store on a regular basis, it has a 1 or a 2 star rating,
Max usually hovers around one.
And the reason the number one complaint. If you read through the comments, people give it one star.
It costs money.
That's a design decision. And so if you start to
build that mentality into the into the decision-making process of deciding what you're going to build,
and how you're going to build it, then every design decision becomes a
hypothesis, it's a guess, it's an educated guess,
but it's still a guess. And so what we have to do as a team collectively, as declare our
assumptions and then test them and when we get those results,
we have to evaluate those results ruthlessly we
To be brutally honest, with ourselves and be prepared to change
course.
Because if it's wrong, we don't want to work on it. That's waste, we want to reduce our
inventory, our inventory in in software product development
is a backlog of untested ideas, and we need to reduce that inventory. And by doing,
so we would be reduce risk and we reduce waste now. Look, I'm a
designer by trade, and it doesn't matter.
We're hopelessly optimistic people designers, and it doesn't matter if we
spent five minutes or five months and idea, when we make a
design decision,
And we know it's going to be huge, it's going to be fantastic.
And so we work on it and then we launched it. Ah crap. Nobody clicked,
nobody liked it. Nobody used it. It didn't work.
Right? And so our job in this, in this collaborative, cross functional role is to
reduce the time between these two points from months to
ours, how can we learn a? No one's going to click this thing as fast as
we can.
And that's this new way of thinking, what if the old way of thinking is that
you're working overtime, and you're building up all this risk. And so you build and you build,
and you build, and then you launch over here and you've got all this risk built up
time, investment money, you know, effort,
Etc, commitments, marketing, budgets and so forth and then you launch it, if it doesn't
work, that's a huge risk. In a huge. Gamble is extremely expensive
instead, you bite off these small chunks of risk and you test them.
And you learn whether it works or it doesn't and you, adjust course, as you move forward, just like
you saw in the Nordstrom video paper prototypes, and then slightly,
higher, Fidelity, prototypes, and then maybe an app that does one thing
and maybe not that those two things and so forth. And as you move forward,
you're iterating towards a more accurate Direction. Essentially, that, the old
cliche plays nicely into this, you're going to nail it first, and then you're going
to scale it and you do that by prioritizing
learning overgrowth. The
thing that you do is you prioritize learning, what do we need to know to
move forward?
And once we've learned enough, once we have a clear sense that yes this
problem exists and yes the solution will work for people and they will actually
integrated into their life. That's when we focus on growth
and scaling.
And we get to learning by prioritizing making over analysis.
So we generate a lot of ideas and then we converge quickly and we just pick a direction.
Even if we don't have enough data to pick that direction, we pick something because
that Insight will come. If you've ever found yourself in a
meeting talking with your colleagues, about how to solve a problem, how
to design a solution, how to write a specific bit of code,
how to fix something for the customer. And you're going around in circles. And you can't come to
consensus or any kind of conclusion in that meeting the reality.
Is that you don't have enough information to make that decision in that meeting?
And that information is not going to magically appear, if you
continue to speak to each other, in that meeting. And so, at some point you just
need to make a decision, pick a direction, and make something and
start learning from that.
Because that helps you frame your business as a set of hypotheses. Okay, we don't know but
we think this might be the way and then you start to test things in
reality. And when you start to embrace this way of thinking, it allows your
teams to move faster.
So let's talk about what some typical product assumptions are. These are some
typical products assumptions. Who is the user.
The next time you sit down with your product teams. Ask this question, you'll
be amazed at the variety of answers, you'll get from your colleagues who the
customer is who's the user, where does our product fit into their work or
life? What problems are we actually solving for them?
When and how is our product used, what features do we think are
important?
Should we have an invitation feature? Should we not how should our product
look and behave? And if you're a designer these should be very familiar
questions for you to ask. But we should ask these questions of our entire team
so that we start to build that shared understanding and that alignment
and then move on to business assumptions because none of us
operates in a vacuum we're not designing something in a vacuum where not engineering
something in a vacuum, we're building a product to be used and to
further our goal as an
Relation or business, how are we going to acquire customers?
How will people find this new feature that we're building or this new product? How
will this make us money?
Who are our competitors and what makes us better than them. What's our
biggest risk?
And then how do we expect to solve for that big risk?
Sit down with your teams and literally asked everyone to write down the answers to these questions.
You'll be amazed and what comes up and when you've gathered
these assumptions from people, you can start to write your
hypotheses. You can start to put them together now with the highest level, a
hypothesis looks like this, you declare something that you believe
to be true and you declare some kind of success criteria.
So, we believe that this customer exists that this customer has this pain
point and that building a specific thing for that, customer will change
their behavior somehow to their benefit and two hours as a
business and will know this is true.
when we see certain outcomes or certain measures,
Change in the real world and so to break the statement down a little
further. This is the hypothesis statement that we write when we're
building software products.
We Believe now, believe is the key word Here. We believe We don't know. We
believe that doing this. Now, the doing this is building this
feature, the service, this widget, this API designing. This
thing, whatever it is, we believe that doing this for
these people. Let's get explicit about which members of our target
audience or actually building this product for or this feature for
maybe it's not for everyone, maybe it's just for a certain segment of our audience.
So we believe that building this doing this for these people will achieve
this outcome outcome is the change that we want to see
after we build that feature. How will this
change the behavior of the target audience that we're going after?
And we'll know this is true when we see some kind of Market feedback.
What can we measure that? Says that this change in behavior is actually happening, people
are buying more, they're telling their friends. They are coming back more than
once. What can we measure?
That says, that there is an actual change in behavior, and these are the hypothesis statements
that will need to write.