Hey and welcome back.
So the last part of this canvas, and this is something that's happening throughout the entire canvas,
is mapping your assumptions.
Now, risky assumptions are one of the primary sources of wasted effort or building applications in
general.
The team has the opportunity to really help each other and reduce that risk and uncertainty involved
in the success of the project by calling out all this information during this canvas that we're kind
of hosting.
Now, the recommendation is to put an asterisk next to any information gathered where the confidence
isn't really high and it's and if proven wrong, could lead to the project goals not being met.
So there are many common assumptions that if they're proven wrong, they can really affect the success
of the project.
And here are some examples if we put too much effort into minor things.
Our assumption is that a more personalized shopping experience is going to be better for users.
So that definitely is an assumption.
And we're going to put this in the middle.
Like we do know that personalized shopping experiences are generally better.
But if we don't get it right, this is very high risk for us.
Let's think of another example, building features of little value to end users.
So let's think about some features within our interests.
A. Generally, when people are searching for products, they really just want to find their product
and they want to be served up products.
And, you know, maybe this interest picker is a little bit too much for a minimum viable product.
So we're a little uncertain if we need this, but the risk is a little bit lower.
You know, we may spend a little bit time building this, but it may be risky.
Let's think about another assumption focusing on the wrong part of the user journey first, so let's
think about our user journey.
We're going to go back up here.
This is something that we quickly built out.
If a user wants to get relevant results and that's our goal over here, maybe something that we should
figure out first is how we're going to serve up those results.
Maybe the onboarding experience is really in depth and so like.
People are maybe really want to focus on deals.
We do know people like deals, but if we focus on this now, it's going to give us less time to actually
finish the project.
So maybe this is in the middle as well.
Another one, the same, another one.
We are assuming that all users want to be on mobile, since this is the mobile app.
Now, this is a high risk and we're definitely uncertain of this.
We don't know the type of user.
We don't know if they're primarily mobile users.
These are the types of things we're going to actually be putting in this kind of like parking lot throughout
the entire canvas.
We're marking all these things with an asterisks as they're on the whiteboard or within Sigma.
We're making copies of this and throwing this on our large assumption grade, probably larger than this.
And these are the types of things at the end that we're going to do our best to validate.
We really want at the end of the canvas to understand what the project goals are.
We want to understand our target users are less.
These are end users and these are our stakeholders.
We want to understand their goals and concerns.
We want to understand the user journey, the main user journeys that we are going to be focused on for
this project.
But another thing that we need to do is we need to understand the assumptions that we're making along
the way.
And our first goal after this and canvas is to validate all these different things.
So one very large assumption that we all make is that we know this.
We know what the end user wants to do.
We may know, but this holds a lot of risk and we need to figure this out early, this is why you do
I'm not the moment to read.
Sometimes I'll just list them and then we can prioritize them as a team.
That's probably quicker in the moment.
So remember to map this out throughout the entire process.
And that's basically the end of the first part of a product alignment cannas.