We're gonna talk a little bit about framing today.
Framing is super important in Anovo
because framing is really one of our most powerful
sales tool.
We sell weeks at Anovo.
And so it is our unit of measure for all projects
for cost for the price of a project.
And so if we can get the framing right
and kind of decide, hey, the appetite is two weeks,
you know, this is what we're planning to do.
Here's the problem we're solving.
Here's the outcome.
Here's what we're not doing.
And kind of clarify that and put an appetite on it.
It's essentially a sellable unit at that point.
And so everybody is gonna be part of the shaping process,
whether you're a developer, designer,
you're helping manage a project.
Everybody's gonna be part of that
because this is sort of our mutual agreement
of how the project's gonna go.
In previous times, we went and in other,
you know, agencies typically, you know,
a project manager sits with a client
and they get a laundry list of like all the requirements.
We write it up in this massive document.
And then we try to work with the developer internally
and figure out, okay, how many people are we going to,
I mean, how much time is this gonna take?
And we try to guess at random estimates.
And then we say, okay, this is 182 hours, we think,
based on all these random guesses.
And then we try to bring that in a huge contract
back to the client.
And we sign off on this thing.
It takes a week or two to go back and forth.
And finally we lock in, okay, cool.
They're gonna give us all this money, you know,
50% upfront, whether it's like 30%, then 30%,
then whatever, 40% of the budget.
We don't do any of that.
We create like a unit of sales.
So we say, hey, there's a two week thing.
It's gonna cost X.
And then to make everybody agree to that,
like we have the client pay the whole 100% upfront.
So they pay for it right up front.
They buy those two weeks from us.
And then we essentially buy those two weeks from you guys,
whoever's doing the work.
So it creates like a nice unit of measure
as far as how we're going to all speak the same language,
because there's different dollar amounts and all that.
But if we talk about weeks,
the clients know how much that week is.
You guys know which week.
And we all kind of know what's possible in a week.
And so that's really around like sort of the appetite
and why the appetite's important.
The framing process is really important.
We've been learning from Ryan.
There's other training on that.
I'm gonna try to summarize it a little bit here.
But the framing is important because it's,
to me, this is the thing we do before we sell the project.
We frame something up, we sell it.
And then when we get into it,
that's when we start to do the shaping and breadboarding
and we get mockups and prototypes.
So that's kind of really
on that uphill part of the project.
But framing is what happens before we sell it.
And we don't necessarily do any work.
There's some work, but to me,
it's like potentially an hour or two.
It's one meeting with a client,
maybe framing it up into a document,
sending it to the client to confirm if this is correct.
Enough for them to say yes
and them to agree to do the project.
So things that are not part of framing,
like necessarily building out a task grid,
breadboarding, mockups.
You can do those things
if you think it's gonna help make it more concrete.
But really this framing piece is really
like the part before we do the work.
It's just kind of saying,
hey, I think there's a problem here.
Here's kind of what the appetite,
here's what we think it's gonna cost.
Do you want us to go work on it?
Because the shaping is really where it's going
to get really much more clear.
And as you guys know, the shaping takes a lot of work.
Like it is multiple hours sessions,
either with the clients or with us internally.
It's typically doing it in pairs.
And there's a lot of work that goes into that piece of it.
And so that's kind of how we would kind of distinguish
between framing and shaping.
And we didn't do framing until recently.
And to me, this is sort of the magic piece
because once we figured out how much work
shaping actually is with the breadboarding
and do the sketches and building out a task grid,
figured out how much work all that is,
we can't do all of that work.
Because that really is a good,
it's a 25% to third of the entire project
is doing the shaping and the breadboarding.
You get really deep into it.
And so we're gonna keep that as sort of inside the project
post payment, right?
So let me jump in.
I'm gonna share a couple of slides here.
We'll see how this works here.
Can I, let's make this a little bigger.
Sorry.
All right.
Why?
Nope.
Standby.
We'll edit all this out.
I was getting fancy with the settings earlier.
Oh, yeah, I'll just do that.
Perfect.
Okay.
So this, I love this quote.
It's like, Ryan said this in one of our talks,
that framing is not about deciding the solution.
It's very specific about that.
We're just defining the situation
and then we can decide what solution to look,
decide what kind of solution we should be looking for.
So we're figuring out things like,
what's actually happening?
Where's the friction or the frustration?
Like, why is this worth solving?
And I actually have a list here at the bottom.
I'll share this in the notes and stuff, but.
here's some really good questions we'll get into
that we can be asking.
And so this is very, it's just being curious.
If you can summarize it down to being,
it's not skeptical, it's being curious with the problem
and saying, okay, why is this an issue?
Okay, great, why now?
Why, okay, you've had this frustration,
you're using a spreadsheet for this particular task,
what's wrong with the spreadsheet?
Like why, oh, well,
because sometimes the data's inaccurate.
Okay, so there's some, you know,
actually, okay, why does that data get inaccurate?
Oh, because people are manually entering it.
Okay, you know, you can keep,
it's basically just asking, being really curious
and asking deeper, deeper questions
to get to the why behind this.
Obviously, like a bad result of this would be like,
you know, the framing is not like,
we don't have a mobile app, we need a mobile app.
No, you know, we need a, the frame,
the problem with that would be,
hey, we have, you know, people in the field
and the website isn't reliable,
we need an app that integrates with a camera
and a thing and a barcode scanner.
It's like, you know, to kind of explain the problem,
we don't really go to like the solution of what it is.
That would be something we do in the breadboarding
is to figure that piece out.
I mentioned this as well,
why it's important we build by the week.
And so that's what we wanna figure out,
how much time is the client,
how much does the client want to spend
and how much time do you think it's gonna take?
So those two kind of pieces that we need to keep,
you know, in sync as a team between the client
and that's where we don't want to have this kind of
extra layer of sort of like the old school,
like management layer,
where we're the ones talking to the client
and then we'll come back and we'll talk to the person
doing the work.
No, you're the builder, we put everybody in the room
and we like figure out what it is.
And so, you know, if we get the framing wrong, obviously,
and we need to,
the framing is gonna be too vague for some clients, right?
Because clients want to kind of like see the thing,
they wanna see the mockups,
they wanna see, you know,
the beautiful kind of end product
of what it's gonna look like
and they'll kind of buy into it.
But we have to keep it back to the framing
and what is the framing we agree to?
That's the only thing we have, you know,
sort of contractually like agreed to
is the framing piece of it.
The breadboarding, the shaping and the actual work itself
is very flexible within,
as long as we stick to kind of the frame.
So getting it wrong, obviously,
we can create scope problems later.
And so that's not the optional way,
it's basically how we kick off the whole process.
So this is actually not correct,
but if we would start with a project,
hey, inbox clients on a meeting,
they say, hey, great, I have this idea,
I want to do this.
Okay, that's immediately kind of a cue
to start making a quick little framing doc for this.
And what I do is if we're in a brand new fig jam,
what I've been doing is something Ryan showed us as well,
just come up with three little sections.
It's the problem and it's the outcome.
And then we also just list down here,
what is it not going to be?
And those are kind of our three little buckets.
And so when we start,
I typically do this in real time on the call with the client
because all of a sudden it gives us all something visual
to look at because we have clients
where there's two or three people on the call
and someone says, you know what I've been thinking
and like, this has really been a problem over here.
I immediately pull up fig jam
and also just a completely blank, empty, white fig jam.
Unless you guys are already in the meeting
and you're already looking at some stuff in fig jam,
just pull it off to the side.
But sometimes just like a clean blank slate
is very refreshing for everybody's brains.
So you can pull in here
and you can start asking those questions.
Okay, like, why is this a problem right now?
Oh, well, maybe like we just hired 20 new salespeople.
Okay, well, that's interesting.
So that's more of a note of sort of the background
and the context of this.
Why is that really a problem?
Oh, well, we have new employees
like who find the current system hard to use.
Okay, so they may say that, we may note that.
It's not really a problem.
It's kind of a interesting note,
because again, what's hard to use?
Oh, well, the buttons are too small.
Oh, well, this, we keep dragging down to like,
what's really the thing?
Oh, well, actually, it's when they hit this button,
it doesn't actually do the thing they want it to do.
Okay, so there's like missing piece in the process.
We kind of keep asking really good questions.
This can be done in a few minutes.
This is not hard.
So what we need over here is like an easy to use system
for new employees to quickly get X report
out of the system or whatever the tool is.
You guys get the idea.
And then what it's not is like,
well, we're not changing this.
We're not changing that.
We're not, whatever, adding all these things.
This is helpful to kind of use like kind of a carving knife
to like cut out the things that are not going to be a part
of this project.
And so this is the little tool I would use,
like kind of when we have that,
I like to capture it right in the call with the client live,
or if it's something, you know,
just so we initially kind of get to see,
okay, there's generally a thing here that looks like that.
Is that something you guys would like us to go frame up?
Then that could be something we do after the call,
or we sync up, you know, with, you know,
one or two of us on the team and try to figure out,
okay, is this a one week appetite, two week?
And I would actually, you know,
I've been putting like the title, this is, you know,
fix, you know, broken, you know, onboarding, you know,
process for X or whatever.
And I would just put in here, you know,
what do you guys think?
Like, is that, is it like a two week problem?
Cause you, and as you guys do this,
you'll kind of be looking at it
and kind of have some ideas of what the solution might be.
But this would be a good time to say like,
is this a one week, you know, two, three, four,
just having it on there and being a little bit,
like showing that to the clients
that kind of know what we're talking about.
That sometimes helps change the whole frame
as we've learned with Ryan is like
shifting the appetite down to one week,
all of a sudden, like, you know,
it kind of gives the people who are building it, right.
And the people who want the thing built,
much more clarity.
So there's people paying for the thing
and there's people building the thing.
We get a lot more clarity.
If you only have a week, I have to do something simple.
I'm going to change the side of the buttons
and add a couple of things here.
You got me, give me four weeks.
Like, yeah, we're adding all kinds of new stuff,
you know, to it.
And then we can solve a much bigger problem for four weeks
or solve it very differently.
So it's helpful to have that upfront, even if it's wrong,
you know, just put like,
even like, hey, I think it's one or two weeks.
Yeah, that sounds about right.
Cool.
This would be a good starting point
to go like kind of capture everything
on the call live with the client.
And then this could be something we turn
into something more of a presentation.
So we'll get into that in a minute.
So we frame it first to talk about sketching it.
Yeah.
Tate off all that.
We just went through that.
And so we don't want to like mix the shaping
into the framing doc, keeping it very, very simple.
I know we've been experimenting
with different templates and stuff.
I'll show you some that I think are working well here
and just really taking basically this same idea,
maybe throwing the appetite as another section.
And then this really, those four sections just in that.
And that's what, when I say like a framing doc,
that's what we would call like our Notion project docs.
So when you go into Notion, you look up a project,
that first page that shows up.
If you want to have additional stuff,
that's where you can create sub pages
and organize it however you want.
But that's typically what we would share with the clients
because it's got the appetite there.
It gives people sort of that high level overview
of what this thing is.
And you can kind of add tasks and sub pages
and things to it from there as well.
So I'm keep going down here.
I said some red flags, right?
Red flags.
We need a mobile app.
Why is that bad?
Well, that's a solution.
It's not even, it's barely even
in the shaping piece of it, right?
It's more just some solution.
And the problem is that you'll find this,
the more clients you work with,
the more you'll find that the clients
love talking solutions, right?
It's actually much easier to talk solutions
because it's tangible.
It's like, oh, well, this competitor has a mobile app.
I want a mobile app.
Or they have this feature.
I want this feature.
They just talk about, let's just go straight to this.
Or I saw this in another app
and I want it to be like Facebook
and I want it to do X.
So kind of backing out of that
and being sort of a good red flag is like,
that's a solution, cool.
Let's try to get to why they think the mobile app.
So questioning, again, be curious about why the mobile app.
Could it be a mobile website, for example?
Could we just make the current app, web app responsive?
Like there's a lot of ways to get there.
Also, you immediately hear someone,
if you're building it, you guys hear,
oh, we need a mobile app.
Alarms of like multiple six-week projects
just went off in our brain
or one very small six-week project.
So you can say, hey, yeah, we can talk mobile apps.
However, like you're talking multiple weeks,
six weeks, maybe two six-week cycles,
whatever to get a mobile app.
So what I wanna do is try and save you
as much money and time as well.
They may not wanna wait two or three months
to solve this problem.
They just thought mobile app might be the solution, right?
So we're kind of like helping them like, cool, yeah.
I don't know if you need a mobile app,
but what if we got a two-week responsive version
of the web app?
Oh, okay, yeah, that's actually all we need
because we're kind of getting back to the question of it,
of why are we doing this and kind of back to that problem.
So, and like general stuff, right?
The user said this important
or these three people came into a support desk
and complained about this problem.
That's like not a problem of that.
We wouldn't put that in the problem bucket of like,
oh, there's been some support requests.
Noted, like you have people,
some of your users thought this was a problem.
You kind of have to get deeper into it.
So, and then like getting.
into wireframes, I say this, we did this literally yesterday with a client.
And sometimes wireframes are helpful or, or V zero mockups.
It can be helpful just to help have the client get their thoughts out on
paper of what they're looking for.
But you shouldn't be doing wireframing in the steps.
Worst case you're, you're over here and you're like, cool.
So if we had like a thing with like a list, like, would this be cool like that?
But this is really getting into shaping or just something simple like that.
And Hey, when you click this, like this changes.
Okay, cool.
Great.
Again, to me, that's noted, delete it.
Like that was just, it was just for a quick illustration, just
to, just to help communicate something.
It's not like this now goes into the official, you know, notion documents.
And then when it comes back, it's like, well, why is the list on the
left and not on the right, or why is it a dropdown versus menu?
You just want to give yourselves like a lot of flexibility.
Later in the shaping process.
We don't know if, if that list is necessarily the right
solution at the framing stage.
We're going to know it once we get deep into breadboarding and shaping
and getting really close to the problem.
So this is, I think from shape ups is we don't ask how long will this take?
We ask like, how much time are we willing to spend?
That's from the book.
It's kind of reframing this thing of like, not, Oh, I, it's going to
take two weeks or it's going to take four.
You kind of start with like, how big a problem is this?
Cause that kind of helps dial the level of intensity on this
problem piece right here is like, is this a two week problem?
Is this a, you know, look, Oh, if we solve this new feature, like I'd put
six weeks, I'd bet six weeks worth of money and time on that is because
it's just like, so critical to our users that we get this right.
Or most of the cases, it's like, it's one, two, three, four weeks,
something in there, some variation.
So again, you guys know this appetite shapes, the solution, it can
help give you guys like the frame of like what to put, put in there.
And it brings it back to a business decision, not technical because once
you go to giant project requirement docs and all that stuff, it gets so
technical, so fast now there's nothing for the clients to like adjust.
They, they kind of feel out of control with it.
And they don't, it just feels like we could just be making stuff up or
we're having a very tightly technical conversation about scope because we
want to use this one tech stack and we get used, it gets super, I mean, some
of these project requirements, and I know this because like we did some of
these in, you know, early on in our, in our agency and you guys have probably
seen some of these that could be 10, 20 pages worth of notes and details.
And the problem is you have to actually like make sure all
that stuff actually happens.
So it's, it's quite a, a nightmare mentioned the framing for communication,
just helping them get clarity, right?
Like that's the main thing that shaping and framing and all this
stuff is, is just bringing clarity.
When we're doing client communication, it's like, Hey, they had this idea.
We're now like getting really clear about it because most of the founders
and clients we're working with, they are visionaries and they're going to have
ideas in their drive, in the shower, wherever, and they're going to go from
like, Hey, I had this idea to, can you guys go build it?
And the framing piece is just like, cool.
Let's like really think about and talk about this idea.
Like, why, why do you get what you had this idea?
Clearly there's a problem behind the idea of why you thought
this would be worth bringing up.
Cause like, cause then again, they probably had an idea for a solution.
Like, oh, cool.
We're going to build a mobile app.
That's the coolest thing in it.
And visionaries and founders typically like the kind of like, there's this
all and wonder of their most amazing idea.
Right.
I just start with everything.
Like, it's probably a terrible idea.
Right.
Just assume it's the worst idea and just move, kind of reset it.
You don't want to say that, but just like, you kind of want to have this skeptical
view of like, okay, that's one idea.
Like that's one way to go about it.
But kind of get back to like, what's the real thing of why this is important?
Cause they kind of went straight to solution.
So there's a bunch of question mark, unknown, you know, problems that are
sitting behind the scenes that they haven't explained to you.
So that's once we can kind of get the problem, why is this important?
Oh, well, and then, and if you keep going, why, like you can keep asking
why over and over again, like, but why?
Like, but why?
Like keep, keep going deeper, deeper, deeper.
And it's going to get something very tangible.
Like, well, this is like causing us to lose revenue over here because we don't
know this number in this report very well.
And if we knew that number, it would help our business.
Cause now we can get more profitable, which means we're going to be around
longer, which means we can pay our team better, you know, et cetera.
So you really get down to like the, almost the more of the heart, like
emotion of it, which is kind of funny to think of in technical terms.
But there's for these vision, for the, these founders specifically, there's
something like very deep in there.
That's motivating them typically.
So don't, I didn't mean to sound like we're dismissing this like kind of idea
because there's something they just haven't thought about it.
There's almost like a therapist going layers and layers deep in this, like
kind of asking them, like, why is that important?
Like, how does that affect the business?
Those questions we will have at the end.
I'll I'll put those there.
Okay.
tools, FigJam, obviously we, we love to, that we kind of standardize on FigJam.
It's easier, everybody should have an account and we can
share things much more easily.
The shape up GPT, this training, all of Ryan's training, all of like shape,
the entire book of shape up a lot of Ryan's blog posts, all preloaded
into this shape up GPT, so you could actually take us a piece like this.
And let me bring this back here real quick.
There we go.
Let's pull it up real quick.
So you guys can see this.
Cool.
And let's do that.
Cool.
So you could, this is a very bad example.
I may take one that we did.
Let me, let me do a slightly different one.
I'm trying to do this a little bit live with you guys.
So we did this one for Kings loop yesterday.
So let's just go in here.
I'm just going to this.
So there's this project and they had this, and I'm just going to
screenshot this and say, help me.
Uh, create a framing doc for this.
And I would just also say like who the client is.
Cause we do load in like all that.
So it will sit there and it'll build out those different process.
Obviously I've given it very little context.
So the more we can, we can create here, I give it more.
So it's actually, it's pulling a bunch of random stuff.
Like it's perfect.
It just hallucinated on this first demo, but okay.
Okay.
Now it's kind of, it kind of is generally sticking.
It's, it's combining a few different projects here.
I'm wondering why it did that.
Okay.
It's using some other old data for that, but you, you, you more context to give it.
What I would typically do is build it out in notion, write it long form and
then bring that plus the, maybe the, the, the big jam piece into it.
And just get it clarified.
I could even just tell it like, Hey, you know, don't, don't bring in other
projects, but it's part of the problem is it knows so much about all the other
tangential like projects that Kingsley is working on that it's trying to be helpful.
So framing docs, notion template, obviously that's very helpful.
And then this is it.
Yeah.
I think the questions are the most helpful, you know, what's
not working the way it should.
These are just helpful questions to have kind of on a printed out, like next to
your computer when these happen, but really it always boils down to like different
angles of figuring out the same thing.
So like also great questions when, if you're not a super social person, you have
questions, like just being curious is like the most interesting thing.
If you're at, in a social setting and you just want to like be engaging with people,
like just ask questions, be curious about their thing.
Like, you know, Oh, this person's getting their pilot's license.
That's amazing.
Like, why, why are they doing that?
Why now?
Like what, what made you think of doing this?
Like just asking really good questions makes you a pretty
awesome human being in general.
So this is, some of this stuff is like technical, but others are just like,
yeah, just, this is how humans communicate well, as we kind of are curious.
And so just defining things like, yeah.
So what's the real friction, right?
Obviously you're figuring out what's the pain behind it.
Why now?
Like, did something change?
Like, Oh, we just hired these, you know, employees or we just hired a new sales
manager and now this has become a problem.
Who feels the pain the most?
Is this like a user thing client?
Is it the team behind it?
Who's running it?
You know, what are they doing today?
And like, you know, how does it fail?
Cause like, they're probably making it work.
You know, we have very pretty successful clients we're working with right now.
Like they're not, this is not like holding back their entire business.
They're, they're somehow making this work somehow today.
Okay.
I'm using a spreadsheet and we have this very, you know, this terrible process,
but it, you know, kind of works actually.
If we sold this, like, well, what would look different or feel different?
Is this one problem?
Or is there like lots of little problems?
This is a great thing being able to, this is just a skill we'll have to learn by
doing it a lot is like people will come in with their different problems.
And I did this yesterday is like, see, there was, we were talking about one
giant thing and then I kind of pulled it into three different projects like that.
So that does help just to, just to kind of zoom out a bit and I would take it
like this and be like, okay, yeah.
Like, she sounds like you, you have something else going on here too.
Let's talk about that real quick.
And I would just say like, oh, we also need to like fix the, you know, broken
export, you know, report thing or whatever, and then just start to
reframe this one up as a new project.
Also, you know, you're like, yeah, that when we're done with this, like
maybe that's two weeks, then you can kind of zoom out and be like, you
know what, that's interesting.
Cause that's like two weeks.
That's two weeks.
So we're looking at like four weeks to kind of get both, which is one of
these more important than the other.
Cause now you're kind of like framing the frames and projects.
Right.
Like, cool.
Like, okay, actually this one's more important.
I would just do this.
Like, cool.
Let's put that at the front.
Cool.
So if we did this first for two weeks and we came to that, does that sound good?
Yeah, actually that that's really good.
Then they may start talking immediately about a third project.
Right.
Cause this is some, some of these things, like once you get on this process,
they're like, well, let me share everything that's painful about my app
right now with you kind of get on a roll and this doesn't have to take long.
This is not a, there's shaping meetings, which are like, To me, 90 minutes to
three hours, like it's, they're pretty long.
These are, could be done on a 30 minute check-in call with a client
and definitely no more than an hour.
This does not need to take long to do.
So I was just saying, yeah, this one problem or bundle of problems, pulling
it apart to like lots of different things is helpful, it's much, much
better to have a one week project here and another one week and another
one week, then to have like a four week mushy, like, I think there's
like four different things going on.
Just pull it into separate things.
Like if we fix the report, fix the onboarding process, then we did this.
Okay.
Is those three things get done?
That's three weeks.
That's much more clear and easier.
And it's no, there's no cost savings.
I think that's one thing I spent a lot of time with clients recently is
actually explaining that like, because they don't necessarily know how
the tech works or how code works.
So we ended up spending a lot of time saying like, Hey, so if we do it in
three steps like this, it's not three separate projects because then they,
they see like number of projects equals more money.
It's not that it's like, it's going to still take three weeks.
It's just, we're going to do them in bite-sized pieces.
And actually that's, if anything is going to save you money because we
can do this one thing, fix the reports.
We're going to do this one thing, fix this other thing.
So that's good bundle of problems.
And then what's not being said, trying to get again, the
questions they're not asking.
And it's typically when it still sounds vague or you don't feel, you haven't
really had this aha moment of like, Oh yeah, no, I totally get it now.
Yes.
This has to be something we do next.
They haven't got to that root thing.
You can keep asking that, like they probably haven't said something yet.
And then any constraints like timing, Oh, we have a launch on two weeks.
We have a, this, like, these are all helpful things to note for context for
that frame, because those are just things to put around.
So I think that's it.
You know, this is sort of how our new template is going.
This essentially talking about the problem, just this bullet
points are very good, helpful.
Here should be able to that.
Anyone on the team could pick this up on the client's team on our team
can pick this up and know what this is.
And the outcome, again, we're not saying we're going to build a mobile app.
We're just the desired outcome of, of, Hey, I need this problem
solved, or when I hit this button, I needed an export that has these
three things in it so I can tell this number like measurable things.
Like we're going to take it from five steps to two steps, or we're
going to cut, you know, the number of steps in half we'll see.
Again, we'll have a dashboard.
Okay.
No, we don't have to have a dashboard.
We just need to know somehow you need to know this number.
It could be emailed to you.
It could be texted to you.
It could be displayed on the dashboard somewhere.
It could be, you know, there's a thousand ways we could get you that number, but
we just need to show like, Hey, the client needs to know this number, this
formula or whatever this thing is, but then not doing just, you know, being
super clear, like we're not going to do mobile, we're not going to do
any UI redesigned for this.
We're not, you know, just very clear.
And most of the time, once we get to this layer, that's where a lot of
clarity comes from the client, because there's a lot of expectations.
They assume this is like expectation.
Can we, our first lesson was on like communication, it's all the same thing.
It's like, they're thinking like this big project we come in with like, Oh no,
it's just, you know, they think it's like an eight or a nine out of 10 size.
And we come in with like a three or four.
And then what happens is we get into the project and they have these massive
expectations, and then we're delivering something down here.
And there's just this huge gap that we have to manage now throughout the project.
So the sooner we can be really upfront and be like, kind of give them all the
bad news upfront, not having any surprises and being like, so just so you, I want
you to repeat this back to me that you're not going to get a mobile app.
You're not going to get a dashboard.
You're not going to get that.
Okay, cool.
All super clear on that.
Great.
What we are going to get is these things.
And if we just got those things, and then there needs to be a little level
of trust where we then go into shaping together.
And I think a lot of that can be done with the client.
I've been thinking like a bunch of ways to go now solve this problem and
constantly, like almost at the beginning of every meeting, come back.
Hey, just the context is remember this is the problem we're solving.
Here's the solution.
If we're in a multi four week project, beginning of every check-in call, we
typically like to do weekly check-ins.
Just bring it up for a second, bring up the pitch doc in notion, really cool.
Just remember, here's the three problems we're trying to solve.
Here's the desired outcome.
So now you can see kind of where we're at on that.
Now we have this page, we have this thing, we have this piece.
Kind of bring it back to like, you see how we're solving these problems.
Great.
Just kind of bring them back.
Cause guaranteed, like we're in longer projects, you know, a
couple of multi-week projects.
We will forget what we wrote in that framing step.
And the clients have long forgotten all of it.
Like we, they don't even like, they would have to go find that link
to notion somewhere in their email.
They're not, they're not going to it.
It's not like they're pulling it up every week before the call.
Like, cool.
I remember.
So doing a little bit of this work, assuming just that everybody's very busy
helping in a, in a way you're kind of like framing the call, right.
With like a little bit of like, remember the frame doc cool.
Now, everything we're going to talk about in the next 25 minutes is going to be what
we.
be, you know, shaped, you know, where we framed kind of in the first five minutes.
So that just gives people boundaries, keeps people like kind of idea of where
this conversation is going to go, because also they may look at that frame doc and
be like, you know what, that actually.
There's actually this new problem that we now see.
Okay, cool.
It's like without FigJam have a little like session where
new problem, new outcome.
Is that something you guys think you would want us to work on next month?
Great.
Got it.
I'm going to note that we'll, we'll circle back with like, you know, a
frame document for that so you can approve it and pay for it.
And we'll jump into it.