All right, guys, welcome back.
We're doing another team training here.
I've got my team here on the call.
And we're just going to share this with you guys
if you guys want to tune in and learn about how
we do projects at our agency.
We've been leveraging ShapeUp from Basecamp.
We've been learning a lot from Ryan Singer.
We've been learning and diving into all the AI stuff.
So we have a pretty unique system
of how we manage projects.
And in this video, I'm going to just kind of walk
through, basically from top to bottom,
I'm going to show you how we start a project at the company
and then what are some of the tools we use,
jump into FigJam, how we do task grids, how we use Notion.
And so I'll show you some of the templates we use.
And that way, if you're getting started either working
with us or you're working on your own projects,
this will hopefully help someone out.
And you can always drop comments and questions below.
So I'm going to share my screen.
We typically kick off all of our projects in Notion.
And so one thing that we have, so I'm going to share this here.
And let's go to, give me one second.
I'm going to pull up a graphic as well
that I'd like to show you guys.
So we kind of, if you heard about the hill chart
from Basecamp, there's kind of like this,
when you start a project, you're kind of starting out
at the beginning and you're kind of working your way up
into a kind of the top of the hill.
And the way that we like to think about this
is in this sort of hill chart example.
So let me just make this in a quick board here for you guys.
Sorry, that didn't sync quite well the way I wanted it to.
But here we go.
OK.
So when I share this, I don't know if you guys can see that.
It's a very simple graphic here.
But basically what happens is we, in this uphill,
this is where we kind of think about the project
as framing and shaping.
Now a lot of people go and do all the framing and shaping
ahead of time.
We like to make this part of the first part of the project.
And we spend a lot more time on this
than most other teams would.
In fact, I think if you think of it more
like the first half of the project
is just getting clarity.
Like getting clarity in all the different pieces.
And it really frees you up to use a lot more time
on this part of the process.
So when we have a project come in,
it's a client saying, hey, I would like to now
have a way to manage quotas.
Let's say for my CMS, I have a video streaming platform.
I now want to have different tiers of subscriptions.
And this person can upload five videos a month.
This person can upload 10.
OK, great.
That's the problem.
You kind of just little paragraph, a little nugget
of what that is.
So we would sit down on a call either with the client
or just internally.
And we'd start the framing process.
We would start to figure out kind
of how this project will work.
And so we do that using this framing template up here.
So I have when you hit a new project in Notion,
we start to define things like what is the problem.
And all we do here is we don't write paragraphs.
We don't draw drawings.
It's just bullet point format.
Four to six bullets or so of what the actual problem is.
Why are we actually doing this?
Why now?
Why do we care about this right now?
Why is it urgent in this moment?
What is the bottleneck that we're currently running into?
And then we kind of focus on the outcome.
Well, the outcome of this is not go add a UI
to the app that does x, y, and z.
You're thinking of outcomes in the terms
of by the end of this project, I will now be able to do x.
And so once we have a number of outcomes listed,
it kind of frees us up to adjust the solutions
as part of the projects.
We don't know what the solution is at the moment just yet.
So it gives us a lot of flexibility as a team
to figure out solutions that then fill into that outcome.
Next, we move into out of bounds.
And we say like, hey, what are we not doing in this project?
So you may say, hey, we're going to deal with this part
of the, let's say this user quota or user kind
of limitations for the content they're uploading
for that example project.
Things we're not doing,
we're not going to integrate with Stripe.
We're not going to integrate with this.
We're not going to do this automation piece.
We're kind of get really specific.
And this is very good for the team who's building it.
It's also extremely good for the stakeholders
or the clients that are investing in this project
because everything's great.
And we like can complain about all the problems
and then outcome like, yeah, great.
We'll come up with a lot of list of things.
But once you start getting into this,
it forces you to take the kind of the scalpel
and the knife, the project knife and kind of cut away
at different parts of the project
and get really, really clear about what we're not doing.
And so much clarity will come out of this.
And the whole process of how we think about this
at our team here.
here is we just like to go and be as totally upfront
and honest about all the things.
There are going to be things that are unclear
in the project at some point.
Try to surface all of that confusion, the vagueness,
any of that, back into the first part of the project.
So if you're looking back at the hill chart here,
let's surface these things somewhere in here,
in this early start of the project.
Because what a lot of times happens,
we take a little project requirements,
we go straight to making tasks,
we jump and we start building it.
And then we're somewhere in the downhill over here.
And then all of a sudden this clarity sort of pops up like,
oh, the client thought we're going to do this,
but actually the developers thought we're going to do that.
And now there's friction and confusion.
And at that point, we're like kind of through the budget,
that's way more stressful.
We're now putting, going into extra hours,
the deadline's not getting met.
So you definitely want to surface these things
as early as possible.
So the framing doc, when it's finished, will look like this.
And we also do this, can do this in a notion,
our FigJam board as well.
Just sketch it out.
This typically happens live with the client.
We'll sort of interview them and any other stakeholders
in the project and kind of uncover what this is.
And so let me pull up a quick example maybe
of what one of these might look like.
So it could look like a document like this,
where we have like the problem listed out,
like here's the project outcome.
And then we kind of talk through the different,
like here's what we're not doing.
So you can kind of put in a little board.
This is very nice because you can move things
around a little bit.
It's very visual.
And so I do like to do this live on the call in FigJam.
And it's very helpful tool to use something visual
like this when you're talking with clients
who maybe aren't technical,
just to kind of visually see what everybody's doing.
And also if someone throws out an idea
and we put it in the not,
and then all of a sudden, no, we say,
actually, we do want to take that.
We can drag this not into the outcome
and reword it a little bit.
So it's very helpful because it feels very,
there's a lot of clarity for all the people
who are involved in that.
And so once we're going through that,
we've kind of get our document.
And that's typically where we will get sort of final sign off
from the two sides.
So think of this like we've got,
there's sort of two people, two sides to this.
We have developers who are agreeing to,
let's say two weeks for this project.
And we also have a client who's agreeing
to pay for two weeks.
So we all know what two weeks costs in dollars.
We know what it is in hours.
We know what it is in terms of a timeline.
So we're looking at the frames documents
and we're looking at the appetite
and we're all agreeing on both sides.
So the developers are saying, yes,
I will do all of this stuff we talked about for two weeks.
And the clients are like, hey,
I'm going to pay for all of that for two weeks.
And then we're all agreeing to that little,
that sort of container of a project.
What we're not doing here is the reason we do it
with the developers that way and the clients
is because now there's like,
we're equally sharing in the risk for the developers.
What doesn't work well if like me as the third party
as like a Novo says, yeah, we'll do that for two weeks,
but the developer's not agreed to the two weeks.
Now we kind of want people to have the,
the developers have the buy-in of those two weeks
so that they kind of win and lose with us.
And it helps just take us that little extra push
on getting extra clear.
Cause we're sort of both all committed.
The old parties are sort of committing
to that budget equally.
So once the frame doc is completed,
that's where we will move into the breadboarding
kind of getting even more clarity.
So we do this little checklist.
When you create a new project,
you can go into the projects and hit new.
And then this little checklist will be here.
So you can kind of go through the frame doc
like we just did.
And then we would create what we call a breadboard
and link it here in the breadboard link here in Notion.
So Notion becomes kind of like our little dashboard
and you can click out to other tools from here.
And so the breadboard may look something like this.
We use very simple process where maybe we're looking
at something that says client files.
Then there's like, you know, you click this dropdown
in the dropdown.
We have like a list of things
that has two different things in it.
You click on this and it takes you to an editor.
So it's not a wireframe at all.
This is not showing like, this is on the left.
That's on the right.
We're not showing UX.
We're just showing like kind of the process
of like this button is wired up to this.
And this is a thing.
It's literally just a thing.
It's a component.
It's a page.
It's just a thing and with things underneath it.
And you'll see a lot of times we'll do things like this.
We'll use like a purple color to show logic.
Like, hey, if this is requested, like then yes
then we'll have a different flow.
If not, then it'll do.
something else.
And then you can kind of wire this all up
to how you would actually want to when you finish this thing,
you basically come back to that.
And that's sort of the flow there.
I don't have in this one, but we'll also typically mock up
a database structure as well.
Sometimes we'll have a database just sitting there
where we may show, here's the specific items we have,
let's say, for we've got this table.
We've got these items.
We typically do the table little block in gray.
And then we'll have that.
So let me just pull that right back up again.
Sorry, it's just glitched on me here.
And so we'll have that table header in gray.
And then the columns, so to speak,
will be in different colors.
I'll grab this one here so you can see something
with the database.
So this is a pretty complicated one.
This is where we had kind of a table here
with different things inside.
And we were showing, here, this thing links to this.
This transaction ID links to this.
This loan ID links to this in this column.
And we don't have to put every single column.
You'll see a lot of times we'll just put dot, dot, dot.
Like, there's other stuff in there.
It doesn't matter right at this point.
And what's helpful about doing it this way
is we can have the breadboard up here
and kind of how the app's going to flow.
And then down here, we can have sort of the data flow
as well.
So we can reference those things back and forth.
And once we finish all of that, we've kind of got it built out,
other tools that we'll use here, if we're
doing this with a client, can be particularly helpful
if this is a brand new project for the developer
or it's new for the client.
One thing we will do is we will just create a heading here.
That'll just kind of go to a little empty space.
And we'll do that whole thing.
And we'll just say current.
And we'll map the entire workflow out
how it works currently.
And just going through that process,
you'll get in a crazy amount of clarity
seeing the different flows of how everything's connected.
And then once you go through that,
then you can just literally select that whole thing,
paste it again, and say, OK, this
is what the new thing is going to look like.
So there's kind of like the old way.
And then we put it right next to it.
We put, like, here's what the new way is going to look.
And we can kind of reference the current, go back and forth.
And it creates a lot of clarity for people.
Because just going through how something currently works,
you'll be surprised at how clients, other stakeholders,
people who have joined the team, new developers will be like,
oh, I didn't even know that was connected to that.
So these things are just we kind of gloss over
in these projects.
And this is why there's a lot of friction that
happens later in the projects.
We don't spend a lot of time.
So I drew this this way because I
want people to really take the time getting this.
Because you can look at this and be like, man,
that sounds like a lot of work to draw this whole thing.
I thought I was going to be writing code.
Well, this is kind of the freeform piece
before we get to writing code to make sure we
know exactly what to go build.
And so framing there, this is what
we call shaping, breadboarding.
That's all part of the breadboarding
is part of the shaping process.
The other thing I would do in here
is we say, like, creating AI prototypes.
We'll have another video we can link to potentially
that has how we use V0 to do really quick mockups.
And we'll do these mockups sometimes
on a Zoom call with a client.
We may be talking about a little feature,
like, what if we had a little button set that did x, y,
and z.
And then while we're on the call with them,
we'll actually mock that up and show them.
Because you can throw a little prompt into V0,
and then we'll keep breadboarding and shaping.
And then I'll just bring it in at some point.
And I think we did this for this user role preset.
Let me see if I can share this real quick,
see if this will load.
Yeah, we had this thing where you
wanted to give people different roles.
And maybe we hit Editor and a bunch of choose,
and then you hit Administrator or Viewer.
And so we were talking about it.
I prompted it.
This is not a lot.
See, look, it's a little, like, hey, give me an example of this.
It was a couple of sentences.
And so I was able to do that on the call, throw this in there.
And that all of a sudden quickly gave just a ton of clarity
to everybody involved.
Like, oh, OK, now I see what we're trying to build.
Doesn't mean, and then we just throw this away.
That's the key part of this is we're not going in here
and being like, oh, cool, let's try to reuse some code.
None of that.
Just that has served its purpose.
The little prototype is good.
We can throw it away now.
So that's why we like to do in this part
to get just crazy levels of clarity
and link to those V0 things if you want.
You can do that.
And then we're kind of ready to start working.
So there's little prototypes.
There could be you jumping into the code using whatever LLM
to search the code base, find out what the tables are.
Because if you have to go put this table together here
and you're new to the project, this
is a great question for Claude or for in Cursor.
You can throw in some different prompts.
Okay, tell me, like, tell me what the database structure is.
Cause I actually need to draw these things out and just you having to like
duplicate it and it feels really, um, maybe overly simplified or like, why
are we doing this in 2025?
Like we had an LLM could make this little diagram.
That's not the point.
The point is that you had to make the diagram and it forces you to kind of take
notes and figure out what's in there and, and kind of go deep enough into it.
Cause that's the problem with this stuff is you, you typically, we like to just,
um, go pretty shallow and then, um, we don't really go deep enough to, so we
don't really, really understand the details of it.
Um, so once we reach this, this point of clarity, um, at this point is where we
want to create a, what we call a task grid.
So we've created the breadboard, we've linked it in here.
We'll drop, you know, and all we do is we grab and grab the link like this.
We'll paste it in there.
And now I've got a little link to jump to it later.
Um, we create a, what we call it as a task grid here.
So this is just, um, an example here where we, it's essentially just a list of
nine things again, um, where, uh, we take the different parts of the
app and bring them into two sections.
So here we're, we're having to like figure out payments work.
Um, here we're going to track like user income and expenses.
I know I'm jumping between lots of different projects.
You can kind of see like, these are the scopes or the sections of the project.
Um, here we've got some UI stuff to mock up.
Um, I want to build this AI framing page that has these little things.
And I have it, this is totally up to you.
Um, it's really just for you, uh, as a developer and it's for the team to kind
of glance at and be like, Hey, how far are we along?
Cause anyone can look at this grid and be like, okay, cool.
So you've done two things.
You have two things in progress and bunch of stuff you haven't started yet.
So it's pretty quick to see where the status of this project is.
Um, and this is a helpful little tool and you can kind of rearrange these boxes.
If you want, you can move, you know, tasks from one to the other.
Um, and then you can just set the status of the box.
Super simple.
Um, you can do this in notion.
You could do this in another project.
I really like this because I don't have to scroll or go anywhere.
I can just see everything on one page and it's very difficult.
If you are looking at, you know, we do have some tasks options here in notion.
You can track your tasks there.
This is great for bugs or we're in clients are sending us a bunch of stuff.
We can create tasks for each one.
And, um, the, the difficulties here, it's hard to look at a list of all the tasks,
even though it's a Kanban board.
Um, you know, it's hard to look at all that and say, okay, are we halfway there?
Are we two thirds of the way there?
Where are we at with this project?
But in this view, you can take something.
I'll try to grab another, a little example here.
Um, and, uh, I want to show you one here.
I've got a few going at the same time.
Um, so I think it's this one.
Yeah.
So this is a project I was working on this weekend and you can quickly
see like most of this project is actually done and you can just visually
see, you know, there's one little thing there, this has got a couple
of little things here and then we're running, wrapping up the landing page.
And then this whole project's ready to ship.
Um, so you don't have to know what's all going on in the project or what
the scope is, this is sort of taking.
You know, the process after the breadboard make a little kind of scope
out different sections that can be completed independently, and then we,
um, start, you know, working our way through.
I highly recommend to do the breadboarding and then the task grid.
If you spend an hour and a half, two hours doing the breadboard, you can
have the entire list of tasks in the next 10 to 15 minutes, and we've done
that over and over again on calls where we will show, um, you know, we'll
get to that point, we've all a little bit tired, we're kind of at the end.
We're like, cool, let's look, pick this up tomorrow and we'll make the task.
Great.
It's like, let's just push through.
Cause in 10 more minutes of having all those things kind of held in your brain
of where all the pieces are to just jot everything down.
And, um, when you're done with this, it should feel the feeling you should have.
Uh, we heard this from Ryan Singer was you should have this thing of like, I
just can't wait to go get started.
Like I, this is so clear.
I know exactly what to go build.
Just, just let me get in there and start building it.
Then, you know, we we've kind of got this really concrete, super
clear, um, plan to go execute on.
So that's where we build the task grid.
And then, you know, we'll add some more pieces here.
But, um, when we get started and we're kind of ready to start on that kind of
top, um, you know, at the reached point of clarity, now we're going to go start
building, that's where we would actually kick the project off to the client.
Say, then we would start those two weeks, um, you know, counting from, from there.
Um, and so, uh, that's, that's kind of how we would think about the project and,
um, that that's it.
So, um, I'm trying to think of anything else, uh, we'd want to touch on as far
as the, you know, our specific systems go.
Let me just talk about this.
Um, typically the project will start, it'll be in framing.
Um, then we can move it to shaping and then dev ready means we're in that point.
We're in that like super clear, ready to go get started.
Task grid's done.
Everything's done.
Um, when once put into dev ready, it means that it's, it's, you can
start working the next day on it.
Inbox, we typically reserve for just kind of ideas
and things we haven't even started to frame.
So that's typically where a client's on a call,
they throw out something and they're like,
hey, one day, it'd be cool to have this.
Great, we throw it in the inbox, we save it there.
In progress, easy.
In review means we're done,
we're just getting the client to sign off, blocked,
clear what that is, complete.
And then sometimes we just actually discard the projects
and take them off of our board entirely.
We have a billing status that's separate.
Estimate means we're still figuring out
all this framing, shaping side.
Pending approval means we've sent it to the client.
Sometimes they've approved, but they haven't paid yet,
so that's in here, and then we've gotta pay it.
So you can quickly see a lot of clarity
for all people involved on what the status is here.
Obviously, once things are approved or paid,
you can definitely start working on it.
But this helps know if we have shaped something,
it's all clear, but the client hasn't said yes,
you can kind of see like, oh, this is pending approval,
and this is dev ready,
means you actually can't start working on this.
But if it was approved, you can start working on it.
If it's paid, obviously, you can start working on it.
So just really, really clear.
There's everybody knows what is going on.
And the last thing here, we'll have a little,
if you slide the sidebar out, you can hit the dates here,
add the end dates.
Let's say we're gonna start on this date,
so we'll say we start today and we'll end in two weeks.
And what happens here, once you set that start and end date,
your schedule will show you what's going on here.
So you can see that, hey, we have 13 days left in this.
And then the budget will also start sinking immediately
once you use toggle.
So you'll actually see that budget start to fill up
based on the hours, and it's using this appetite here,
which you can set any of those scale weeks,
we only go one through six.
So if I change it to two,
the budget will adjust accordingly,
and it tracks time in toggle,
and toggle feeds back into Notion automatically.
So you can, in real time,
see what the status of the budget is there.
So that's our whole little template.
Hope that's helpful.
We'll drop some links to the templates below,
or if you guys are watching this
and you're not on our team yet, but you'd like to be,
there's always a option to,
in the comments here, in the description there,
you can apply and work with us.
So we're gonna jump over to the team now
and do some internal discussion on this.
I just wanted to share this with you guys,
and we'll catch you on the next one.