you
what's up? Not too much. How are you? Good. Good. Then guys getting ready for the holidays.
Yes, we're, we're trying the kids, the youngest just got sick. So he's trying to pass it to
everybody. So we're, we're in that fun little phase. Yeah, it's the you get sick the most,
the more kids. I just noticed. It's insane. Yeah, it's insane. They have no way. So again,
I'm trying to, I found some good mechanisms for all to start elderberry tea, like all the vitamin
C that I can just trying to prevent it. It's like I was, it's gotten better. They get sick
less frequently, and your immune system starts to build up. But yeah, not always fun.
It's that time of year for sure. It is. That's good. Hello. Hello. Hello. Good morning.
I'll let everybody get on here. Well, and so Chris is Chris, Chris is like our, I guess I'd say like
helping me run all of our agency. Like he's kind of head of product or maybe like chief product
officer. If there was, I think it's the title we gave him. And, and then Zan just jumped on
Zan's one of our product people has helped works with our developers. And we've got two or three
other people that will jump on. But we thought we would just get as many people on as possible.
And then kind of all learn it and upgrade at the same time. So excited about it. Yeah.
For sure. All right. So you let me know first once. I think this is close to everybody.
Yeah. Six. I think it was six total. What's up, Carolina? Well, I think Janata is coming.
Yeah. He's most important person. Luchin. I'm just kidding. No. You've got a beautiful beard.
Got a beautiful beard. Love that beard. Luchin is in from Canada and has, he's our lead developer,
all these things. So good to get. And then Janata also have, he's,
Janata has been helping us work with Chris Monely on a lot of our custom mobile apps and some of our
platforms as well from Brazil. So it kind of all spread out all over the place.
Very nice. Are you in? You're not in Texas. Drew, are you? Me? No, I'm in Orlando, Florida.
Orlando. That's right. I know you're, you're East Coast. Chris in Atlanta. I'm in Nashville.
Carolina's in Texas. So we're all spread out. I grew up in Lakeland, though. Drew. Okay,
nice. Where I grew up from. Yeah. Very cool. Yeah. No, it's not far at all. Yeah. My mother-in-law,
she lives out there over like winter havens, like close, close to that area.
Very cool. Okay, I'm gonna. Yeah, you can jump into whatever you want. I'll just say like,
guys, thanks for showing up. I know this is like, we're going to do a nice,
we're very light meetings. So doing a three hour intensive, this is like the most we'll
be hanging out together in a long time. That's great. And then, yeah, I'm really excited. I've
been following, if you guys aren't following Drew on X, obviously go do that. Sign up for his
newsletter, some awesome content. There's a few people that are, you know, that are
some awesome content. There's a few people that are taking shape up and also combining it with
like agency world as well. So we've been kind of in that weird spot. And so when I saw what Drew
was doing, I was like, this is exactly kind of the niche we're trying to figure out. So
appreciate you guys all taking time, but I'm excited to learn from Drew. And you can take
it away however you guys want to go through it. Drew, we're ready to learn. So sweet.
Okay. Awesome. Yeah, I put so you can see there's a link in chat. I threw that for just
the FigJam board. This will kind of guide us through it. I'm thinking, so we'll start with
just kind of high level. I'll give a little background on myself. I'd love to hear just
like short interest from everybody that we just kind of talked a little bit, but just sort of
what your role is, kind of what you focus on. The thing I want to talk about here is like,
this is three hours. It's a long time. We're going to go deep on stuff. I don't want to stay in like
a lot of theory. I'd love to see your process, like the more context that I can understand around,
like, what does a pitch document look like? How do you take something from trying to find what
the problem is up front to creating this pitch document, handing it off, going through this
process. So the thing about me that you'll learn is like, I'm very.
big on principles first, because as you know, it's like shape up is great, but it also applies
to a product company that operates in a very specific way.
So as I've had to implement this over the past five years, and that can get into a little
bit of my background, because that might help here.
So I've been building software for almost 18 years now at this point, started in design,
moved into software engineering, and then got into more leading teams.
I still write code, I still design, I still like to do strategic work, been working at
Currentplace, which is an agency called Differential, I'm chief product officer there.
I've worked in startups and enterprises, our agency builds for clients, but we also have
our own side of the business where we try and turn those into ventures.
So we have SaaS products.
So over the past five years, I've had to implement shape up, kind of find our expression of the
framework across our software agency, client product teams, as well as on the SaaS side.
So this is where I really believe heavily in principles, because those are more timeless,
they're evergreen, they're things that we can apply more broadly.
So that's mostly what I think about when I think about shape up is kind of the larger
zoomed out area of these key principles to go through.
And when I got all of your survey feedback, which thanks for taking the time to fill that
out, they fit into those buckets too.
So I'll kind of walk through what that looks like before we get into each of the sections
and kind of talk about it as an overview.
But in general, really interested in going deep on things like, I don't want to just
sit up here and just present and talk.
I want to learn, listen, like, let's look at some things that you're actually going
through, projects you've actually worked on.
Because the best way to understand the process is to understand decisions that were made,
the trade-offs that were made, the pain points.
And you guys had a lot of examples in your survey that you called out that I think we
can go deep on.
So before I get into that, we'll get this kind of all situated, but I would love to
get just like even just 30 second kind of elevator, hello, and give me a little quick
run through of like what you do kind of in the day to day would be super helpful for
me.
And Bruce just gave me a little flyover, but I'd love to hear that from everybody.
I'll just call out who I see in order on my list.
So Chris, if you could kick us off, that'd be great.
Yeah.
So as Bruce said, I guess, chief product officer, mainly just trying to go from project
to project, implement our process, make sure that things are running smoothly.
And I'm just lucky to work with so many talented people.
So it makes my job a lot easier.
But I think for me, what I'm interested in getting out of today is, you know, I'm
always reading about best practices, different things from Substack or from Twitter or
whatever.
And it's hard to kind of make sure that we do it the right way, do it our way.
Right.
It's not just, you know, copy, paste, lift, shift, we're done.
Right.
Making sure that we follow up, we measure.
I think Caroline and I work very closely together.
Well, when we meet, when we can meet on trying to talk about, hey, how does this actually
work when the rubber meets the road?
And sometimes it works great.
And sometimes like, well, we got to rethink this.
And how do we kind of recover and get back to that instead of just being ruled by the
tyranny of daily?
So I guess that's kind of kind of where I sit.
I've got a background just briefly in consulting.
I have a law degree, which is kind of weird, just out there.
So I like to write stuff.
Right.
But also I've got a lot of experience in startups and just kind of just starting things,
instigating things.
So that's kind of where I take things, just being autonomous, moving quickly and just
running rapid experiments.
So thanks.
Awesome.
Love it.
Appreciate that.
Giannola?
Hey, so I'm a fan of the shape of method.
Since I've discovered, I like kind of dive right in because after like a few years running
with the overall general Scrum method, it felt like refreshing.
And I think the most important part is that it feels a lot more adaptive.
So you can adapt it easier.
And I think probably that's what I would like to kind of learn the most to like understand
how can we adapt and what are the parts that shouldn't be adapted?
Like what are the parts that we should avoid changing and what are the parts that are more
flexible and that we should look into changing and adapt to our scenarios?
Because I think in terms of mastery, first you have to master the process as is.
And then you are able to make the adaptations that you need for your personal scenario.
So that's what I'm most curious about how you think about it.
I'm also a follower of your newsletter.
I was just reading the last issue.
I believe it was 14.
about like design thinking and first principles thinking.
And it's just it, like, it's just what you said.
It's like, we can like get to focus on like methodology
without looking at what's the essence
of what's being done there.
Because if you understand the essence,
then it becomes a lot easier to move further.
So my goal is basically to kind of download
a little bit of how you think to understand that
and to be able to adapt to how we approach things as well.
So I believe that that's the, my view about it.
Yeah.
That's awesome.
No, I love that.
And I've actually, I've had a lot of experiences
with teams at Differential where they've told me
they don't, they feel a lot of pressure
that they are not following the process.
But then when I just started asking them questions
about what they're fundamentally doing,
I'm like, you are following the process.
You're just little nuances that are different,
but it's like, fundamentally,
are you bubbling up to follow this principle?
Like that's what matters.
And I think that's hopefully what we all come
through with today.
It's finding, I would say, find your expression.
Tape up's a way of thinking it's a mental model,
but we have to apply it uniquely to your team
so that matches what you're trying to do.
And I think that's huge.
Perfect, perfect.
Thank you.
Awesome.
Appreciate it.
All right, Zan.
Hey, yeah.
So yeah, my name is Zan.
So I'm coming from more of a startup environment.
So I started there and went through accelerators
like Techstars and similar stuff,
which they, it's not so much about how they teach you
about managing project.
It's more about, okay, here's the problem
through everything at it, right?
So I'm now more in the, and for example,
shape up for me is like trying to get somewhere
in the middle, right?
So from this hardcore startup,
everything has to be done by yesterday
to some of the hardcore management,
which is also slow, right?
So this is where it's like somewhere in the middle,
which is where I'm currently at also in the mindset.
And that's, I think where, yeah,
this is something I think that this tool as a shape up
or like methodology coming in my space.
I don't know.
I'm just like, as I joined, I think Bruce,
we started working, I don't know,
probably now eight months ago.
So I've been here in that mindset set,
like slowly, slowly adapting it with that, but yeah.
And yeah, I'm coming here as a role.
I don't have directly,
I don't communicate directly with customers.
I'm more as a bridge between like when project
is shaped up, I don't know, 80, 90%,
we, me and the developer that I work with
or two, we finish it up, prototype last things,
and then we take it from there.
So that's currently where we're at.
So I'm not directly with the customer.
I'm more with the product manager in that case, Carolina.
So yeah.
Awesome.
Cool.
Appreciate it.
Carolina.
Hi, I'm Carolina.
I work as the product person
for the tribe social side of the business.
So work closely with Zahn
and getting new features out the door
getting, you know, taking the brainchild ideas from Bruce
and getting them shaped and making some of those decisions
on where things go, how they work, things like that.
So.
Awesome.
Thank you.
All right, Lurchin, wrap us up.
What's up, what's up, what's up?
Great to be here.
I'm the lead developer.
I've been with the tribe social for like a few years
before that I was doing freelance development
and like some of the background of like,
I really love a shape up.
And to me, it's connected to a big influence for me
was a Tiago Forte, like building a second brain,
knowledge management, all of that kind of stuff.
So, cause like we're at the end of the day,
knowledge workers.
So having a good skillset around like managing the knowledge
makes it like really feel like less rushed
and like we're in control
and like we understand what needs to be done
and just we're getting shit done consistently.
So, what I'm looking for today is just to like expand on like feeling really open to
like learn as much as I can.
And I think we do pretty good.
But like, I'm very curious, like free up blind spots or like how we can improve.
So really looking forward to, to what we can learn and what we can share.
Awesome.
Actually, Bruce, I mean, I skipped you, but I've heard that you can do it again, get your
The only thing I would say just for context is we, we kind of have organized ourselves
into two teams.
So we have like our Innovo developers, that's doing customer agency world.
And that's what Chris is kind of helping run and oversee all those projects.
And then we have tribe, which is a smaller team, Zan, Lurch and Carolina are really the
focusing on that.
And then we're kind of leveraging like, Chris is helping Carolina stuff, I'm like, we're
kind of cross sharing resources across those teams.
But that's we've kind of got to two sides of the business together today.
For this, we're all using the same processes, just kind of in different places.
So the only we just kind of turned tribe social to where like, I kind of play the client role.
And then instead of having an external client, but it's still kind of the same process.
So
Okay.
Okay, then tell me, so you mentioned, so with Chris on the Innovo side for agency, who else
is involved, like from a development perspective with that side?
So Janata, mainly, and Lurch is kind of helping on the tech side.
And then we've got other contractors and stuff we work with.
But this is kind of our core team that as far as the shaping and product management
side goes, this is everybody touches that.
Okay, awesome.
Yeah.
So those those nuances are super helpful.
So I'll ask a bunch of questions to get clarifying, just context on those pieces.
I fully understand the managing resources and client projects and all that stuff.
This totally can work there.
But they're obviously, again, these are the nuances that we have to wrestle with.
So before I get into some of those questions, I want to call out and I'm just gonna share
my screen make it easy, but everybody looks like they're in here too.
So when I went through the survey, I was trying to figure out kind of groupings and what things
look like.
And when I think about like, this product development in general, and shape up specifically how it
applies to that.
It's really these three core phases of framing, shaping and building.
Framing is an interesting one that I think Ryan senior sort of discovered later on, because
a lot of people kept saying, well, shaping is cool, but like, how do you know you're
shaping the right thing?
Or how do you pick the right thing to shape?
And the thing I always say is that all the stuff downstream relies on that upfront problem
context, the better the problem context, the better the product decisions, those things
are intrinsically linked, like you have to have deep context in order to make good, straight
off decisions downstream.
So you'll see a lot of problems where you're having trouble potentially hammering scope,
changing scope, if you don't have a clear context problem.
So I wouldn't say like the solution space is great, but as the team gets better at delivering
on the work, taking those pitches, really the problem context is what's most important.
And I found that like on zero to one products, which is what I spend most of my time on with
new team members, like we can't really shape a lot because of the brand new code base,
which is difficult.
But what I spend a lot of time on is like, how much can I pull and get a problem there
and just hand them a problem statement, and we'll kind of shape the solution rapidly while
they're actually building the work.
So you can think about it like you're in the problem space, you're in the solution space,
or you're in sort of the delivery space.
So each of these I pulled out, and if you haven't heard my spiel on this, and I can
send stuff before, but I kind of abstract these five key principles of shape up.
It's appetites, not estimates, projects, not tasks, make bets, work in cycles, uninterrupted
focused work and fixed time variable scope.
Like the whole book of kind of like Cliff's notes version, it's sort of those five key
things.
And those are the principles that I pull out and everything kind of bubbled up to those.
So when I thought about on the framing side, this is where you're in the appetites, not
estimates.
You're thinking about reversing this problem that software development has, where we're
trying to focus exclusively on how much time is this going to take, but you don't really
know anything until you actually do the work, no matter how many times you do development
work, even if it feels like it's the same thing, there's enough complexity that you
just never really know until you do that work.
So you just have to lean into that and scope becomes that lever.
So appetites are constraints.
They force those creative solutions.
So you have to understand those root causes.
And some of the survey talked about like, how do we translate customer problems, understanding
actual root cause so that we can shape the right thing or going deeper into kind of a
user research customer space.
So that's a good spot for us that we'll start there, but I kind of want to walk through
these, but I think that's a good place.
So I think, you know, deeply understand the root causes of customer pain points before
shaping.
So like framing work, setting constraints, reducing the service area, having like a very
clear problem definition.
There's a lot of tactics and techniques there.
So we can dig into that side.
That's problem space.
Then we shift into, okay, we're shaping.
We know we have an opportunity here.
We know there's a problem that needs to be solved that we're now in projects, not tasks.
We're not cutting up tasks for developers ahead of time because that's all just imagined
work.
know that what it looks like until we do it.
So you have to create the consistency and clarity
and pitches so that work can be handed off effectively.
And I think there was a lot of some of the feedback
talked about there being,
depending on what the boundaries look like,
knowing when something's fully shaped,
which, you know, a lot of this is more art than science,
but that doesn't mean that there aren't tactics
and techniques that we can apply
to make that a little bit more clear.
So I think that's kind of the shaping area.
Then we're moving into delivery.
We're shifting things over into this building phase.
So we're in kind of,
we're making some bets on work to be done.
We're working in these iterative cycles.
And this is another great example
of the whole shape up thing.
You know, they're big, big batches, six weeks,
and a small batch is one to two.
It doesn't, you can pick whatever you want.
I mean, even Brian Singer,
like I've even seen him lately say this.
It's just like, yeah, some teams want to do four weeks.
Like, okay, that's fine.
Like it doesn't, ultimately it doesn't matter
because the principle is,
are you working in some iterative cycle
where that gives you enough time to do meaningful work
on a cadence that works for your team
and you're betting that time.
Like that's what really matters.
So making sure that time and resources are being managed,
which this was definitely some feedback in the survey,
obviously with agency work,
with sharing resources across teams and across a product,
that's kind of a space we could talk about.
And then uninterrupted focus work.
So obviously like the requirement
is making sure that there's focus there.
So I think this bleeds a little bit into resources
and making sure that there's focused time.
And another thing you'll hear from me a lot too,
is like, I'm a big believer,
and Alucian, you kind of said it just about,
you know, personal knowledge management.
I'm also a big believer in like the personal development,
like individually, you have to operate well
and manage your time well,
and track your time and write things down
in order to work collectively as a team well.
So like, I believe in that a lot too.
So that really feeds into it.
And then last piece is obviously fixed time,
variable scope.
That's the ultimate control point.
That's the main lever inside of ShapeUp is,
hey, we're fixing the time.
You only have X amount of weeks to do this work,
but you can change the scope.
You can make decisions.
All of that's predicated on this work that preceded it.
So this is really where the empowerment comes from
and those trade-off decisions.
This is the fun part,
but it takes the team really working together,
thinking out loud, a lot of those different principles.
And I have some other stuff we can jump into there.
So just wanted to zoom out, Elise,
and say from a survey perspective,
this is kind of how I bucketed it out.
And then you can see over on the side here,
I just put those in the same kind of pipeline,
because when I went through all of,
what I did originally is I took all the feedback,
stickied it out, put it in all these buckets
because they kind of fit in there neatly, which was good.
So we can flow through this,
kind of thinking it from the beginning to end
and we'll kind of hit it along the way.
So let's start in sort of the framing space.
So like we're in problem space here.
So my question would be,
and this is just open question to everybody,
just kind of like, how do things start?
Like what's the genesis of a lot of projects,
whether it's, and we can kind of treat it on both sides
or just kind of talk holistically.
What does that look like in terms of framing up problems,
how you're obviously on the tribe side,
it sounds like, you know,
sort of the typical product work of user research
on the Innovo agency side, it's more of like a client,
but I'd love to hear just like,
kind of walk me through some of those nuances.
Oh, I can start a little bit.
So it's funny because it's a spectrum, right?
So sometimes we're very fortunate
and I would say this has happened maybe twice in my life.
And first was here in Innovo,
but we had a client come to us and there's this massive,
it's like 78 page document.
And it was literally written out like,
kind of like a blueprint of how to build it.
And it's tempting in that respect
to just kind of lift and shift and just, all right,
we're done, we don't need a shape,
just spit stuff onto the page and we're good, you know?
Maybe it gets chat GPT to kind of, you know,
shape it up a little bit from a verbiage perspective,
but really thinking through, it's like, it's not just,
hey, the client gave me this, we're already a leg up,
but how do we actually make this
so that it's functional and thoughtful?
And just because they gave it to us
doesn't mean they're actually good at shaping, right?
So it's kind of like an old product requirements document,
if you will.
So I think there's that, and on the other end,
there are folks who are just saying,
well, I've got an idea, I want this to be a result
and we get to be more maybe creative, right?
And they kind of have a little bit more,
I don't wanna say autonomy,
but we are looked to as the experts to do this, right?
And so there's of course stuff in between,
but I think that's where a lot of ideas come in
and then at least in my world,
getting from concept to that first prototype
is really exciting for me,
working with someone like Janata
or I've worked with that in the past too,
and of course Lucian,
just getting their feedback on things, right?
Saying feasibility and what's that first step
in prioritizing really helps sharpen my thinking.
So from my end of things, that's kind of what I see.
So would you say that like typically
things are coming in with a more fixed scope,
fixed requirements from the client side?
I think that's fair to say.
Yeah, we definitely have a.
timeline for delivery, and I think we've gotten better
at saying no, right, and making things smaller
so they fit the appetite better.
Okay, yeah, no, that's helpful.
Yeah, I mean, that's what my experience has been.
It's typically, it's fixed time, fixed scope
is pretty common is what it comes in as,
and then it just takes a lot of coaching
and understanding that that's just not how software works,
so let's get this delivered on time.
And the thing that's difficult is a lot of people
realize any idea anybody has,
it naturally goes through an evolution.
It never ends up the end the way that you thought it would.
Like, that's just not how anything works.
Like, the analogy I always use is like concept cars,
like in the auto industry,
they always roll out a concept car.
It never quite looks like the end product,
but it gives you a sense of like visual aesthetics
and feel that can tell you what that would look like.
So even if you do high fidelity type work,
it's more just concepting,
like this is what it could look like,
but understand that's gonna come out different.
I mean, they do it in movies too, concept art,
like it doesn't end up looking exactly like that.
They tweak it once they get in there.
So I think it's like,
you have to reframe that thinking a little bit.
So is there a tension with getting them towards,
okay, well now we have all this stuff,
but now we actually need to shape it
and approach it in a different way.
I think just from a recent project,
there were a lot of different connected parts
to make the whole thing.
You're trying to build a Tesla, right?
You can't start at Tesla.
You start with skateboard, like just that analogy.
And so I think educating, working with that client
to understand that,
hey, we got to build this little piece first
and ask to work as a complete system
before we can expand and add other things.
And as we've gone along and we've built that rapport
and that confidence with that customer,
they've kind of said, okay, great.
I'm gonna not hold and grip so tightly
and just kind of let you do your thing.
And that's been super helpful to do that
and cut things out that don't need to be in place on day one.
And I think I've learned a lot from Bruce actually
in how he kind of finesses that point too.
So, yeah.
How to say no to the client.
Exactly.
And-
There's an art.
Or not yet, right?
Or not yet.
And I'll just say for that particular project,
for some other context is like,
clients come to us for a discovery project.
And so we spent two weeks kind of looking
at like everything they want to do.
And we sort of just sketch out blueprints.
So like, hey, there's probably two projects here
that are six weeks.
There's probably a project here that's a few weeks.
They sent us this like, I don't know, 30, 40 page document.
I can't remember how extensive it was.
And we turned that into about 80 weeks worth
of shaped stuff.
So we kind of shaped everything about 30, 40%
enough to be like, I think this is six weeks.
I think this is, you know, instead of two.
So we kind of could go to them and be like,
cool, we can do everything you want.
It's gonna take 80 weeks and cost X.
And so they wanted us to just go
and start chipping away at it.
So we're like, no, no, no.
We have to put it in an order where it makes sense.
So we can like, we can have something usable at each stage.
And so then what we do is we just pick like a velocity
of like, cool, they want to go at four weeks a month
or eight weeks a month.
And we just roll, you know, on that and kind of chip away,
kind of figuring out what we're gonna do the next month.
So we're constantly like in discussions with the client
for each month that's coming up.
But like Chris said, like in the beginning,
it was like, they wanted us to do, you know,
just go build it for a year
and then come back when it's finished.
And then our version is like, let's build it slowly
and iterative like throughout the whole process, so.
Okay, now that's interesting.
Yes, it sounds like there's,
so then when you start new projects,
so this is something I'll just call it, we have,
is like, I have some teams that are standard iterative.
Like I set a cycle calendar for the year.
So it's like six full cycles and a year
basically is how it lines up.
If you do a six week cycle, a two week cool down.
And then there's always like right now,
they're all in the end of year cycle,
which is usually like a four week end of the year
before we kick off next year.
But I always work on the new projects.
They are never on this timeline.
Cause like, we can't say we don't delay clients
to start to line up neatly with those
if we're in the middle of a current cycle.
So I guess that was my question with
like kind of how between Anovo and Tribe,
like, is there any like cycle,
are the cycles lined up at all?
Are the cadences lined up?
Or is it unique?
What does that look like?
Everything is kind of on a monthly cadence, I would say.
So there's not any gaps, which is probably a problem,
but it's just really like calendar months
has been the easiest way to just keep the billing recurring
and everything kind of from a business standpoint
has been easier.
Okay.
So when you said there's no gaps,
like, you know, there's no like a,
like a dedicated cool down period between,
it just goes month to month?
Just.
Okay.
Just keep running the race.
No, no breaks.
Yep.
Now I get it.
Okay.
That's good to know.
And one thing on the Tribe,
like we do have clients in Tribe
who are kind of our partner level clients.
clients. So they are sponsoring and paying for specific features. So I wouldn't worry too much
about the distinction between the two. They're just, there is slightly subtle differences, but
they're still clients who are like asking for features in Tribe like they would, you know,
on their own projects. So it's kind of the similar problems on both sides, I would say.
Okay. So I don't know if it's helpful. Typically what I'll do is like if there's new,
if I'm working on a new project, I kind of, it operates under the same principles. I don't do
like a neat, like clean, sort of here it's following an exact six weeks and it's just
milestones. So I kind of time box it to releases. So like when we just did a zero to one, it's like,
okay, let's do a core build and it's eight weeks in total. And then I kind of just break out little
projects that'll map on that timeline on sort of a Gantt chart. Then do, so I create a project plan
for the whole thing. So it's a six month project. What are the three milestones that map to releases?
And then I kind of back in small features. So it sounds like you're kind of getting in that
same place. You're taking their big thing and showing them, let's break it down into smaller
individual projects that have some constraints, some appetite on it, that map. And then, so would
you never go longer than four weeks on an individual project or feature? Yeah. We're
kind of stuck in the one to two week hell at the moment. Like everything's just short little bursts
of quick fixes. We've done, we started to add, I think for the project Chris
and John are working on, they're in kind of more four weeks, but yeah, it's kind of stuck around
that. Or if it's a six week and from a billing standpoint, we have to keep it in a monthly cadence.
Then we'll do like a part one of the six for three weeks and then a part two for the other
three week, like break it up like that. But we kind of having them put money or like the payment
using that as a, has been a massively helpful tool because everybody wants everything when it's all
free. But as soon as you start putting dollar signs by it, clients get much more clarity on
like what actually they want and how fast they want to go. So that's been a, we've used that
as a tool to help keep them like focused and kind of in the flow of it. And they're kind of
all running their businesses monthly. So it made sense for us to kind of shift to that. So anyway,
and I'm not against like switching to a six week or changing up the cadence. Like we're open to
ideas. So we definitely, I know for a fact we need to cool down of some kind. So for sure.
Yeah. Yeah. The cool down, the cool down is interesting too. Cause we kind of, we found
like we do them, but then we had early on, a lot of it was bleeding into the cool down. So then
that had to, we had to learn, okay, you got to tighten things up a little bit more in the
actual cycle itself. We are. So we also started shifting like all of the like process things.
It was like nothing happened in those six weeks, shove it all into the cool down. But then that
also starts to balloon it too. And then you shrink the amount of time developers actually get to
the reason it's important is like, well, fixed improvements are part of it, but it's like,
if you're going to shave scope off and feel good about that, throwing it into a cool down that you
can immediately tackle that on. It feels good. It's a lot better. It's not saying like, Hey,
it's on this backlog that we're just never going to get to. It's saying, Hey, it's on the list that
we're going to get to in this time walked period following, but you could always experiment with,
you know, is it like getting things to like a three week in one week, you know, like finding
some middle ground. And this is the thing I always say too. It's like, just experiment with
it. You don't have, this is the perfect way to do it. It's like finding the expression that works
for you. See if there's a way to just incorporate that. Cause that, that part is hard. I think
building new features and balancing like maintenance and fixed improvements. So that's
kind of another question I have just with sharing resources across products. I got some sense from
survey that that would be definitely a pain point, but like with some of the fixes and improvements
type work, is that something that's just sort of got to be reactive and you get pulled off the
feature to go tackle or what does that look like? Again, I guess I'll speak up. So yes and no. I'm
fortunate that I can kind of multitask and kind of go from just kind of cataloging features to
some of the reactive work on other projects that I have to look into. I will say it is sort of a,
you're shifting your brain. So the shifting focus takes a little bit of time, right? To kind of get
back in that ecosystem for that customer and think, Oh yeah, I did this before like three months ago
or whatever, right? As a feature. And now it's coming back as a, Hey, let's tweak this a little
bit. Right. So it does take a little bit of time to kind of get back in that mode of, Oh, okay.
This is a reactive project for this other client that I'm, I haven't been working on day in day
out and just kind of diving back into it. Right. And kind of reconnecting with that. So it's a bit
of a mind shift. And that's.
been the hardest part, I guess, just for me to reframe that.
OK, that's helpful.
Yeah, I think I'd love to hear from the developers
as well on that, because it's a constant tug of war
between like, let's do deep work and focus stuff.
Oh, wait, this thing is broken, and it's
affecting thousands of users.
So that's been a, we've tried to experiment
with having one developer who's kind of on call for the day.
We've not really kept up with that super well.
But that way, like, OK, if one person
is going to get interrupted, it's Lucian on Fridays,
it's Bruce on Wednesdays.
Like, we kind of have, we experimented with that.
Something like that would be good, because then we know,
like, OK, one of us has got it.
So I'd be curious about support as well,
how you guys deal with that and having critical bugs come in.
Yeah, no, for sure.
Yeah, definitely balancing React work and feature work
is difficult. If we have the capacity,
I've always said that the real solve to it, which is just,
it's an easy way to say this is the solve,
but it's have somebody who's dedicated to steady state fixes
and improvements, and they're dealing with it.
Every team that has had the product
get to a state at which there's enough Reactive work happening,
we have to have someone reserved to just pay attention to that.
So I think there's strategies you can use where it's,
you have somebody that's on specific feature,
like, if you can't pull, like, a dedicated resource to do it,
it's taking one of those features and identifying one
where it's like, this one, like, there's some development work
that you really need to break it down deep.
It goes a little bit further, but maybe it's a one-week thing
that's sort of like a two-day fixes and improvement type deal
that you're putting a little bit of extra time into.
So maybe they could, they're doing kind of like
the batch fixes and improvements work.
So an example I have is I'll take,
if there's an area of the code base,
and like, I know we will archive the backlogs.
We try and follow that.
It's like, just clear them out cycle to cycle,
get through what we can.
But typically there's like, here are 10 issues
around this specific part of the code base or product.
Let's, I'll, like, call them just batches.
So I'll take, like, here are the 10
little fixes and improvements.
They're all a day or less of development work
just in terms of how we're constraining it.
Put that in a pitch, essentially,
and that is a feature you can bet on.
So it's one way to do it where you almost like,
turn that work into pitches that are feature work.
And then that also allows that same person
to deal with the reactive work, potentially.
Just trying to think through, like,
if you can't get somebody dedicated to it
or have a dedicated support,
it's just being strategic with which person
is working on which feature that allows them
to maybe context switch a little bit.
You just have to be more strategic with it,
but it's really hard.
Cause I mean, it's, this is where like,
the uninterrupted focus work is critical to it.
But I will say, if you're working on smaller sized features
from a development perspective,
like if you go to six weeks,
those require a lot of breaking down, more diligence,
but you can also solve some of that
by you go deeper on shaping.
You bring more engineering into the shaping process
to maybe get it a little bit further along,
do some of the uphill work
so that it's a little bit easier once you get downstream.
So there's some techniques there,
but that one is just, it's sort of a very difficult one.
Cause even if we, on small teams,
like I always just do it with two developers,
whatever new project that we have.
And, you know, we're feature after feature after feature.
I have to just start building,
like kind of buckets into the timeline or adding,
like you can still pad appetites.
It's like, all right,
they're just gonna do a couple of things on this,
but I'm gonna give them a week
cause I know we need to clean up some things
or things end earlier than we thought.
And that's your opportunity.
So that one's kind of tricky,
especially if you're sharing across
kind of two distinct areas.
My guess would be, would Innovo,
like agency side issues would probably take precedence
over tribe because you're kind of in the, you know,
paying clients versus customers are still there,
but how does that work?
Probably equal.
They're both paying clients
cause we have people who are like licensing tribe
and then they're sponsoring features as well.
So we've tried to keep,
so Looch and Carolina and myself and Zan
are kind of on tribe mostly.
And then we've kind of split the team,
even just in the last month or two,
we've got more clarity on that.
Because it was, I mean,
like, you know,
or else people just pulled in every direction.
So that way it's just one,
one kind of team working on one project
versus having to have, you know, multiple things running.
Okay.
Okay. That makes sense.
Okay. So if there's customers on tribe side
that are paying, you know,
they're sponsoring feature work to be built
and they're essentially operating as a client at that level
once they're doing that.
Okay. That makes sense.
Okay. I'm just calling out things in areas that I'm hearing
just to get a better sense of things.
I would love.
I was thinking about that question.
I'm noticing something about like our team.
Cause we did have like that support system
that we're like one person dedicated per day.
So.
I thought that was like a really good system
because that person, if like a critical issue happens,
then like that person is like interruptible.
Plus like that person, we had like a backlog
of like miscellaneous issues come in.
So they're expected to like kind of chip away slowly at it.
So I thought it was good, but like we didn't keep up
and it's kind of like, hmm.
I just prefer having Lucian on call all the time.
It's not a specific reason you didn't keep up.
You're just on call all the time, I prefer that.
Right, that's much better.
So I thought that was really good.
And yeah, so I'm noticing this thing of like,
you know, we have a good thing
and then it just kind of gets neglected and stops working.
And we had a similar thing with like a deep work
because it's like a more like a personal habit.
And we were trying to establish that like for each person.
And I remember like me and Carolina,
we're like cheering each other on,
like, okay, I did my deep work session this week,
you know, like getting the habit down.
And we just kind of stopped doing that.
So I'm like, sometimes we have like really good thing doing
and we stopped doing it with like, there's no reason for it.
So I just thought that was interesting.
Okay, that's good to know.
Yeah, so I mean, so you felt like,
so when you were doing this one,
so basically it's one developer is dedicated to covering
per each day, it's a different developer.
So you have like one day per week
where you're dedicated to dealing
with just reactive work essentially.
Yep.
Okay, so I mean, that's interesting
because I think the equation that I found
with a lot of the reactive work is you have to find much
like we can just take the apathize on estimates principle.
It's like, well, we know it's difficult.
So we've been trying to just estimate,
well, what if we didn't?
What if we just said, we're only gonna spend this much time?
What can we control?
So you have to kind of reverse the equation.
And I think reactive work, it's like, well,
how can you make it a little less reactive?
Because this is happening in the development world.
Like the customer, the stake, whoever the stakeholder is,
customers, clients, whatever,
they're always gonna think it's a fire.
But like, there are very few and far
between actual fires that are happening.
We're like, you know, this,
depending on what your software is, you know,
it depends on what it's actually doing.
You know, is it a medical something?
And, you know, it requires, you know,
all this on-call work or the reliance there.
But typically it might be like, can it wait a day?
Cause it is very different for you as a developer.
If you can go, I'm still staying focused today.
I know I have reactive work tomorrow,
but it's like planned reactive work.
So I think there is something to trying to shift
to that way of thinking at least,
where you can sort of plan your own reactive work
because it does help you when you plan your week.
It's like, all right, well, I know every Wednesday
I'm gonna be kind of reactive there.
So I'm bucketing out my time Monday, Tuesday,
and I'll get back to it Thursday, Friday.
And that helps.
And I will add, I think we were doing a pretty good job
of separating out, like we did some like customer education
of yes, like they do always think that it's a fire.
And we said like, no, no, no, actually it's not like
totally unusable for like half of the people.
It's not an actual fire.
It's like not critical, it's high.
So we had like a list like that.
And for developers are like the expectation of like,
okay, critical, you need to do as soon as it comes in.
High, like do it when you can.
Medium and low, like you could just like not do it.
It's okay.
You can like spend the rest of the day
doing like your project work.
So I think we had that part of the process,
like pretty good.
Okay, nice.
I like that.
On the, so I'm trying to think with framing,
like where to start at least here.
So I would love to, like, that's where I mentioned,
like I'm sharing my screen just for this,
but we're all on this board.
I'd love to more specifically look at stuff too.
Like, I mean, if it's like, let's get into,
you know, from a framing perspective,
since we're kind of still in that spot,
like even if it's like, what is a,
like we're in the problem space.
Like what do those things look like?
I know we talked about this, you know,
massive, you know, multi-page PDFs
that we get on the requirement side.
Also on the tribe side, like what does that look like?
So like, Bruce, are you the one giving the inputs there
and like, hey, here's the problem.
How is that being like mined from customers
and customer feedback?
Some of that stuff would be helpful to get into.
Cool, yeah.
I'm trying to think of,
if you guys have ideas on sample projects,
we have, I have a couple ideas of projects
we could even pull up.
We have everything in Notion.
So it's where all our pitches are.
It's like one massive database,
just filtered by clients and dates and stuff.
So some of them have worked great.
We had one project, the courses,
which everybody will laugh at,
like was like, oh cool.
Like this is a four week or eight week project.
And we shaped that in February
and we just released it last month.
So it was just, it was a very long four weeks,
but we did get it done.
And we learned a lot as far as like processes
and we had different people work on it
and then start again.
And it was just a kind of a mess.
And so we, what was good about it was we,
from a tribes, this is for tribe,
like we ended up on a great solution
because it was kind of the third time
we were building it for whatever reason.
And so.
So it did end up with a really slick process,
which we ended up only spending really two to four weeks
at the end to build the final version.
So it was definitely, we were accurate,
but we kind of went in this meandering,
like exploratory thing that try a bunch of different ideas
and then ended up throwing a bunch of stuff away.
So there's more flexibility on that side to,
we don't have to have like a deadline,
like this thing has to be done on this date.
Whereas the agency world is a little bit,
they're planning things around that.
And we, you know, if we take an extra month on tribe,
it's not the end of the world.
And so there's the courses example.
Obviously we can show Extech stuff, Chris,
if there's good examples there,
but we're finding that like,
it's kind of getting into like the very tactical things.
I think is where like,
I've had good conversations with Zan,
where like we'll shape something
and then we'll start the, let's say two week project,
but then it's really only like 60% shaped.
And so we're still like,
do we spend the first few days of the two weeks,
like shaping, you know, specifically,
like getting it to maybe an 80 or 90% fleshed out?
Because some of that work requires a developer to go in
and be like, what is actually possible?
Like, which way should we go?
What is the solution we want to propose?
Or is that all done like ahead of time?
And then the two weeks is like,
start working on like implementing.
So there's just,
those are kind of the little nuance things
that we're getting hung up on.
And it's, you know,
either way we're like margin would be great
across the board on everything
that solves a lot of problems,
but that's where we're kind of bumping in.
So like now the project feels behind
because like we're on week two
and we just finished shaping it,
but now we've got like seven days left
or five working days to get this thing done.
So Zan probably has thoughts on that.
Yeah, exactly.
Like for example,
the Go Live project was also similar one,
which was, there was a lot of things.
So I think it was like four weeks project,
but then let's say one week it was just about shaping up.
But then the second week that we went into,
we actually had to have like a developer come in
and then try like actually prototyping technical part of it
more or less,
which could like this second week,
then actually like it delayed stuff,
but this part could also be already a part
of the development cycle,
let's say like that.
So for example, it could,
it was part of the still the shaping up process.
Let's say it was 80% or 90% results, right?
But for those last 10%,
it actually needed like five weeks of the developer
to actually try different technical parts there.
So I think in these scenarios,
it will be helpful of actually how to think about that,
where it's like, okay,
the developer would have to go in to,
let's say we complete the shape up 100%
or we can already get started with the development of it,
let's say in 80, 90% shape,
but then actually adapt that as we go, right?
So I don't know if that makes sense,
but it's more like shaping solution
and building at the same time for the last 10%,
let's say something like that, right?
I think that was one of the thing that we ran into.
Yeah.
And I know we're going a little deep on this project,
but maybe it's helpful to use it as an example,
cause this, just so you can see kind of how we track stuff.
Everything is, we track the hours on everything.
So it was, I think four weeks,
and I think there's a reason this is that way
for billing standpoint,
but we can track like the actual hours we spent.
So I'm not too worried if we go 10, 20% over budget,
we've kind of built that in knowing that's gonna happen.
And we break stuff down into tasks here.
So you can see like there's 31 things,
like we kind of broke these into little bite-sized pieces
of kind of how each of these flows.
And every time a bug came in,
we would track it in its own little board here.
But then the usual, shape up structure,
which is like the problem,
talked about like what was not working
with the current version.
And this maybe could have been more fleshed out.
And then once we got into solution,
you can see like this was,
we like to keep notes on stuff.
So like, hey, we think this could happen.
That's version one is like,
we get something live out the door.
This was actually to Zan's credit,
came up with this like very iterative version.
Like, okay, we'll get one version, which works this way.
Version two, we'll have this extra little feature.
Version three is gonna have this extra thing.
And so by the time we get there,
we've like solved all the hard things.
First leaving, you know, testing the whole,
like trying to.
build it all for two weeks, and then try to test it for a week.
Build a little piece, make sure it's solid,
and build upon that.
And so this was just us thinking through how
we would define each one of these things, what
tools we would use.
Got a little bit technical here on how
we use webhooks, some of the settings for each
of these different roles.
So this one's pretty extensive.
It's a lot.
And maybe we put too much in the document here.
We had examples from the app of how it would look, and so forth.
So I don't know if that gives a better idea of what
all went into this.
And so this is still going.
And then we do talk to rabbit holes, of course,
like where we could get stuck, technical stuff,
questions we had along the way, decisions we had to make.
And then out of bounds was like, we
didn't want to change the UX too much.
We didn't want to spend a ton of time replacing any UI stuff.
We don't need to share links outside of the app right now,
things like that.
So that's kind of how we split it up.
OK.
No, that's super helpful.
And even if it's like the project that did not
go the way you expected, or one that didn't go well,
and one that went really well, there's
a gap between those two things that we could talk about
and go deeper on.
But I think what I'm seeing is very similar to what
I've seen before, which is there's
more time spent down on the solution space
than the problem space being there.
And it's very common.
I've seen every team do this.
It's really hard.
And I think, Carolina, you had a couple of questions
around that, just like, how do we get that data out?
It takes a lot of digging to get there.
But ultimately, you're going to make better decisions down here
if you have more clarity of the problem up front.
So we can get into some of that, too, if it's like,
what's some of the problem definition
side in the problem space, and what that looks like,
and root causes, and going through that.
And I shared it in my newsletter this week as an actual example.
But one of the products we're building currently
just had an Algolia search.
The client wanted the highlighting
when you search for a keyword to show up in every result.
But Algolia's got this weird character limit
where it's like 50,000 characters.
So it didn't go through the full result set, yada, yada, yada.
So we went through this whole thing where they're like,
it's a developer on the client side that knows some of it.
So they suggested, well, you could chunk the data out
and do this or that.
We kind of explored it and looked at those options.
But when we talked it through,
we were just getting back to like, what's the problem?
And actually, one of the developers on my team said this.
He was like, well, if we can get a better sense of the problem,
we can probably come up with more solutions here.
And I was like, that's the best way to think.
Like, when you think that way, like, that's what you want to think.
It's like, I can't, I'm wrestling with the problem down here.
I need to know, like, what's the core problem?
So when we got to it, it's like,
ultimately, they just wanted the results to be highlighted.
So our simple solve was just do it on the front end.
Like, we don't need to deal with Algolia
and chunking all this data out.
We can just manage the results ourselves.
Let's just highlight them on the front end.
Works way better. It's way faster.
Took us way less time.
So you just have to get into that space.
But the only way you can operate more creatively down there
is when the problem is like,
you've really explored the problem space.
And I think that's the part in shaping
that gets really tricky
because that part is very fuzzy a lot of times.
And sometimes you do have to operate
with a little bit more fuzzy.
And we can talk about,
I can give some techniques at least around
like the technical de-risking side.
I will say like, I reshaped them myself,
but I'm a designer and an engineer and I've been built.
So like, I can do, I can view it from all three lenses.
But when you have different people
that have different skill sets,
you have to bring them to the process.
Everybody's got to view it from a specific lens,
which I can talk about,
because that can help where it's like,
I'm writing the pitch this way.
I have a second perspective that's writing it
and thinking about it this way.
And they're identifying specific things.
So when you get those for your team,
that'll be what will help.
Like Chris writes it here.
Okay.
Then Lucian comes in and he looks at it and he does it.
Like you can figure out what each person's role is
and how they should be thinking about the pitch.
Cause it's very much a design focused exercise.
But the big part that you're trying to figure out
is like, what's going to trip us up
from this shipping this on time.
It's like, there are always rabbit holes lurking somewhere
and you're not going to catch all of them.
And a lot of times, and I can show examples,
I'll try and dig up some around pitches I've written
where I probably do have it 90% shaped.
There's an unknown here,
but it falls into the territory of like uphill work.
And I feel confident in that.
The team can, let's figure it out in the first week
of going up the hill
and they'll be able to figure that out.
And I think that's where the hill chart does help.
And you guys are using notion.
We moved away from base camp and into linear.
So we're kind of out of hill chart territory.
I still like it.
I still think it's a good visual.
Even if you just draw it on like a fig jam board,
I've done that before and just put little dots
and kind of have a conversation about it.
It's helpful just to think about things that way.
But yeah, no, I totally understand that.
If we could go on that project specifically,
that would be really helpful.
And I would say like even just the kind of thinking
about like what's an outcome we need to hit
for each of these things
and that pitch document helps a lot.
So is there like a standard pitch?
format or template you're using in Notion,
or is it kind of the general problem solution
and kind of changes per?
We have like a template that we'll start.
So for here, we just start a new template
and everything kind of starts with this template
and we leave everything in Inbox.
And so this is like just an idea,
like stuff where we one day look at,
then we kind of go through a process of shaping.
We've recently tried to add this waiting for client,
sometimes we're finished shaping it,
we're just waiting for them to approve it.
And then we call it dev ready.
So this means like people can go and start on it.
So we're trying to get to this point
where it's pretty shaped,
but typically what happens
as soon as you flip it to in progress,
then it's like, oh, wait,
this is only partially way shaped
and then in review completed or we discard stuff.
So we try to keep it clean,
but same thing like problem solution,
rabbit holes out of bounds.
And this is what would success look like.
And that's kind of our template for now.
Okay.
Now that's helpful.
Yeah, so you treat it as like it's an ocean project.
It has the pitch embedded alongside the actual tasks
that are going through the process.
And the tasks are just like a different database
called tasks that link everything together.
So I would love to hear how linear I've been exploring it,
but I'm trying not to be like,
jump on the next cool thing
and just totally derail,
throw a grenade into everything we're doing.
But yeah, I've been tempted with linear.
It looks good.
Okay.
Yeah.
I mean, I'll say like I've used Notion since like 2017.
Like personally, I have a crazy Notion system.
I love Notion.
We toyed with taking it,
taking us there at some point,
but it was gonna require a lot of my time
to teach people how to Notion.
And I would spend all my time just cleaning up our Notion.
So we shifted a little bit.
So we use Basecamp for a long time.
Basecamp was getting a little rough.
Like it's almost too simplified.
We couldn't get a lot of like data and metrics out of it
that we wanted when we were doing more support work.
So we've been doing linear since March of this year,
I think.
And I've had a lot of success in it.
It is a very good product.
So I'll say that it's probably worth it
from that perspective,
depending on like,
I don't know how much clients get involved
with any of the Notion projects.
Like, do you add them to any of the projects?
We'll typically like publish it to the website
and then they can share it.
But our clients are not technical at all.
Like their founders,
they're running a electrical business.
They're running like a coaching business.
Like they just need stuff done.
You know, they don't,
that they get bothered
when we show them that level of detail.
Which is a great thing.
Yeah, that's fair.
Yeah, no, that's good.
I mean, I try and I always coach our teams.
It's like, I use the analogy of,
it's like a kitchen almost.
Like you don't,
there's some stuff happening in the kitchen.
You don't want to come back there.
People might be screaming at each other.
It's a little chaotic.
It's part of the creative process.
It's fine.
But then there's the front of house where it's like,
hey, here's the menu and here's what's on it.
And it's very nice.
And so like, you kind of have to curate it.
So I always say like,
it's in general when you're doing client work,
it's like kind of keeping them out of it's good.
You want to like strategically show them
some of those spots,
but they'd rather have the menu that shows them,
you know, Gantt chart.
That's pretty instead of, you know,
all of the potential messiness that's coming in.
So we can, I'm trying to make,
this one was close to some of the,
I know this one was a little bit later downstream,
but are there standard questions
to ask to nail down the real problem with a client?
Or how can I get better at learning?
What questions to ask to guide them?
Yeah, I mean, this one's, like I said,
this one's very more art than science.
Like you can always come up with a list of questions.
I think for me, like when you think of any problem,
there's always so many different angles to it.
So like the goal,
I think when you're to set something up to shape it well,
is like, it's narrowing the problem down
to like the lowest amount of surface area that you can.
Cause like the problem in software is like,
where do bugs come from?
It's like increased surface area of code base,
more code, more things.
So if you can start from the space of like,
I always talk about like with my teams,
I'm like, I'm always just doing this all the time.
I'm like, nope, let's avoid that.
Just keep, let's go.
We got to keep narrowing it down.
And that might happen as we get into it further.
It's like, what is the real,
it's like, you just want to know like,
what's the crux of the problem?
And a lot of it is just kind of like first principles,
asking foundational questions,
challenging some of those assumptions,
like getting towards the root thing.
I mean, it's the, you know, Steve Jobs thing, nobody,
or I guess the better quote was the,
it's the, if Henry Ford asked what people wanted,
they would have said a faster horse, you know,
instead of a car.
So it's like, you do have to get to a place where like,
they don't, they're going to give you something,
but you have to get behind it.
So I can call out like specific techniques that like,
like I do like, like jobs to be done as a good framework
for some of this thinking, if you haven't looked into it,
it's a good one because it does get into a lot of like user
kind of like struggled and context outside of it.
Like, what are they hiring this product to do?
And if you get more into that space,
you can start getting a better understanding
of what they're actually trying to do.
So it's a lot of that's just kind of digging
and user research.
So I think what I'll do on this one,
because like there's specific questions
that could be.
ask, but I will provide like specific resources that I found to be helpful.
Um, there's two, so I think jobs to be done and I have some books that I've
can recommend on that, that are really good.
And then.
Um, there's a book by Teresa Torres called continuous discovery habits, and
she has a technique called opportunity solution trees, but this would probably
operate more in the product space.
Um, but she has some very interesting techniques just for, for how you do user
interviews, talk to people, uh, have those conversations I have, like, I can
provide a bunch of different books and links on that one, because this one.
Like, I never have, like, even when you ask if there are standard questions, I
feel like I probably have like a bank of them, but it tends to be, it tends to be
more of kind of like a user interview kind of thing, where it's like sort of
the five wise, it's like, okay, well, why do you need that?
Why do you need that?
Why do you like going deeper to get your goal is to try and get to like, what's
the smallest atomic unit of this problem?
Cause that's going to help you shape.
It's way clearer to shape then it's way easier to see all the lines of the words.
Like that's really where you're trying to get to.
I hate when these answers are sort of just like, it depends, but this is one of
those where like, there are tactics, there are ways to go about it and I'll
provide some of those resources.
Cause I think that'd be worth looking into on those.
Um, and from those, you could probably come up with like a set of, I, I, I
probably haven't written mine down, but I tend to ask the same questions, but
each problem is a little bit unique.
So I tend to go to it from that perspective.
Yeah.
And just trying to shift people into thinking about the problem, right?
These things come to us, not in the form of like a nice organized meeting or an
email, it's a Slack message with directly from our client to our team.
Like this thing is not doing what it should.
And you're like, great.
Like my first question, my first question has generally been like, can you explain
like, what, what is the problem?
Cause they're like, oh, it needs to do this, this and this.
Okay.
That's one solution.
Like, tell me like what the actual problem is like, oh, well we need, you
know, and then I kind of back up for it.
Once they explain it a little bit, it starts to get a little bit clear, but
um, that's typically, you know, we're not really working with our client.
We're looking, working only with like our clients team, like where there could be
five to 10 people that are all giving us input on a particular app.
So.
Yeah.
I mean, when you say it really makes me think, I think the lesson I learned is
like, he's now six, but he still does it.
My son, my older one, he, I mean, it's like the classic kid, why thing?
I mean, it is like when they say, well, I want it to do this.
Why do you want it to do that?
Like there, there, there is a problem behind that.
Like there's always some motivation behind it.
You have to, and I think like you have to get to like, what
is the motivation behind this?
They're going to keep telling you the solution.
Cause that's human brains.
Don't like, we don't like gaps.
We don't like open loops.
So for them, I have this problem.
I'd rather just tell you, here's how you'll solve it.
And the problem you're going to be right.
But their brains was trying to close that.
So you have to like figure out what's the open loop for them.
Keep asking them why.
So it really is.
So a couple of things that like the five wise exercise with one, that's a common
one, and I'll dig up some resources I have on this one too, but I want to
at least create a list around that.
Cause that's like in the problem space, that's incredibly important
is to try and get towards that.
Especially if you're on the client side where a lot of it is, you're
getting fixed requirements, you're getting prescriptions, you have
to find the problems behind that.
Cause then that'll, that'll help you because it is true.
Like even, and a lot of this is trust building too.
Like when I mentioned that Algolia solution, when I brought that back to
the client, the response was like, well, we trust you it's like, yeah, because
I'm giving you the exact same, I'm giving you the solution, I'm solving
the core problem and we're not going to do, we're doing half the development
work to get there and it'll get done on time.
It's way less complex.
The code base will be simpler.
The product will be better.
We can test it and make sure it solves the problem.
And if it doesn't, then we go down that path.
So you just have to, it's like that's on the client side.
I always see it as that way.
Like we'll take you through this process and then you'll see that the way that
you build things is by making trade-offs and you can only do that effectively if
you understand the problem space upfront.
So I'll put this here for now.
I don't want to do it in a second, but I have a few on top of my head.
So I'll, I'll provide some links on that because I think we'll attach
that to, to this one on that side.
Um, is there any others like with that specific project when you
talked about some of the courses?
So that first, the one you showed was the courses project, correct?
Uh, it was the, it was go live.
It's like basically like a live stream, starting a live stream in the, in tribe.
Uh, that one, that was just a very recent one.
Um, it's a more real example.
Cause we were spending a lot of time also pausing in the middle of it
to try to figure out our process.
Um, and why stuff like how, cause we obviously, and again, it was just kind
of too, too tight of a deadline for too much work, and so we did in the process
end up simplifying it quite dramatically.
Um, but I feel like I actually, to be honest, like I didn't even see how
quite how long this whole pitch was until right now when I'm like scrolling
it through, it was that we may have like over overdone the notes and the feedback.
Cause I, I'm a huge fan.
Like we've either like say too little.
like some of our projects can say like, hey, we need to add courses to the app, right? Like,
it's way too vague. But I do think there's the right amount of this, like, precision language
that goes into a pitch that's very, it helps, like, it's precise in that it cuts through,
like, where it's not this, but it's this. Like, your example of the Algolia is like,
I want it to highlight, and so when the results come back from Algolia, I want them all, like,
and so, like, immediately in that sentence, they've already thrown in, like, oh, this has
to come from Algolia's problem, it can't, like, oh, no, hey, I'd love to, hey, when someone
searches, I'd love to see the text highlighted, the search term, like, highlighted, like, you
know, that's the problem, but they immediately want to, like, throw it into the solution.
So, trying to get very specific on the language of, like, spending a little extra time, I think,
shaping on the front end, and I'm happy for our team to, like, spend more time up front on that,
whether we count it as part of the project or not, that's totally fine, but I think just iterating
on, like, cool, like, we've recently, like, gotten to the habit of, like, cool, I think this is,
like, 30% shaped, I think it's, like, 80% shaped, like, just give it, like, or even out of 10,
like, how far do we think this is? Because just because there's a lot of text and there's a lot
of notes and to-dos, like, doesn't mean that it's actually really shaped well. In fact, taking it
and editing it one more time, like, okay, I don't think we need to include all this, I don't, you
know, we can delete all this, we can say this with one sentence, we don't need three paragraphs,
just being very clear and precise, it helps us communicate to the client, to the team,
so, and then it comes back, I know, you know, Basecamp Anthro Signals, super
important to, like, have great writing skills and communication, so it's, we're all having to,
like, level up our writing abilities for this to write very well, short, you know, to the point
stuff, so anyway, just a few thoughts on that. Yeah, no, I know, like, there's, I'm trying to,
like, experiment too, it's just, like, I mean, I enjoy writing, it's a huge part of it, I think,
like, it helps clarify thinking, you're having to write the problem out, go through the solution,
like, there's a lot of benefit in that, but even, like, everything I shape, it always comes from
different, like, places, I start at different places, sometimes it's, I know enough that I
need to write this out and just get a framing for it, I don't really know enough there, so it's,
like, you're just in, like, rough sketching kind of world, ideating more from a user interface
perspective, or, like, the breadboarding technique that they talk about is a really helpful one to
get you out of, like, to get you into a sense of flows and, like, what you expect from screen to
screen, I might be able to actually, let me, I can show, might be helpful since I'm in R,
showing you some behind the scenes, this, I just threw this together in here, so I was actually
shaping this, this feature, like, they have this, in this product, it's, like, a whole subscriptions
thing that they want to build out, it's, like, an onboarding flow, but this is, like, how I
started shaping, I didn't start from anything else, it was trying to just wire these things up,
so really it was essentially what you're doing, like, it's the same breadboarding technique that
they talk about, but it's just doing it, like, a sticky form works the same way, it's screen,
it's what they would call affordances, text, link, buttons, whatever's on that page that you would
expect, and then you have arrows to signify, are you, those things flowing between each other,
so, you know, they, authentication gives them a signup link, they create an account, it has
these affordances, they, when they submit, they enter a code, it auto-submits, so this is kind
of, like, creating an organization, has different elements here, and I kind of went through this,
and the reason I was exploring this is because it's, like, this whole onboarding flow to creating
a subscription, so do they upload a video and do this, like, nice uploading flow here, or can I
just do a more streamlined version of it, where it's just letting them create an organization,
do the subscription, and go to a message screen, and just kind of getting a sense for it here,
so, like, this is a bit more about the specifics, it's just, like, saying from a
shaping space, it's, like, I started here, it's, like, you can start from, each problem can be a
little different, so you start from, like, you just need to get clarity on the problem, like, can you
just write a really clear problem definition, then, based on that problem definition, you start at the
right place you want, whether it's, I need to sketch, I need to get a sense for, like, overall
flows, which you can do in sketching, too, this is just, the reason the breadboarding technique works
is because it's a lot faster for me to just go, like, oh, actually, what if we didn't have this
screen, what if we moved it over here, I can do it more lightweight and easier in this format than I
could do in a, you know, actual sketched version of something, it's just a little bit more lightweight
to move things around, but one thing I've been exploring is, like, you know, we all have to
understand, like, AI is rapidly changing, too, so, like, how can it help in that process, and, you
know, through this, as I was shaping this one, I'm, like, can I just, like, screenshot different
things that I've shaped, like, this, and give it to ChatGPT, or give it to, like, a custom GPT I
created that does a pitch that I like, and just feed it that, and kind of get me more 80% of the
way there, so just want to call out, like, I know, I think Carolyn or somebody mentioned, like,
Chappy RD, you know, there are other tools that are out there, uh, to those
ones do get like, sometimes you have to QBT where there's give you, you know,
it's the AI slop thing where it might give you too much.
So again, you gotta give it good inputs to get there.
Um, but just calling that out, if that's helpful, at least to like, when
you're thinking about approaching these things, there's different ways to do it.
So like, this is a good place to start.
Cause actually even with the developers, I had good
conversations with them around this.
I showed the client, this is part of just to kind of understand like, Hey,
here's the thought process behind, like how we're thinking about this.
And this helped me understand, okay, we have all these authentication
screens in place already.
The new thing is creating an organization.
So we know that that's the scope of work they need to tackle.
We know that Stripe and subscription model, and that's a scope
of work that you need to tackle.
And then we talked about this whole upload video thing,
and maybe that's a scope.
So that's identifying those in the pitches kind of helped too.
But, um,
one project that you just hear, is this the entire app, like on this board?
This is one.
So this is the features called subscriptions.
It's one.
So here I show whatever I'll show you guys.
Um, So you can see here, like this was, and this is not how it looked at first,
but this was kind of like, we're in this public release, this is how I kind of
blocked out this, this chunk of work.
And I kind of mapping them on here.
So like this data migration was actually supposed to be a week, but then we had
all these permissions issues kind of blocked on their side, it got extended.
So this is where like, I was, it's fine.
Things got, this was supposed to happen later.
This was supposed to happen later.
They got done sooner.
These were extended a little bit.
So this thing I'm showing you is this whole feature, the subscriptions one.
So it's much bigger than all the other ones within this project.
So it was about a six week project.
Yeah.
So this would be like a more typical, like as big as you can go feature size,
which I like shape of has the, there's a six week version of any feature.
In theory, if you break that down, you could actually do, I mean, like I,
then you don't have to follow shape up at all.
Apparently, but I mean, honestly, like, even if I thought I started thinking
about this recently too, where I'm like, I'm going to give them a full pitch
that has about create organization.
I could also give them a one week pitch to make create organization.
Like I could take that whole block of subscriptions that's across six
weeks and I could break it down further.
So I guess where I say like the appetite size, it's just really how far you want
to break it down for your team that fits your cadence, that's totally fine.
Like you can change it however you want.
This just happened to be a bigger one, which I will say like, this is probably
the first time I've done a six week feature in a while, like a lot of our
teams do, but I tend to think that that's just like, you can always
break it down further.
You get, the goal is to get tighter feedback loops.
So if you're just doing a one week feature, you can get tighter.
I think you build the muscle a lot better when you actually go through that
process and do it faster over time.
But, you know, this was, I'm sharing this cause I think this is the cool, like
it's, this helped me a lot.
And this is a good place to maybe start.
You can have different conversations looking at this than a pitch document.
Cause you know, the documents like somebody wrote it.
I see the pitch documents kind of like the artifact that's like wrapping up all
the thinking at the end, almost is kind of how I view it.
If that makes sense.
It's like the formalized, like we're viewing this as like, is this good to go
into development?
This is the problem space here where it's like, like this is more solution space,
but it's like, all right, we're kind of experimenting here.
So good.
Does this get, I'm just kind of thinking of the process, like practically, like
you use this for yourself before you write the pitch, or do you include links
to this in the pitch when it's done?
Um, it kind of depends.
So I, I did this, I did this one by itself.
I have not included links to it.
So what it gave me was for each of the scopes.
So I basically broke this out into like, they need to create an organization and
the developers would build this as like, they can sign up, they can create an
organization and then they get to this, like the root screen of the app basically.
So I had it set up this way.
Let me zoom in here.
And then I was like, okay, well, there's a second.
And I try and just pick three scopes.
It's just sort of three is a good magic number.
Start with three.
And they're kind of like, they need to be validated once they start building,
but okay, you can create organization.
Uh, you can like, I think I had managed subscription or start subscription.
I can't remember what it was.
So then it was like, start subscription.
Okay.
This goes a little bit further and you create the org.
Then you start the subscription and then you get to the root screen.
And then the third one was the like more full flow was if, if we're trying to do
kind of product led onboarding kind of product growth, like let them go through
the app, realize the value of the app faster than it was like this, most of the
app is basically like uploading a video and being able to like search a lot of
video content.
So then you would get to this and it's like, well, can we upload the video here?
And then have it.
So this is just showing, like, I broke it out this way.
Cause the way I think about it when I'm shaping it is I'm thinking about from
like a flows perspective, like these independent scopes that could be built.
Cause like I, even if it's a six week thing, I'm saying like the developers
can start on this.
Actually, we have a lot of questions on this.
This goes into like pricing strategy.
Like we got to really clean up the uploading UX for this to actually work
effectively, but they can actually start building this.
Like they actually finished some stuff early.
So they started this week on, on this.
I'm like, yeah, you can clean up some of the authentication
stuff before ahead of time.
So I'll always rail on like the flows, like the, and I'm sure
every developer on here will nod.
This is, this is the kind of the layer cake thing they talked
about in, in shape up where it's like, you can, you know, the
backend developer goes and builds the, all of the, I wired
up all the API end points and did X, Y, and Z.
And here's the database is great.
Frontend developer went and like made these static screens,
but nothing's connected.
Like all tension points in software happen in the overlap.
Like it's the integration points, like you have to make
sure those things are working well together.
So that's where I always try and figure out like blows, like
get to like the, the thing that'll give you progress is
touching all those things.
And I do that with early products too.
It's like, what are the, what are the flows that actually
they're going to go through?
Like, we have another one that just started and it's like, I
told them do authentication, but this has been spending two
weeks on authentication.
Like you don't need to cover like, okay, we forgot password.
I did this.
And all these edge cases and authentication, can they sign
up and get to the next thing and then get to the next thing?
I get to a full flow because all those, that'll help you.
You'll see more parts of the system.
You'll be able to lay out more of the code.
That's just like, if that's helpful, that's kind of how I
tend to think about, about this.
So I started from this place.
You could link to it.
We're still in a weird spot with that.
Cause I use whimsical for pitch docs.
Cause we've kind of used whimsical as like sort of a, I
don't know if you've used it at all, but it's like another one
of those that's floating out there.
They're good.
Cause it's like a notion you use notion.
So it's basically, we'll have similar overlap, but it's like
my notion replacement that I can use to sort of help here
because they'll let you embed like figma boards, loom videos,
that sort of stuff.
So what I would probably do if I felt like this was
complicated enough that the flows needed to be shown in the
pitch, then I would just embed this like fig jam as a, or
screenshot it, or just embed the fig jam inside the pitch
itself.
But Bruce, your original question, which I went way
around, this was what I started with and all I did was the
exercise to get to the pitch.
So I don't actually think none of, none of this really needed
to come forward to the pitch.
Cause I just needed to get to those three and like three
scopes and flows that I could put in the pitch.
Yeah.
Well, that's, that's helpful.
I think one gap for us is how do we like present the pitch?
Like we're, cause we're writing it for the client, but we're
writing it really for ourselves.
And there's this work that gets done.
Like the pitch is not all of our notes about the problem,
like about the project.
Right.
I mean, it can be, maybe you can have it in a sub page or
whatever, but we tend to just like use it as like a whiteboard
of just stuff for the project.
But I think there's this level of like presenting it that just
helps us like think through it a little bit more deeply.
Especially, and I think the bigger the project, obviously
the more shaped it needs to be.
So I think that that's very helpful to kind of see these
practical examples, super helpful to me.
Yeah.
And sometimes you'll want to like, you can, I mean, depend.
Like I shared, like, I just, I'll always do a loom video
talking through it.
Like, I don't just say like, Hey, here's the pitch, read it.
It's kind of like, there's so much nuance to it that a loom
video is great or, you know, whatever loom stuff I just do
that collectively is a video where you're talking through
something to get more context.
Like that's, that's always really helpful.
So like if you present it that way, and it's kind of what I
said about the whole kitchen analogy that they want the
menu.
So sometimes you have to take, it depends on the client.
If they're very non-technical, it's good to say like, Hey, I'm
going to give you like, maybe it's like a five slide deck
pitch deck.
That's just like, here's a slide that talks about the
problem.
Here's like how much time we're spending on it.
Reminder, this is what it looks like on a timeline.
And then here's like a couple of screenshots of like, Hey,
here's how we're going to approach the problem and just
give them that sense.
There's different ways you can go about it.
That's, that's awesome.
And can you like, so this, this gets shaped into some sort
of document that you then give to the client, give to the
team through, how does that work?
Once you translate it into, to linear, does that all go into
tasks to the, does the team just come up with their own
tasks?
Like, how do you guys, what's that process look like?
Yeah.
So we can in linear, they, each project has like an overview
page where you can just have like kind of how notion has
properties on there.
You can just do like a link to something.
So I'll just put a link to the pitch outside of it.
So they can just link out to the pitch.
Then it's pretty much empty.
I'll sometimes fill out.
So like what we call like the subscopes, like, so linear
we'll have a project, they do milestones.
That would be like those three I showed you where it's create
onboard or whatever it is, create organization, start
subscription user or upload video.
I would take those three and just like put them as
milestones on that project, but everything's empty.
So then they would just read the pitch.
They're going through the code and actually like looking into
the project and documenting tasks along the way.
And this would be a call out I'd have for the team here.
One thing I felt too, that's really critical to this process
is the tasks that you create should not purely be like
downhill execution.
I know what to do work like you can put a time.
actually might be critical for your team too, if you're kind of crossing over and
blending, shaping into some of the development work, hauling out, like,
like looking up documentation, figuring out a solution, those are tasks that you
should put in that notion board, like questions you have, like, they'll do that
for me all the time is, you know, like, how do we want to handle blah, like we
used to call them, like, how will we question?
So we would put like HWW, like if you've done like the design sprint thing,
where it's like, how might we questions?
So like, how will we handle.
Authentication, you know, and that'll just be like a question mark.
That is a task that lives on that board.
Cause that's great.
Cause that's like, well, Chris has this knowledge of shaping that work ahead
of time, so he can inform that.
So it's like, that's, that's sort of like what you might have to lean into as a
team is surfacing uphill work as tasks.
And the questions you have early in the process, like the way you want to think
about it, like, I think this is probably true of any feature that's above, usually
when I think about a six week feature, it's like that first week of work is very
much like, we know all the lines of the work we've identified the three key
scopes, and we know what it's going to take to get to the top of the hill.
Like what questions we need to answer to feel confident in our solution.
That's like what you have to do.
And like, if you can make sure you're surfacing those, that's been really
helpful and that's something that like, I've seen some teams, the teams that
have struggled with it is when there's nothing on the board, the developers
going deep on something, they're figuring something out, but what they come out
with at the end is like, oh, I have all these tasks now that I know I need to do.
But surfacing the thing you're actively working on, which is maybe you're
looking at documentation that's uphill work.
Like if you go read some docs and, Hey, I want to use this package
or you're validating something like that's all part of the process.
So that might be something interesting.
I don't know if you're doing that or what level of granularity
you have for your tasks, but that could be helpful if it's like surfacing.
Some of the things you're trying to figure out as from the development
side can help from a shaping perspective.
If you're kind of blending those two things.
That's awesome.
Super helpful.
Any other questions from you guys as well?
I've like, just since we've got this example, I don't know if you had something.
Yeah.
So maybe just, just one, one more stuff, just in terms of the flows, right.
Where you mentioned, uh, uh, like those flows are part, are, are, are then
part of the pitch, which is like, uh, the pitch is then distributed in three
milestones, which is each, each flow is essentially one of the milestones or.
Correct.
Or today.
Yeah.
Um, so it's not like it's three different, yeah, it's not like three
different pitches of like three different projects of, let's say one or two weeks
projects, but like one, six week project with three milestones, which is
essentially three different versions or flows within the project.
I should write.
Yes.
Yeah.
I mean, none of this stuff is proprietary.
I'll just show you guys a little bit.
I'm still like shaping this pitch, but showing in progress
stuff is super helpful.
So let me stop sharing this.
Actually, I think I can share both now.
Let's go to scare.
Okay.
So you can see at least in, um, whimsical and this is still like very halfway.
And typically like I've had pitches, I actually like whimsical has, um, where
to find it, I have like a pitch template that I've been using for a while.
I have like a pitch template that is published in like whimsical public thing.
So I have a more built out one of these, but I kind of got back to
like early stage stuff.
I keep it extremely simple and it's just like problem.
And you can see this one doesn't have deep problem definition
because I don't need a ton of wise.
I mean, so I want to call that out to like, sometimes you're not going to
have this elaborate problem statements.
And I'm like, yeah, we just know that like in order to release this
product, people need to pay for it.
So we've got to, these are the things we know we need to do.
So I don't need to go deep into the problem space around that
one, um, for what that's worth.
I always put this in here and I like to highlight it this way.
Cause if I do share it with clients, I just like always rail against the same
thing, like, Hey, this six week after that, just reminder that like this,
we're going to make trade-offs.
We're going to adjust the scope so that we can stay within this timeline
while solving this problem we just identified up above.
So, um, Xander to, for your question.
So yeah, I took those three things like, okay, create organization.
These are how I'm breaking out the solution.
So one thing I would call it, like I always do this.
Cause again, I've been thinking about it from a development perspective
and I'm saying, okay, what are.
Three scopes within this larger feature that are independent.
Like we could ship this to production, even if it's behind a feature flag,
whatever you could ship this to production independent of the other
parts of the work and it's good.
Like that's the way, like that's the mental model I typically have for it.
I'll break that out.
So that might be a good kind of tactical thing for you guys to do is like, if
you're technically looking at the shaping work, it's like, maybe you're
starting to think about like, well, how would I break this out to actually
ship this and deliver it?
Like, what would I want to do?
So like when I create the project and linear, I'm saying, here's a milestone
man, a subscription of the milestone.
And then this upload video one is a milestone, you know, and I was still
working through what this could look like, but I try and think about it as
like, how can we make.
forward progress on each of these pieces and break the work down. And then I'm doing some
technical work here. So you can be like, I, we use clerk for authentication for this app,
they have a whole component that will be pre-built here. So I can, I'm doing some
technical de-risking on it and kind of looking deeper, like, well, how can we use this? Okay,
Stripe, we got it on that path. I know we can use like a managed Stripe page for this. I kind of
have enough of those pieces in place, but yeah. So you're basically, what I was showing you is
like, it breaks, it's still one project, but one appetite. And then those individual bodies of work
are what show up in between. So that could be a good collaboration standpoint. It's like,
you're from a technical perspective, what, what are the big, and that's actually, I haven't gotten,
I did my own kind of technical de-risking, but I'll send a loom to developers and have them
kind of think through this and just like, do you have any call-outs on anything that major
that would come up? But there's never, I mean, I think what I want to call for you guys is like,
what you're doing, like where it feels like things are blending between both is totally
fine. And I think that's natural. And I don't get caught up in, is this thing a hundred percent
shaped or not? Cause I just think there's, there's always loose ends and you can lean that into the
work, but it's just like, how do you collaborate to resolve those and trade and make the trade-offs.
And that's really where I always emphasize, like if everybody has really good context up here and
this problem definition, then, and you know, the constraint that you're operating under,
everything down here is malleable. Once you're in the process, you just want to do your best
job during shaping. And sometimes you'll miss, I've had somewhere I'm like, totally miss.
Like we had to rewrite this part of the API, totally missed it. And it's like product maturity
changes. So the reason I'm lighter with these is because it's a new product we started building
six months ago and we just got it to beta and now we've got to release it next year. So I'm
just, it's a little bit newer. It's can be more fluid typically. And that's kind of the use case
for it. But I can dig up more specific examples here, like way more built-up pitches. I have tons
and happy to share things. It's helpful to see it kind of in progress. Cause that's kind of where
like, that's where the, it's the messy middle of all the getting it from, you know, from the idea
to kind of in progress, then obviously it gets kind of comes out the other end nicely. But I was,
I like, I'm just thinking even on the payment side, like, or the stripes I've made on number
two there, like you've, you could easily go so much more details because I'm thinking like,
oh, they can choose a selection of subscription. Like that's like, what is the selection? What is
the pricing? Is it annual? Is it quarterly? Is it, you know, weekly? Like what's the billing?
So where are those decisions made or highlighted? Or is that something that goes into linear
later or something that we like create a list of questions for the client or like,
how do you deal with that kind of level of detail? Yeah, no, that's a great question. Yeah. So that,
this is a good example of that. So I kept thinking about it. The way I pitched this to the client was
we need to, like, when we talked about, and actually, I don't know, you can see there's
open questions here. Cause I, they talked about this idea of like, okay, they upload the video,
they have this giant content library. It's a church that we're working on. They have like
this giant content library of like 30 years. The whole product is basically built around,
like, can we do like AI kind of semantic search to find like specific piece of the content areas
in videos where you talk about content? So the benefit here is like, okay, well, if they can
upload a video as part of that process, cause like what you want to do in the onboarding flow
is try and get it to have the user realize the value of the product as quick as they can. So
can you get them towards that? That's kind of the product led growth movement. So I have questions
in here just around that. I'm like, well, you know, we could go down the path of just making
this like great uploading experience per video, but are the people that are going to be coming,
the customers are going to be coming into this product actually have a deep library already.
And we need the friction for them is getting all of that ported over. Then we're probably better
off solving this from like a data syncing. And if you've seen this with all tools, like notion,
we'll have a Evernote importer and a, you know, they'll build like more importers to help bring
you from other tools. Cause a lot of it is the inertia to get over. I need to move all my stuff.
So that was just sort of like, this is the problem space kind of thing. So like, I can't really solve
it well, you know, they, they kind of lean more towards this, which I think is fine. It was like
making a good experience for like, can we make it when they upload a video kind of auto pulls a lot
of data so they don't have to do a lot of data. So that's kind of where I'm at.
They don't have to do a lot of data entry. That's fine. So getting a sense there. So like,
where's the answer to your question? Like there are open loops here. And I, the question you have,
like the tension point is always, is it something that has to be solved now? Or is, can I like
solve it now or give more context to it? Or is it something that just needs to happen?
Once we start building, like, that's always going to be the question you have to ask yourself. It's
like, can I, can this be answered during building in such a way that it will, like it needs to be
answered and it will not impact timeline overall. Like, I'm not worried about that one because
the stripe fund, like the foundations we need to build for stripe. A lot of it's like, and that's
where I put it in here. We need to make sure we can create plans on the backend and stripe. And
then if people can select plans on the front end tag, their org, if those pieces are wired up,
the pricing strategy, it won't be blocking that shift. That was always how I was thinking about
it, but there's going to be open. I think that's the thing we should.
Shaping is like you're 100% complete on shaping is very hard.
It's you're not going to have every question answered.
You're just trying to make sure that you have a pretty bounded and a rough
solution in general idea that gives the team enough that they can operate within
and deliver once they're actually like doing the work.
Yeah.
And I, and of course, like you're working with the team who can say, okay, yeah.
90% of that is these are all the uphill things.
Like how do we get them into this page?
How do we get out of this page?
How do we write that to the database?
Yes.
If we can just kind of outsource the questions, cause pricing is just one,
one of those things is going to change every week if they wanted to experiment
with sales and discounts and you know, whatever.
So that's a, I see you.
What you're saying is like, um, just basically make it like, cause the idea
was like, there is selection, meaning there's not just one, so there's
gotta be more than one option.
You've kind of used that word, um, to help define like they're making
a selection at this stage.
So all they would have to do is mock up one with maybe one or two or three.
Right.
And then make sure that there's not 10 subscriptions, right.
But all the edge cases, but, um, no, that's, that's helpful.
And I like the idea of like calling out that one question, um, in the, in the,
like a, what note we call a notion call out to whatever whimsical calls
they call one of the calls that they call it.
Call it.
Let's say whimsical and notion are basically the same thing.
Yeah.
I, um, I occasionally, I know one of the whimsical co-founders
and talk to him occasionally.
They have a good product, but yeah, they have a lot of things
where like, they don't like notion, but I'm like, yeah, you guys
also do a lot of notion things.
That's fine.
Notion kind of set the stage moves.
Like, I mean, if you look at all of their, it's like all of these
things are very familiar to anyways.
Yeah.
Um, that's great.
I think those types of things are helpful.
Cause when we get on a call with a client, they can see it in context of like,
okay, we're talking about this scope or this, you know, upload video section.
We've got this one question.
Obviously we could turn that question into a statement once
we have the answer for it.
Um, I imagine so I, this is very helpful to see.
I don't know.
Hopefully I think everybody else is getting some value out of that, but
to see, to see the level of detail.
Um, and is this, I know you're still working on this, but are there any other
sections that would still get added to this?
Like, um, yeah.
So I have like, there's a probably have a pitch template here
somewhere I could find it.
No, they're old.
Yeah.
This is, this is one that I have that I think I've used.
Like, so I, this is a more built out version of just like a templated one
that I do typically, um, or forcing kind of experience.
So there's another way you can do like for, if you come up with good, like,
like what, you know, there's a description of just like what problems
being solved, but then there's a deeper, like, why does it matter?
Like, why are we actually doing this right now?
Why is it so critical to be focusing on this problem?
Then there's also like, well, who's it for?
Like an understanding around like the person that you're
solving this problem for.
The how is where I kind of do like, does it zoomed out?
Here's like the phases of work, like some of these scopes, like, okay,
we need to tackle this.
Like these are the flows that it's going to go through.
Then I like, I do it this way.
And like, this is purely a visual thing.
I just like to show the scopes that I'm going to lay out here.
So this is the typical one I'll do.
It's like, okay, here's scope a, B, and C and kind of like
their individual points below.
This has, this is just again, placeholder, but you could put sketches.
Um, I call this area, like the swim lane.
So it's like no goes any risks and rabbit holes, um, open issues.
So this one is kind of interesting and this might be helpful for
you guys to like segment this out.
But I've, I've done this as like a, it's my working list while I'm shaping,
like there's still like open loops I need to figure out.
And these are the tension points where you need to determine.
Sometimes I leave them in there and it's just like, that's an open issue that
we need to figure out and the uphill, or it's an open issue that I need to
get some resolution to, or some confidence around before it gets handed over.
There's another way to potentially think about it.
Um, and then the last piece I have in this is I try to do,
and this was another one.
I don't know how you guys did this too, but it's like, it's really easy to
get caught in just like the, they call it like the feature factory, but it's
like, we're just turning things out.
But it's like, did that thing do well?
I think you guys have done a good job with it.
Cause you're going back and adding notes and doing it.
Notion keeps it a little bit more up-to-date there, but like what things
need to be true for this to be considered complete, a user can do this.
They can do that.
They can do this and you can go check it off and you have some measurables.
Like we're trying to move the needle on this.
So these are sort of like the flip side to the problem statement.
So it's like, we're trying to solve this problem.
Did we actually solve it based on these measurables?
So this is an example, which I can give a link to if you want to.
I actually think I haven't, I have a notion page and a notion
version with this exact thing.
So I could share that, but this is like the most built out one I've done.
I typically will just fall back into the one that I had previously, like
this very basic kind of problem outside solution, and then you can
build on it as much as you want.
But again, this is more like early product development work.
That's all.
Awesome.
That's helpful.
Sweet.
Very, very good.
I think, to me, the biggest takeaway is just like,
and maybe you could hear just since we're coming up
on an hour and a half, just some quick takeaways
from each person as well.
For me, it's just like, hey, this is really a presentation
tool of the finished.
Once we're finished shaping it and putting everything
together, this is, we have to do this extra few layers to clean
it up and present it well with clean headings, organized.
It needs to feel logical and clear.
Because I think if it's just us throwing a ton of notes
and stuff in there, it's not, we haven't really
fleshed out to that level of being
able to simplify it at the end down to explain it to people.
Yeah.
Yeah, so let's, yeah, Bruce, that was a good call out.
I'll get caught in this and enjoy it and forget the time.
But let's, since we've kind of gone,
we've pretty much gone through these top threes
or we're sort of in, we've stayed
in kind of the problem and solution space shaping world.
Maybe here's a good spot to kind of recap and like come up with.
And the way I always frame this too,
is like find some experiments, some small things
that you can test as a team, just do something
a little bit different.
Like maybe it's a new template that you test.
Maybe we talked about in this framing space,
maybe it's a set of questions that you go through
and make sure that you have a strategy for answering
those questions to try and get to the root cause
of the problem.
Like there's some different techniques there.
I would love to hear, yeah, if anyone has specific takeaways
based on what we've talked about in this problem space
and solution space, I think it'd be good for us
to get down like in those areas.
What are some things that you can tactically do as a team
to like test out, see if something works
or any aha moments you've had?
Because I'm sharing things just on my experience
and this is how I go through it.
But I would love to, I want to get some tactical things
that you can take with you.
I believe we can start.
Are you able to hear to me?
I had my microphone disconnected.
Okay, awesome.
Yeah, we got you.
So I believe my key takeaway was like,
we discussed it like how customers like to think
about solutions instead of the problems.
But I think we too are a little bit guilty of that sometimes
like in the case that it feels like postponing things
if you're not like doing the work.
Sometimes it feels like framing and shaping
are not like doing the work,
at least for me as more like developer oriented.
And the more like I learn about it,
the more I understand that kind of developing
is just like a manual, not manual
because you have a lot of creativity involved
but it's like a lot more straightforward
if you really spend your time
in framing the problem properly
and actually understanding the situation.
And it's like the example you give about Algolia
on the mail is just perfect.
It's like by just like looking at the situation deeply,
you are able to think better ways to approach the solution.
And I think this is at least on my side,
the most frequent error.
I believe I can like do a quick look and think,
oh my God, I understood everything.
I can just get to coding and open the ADA and let's go.
But I believe it's good to have like a second thought
about it and like properly reviewing.
And I think the document you just showed
is like beautiful constructed.
And I believe that's something we should aim for on the end
because if you can present your ideas clearly
on a document that's well constructed
and like easy to read,
usually that means that you have understood things properly
because if there are like too many gaps
and if there are too many like open ended questions,
this will reflect on the document itself.
Like the document will look like too open
and not like the funnel like you described it.
I feel like the shaping document must feel like a funnel
that start like with this broad thing
that we are approaching and it goes like tunneling down
until we've got this like this starting point
that we will use as leverage
for the next phase of the product building.
So I believe my key takeaways are around that area.
Love it.
Anyone else, any call outs in there?
like I think of them kind of documenting here is like spend more time in a problem space. I think
like some potential tactics could be updating the pitch templates include a checklist of questions
that you need to answer. So like that'll help like make sure these things are answered,
creates consistency across them. I think it sounded like I heard some thoughts around like
this is the pitch document. It's sort of the presented state. You know, it's hard to,
if somebody wrote a pitch document, it's hard for somebody else to come into it and understand
where it's at. You know, so you have to like understand where, where it is in its life cycle.
But a lot of the thinking lives outside of that. So there's other artifacts that need to be called
out and that can be updated in the template. But, and then I had another one, but I think it's
actually related more to what you're not, I said just about, I think the scopes and kind of like
the funnel. I like the idea of the funnels. Like you're starting with a big, the appetite is the
big part, but you're trying to create a good funnel in the pitch document itself. That makes
a lot of sense. Hey, I want to go next for like takeaways. I really like the thing about like
presented state, like make it presentable because that gives a like what to work towards.
Cause sometimes like if I'm shaping, it's a bit, I go with like developer perspective, like, okay,
like how technically should it work? And I like the idea of like figuring out how it should work,
should be like in a task that way it can like neatly separated. Like I can like do all the
research and cause I finally put too many notes in the shaping. Like I go too detailed, but that's
like really nice that I can just put the technical details and like basically the architecture
outline. And I could like link from like the shaping. Like if you want to see technical
notes, go to this page. So that makes it pretty neat. And I think I had another takeaway.
I like what you put, like the issues and the scorecard in your like template,
because I find like what, what do we, the way we do, it's like kind of like the work before,
but you keep updating your shape to like your pitch as you're working on it. It's like, it's
more of like living documents, like what happened as we were building, just be aware of these issues,
still like front-facing, be aware of these limitations and like what we ended up being
building a bit differently, but we think it's still addresses your problem. So like
all of that is like still surfaced. And I like the idea of like Loon videos to be like more
accessible to clients. So, so a few good takeaways, feeling good about it.
Hmm. All right. That's awesome. Yeah, exactly. But just on that note, like
it, it relates to my question before, right? So it's more of like this perspective of a living
thing as a, as a, as, as a, as the project goes on, right. In terms of solution, but actually,
so the problem part is the one that actually has to be more or less fixed before starting,
but actually the solution part is a living, is a living creature as, as you go by. Right. So yeah.
And I think I had one, one more. Oh yeah. By the way. Yeah. On that note. So for the problem part,
right. I know in our template, we have just like a simple, simple problem section and that's it.
Right. I think your template, the, the, the robust one, right. The, the, the, the longer
template that you showed, like you had the first three sections actually focusing on the, on two
of them on the specific, specific of, of the problem. And then actually for whom we are solving
that problem. Right. Right. So I think this could be, this could be helpful to add maybe to our
process, like try it out just for, for maybe because that, that helps us then maybe also
think more in terms of flow, because if you're not, who are you solving it for?
That's easier than when you are imagining the flow essentially, as you go by what's the important
thing to solve first and things like that. So yeah, it was those two things mainly.
Love it.
As I was reading through your, well, reading through, you showed your template for that.
And it reminded me a lot of what we did for Bruce, for X tech, for that kind of encyclopedia
approach. And I remember the feeling, the glossary. Yes. Yes. And so what I like to do was kind of
linked, right. And notion, you can link different things just by clicking on them, like hyperlinks,
right. And just going back and forth and quickly seeing, okay, I see how these pieces relate.
That's kind of reminds me of how this is written. It's written almost like a, I don't want to say a
product description or manual, but pseudo, right. Saying like, this is calling this thing into
existence. Like it's actually working this way. The user should be able to do this, this, this.
And I think that I remember when I was putting that together
with Bruce and with Anna, it was very much of a,
your brain sort of said, oh yeah,
I didn't even think of that,
but because I'm actually writing it out in long form,
like the Jeff Bezos kind of Amazon approach,
it's triggering these thoughts,
and it spawns other things for me to think about,
other things to link to,
and kind of making those kind of linkages in your brain.
So I think writing out long form,
spending more time with it, sitting with it,
and even breadboarding a lot of it, right?
Because I don't think we do a lot of that,
at least on the agency side.
We might make some short sketches,
but I really like how you use the sticky note kind of thing.
It's so simple, right?
Just kind of put it together and, oh, this links to that.
It just makes more sense, right?
And not just one breadboard,
but different competing versions saying,
well, okay, this is good, better, best,
or this is one way of doing it, here's another approach.
Gennano might say, why are we doing it this way?
We could do it this way, it's more streamlined.
So I think having it more visual,
spending more time with it,
and writing long form really helps, right?
It takes more time,
but obviously you get better at something,
it takes less time, and it's still got the value.
Yeah.
Sorry, I didn't want to, go ahead.
Gennano, I don't know if you were going to add something.
I don't want to cut you off.
I was just going to say that I totally agree
on being more visual.
It's like this idea of connecting ideas
and having these competing versions is just awesome.
If we are able to implement more of this on our workflow,
I believe it will be very great.
Yeah, I love that.
I think that actually, now that I'm thinking about it,
that's something I would definitely call out.
Breadboards and sketches,
I think the pitch thing is,
there is a lot of, somebody wrote it,
you've got to read between the lines a little bit.
You have to try and infer a lot of meaning,
but when you get into breadboards or sketches,
when it's more visual like that,
you were kind of all on the same page.
You're looking at it like, it forces,
when I show that flow, it forces me to think,
this is the screen, these are the things on it.
It goes to this when I click on this button.
It really gets you out of the pitch.
So I think this presented state idea
feels like it might fit better
with how you guys are more collaborative with one another
and all viewing across,
getting more into that breadboarding.
And the breadboards, they mentioned it,
but it's just, find a technique where you can just lay it out
and kind of see things more visually.
And that's a great example,
because I tend to show with the developers,
I'll always, I'll give them the pitch at the end
of like the presented thing,
but if I'm working through some nuances
that I can't solve technically,
or I need their input on,
it's a sketch or a loom video walking through a flow,
it's flow charts or sketches.
So I do really believe that's a good place to start from.
It's just, can you get into more visual work?
And that's a fun process.
I come together and like,
hey, read this doc versus like,
let's look at this visual together in a FigJam board.
You can have a good like shaping session around it.
That can be a lot better.
So I definitely think that's worth experimenting with.
And toward the visual perspective,
this is something I noticed I was doing
more in the reactive work about bug fixes
and hey, it shouldn't be like this,
it should be like that.
I'm trying to put more of those things
into the actual feature work.
So for instance,
we were just having this discussion the other day,
Janata, about how do we make this profile section
of the app work better?
And look better and be more functional and more streamlined.
And I literally just went to Twitter.
I went to, I think, Instagram, other things and examples
and saying, hey, they got smart people working here.
They did this already.
And I would just go into Skitch or into CleanShot
and just like, dude, do it like this, right?
We don't need this button.
Just make it over the profile photo or whatever.
And it's instantly recognizable
because we all use these apps, right?
Instead of being like typing it out
and it's like a three bullet list.
It's just, it doesn't, it's not as evocative, right?
So call outs and kind of not just sketches,
but screen grabs beg, borrow, steal
from other successful applications
that accomplish our objective.
It's like a picture's worth a thousand words, right?
Yeah, I mean, what you're talking about,
it's a mental model too.
It's like, if you show somebody,
that's why I always say,
when people describe like new products,
it's like, it's like Airbnb,
but for, they'll pick some other org.
It's because you just take a mental model
people know about and you apply it.
So I do think in this process it works too,
because you're trying to take something
that's existing today.
This is all, we're all remixing stuff.
I'm sure as you're building products,
like we do it all the time.
It's like, all those flows are things
that have been done before,
signing into an app, creating an organization.
You can find the novelty
and some of the innovation points in there,
but they're still good.
The mental models are useful in software
because customers are used to those same things.
So that's why like, Instagram did stories
and then all these other products started doing it too.
They're all very similar UI patterns
because they're building off
of that existing mental model people have
and then finding their own little ways to remix it.
So yeah, I think more visual,
it sounds like more visual is definitely a big theme there.
And then Chris, while you were talking,
I wrote out, this is another one I thought about earlier
just too, with some of the...
i'm looking kind of catching up on all the chat stuff you guys been adding and like i think
writing those figuring things out kind of uphill to do's or trying to like how will we like the
thing you can do in notion that's cool too is like if you're if you could i don't know how you're
doing it with the task but even if you like tag something i think the thing i'm trying to call
like as a developer if you're documenting something it's good to flag the things that
the person who shaped or like still needs some thinking could kind of come in on that can help
a lot and that's i always call it's like raising the flag it's like all right so like what's the
bat signal for somebody on my team i always tell them like here's how you do it like if you create
a to-do for me and it's like that's the question you give me the context i can go and like okay
that's a great call every time it's like yeah i missed that that's a great call out but here's
the problem okay let's try this and then we talk through it but if you can surface those things i
think it'll help a lot because it is like it we our mind are very like well execute on it what's
the downhill work but you can you know we need to figure things out and seeing that again visually
seeing those to-do's might be really helpful let's see who else any other from kind of on
the framing shaping side any other tactics takeaways that i have not captured at least
i definitely this would be something for 2025 but i would love to like just mess around with linear
as well because it's always fun to play with the new shiny object
so i could show you any linear stuff too if you're just interested in that we can also do that a
separate time i could show there's probably some areas i've had to do because i had to onboard all
the teams to it i'm the tool person so i have to like onboard everybody to the tool teach them how
to use it make sure our process fits which again like the whole the shape of things here is just
like i mean fundamentally linear is no different than most other things it does the same fundamental
things i think the thing you might like about it that i call out that i've found useful is it does
a lot better job of taking it taking the thing from like it starts here and it stays all the
way through and it just changes hands but you see it as like one continuous flow that's been really
nice because it's like all have a body of work like that subscriptions is on a timeline and i'm
the lead shaping it right now when i'm done i'm going to just give it to a different developer
i'm just going to sign them to the lead and i'm going to change it to building and then it's on
their plate but it's all and like the pitch is there and it'll go through the whole and i have
you know we complete the milestones we do like a loom demo on each of them so it's a good product
i mean they built a really nice one but yeah i like notion too so yeah and like you're either
adopting some some of their workflow but then like the way that you guys are using linear is probably
there probably some insights there as well which could be helpful because also you're breaking it
you have multiple projects across maybe multiple clients it's all in the same like you know how
are you organizing that to kind of see it at the right level but yeah we we've definitely
hit some growing pains on the i think on the tech that we've got like the tasks are a lot to track
in notion we tried to simplify it and it kind of worked and i feel like we outgrew it at some point
so as far as like i think tasks could move to linear and the pitches obviously could stay
and the projects could stay in notion as far as like how we're doing that but sweet that's good
yeah and i i put i'm sorry just looking through chat and i'm also seeing some of the conversation
that is helpful too i think like there was a question around like bruce you said questions
the tasks and notions helpful clean up the pitch area and then you guys talked about decisions and
that was that was a very important call out too if you just focus on the execution focus tasks
those are the result of the trade-offs you made so like you're saying i decided we're going to go
this route so i created a task to represent that so if you don't document like the question you
were trying to answer you do lose some context so like that conversation i was talking about like
context is king like the thing that will save you is understanding those changes over time
especially if you're doing maintenance work down the line i can't tell you how many conversations
we had like the development teams were like i know we made this decision for a reason we had
a long conversation about it but it was six months ago eight months ago we cannot for the life of us
remember what it was so whatever your breadcrumb trail is i've even with this project i'm talking
about i have a spreadsheet called a project log and i write a it's either a discussion a data point
or decision and i just create a line every time and a lot of it's like on the client side it does
have kind of your cover your ass sort of thing too is helpful but i do have that in there because
it's like we agreed over email to do this they said the priority is this decision was made here
so like wherever you want to put it but i think you can naturally surface it through there and
that's how you'll really get better about trade-offs and you'll also get better at identifying what
trade-offs there might be so i think that's where shaping gets improved over time but it's like you
have to build that muscle i love that decisions made thing we did when i was a consultant we
literally had a log of that it's like a it's like a change log right it's like who proposed it who
approved that and what we're doing instead what was the trade-off list i like that yeah i know
you had like a decisions log actually in the git repo for tribe and so
And again, it's one of those things we're like,
oh, maybe we should bring that back
now that you're interested.
Yeah, I remember this was like a developer
really centric focus.
Like what we're talking about is like more on the product.
But yeah, it's like, what was it called?
Architecture Decision Record, ADR.
But again, it's like a good habit,
but neglected somehow, so we just stopped doing it.
Yeah.
Okay, there's a lot of good takeaways here
and tactics here.
I wanna, I know acknowledging time,
like we're coming up on almost an hour left,
which is fine.
I think we should spend time on kind of building
and that phase here.
But I do want to, we can also take,
if everybody wants to do like a five minute break
and then we can top of the hour,
circle back, buy a break.
I know we've been going strong for a while.
So we'll do that.
And then when we come back, we'll do,
and like, let's go through the building phases,
talk specifically about putting those features
and then try and make sure we get some of these takeaways
and the next steps and then like an additional Q&A stuff
that I can answer and help with.
We'll do that.
So just top of the hour, we'll come back.
Awesome, thanks Drew.
Thanks everybody.
you
how's it going there sorry i had my speakers turned off i don't know if you
are saying anything no it's been great so far so appreciate you taking us through it
no of course like i said this is it i didn't have like a strict like i had this like rough
format but it's like let's we'll go where it needs to go but hopefully everybody feels like you know
there's stuff to call out or i can share examples or see examples you have and get into the more
nitty gritty which i think in the building spot seems like we have a lot there i think in the
where we got to from framing and shaping so i feel like in this building this is a good space
maybe get into some of the details of like what does it look like a notion how do things flow
through and um get a sense for that and like these are you know how this happens like picking what to
work on who works on what make sure you know time tracking i guess will be around like the reactive
and maintenance work and then you know trade-off decisions and actually who decides that how that
process looks so got a lot to get through but we can do it yeah that's good and i think just
having us focus on this for you know intense time helps us just get clarity and talk about it
first just being uh in in the day-to-day um so it's good good exercise yep yeah no actually
while people are still trickling in or anybody who wants to get like the only thing i didn't
really cover i'd love to hear is just like in general like what are the you talked about the
monthly cadence but like team rhythms so it's like we like or i'll give you an example like the way
i think about it is you know there's got to be some sort of like betting like the idea of a
betting table people come together to review some work and figure out what to work on there's like
the plan the cycle plan it's like all right here's what we're going to work on this is who's working
on what and for how much time links out to the pitches or whatever the work is going to live
there's like the kickoff i'll do typically the team it's like let's all look at all the pitches
and walk through all the work um like a retro where you're like after the end of things so that's
like what are the rhythms because that also might actually
help in the building phase.
Like if there's, if there's something that's consistent or if it's
different on both sides, I'd love to hear how that works.
Yeah, I think, I mean, we definitely, one takeaway is like, we got to
figure out a good cadence, like monthly.
Like that's one takeaway for me was like, we, we have kind of let the
clients dictate that cadence because it, they worked in months and they
have monthly payroll and they have monthly expenses, so, and then we also
do, so we've kind of just set our billing and everything to match that.
There's probably, I mean, it's just to keep it simple, but it's not saying
it's impossible to do six weeks on and then two weeks cool down and then go
back into projects and kind of break it up that way, it's just a little bit more
admin on our side to maybe like, let's say build four, four weeks and then
build the next two weeks or so.
So we might have like less consistency month to month.
So there's some trade-offs there for us as far as like trying to keep it simple.
The main thing though, again, to go back to the problem of this is that we do
need to have some margin for sure.
And I think even a three, like three weeks and then a one week kind of reactive
stuff where things are getting ready to get shipped and then you kind of start
the next month again, could work.
That would be a lot of our projects are two in one week.
Like we're kind of stuck in that two to one week spot.
Um, so I don't know.
We'll, we'll have to see.
Yeah.
Okay.
I mean, which, and if we get into this, like I can totally help with that
cause I've done that with so many different random cadences and trying to
figure out how it lines out, like we wanted to look at it if there was like a
specific example, cause that could be helpful.
I think the, the thing I always recommend is like make a small step change.
So even if it is just like, you're going to try a three week, three weeks on one
kind of cool down.
And I don't know if you guys have this problem, but we keep hearing it's like
cool down was like an interesting language choice, like in the product
space, it's cool to talk about, but like with clients, like, what
do you mean you're cooling down?
What are you?
Yeah, that's not your, so you're not, you're not working, but you still have to
pay for it, but the funny part is you actually end up doing like, I always say
like my, my work is like the cool down is where like most of the work happens.
It's like, I feel like it gets a little bit calmer once the cycle starts, I'm
kind of looking ahead and that's, that's fine, but it's really like a ramp up.
So, I mean, you can just change language.
I tend to just say like, we work in four, you could say we work in four week cycles.
How you break that down.
It doesn't really matter.
It's just, you know, we're going to lay these things out this way.
And then fixes and improvements is your, it's like, or the product.
So for the features to work well, it's like, you're going to have feedback.
So we're going to release it.
And then we're gonna have a week where like, we're cleaning up those things and
getting ready for the next round or something.
We do have like a project called, it's just called reactive work, like
for tribe or for each client.
And so these things are just stuff that kind of accumulates.
They're just a bunch of random, small things.
So that's, we've kind of, we've actually talked to the clients like that.
Like, Hey, this is, we've got these two weeks in for the month, because
this is what's going to cover, you know, 50 hours over here to just
do a bunch of stuff that comes up.
So anyway.
No.
Okay.
So it sounds like that's, that's part of the rhythm.
So is there any, like before the work starts, is there any like official
kickoff or the team's kind of reviewing what that work looks like?
I mean, no, not, not really.
Uh, I don't think we've done, I think we've tried to get in the cadence with
like, Chris and Janata have the most consistency because we have like, we're
on a set four or five weeks with the client each month.
And so we're trying to get it to where like, Hey, we're already shaping stuff.
It's kind of set by like the middle of the month.
Clients like approving the work for the next month by that, you know, then that
way there's a good week or two of margin to talk about it, kick ideas back and
forth to that by the time December 1st rolls around, like we're ready
to rock with the, with that, that project.
Um, that's the most we've been like ahead of schedule.
The other stuff, like it tends to kind of just be, um, a little mix of
shaping and all that stuff together.
So we're still, we're not quite as disciplined on, on tribe,
but we're working on it.
Okay.
Yeah.
No.
So I think that might play into that.
If you get that little bit of margin, that's probably the spot where you'll
be able to do more of more of that potentially coming together.
The kickoff thing that's been interesting is like, if I have, if it's a bigger
team and everybody's working on different features, it's still a good place for
everyone to review all the features at once, because that happens a lot where
it's like, well, some developer actually worked on this part of the code base
previously, and they can share some knowledge or this team finishes early.
So like you get some synergy there.
At least if you share across both teams can get a sense for all the
work everyone's doing at once.
So you could probably do a combined one.
What does, you know, January, 2025 look like?
Like you kind of have like a, if you're coming up on it, like the end, last
week of this year going next year, however you want to line it up, looks
like some sort of, and you can figure out what the cadences are, but that's
just the example for that one.
And then what about with like a, is there any sort of like retros or reviews
that happen more officially, or is that just sort of ad hoc?
talk kind of when they can.
Yeah, we do need to do more regular check-ins.
We've even been talking with like Lucian and Janata,
doing like a tech check monthly, kind of just syncing up
and seeing, are we using, just from a tech standpoint,
are we being consistent across the tech that we're using
and processes and all that?
But yes, we do need to do some review as well.
So that is saying that the review and sort
of the prep for the next cycle would be in that cool down.
Yeah, so we'll typically do like,
I call it one's just like the team retro.
So we get everybody together, talk about the last cycle,
how it went, like learnings you had,
some things that you can experiment on in the next
cycle.
So that's a good way to get in a good feedback loop.
And it's like, you learn something cycle to cycle,
project to project, so you can kind of implement things
as you go.
And then you would have like a cycle kickoff,
is what I call it.
But again, you could combine those.
It could just be like, how did the last thing go?
And kind of like, let's prep for the next one,
like make it more lightweight.
Because I've also heard some of those.
There's lots of artifacts, lots of meetings.
So if you sandwich too much stuff in there,
it can get a little bit, be a little bit too much.
So it might be worth, again, find
your expression of what works.
But maybe it's a touch point, really.
It's like everyone can review the work
they're about to do together and reflect on the work
that you did to learn.
Like those are the principles that you're
trying to adhere to, if you can experiment with that.
So I think this would probably lead into that.
If you had more of a experiment with some sort of one-way
cool-down, it's like try to have some,
maybe just introduce like one something,
some one kind of rhythm for reviewing work and looking
ahead and retro, kind of looking ahead at the same time.
Let's throw that in here, at least as like an idea.
That's like a retro, so that was really like a review.
Yeah, let's not use retro.
You can't use too much agile language in there.
Yeah, yeah, yeah, I know.
That's true.
Experiment with it, like it was like review meeting and that.
We've been traumatized, as you can tell.
Oh, I know, yeah.
Well, if somebody says sprints, I just, you know,
my skin starts melting.
So I try to avoid it as much as we can.
Velocity, it's OK.
We've all been there.
It's fine.
OK, so that's helpful.
So I think, yeah, that's another one I call it,
because I think I'm big on figuring that out, too.
Like what are the rhythms?
And you don't want it to be so overwhelming,
because like, you know, in the or for in this building phase,
too, obviously, we've talked about like the critical thing
here is that like this work is hard.
It's cognitively demanding,
especially if you're handing over work to developers.
I think about how to break it down.
They got to write tasks.
They got to make trade off decisions.
All these like little hundreds of tiny little decisions
are happening while the work's going on.
So focus, uninterrupted focus work matters,
especially if you're kind of shrinking it down.
It's like we got three weeks to go against it.
So just it's the constant tension you have to be mindful of with that.
And, you know, Lucian, I know you talked about like tracking deep work.
It's like I'm a huge fan of that.
Like, make sure it's a good thing to track like that.
Probably the best leading indicator for like development work is just,
you know, like, are you getting at least like three hours of like consecutive,
you know, unblocked, you know, pick a metric, whatever it is.
Obviously, it could be more way more than that.
It's like, you know, six hours or like whatever works for you.
Are you getting those stretches each day and having some metric
you can track is really helpful.
And that's usually where I start with most teams is if there's
delivery problems and it's not because of the shaping or
anything happening within like the technical side, then a lot of it's like,
well, are they like blocking their time or actually getting time to do the work
or maybe where the daily stand up out of the world is awful
because it's just you're segmenting someone's day.
It's like, well, I'm not going to start work
because at this 15 minute window at 11, we're going to come together
and talk about problems when they should already have been surfaced yesterday.
And you can work through those.
So just, you know, you got to find a balance,
especially like with remote, with async.
You can definitely find that right bright spot there.
OK, so then what about like a
bedding table is kind of.
An interesting language, but how does that come to life,
I guess, with like with clients and then we're just we're working off of.
The initial specs and kind of just aligning with them as we go,
is there anything official happening there where it's like, hey, here
they're the pitches for this next block of work, right?
It seems like it's a tighter window with these months,
so it might not happen that that specifically, but talk me through that.
It's good, I mean, for I can like Chris talk about the agents,
but for tribe side, we it's we're kind of a combination of things we want to do.
It's stuff that clients have sponsored.
So we're sort of presenting, you know, hey, here's the baseline
of like general reactive stuff that we're covering.
And here's some of the things we go into specifics like bugs
and things that they're needing fixed if they want to see that level.
And then it's just high level like features that we essentially
because it is kind of like from our stand, from a business standpoint,
it's also the sales pitch portion as well, where basically it's
it's basically getting them to sign up and renew for the next month.
what they want. And maybe there's better ways to do that.
But they're essentially like pitching it, we're getting them
to agree that they understand what they're buying, we go into
the next month. So that works pretty well, because we've
really got like one or two clients that are typically
sponsoring stuff on tribe. And we're just kind of their
sponsoring features, but we're also the product owners. So
we're deciding like, if those features should even be
presented. So we're trying not to give them like, here's a menu
of 10 things you could do. We're like, we really want to build
this one thing. Do you want to sponsor it? Or else we end up
with like, kind of a Frankenstein app. We're like,
oh, we need Salesforce integration. Now we need this
thing. And now we've just like built it in 17 directions. So
we've gotten more, we've been guilty of that in early stages
where it was like, this client wants it, we throw it in, like
we just do it. Now. It's a little bit more like, oh, we'll
take that under consideration and see if that's something we
want to do. So
okay, that's helpful. Any nuance on the agency side, Chris, that
you could add?
I think it's interesting, at least with one of our clients,
we usually get more reactive work, but sometimes it'll bubble
up and say, actually, this isn't reactive. This is a completely
new, you know, feature request that we need to think about,
right? And this is way bigger than just, oh, yeah, just make
these few changes here, this 17 small changes, you know, and
really, I think it goes back to us needing to be asking the
five why's, right? Why? Why are we doing it this way? Again,
you know, this is a departure from what you did before, you
know, and sometimes we'll get a really good, like a loom video,
right? And they'll say, Hey, this is why this hasn't been
working. You know, we tried this, we thought about that we
asked people in our, you know, in our cohort, and here's what
they're saying. And here's why we're articulating it this way.
So that's, that's rare, though, right? Because that's usually
something that we'll uncover, if we ask the questions, instead
of getting it to respond today. I don't know if I answered your
question, though. Did I touch on it?
Yeah, no, that's helpful. Yeah, I think I'm just trying to get a
sense for like, this is where this is exactly like we talked
about where it's, you know, make bets, work in cycles, I don't
say, you must have a vending table meeting that has, you
know, because it's, you're operating in similar nuance that
I am where there's a agency clients, there's SAS kind of
size, and there's different stakeholders involved. And it
sounds like it comes in different ways. But you're sort
of having an internal discussion just on, you know, prioritization
and what work should occur.
We are. And I think one thing I identified is I certainly need
to be having more regularly recurring meetings with our
clients to kind of not just get them up to speed, because I'm
talking with them directly, they know, I'm, you know, in there,
but, you know, kind of setting that cadence of, hey, so in this
meeting, here's what we're gonna get out of it. Here's what we're
gonna talk about. Here's the priorities, because what we've
been doing, at least what I've been doing, is been kind of
dropping into huddles, right in Slack and setting up in
impromptu sort of meetings to kind of put out fires and get
clarification, which is necessary sometimes. But I think
having that cadence will help us, you know, continue in the
future, have that expectation of, okay, here's that regular
rhythm, going forward on some of these things to answer the
questions, get the feedback. And, you know, of course, they
might give me something in a live meeting that they omitted
in an asynchronous meeting, because they were just focused
on getting a message out, you know?
Yeah, 100%. Yeah, I think the reason I touch on the rhythms
thing, I think they're so important, is because they can't
they become a forcing mechanism, because especially if you set
them as recurring, and I always tell teams to do that to them,
like just if it doesn't matter what the cadence is, just it's
set at recurring. And for us, if we're doing these like eight
week total cycles, it's like, well, just have at least some
hour, hour and a half session with clients. So like, I just do
a generic, I call it like product strategy workshop, like
because then you can just that can be whatever. So I kind of
just have a bucket that I'll typically do, it's like, hey,
let's come together. And I can kind of move them into different
spaces, like, all right, we're kind of pulling out more
problems. And for us from the client side, a lot of it is, I
need to, once once we know what we've gotten to the point where
we know what to build, and we're kind of an iterative product
development, we, I want to try and surface, like potential
opportunities, like what should we build? What do I what should
I start kind of framing and shaping up? So I have to like
surface that from these meetings. So that's kind of one
thing I'll call out. It's like, I call it a product strategy
workshop.
And one thing is, like, Chris, I know that you're doing in the
extra example is, we, we do have like a, there's a place in
notion that has like, basically all the projects sitting there,
and kind of a rough idea of when we need to do what. So we are
trying to like not also overwhelm the client with like a
bunch of options, because we're trying to, we're trying to like
basically do the work for them, and then just get them to give
us a thumbs up, unless they were like way off base, but kind
of, hey, if we were picking the next project, for like x tech,
for example, like, here's the here's the next project we would
like to work on. And then here it is shaped and all that. So I
think
Because I think that's kind of where Chris, you,
and Janata are working to shape that stuff ahead of time.
I think getting it to this level of presentation ready,
and then presenting to them in a Loom video or something
would be great.
But then there's, I think, these strategy workshops are great,
even internally, or with the client, whichever one.
Depends on the client and how involved.
I just know some clients, the less
they have to talk to us, the better, as long as it gets done.
So, yeah.
Yeah, I mean, even like, you know,
I just, let me draw this real quick.
Like, if you had something where you had,
like, if you're operating on those, like, four-week cadence,
like, that's a good way to just look at it,
is if you try and, you want to see,
you know, we have these four weeks,
like, how would you actually do it?
Like, this was, you know, so this is like a cool-down.
These are like a, you know, build weeks or something.
Like, if you zoom out, like, look at it this perspective,
it's like, what's the rhythm that's happening here?
It's like, that's why I was calling rhythms,
because of the gift fair, like, what's the team,
the checkpoints that we're going to hit
so that we can surface, and it helps a lot.
So, like, shaping sessions are another one,
or framing, product strategy workshops
sort of a good catch-all for, like,
bringing a large group of people together
to talk more holistically about the product
and whatever you need to.
You can also, I just do, like, strategy sessions,
could be a shaping session, a framing session, whatever.
That's another good one, too, where it's like,
if you want to get into a better rhythm,
where it's like, shaping happens at a certain spot,
it forces, you're basically, like,
time-blocking as a team,
is kind of the way I think about it.
Like, if you time-block your own schedule,
it's like, I'm going to do this for these two hours, this.
I'm just like, oh, the first week of every cycle
in this kind of monthly cadence,
there is a hour and a half shaping session on X,
and that's just, like, blocked out.
Because I will say, like, those,
it creates a forcing mechanism, then,
because you know, and it'll kind of keep you accountable
on those rhythms.
Otherwise, like, the fluidity can work,
but you guys have a lot of competing stuff,
so it might end up starting,
things can get lost in the shuffle.
So just calling out, like,
that could be a good exercise to go through.
I'm happy to, you know, we could go into that
a little bit more deeply if it was worthwhile,
but, like, what sort of things, like, would happen here?
And I can try and dig up,
I know I have this, like, for ours to show you as an example,
because we have certain things that happen
in those two-week cool-down periods,
and then it's, like, by the first two weeks,
it's more of, like, the discovery stage,
and then the next two weeks of the cycle,
the product leads are doing more shaping work,
and then it's, like, the following two weeks
are kind of piecing things together
and getting final approval
and moving into bedding tables.
So, like, everyone has their rhythms.
You just have to figure out, like,
what that can look like.
So I'll try and, while we're talking,
I'll try and dig it up if I can.
Yeah, I think to kind of make it real, like, yeah,
if you can show us this kind of four-week cycle structure
would be super helpful.
And also kind of consider, like,
hey, if we use this as, like, a workshop to, like,
hey, what should January look like here?
And we obviously got stuff running in December,
but, like, hey, let's, whatever we come up with here,
let's, like, experiment with it in January
and kind of keep that in mind
as we shape and prep for January.
I think that'd be great.
And I don't know, this is old,
so this isn't super accurate,
but this would be an example of, like,
we have a lot of things in our process that have to hit.
So, like, this will be more than what you would need,
but just to call it out, and actually this one,
I think I might actually change this to, like, product demos.
But the idea was, like, okay,
in this total eight weeks,
like, what are the things that are happening?
Like, in week one, we do, like, performance pulses.
So these are just more of, like, reviews,
like, feedback reviews for team members
from the previous cycle of work.
So, like, the product leads are doing this.
And, like, some nuance for our team is, like,
our product leads are senior engineers,
so I don't really have any typical.
I have one project manager currently.
I'm training her up to be a product manager,
but in general, they're all senior engineers.
Week two, they're kind of putting together product demos
of the previous cycle.
So for us, these are helpful,
because, like, internally,
we want to see what everybody's working on,
because you kind of get siloed a little bit.
It's like, I'm a huge fan of demos.
It's, like, just demos are the ultimate.
Getting to working software as fast as you can,
like, demoing it forces you to get there,
and having those are really helpful.
We can share them with stakeholders.
Here's what we shipped in the last cycle.
You know, the whole team can kind of see
what everybody's building.
I bring together, like, all of the product leads
across all of our teams on the SaaS side,
and I try just to collect what went well,
what didn't, some things that experiments I can run,
and kind of get a good bird's eye view
of, like, how the process is being expressed
across the team and, like, where there are gaps.
Then, really getting into, like, shaping work.
Ideally, you have some time blocked off for shaping work.
Then you have time for some sort of retro,
some sort of bedding table.
This PTHM is, like, the product team health metrics,
so I track metrics on each of the teams.
So I have to, like, collect that, get the data,
like, how did the features deliver?
Did we follow the process?
Team collaboration feedback,
so some more, like, metrics-based stuff,
and that's what I've started doing this year.
Towards the end of last year, just to get a better sense
for, like, how the teams are performing.
And again, so we didn't start from this place.
We got there eventually.
I've kind of streamlined this down to, like,
I just call it the cycle doc.
So it's, like, the things we're going to build,
how they went, because we like to see,
in the product team health metrics, like,
did we actually deliver that work on time?
Was there a big scope changes to get it there?
or did we not plan the plan on time?
Like just getting some sense for that
and then that kickoff.
So you could combine, you know,
these and whatever you want.
But this was sort of an example
of what I think I had previously.
So let me bring this.
And then the four, the six weeks there in gray,
like, cause to me that's like a cool,
that's what like Drew's working on,
but it was like, what's the rest of the team doing
in weeks four to six?
Like, are they still working?
Yeah.
So this, this one was more driven.
I think I was doing this specifically
for the product leads
where they were having to cover more things.
So like, there would probably be a version of this
that would look, you know,
they wouldn't have to do.
So like, if you're building the product,
like your, it's really your schedule essentially,
or whoever's leading the product,
not like the whole team.
Yeah.
So this looks crazy.
So it's like, hey, there's so much stuff.
But for developers, I tell them like,
I'm not bringing you into much.
They're basically gonna,
it'll look more like this for them.
They're kind of in building.
So one thing you could do,
which I've seen teams have success with is like,
kind of expectations around,
if you're working on a four-week timeline,
you'll have a pretty good sense,
or say three-week feature timeline,
you'll have a pretty good sense for like,
by the end of that first week, where should we be?
By the end of the second week.
So you can create checkpoints if you want.
So you guys could do like, okay, here's where we're,
you know, there's a shaping session that happens here.
If we want to, we know the review, you know,
this is, I'm showing the wrong example,
but yeah, there's different versions of this.
Cause you should consider like,
what are they like for developer?
Like, what are they, what are their rhythms?
What is the team?
Like the shaping level rhythms
that have to happen on top of that
could be an interesting thing to think about at least.
And I don't know if that's helpful.
I see some potential benefits to like,
going to that place, if it's helpful.
This is what you guys are currently doing
in the eight weeks in, for the agency?
Yeah.
We're currently doing it this way.
Okay.
I have a lot of questions,
but more on the business side of like,
yeah, that would work.
But the only one that's kind of getting off into the weeds,
and we still build monthly.
And so we do it a little different.
I mean, we're building off of like,
like we don't do our, like we don't bill hourly.
So we'll just bill off of like a bucket of hours,
essentially on it.
But we still bill monthly and operate off of this cadence.
So we're still just building them at the same increments,
but our cadence is kind of off of that.
Okay. Gotcha.
That's good.
Yeah. Cause that,
cause that is hard to explain to a client, the like,
oh, so we're only going to work half,
half of a month this month,
but you still owe us a whole month, right?
Yeah.
But, you know,
it makes sense if they're getting value for that
and we're cleaning things up,
cause there is just going to be, you know,
all projects start out beautifully.
The Extech one that Chris,
like we're only on month two or three, I think of that.
So like, there's just not a lot of reactive stuff
because there's not actually even any,
any real users in the app besides the client,
just kicking it around.
So as soon as like you add users and, you know,
stuff and bugs and all that stuff, it does,
the reactive does build up.
So do you, is that how you kind of present it to clients?
Is that, hey, this is,
this is where we solve like reactive or bug type things.
The, I mean, yes.
Or at least with the cool down period, like here with them.
Yeah. I've shifted.
I think that's where like the cool down language
is a little bit tricky to sell on,
even though it's really important.
Like most of our team, we call it like the ramp up
because we feel like we're not really cooling down
as much as we're like doing a ton of work
to prep for the next thing.
So the way I usually frame it to them is
I kind of got away from the cool down language
because it is, there's too much nuance to explain there.
It's kind of like saying developer experience to clients
and having to really explain that to them
so that they understand the benefits of it
from a business perspective, not just appeasing developers.
So this, I usually just say it's an eight week cycle
is typically what they're, they're operating on.
That includes we're working against features
to deliver value.
And we're doing fixes and improvements work on that.
Cause the worst projects I've had experience with
are ones like I did it early on,
where it's like, let's just do back-to-back cycles.
There's no cool down.
It just, it gets really hard.
Like you hit a, you hit a threshold
where like there's just a bunch of,
there's so much instability in the product.
Like you just start getting a lot of bugs.
You just have to build in some mechanism,
find the unit that works for you,
but just communicating at that level.
I think you still can do the four weeks.
I mean, you could think about like the eight week thing
kind of works too.
Cause it's like, if you can line it up, right.
I mean, you can do it on the months,
but I guess we're not, I mean, Bruce,
we could always dig into that later.
Cause I feel like I'm not, my brain doesn't map to,
like if they don't, we don't, we don't,
those two things don't sit together, I guess,
the way we think about it.
Like we set our cycle cadence, but it's off the months.
It's like not on those months, but we still just bill,
like they pay for, so like,
I guess if we're getting into the nuts and bolts of it,
like we call it like a DTU
and that's like a differential team unit
is like a full-time developer.
So like this product I was showing you some examples of,
it's a 2.33 DTU team.
So that's two full-time developers
and then like overhead of like product strategy leadership.
That's what I'm doing.
So I'm that point.
So they just get billed this rate every month for the duration of that project, and then
I just slice up the project into whatever.
So the work doesn't deliver within those like month units, it might be across two months,
they just kind of shifts separating the payment.
And we've just made it super, like, this is the project, you pay for it, and we do the
next project, you pay for that next one.
So that could be, we could probably experiment with that, I'd be curious, but we do the same
thing, we just build by like, the week, so like a two week project has a price, four
week project has a price, so forth.
So and also, like, yeah, there are more, it's not a one to one ratio of one developer to
one week, it's like, there's sometimes there's two developers or a designer or someone as
well.
So okay, okay, well, let's Yeah, that's good.
So we, I'd be curious, whatever, like, Chris or Lucien, specifically, like, anyone really,
if you have a opinion on the each between these two, like the eight, or the four week
I first I I mean, from the tribe side, like, I feel like our, our artists are our biggest,
like, lock right now is getting work delivered on the time that we set.
I don't have a good solve for that.
But I know that's something that we've consistently, like struggled with.
And I mean, even like looking at like a three, one cadence gives me some pauses, I'm like,
we're already struggling to deliver on time.
Are we going to continue?
Like, are we just gonna make that worse?
Yeah, I guess it depends on our like, average project size, like, I think just because we're
stuck in like one and two week projects, it makes sense, like, oh, you did a one week
and a two week, and then it's the end of the month, then go into reactive, but it like
I know on x tech, it's they're sitting at four weeks, right?
So yeah, we could we could experiment with it.
Yeah, that's interesting.
Okay.
And I think this is worth spending time on.
Because I do feel like if you if you have a good consistent cadence, and then you can
figure out the rhythms that you can fit within that, that would help the team, again, that
you're all kind of in sync, then if there's specific rhythms here, and this has helped
me when it's like, all right, every in this, this was a struggle, like, all right, how
should, especially with eight weeks, like, how should you be thinking about this work?
If you're leading, and you're doing more shaping work, if you're building, like, where should
you be spending your time and these little, like, it's like kind of internal milestones
for yourself.
And if this is true, that's like, well, Chris, you know, I'm going to schedule a product
strategy workshop for like, this is part of your onboarding with a customer, it's like,
I'm going to schedule this, and we do it week one here, which is great, because then I like
these two, then it forces like, well, here are the input mechanisms for clients, it's
like, you're going to come together in this meeting, we're going to go do some stuff,
you're going to get feedback, and then you have a rhythm with that.
So yeah, I mean, there's another way to think it's like, almost like, you know, if you get
into the four week thing, it's like a there, you know, month one, it's like, well, we were
maybe not finishing the work, but then there's, because you could, that's the way I've typically
thought about it, that lines up with months, because if you get into the full eight weeks,
then you really get into there's six weeks of features, and then the two week cool down
period gets you like a clean, you know, two month.
So like, the dyno doubles what you're currently looking at.
But is there a way to reconcile the billing stuff with that, potentially?
Yeah, I mean, I'm, I will figure out the business side of it, if it frees everybody up.
So I don't take that constraint off.
It just it was something it was one of those assumptions we've just had to simplify.
But that doesn't mean like, if it's, if there's a better way, I'm flexible, I'm just letting
the team know, like, we can, we can experiment with it next year and see, see if maybe we
can spread it out.
Basically, we know we need margin.
So I think that's like the decision is like, add margin either in a one month, or two month,
or we just try it and see how it goes.
But I do think we need some consistency.
And I think once we have the cycle decided, then yes, like Chris, you go slot, what what
are you doing in like, week one, two, three, and four, like, you can kind of have like
your general map of the month or the six weeks, if that's where we go.
And same for the developers, like that, you know, I'm working on feature work, and then
we're going to reactive on week four, or whatever the split is.
So that'd be, we can definitely take that offline afterwards.
Okay, yeah.
The thing I've always said too, because this came up with a couple of teams where it's like,
yeah, six weeks, like, I feel like they were having trouble with like six weeks and picking
that as like, can we do shorter time units? Like, I think we need like a four week cycle. And that
came up, I was like, I mean, you still sit within the same cadence, you think about it this way,
where it's eight weeks, just I was like, there's no reason you can't do four weeks of features and
four weeks of, you know, fixes and improvements kind of cool down work if you want, like,
you can balance it. So I always view it as it's more of just a time box. So that cadence,
and then you kind of fit, what's the ratio that works for you and your team and keeps it
consistent. But yeah, that's always something I think the call out would be, figure out what
cadence works that gives you some level of margin, this could be an experiment you could try. But if
it's not quite enough, then you know, do you extend it some way or add additional time?
Potentially, you know, could you do at four and four seems like not enough, you know,
potentially to do it that way. But you know, it's like, if this one is
four straight weeks, can the next month be split, you know, so then it's two and
that's kind of what I thought about it was, you'd still do it.
It would still line up. But yeah, I know, that's
Hey, Bruce, I think once we get more of the projects integrated for x tech, right? Because
as you said, there are no users right now, really, you know, and we see how the system's working,
it might be a good inflection point to say, okay, we've got these four core areas, right?
Built, they work as a complete system together, you can actually have users test them to go
through several workflows, which will designate almost like use case, and test cases. But then
we could say, Alright, we're going to integrate, since we're gonna have more users, we anticipate
we're going to need more time to do reactive work. And we could have sort of these firebreak
kind of sessions, right? So it's like, hey, we did feature development, we're going to kind of,
you know, go down to this different mode, and kind of work on things that users report and
stuff like that, instead of just keep plowing on, right, potentially increasing to more bugs
and things like that, because of the code base, right. So I think that would be an ideal time
to do it, it doesn't really make sense to do that. Now, though, where we are, because obviously,
we're deep in trying to make the individual components, and then, you know, we haven't
integrated everything yet. So it might be a good way to kind of pitch to our clients, you know, then.
Yeah, that's good. And one just practical question, like, this is good to talk strategy of like the
weeks, but how do you guys track? Is this in whimsical? Is it in the Google Calendar? Is it in
linear? Like, how do we know, like, if you're looking kind of zooming out of like the next
three months, like, okay, here's, these weeks are kind of blocked off for whichever piece or
feature works happening here? Is there a schedule? Or is this just kind of noted somewhere like this,
pretty loose? Yeah, so I just posted it ours yesterday. So what I do at the end of the year is
I set the whole cycle schedule for the next year. So I post them, I give like each cycle, I come up
with a theme, and I give it like a code name for each cycle. So there's six, pretty much every
calendar year, it works the same way. If you do a week cycles, there's six full cycles, you can get
in. And then there's an end of year, I just call it the end of year cycle, which is usually like
December, which works well, too, because the team can kind of do end of year cleanup, like extended
cool down time, heavy prep for the next year. We do this across both sides. And this tends to
work pretty well. But then like with new projects that are kind of off that timeline, that was the
one I was showing you. And that's what I typically spend time on. Those are just they're set,
they're on different cadences. So they have a little different rhythms than those other ones.
Yeah. And what tool do you use to like, communicate that, I guess, to the team?
I always, yes, I design like I do like a little PDF. It's like a calendar poster
that has like the titles. It's like themes. That's just because I like to do this. So it gives me a
chance to do it. And then I have a Google Calendar that's public to everybody that has all of those
dates listed on it. And then the third piece of linear does have cycles built. And I want to have
this is not me selling linear, but it does have some stuff that are useful. They have cycles built
into the product. If I do, if I do, they have, they have cycles built into the product. So you
can do the same thing in there. So basically, like you can set start what your cooldowns are.
So you could do what in linear, you could say, Oh, we do three weeks, and then a one week,
and it'll auto create that. So it'll show Oh, and how many cycles you want to do a year. So they
let you kind of, which is nice, then you can kind of track things cycle by cycle. So it's kind of
those three mechanisms technically that we go off of. So the team just works off of they know,
since most teams are on that, it's a little bit easier. But then the teams that I'm leading are
always they're off on a different schedule. Cool, that's super helpful. Okay, yeah, like,
that doesn't mean this might be something work to workshop. So maybe we'll just put that as a
takeaway. So like,
I think we had the experiment with adding cool down.
I think also like an experiment with possibly ending cyclone.
And I think I already caught out more team rhythms and service
issues and object progress.
I think that was kind of a key thing.
Like I didn't know that this has always been helpful
for our teams to see this.
It's just kind of like to whatever
it ends up being for you.
Like if you have some consistency,
it's like a good way to think about it
from project to project.
And you know you're scheduling this hour and a half
block for this workshop.
And it's recurring every four weeks.
It sits on this first week.
And you have that time.
Maybe you just the following week is like framing.
Or both of those could just be kind of shaping work
week to week.
And then you have this fourth week
where it's more of the review.
Reviewing the work, getting the team involved,
like kind of like double checking on the shaping.
I think if you have that checkpoint too,
that might help with some of your kind of 80%
done and something bleeding in.
If you have a review point, that could help potentially.
But the other idea I thought of like kind of top of head.
So I think another good place that I'd love to hear about,
because I know this is a pain point,
just the reactive kind of like maintenance work.
And then we talked about the daily,
potentially somebody's kind of on call daily.
I would also throw out that developers
being able to give like technical input to shaping
kind of falls in that bucket to me.
Where it's like, you need to account for that.
Like they're building work,
but they also have to give input.
And I know that came up in the survey a little bit too,
where it's like, well, I'm delivering features,
but, or like I'm shaping work,
but I need Lucian to come in and like review this pitch
and give me some feedback.
But that is context switching for developer.
Like you're going totally out of the space of the problem
you're actively solving,
moving to a totally different problem to think about it.
So calling out that like on call could also mean more
than just reactive, like the bug fixing work.
It also could be like input to shaping
could be an interesting thing to experiment with.
Just a thought.
Not like that.
Yes.
Always write that down.
Just a thing.
Is there any more like around that?
So like, what's the current,
so the currently just like that board
that tracks all the work, things pop up.
Who, how do you determine who grabs it?
We just slack each other and bug each other
till it happens.
That was, I don't know.
There's no system.
Okay. That's fine.
No, we, we do have like, for trial,
at least there's a reactive project where things,
and it is, there's a lot of backlog in there.
And so we've tried to be good about like clearing out that,
you know, November before we start December
and kind of cleaning it up.
Cause we don't, we try not to assume that like,
just cause a bug was there that we thought of doing
in November.
If we didn't, we went the whole month of November
and we still didn't have it.
Like, is it really that important
that we have to move it to December?
Like being more specific, like do we discard these
or do we, these are, no, this is like really important.
We want to move this forward and that it's like,
but that is a problem because we can, those,
we have to be very careful.
Cause we've tried it to say like,
those are all task level, but very easily,
those are very like, it's right there
and it can become a project really quick.
Sometimes it's, there's just some ideas.
Like we've kept these typically say,
if it's more than a day of work, we turn it into a project.
So if it's just a couple hours,
we think we can knock it out, you know, in a morning,
then we'll throw it into a task.
But we have had tasks that as you, like everybody does,
where you're like, look up and you're like,
we've been working on this for two weeks.
There's, you know, two pages of notes in this task.
And now like, you know, they become,
it just balloons into that.
And I'll say I'm the most guilty of that for the tribe side
because it's less constraints,
because we don't, we have not quite as tied
to the clients as much.
So, and you know, like we start a pro,
we like have an idea for something.
We add that and we're like, well, while we're here,
like let's add this other thing and so forth.
And then it does turn into a project.
But I think a lot of this for me is just coming back to,
for all anyone in product for like me, Carolina, Chris,
and everybody else who's involved in like the shaping,
like we have to spend a little bit more time
on the front end, really thinking deeply about this
and taking the time to shape the stuff.
Like this isn't, there's no way
to quickly shape stuff, right?
We gotta do the work, we gotta sit there,
we gotta think it through, iterate on it,
get to version three, four, five
before it's like ready to present.
And I think that's gonna help us.
Once we get to do the work,
we're gonna basically prep really, really well.
And then at least gives us like,
with the things that pop up,
we're like very much in control of those variables
or as in control as we can be,
because we have like sort of a mass or grasp
on everything that has to happen for this project.
And we've had technical input,
we've had a bunch of different things.
So I think that's one of my takeaways.
It's just been a little bit more intentionality,
a little more time.
It's not like gonna be like these three hacks
will cut our shaping time down in half.
Like that's not the goal here.
And we actually probably need to spend much more time
and exercise those muscles.
And then it'll get faster over time.
But some of it's just doing the work.
Yeah.
No, I found what I did the exact same thing
with fixing the impairments is just what I generically call it.
Anything that falls in there is a day or less.
And then you just give it to us.
It's time boxed, or they go into it,
like, yep, way more uphill work than I
thought, then it's got to bubble up into a project.
It's got to get some level of shape.
I mean, we're shaping, like, all those things are happening,
like, framing, shaping, building.
Like, that loop happens at every level.
So even if you're just starting that work.
But another thing I thought of just sharing a tactic
that I've liked a lot, and this is the demo thing,
is for developers, it's like, every week, like, so linear.
I feel like I'm selling linear again.
I'm not.
I'm like, there's tools.
You can do whatever in whatever tool.
I'm not selling linear.
But they have this built in, so it's useful.
Just calling out, they have like a,
so if you're assigned a project, so, like, the feature you're
working on, it's like a health check
you can assign every week.
So you do, like, a on track, off track, at risk,
and, like, a text update each week.
So that's super helpful for me, because, like, I go and see,
are they blocked?
Are they making progress?
But I always say, like, include, like, a loom demo.
So, like, show working software.
It's like, demo, where you're at so far?
Like, just talk, because, again, it's
that nuance and that context that a developer can provide.
And it's such a great little breadcrumb trail along the way.
That's where I'm, like, trying to get more towards,
like, you can write this stuff out and document it,
but it's, like, loom or other tools like that.
It's, like, just talk through it and, like,
have that artifact that you can share along the way.
So I'll just call out.
I think, like, weekly demos are, like,
the idea of a weekly update.
Like, that's a good checkpoint, no matter what cadence you use.
Something like that could be useful.
And also, as a formative perspective, too,
it prevents you from having to get pulled into, like,
the, hey, where's this at?
Or, like, oh, this nuance.
Like, if you just, you surface it yourself,
again, you can plan it.
You can say, every Monday morning,
I know I'm, like, gonna review.
And I'm just big on, like,
I think the thing that I'm zeroing in on here,
just as I see all these different tactics,
is, like, if you're gonna spend, like, the highest,
like, the 80-20, the highest impact you guys could have
is figuring out how to create margin.
Because I think a lot of these stem
from not having some small window
where you're getting a chance to, like, review
and, like, do a little bit of prep work.
Find what fits in your cadence,
but that's just my recommendation would be, like,
figure out, like, how can you get a little bit more margin?
Even if you try a little bit of extra margin right now,
I think you'll, a lot of these things
will come to life through that, potentially.
Bernardo, did you have something?
Yeah, I was going to ask about the reactive work.
Do you have any mental model or framework
that you use to think about when a customer comes
with something that, for them, it's a fire?
But how do you usually think about it to, like,
okay, this can wait a little bit,
this needs to be done now,
or this even can be, like, postponed to next week
or cool down?
Like, do you have any,
I know it's probably not a clear-cutter,
but how do you think about it?
Yeah, yeah, there's never a super clear way.
I say that my general strategy has always been
you need to force the client to confirm
that this is important by telling them
what they're going to lose as a result.
So usually it starts with, hey, you're, we can go do this.
That means this is getting deprioritized
and it's going to change the timeline.
Are you okay with that?
So, like, that's sort of a CYA kind of thing.
But also, like, I make sure that, hey,
we're shifting priorities from this to this,
so the timeline's going to change.
If it's super important to them,
then they'll say, yeah, drop that, that's fine.
So, and you have, you've covered yourself,
but you have acknowledgement there.
And then I think there is some level of, like,
coaching around, and it takes a lot of effort
for a developer to context switch over to this other thing.
We lose momentum.
So I think I do a lot of coaching around, like, momentum.
Like, that's a huge part of software development.
Like, you got to get moving on things.
So you kind of just have to create,
make sure there's an acknowledgement to them,
like, that this is not,
they always view it as, like,
oh, you can solve this bug
and keep the progress on the other thing.
Like, that they don't, there's no trade-off to them.
But there's, like, you have to raise it.
No, there is a trade, there's an inherent trade-off.
We may still stay on schedule,
but just acknowledging that,
that's the thing that I've had the most success with,
at least with keeping them with that.
Perfect, perfect.
Cool.
All right, so now we're coming up on 10 minutes here.
So I'm gonna make sure I can land the plan on things.
I will give, like, a lot of, like,
we're summarizing a lot of things.
I think I have a ton of things here
and lots of templates and things I can share afterwards.
Like I said, I think, which we have it,
I think, like, adding a cool-down the margin thing.
I still think, and I'll give, like,
kind of recommendations as I reflect on it,
but I feel like.
That has a lot of, there's a lot of leverage to that.
If you can get to some space where there's some space in between things, I think you'll
be able to figure it out.
And I think that will, that will help you build rhythms that you can work within that
are a little bit more formulaic and you're scheduled, then you have those in there.
And that will help you kind of predict more of your time.
You can manage more of the on-call work.
I definitely think like the technical perspectives on shaping, cause it's kind of nice that if
you're shaping, I heard this in some of the survey feedback, it's like, well, I'm shaping
this thing and I need someone's input into it.
And I know like from a development perspective, maybe you all can't look at everybody's thing.
It's like specific areas you look at, but I also like to force the knowledge sharing
and like just make sure everybody understands it.
So maybe you pull in somebody who didn't build the feature, but they can look at it
from a technical perspective and get up to speed.
Cause they're on call that day for all reactive work and all, you know, giving technical perspectives
on anything being shaped currently.
So there's always a developer handling those to protect with time if everybody else could
be a thing.
So there's a lot of tactics here, a lot of good things.
I will summarize all this.
Like I said, there's lots of templates I have and links to other resources that are, that
are super helpful.
And I'm going to share a notion page.
I'd love to get feedback, but I also want to create a little mechanism for all of you
to like, this is a lot.
This has been three hours.
I haven't done like, I've done this with teams like internally for years.
I've never done it like externally.
It's super fun for me, but there's so many different places we can go and I'm sure things
will surface for you.
And I still want to be a resource.
So I would love to like, as you have those questions, I'll put a little database or something
in notion in the page that I share.
So you guys can ask questions.
Cause I'd love to kind of follow up with this.
I want to give you a good writeup of all the summary of this and kind of what we landed
on.
But as specific things pop up, you know, you know, Bruce and I can figure out, I can help
in many different ways.
And I'd love to, cause this is the stuff I really enjoy because it's taking the principles
for God applies to your unique companies.
Hopefully you feel that.
And I think you have, you're kind of experiencing like, Hey, we want to adopt these principles,
but like we're not 37 signals and the way they operate, they have a certain method,
but take the principles out of it and find a way that works well for you.
And I think there's some like small things you can experiment with regularly.
Cause those reviews will also give you that margin will give you a good place to check
those experiments.
Like, Hey, next week, let's try this on-call thing.
Then when that next review point comes up, did it work?
Yes or no.
Okay.
That's the thing I found to work the best.
That's how I've made the process improve over time is just having those spots.
So I feel like that's a huge part of this for you.
Okay.
So that was kind of my, I don't want to get too deep in something else, but we do have,
I want to make sure we use the time.
So let's like, are there open questions, open loops, things in your head that you've had?
That's like, we could talk there a little bit more deeply.
Any questions that have popped up along the way?
So I don't know the size of projects that do this.
I know that in my career, I haven't had a lot of experience with.
Like NPS score, NPS and all that kind of stuff.
Like, do you have clients that actually request that?
Or, you know, have you had good alternative solutions to that, or at least unearthing
and highlighting some of the insights that could come out of something like that?
Yeah.
So NPS is an interesting one because I think even the person who invented it, he ended
up saying at some point, like, yeah, we're going to like most things we just sort of
adopt it.
But then nobody goes back to that person.
Like, actually, it wasn't meant to be like this.
The general thinking is, like, from a psychology perspective, if you're asking people, how
likely are you to recommend this thing?
You're making an assumption that they're a person that recommends products to people
that they know, which is not common.
Not a lot of us are like running, like, I'm talking about linear here, but I'm usually
not like telling my mom about linear or, you know, random people.
So the question, the latest trend has been more towards the CSAT or customer satisfaction
score.
So it's just, how satisfied are you with this product or service?
So I've done that.
And that's part of those product team health metrics.
I just call it stakeholder satisfaction because we can send it to customers.
We can send it to clients.
And it's sort of the same fundamental question.
And that's just what I capture.
I try and get that once a year just to get a sense for tracking how satisfied they are.
I find that to be useful.
And I think you can use it in the product space or not.
So I've heard that was the shift from NPS to that specific metric, which does make sense.
That's good.
Thanks.
Yeah.
Sure.
Any other open questions?
I'm going to keep talking.
So do you also do, since you do have clients as well that you're building things for, do
you also do like a year in review, things you've accomplished, not as a pat yourself
on the back, but sort of like a, hey, here's where we've been, right?
Here's where we're going next.
I mean, at a higher level than, oh, here's some pitches, you know, that you can look
at.
Do you do that?
And what's been the reception to that, I guess?
Yeah, we've, I think, I think I deleted our version of it, but yeah, I think I had in
here too, that like the team once, cause I always say it's like parallel paths happening.
It's like, there's the strategy work that, you know, like you would be doing Chris.
And then there's like.
you know, the development building work, they're happening in parallel, you're looking ahead,
but they're building what you previously worked on. During that period, I tried to like product
demos, like take the product lead, it's like, go and like zoom out, like, what did we deliver?
What? And I think this is part of those success metrics, too. It's a good place to remind,
because you'll hear in the product world, there's like feature factories, where it's like, we're
just churning out features left and right. But it's like, if you're not measuring the progress
and the impact that's being had and learning from that, then you know, what's the point? So yeah,
we try and like do we haven't done it as officially enough, I'm actually trying to implement this for
next year, but doing like a product demos where it's like, can this I like creating an artifact
that that's serves multiple things. So like the team, like we can, our company can all rally
around it, because I can see what another team built and is working on, we can send it to the
client. And I think it reinforces that cycle cadence. So if you shift to something longer,
but you have a more formal artifact that you're doing to show them what was delivered in that
batch of work, it could help reinforce that, like, hey, we work this way, because it gives us ample
time to create impactful work. And that could be potentially some way to look at it. So that's kind
of been the loose thing I called it, I had it, I think, when I pasted this in, I had it as like,
stakeholder presentation was one thing. But I think product demos was kind of one thing we did.
We used to do those real time, the whole company would come together, and each product lead would
talk through it. We liked it, but it was a lot of time and energy, we switched async to them,
but then I have to chase people down to try and get them. So trying to find a good balance there.
But I do think something where you can, even for you, like, it's good to just kind of reflect on
it. I think if you have those, again, back to those margin, if you have that spot, where you're not
having to shape the next thing, or you're in the middle of the current work, you have a place where
you can figure out, can I do a demo? Can I do something, some artifact and create that as part
of the rhythms? That's good. Thanks. It's awesome. One thing that worked well, Chris, I don't think
we talked about this, but on the tribe side, we had, I had some time to like strategize for the
for Q4. And so as we came into Q4, like we had a little, I just did a little document that I shared
with Carolina and Lucian, and Macy. And so we kind of covered like, here's the just kind of
an overarching theme of it. So I think we could do that kind of forward looking to like, hey, here's
those kind of, as you were saying, like, there's themes, maybe to the cycles, or, hey, we're gonna
do this thing, we're gonna really focus on this area. But doing it at the kind of, even at the
team level as well. So I was, I made a note to myself to like, I definitely will do one for 2024,
just from my perspective. And of course, anyone else wants to do that would be great.
But also just thinking like, I think like quarterly is probably as granular as we can get,
because I think things, it's hard to like imagine everything we want to do for 12 months next year.
But if we just said, hey, next quarter, we're going to like, experiment with some different
cycles. And we're going to do, you know, this, and by the end of it, we'd like to have
our like decision on like, which way we're going with like, the cadence, the rhythms, like the
cycles, all that stuff dialed in, that just be one sort of overarching thing, just know like, hey,
we're going to experiment, it may not be the same for January as it is for February, but it's going
to be different. And then just kind of set everybody's expectations. So I think that'd be good.
So you can kind of do the retrospective stuff. But also, I think, taking a little time to like,
write up a sort of blog post of what is what's to come. I think it's helpful.
Oh, and that's actually the one thing I've liked about that. If you do the six cycles a year,
you're kind of in the headspace of like, what six big things can we ship this year, it gets you like,
it kind of simplifies the framing a little bit. And then Chris, you asked more about year in
review. But I think if you do those, whatever the cadence is, if you have those like individual
checkpoints, then the year in review one is just kind of like, reflect on everything you did,
you know, and that's, I always encourage teams to do that. Because it's, it's very easy to just
move to the next thing. You know, it's like the, whatever the achievement bias for just kind of
you get to the thing, but you know, all right, cool. I ran a 10k. And that's what I wanted to
do. Well, now I got to run the next thing, you kind of like lose that. But it's like,
well, if you reflect on like, where did you start? So I think having those, I think, again,
this all comes back to you guys can create that space that little bit of margin for some of these
to introduce these rhythms, you'll be able to create some of those artifacts.
Very helpful.
We're close on time. But yeah, I'll reiterate again, like, you know, Bruce will reconnect,
I would love that. Yeah, I'll send out I'll summarize all this stuff, because I want you
to have a good takeaway of like, here's some tactics. And then I'll give you a mechanism.
I'll send out the email to everybody. But then I'll give you a link. I have a notion page I've
been building that you guys can do get access to all this, I'll include the recording, all that
sort of stuff. So you'll have this again, I know this was a lot to unpack. But I would love to be
a resource to just answer questions. Like I'm very interested in how this expresses for other teams,
it helps me and all that. So just happy to answer more questions. And appreciate all you taking
time. It's a long three hours to go through this. But I appreciate you sharing everything.
Yeah, we really appreciate it. If you guys want to take a second, I know Jonathan, you just did
this, but anyone else just give some feedback. I know Drew can go in there and screenshot some
comments just so he can love it.
This is one of your first ones and I know you want to do a lot more of this so I'm already posting something on X with the photo. So you can use that if you want.
Love it.
But, uh, love it. So you could just drop some love in the chat would be great. But yeah, thanks. Thanks for taking the time and letting us be kind of a guinea pig for your for this. This is great. I think we got tons of value.
I've got more out of it than I was thinking we would. So this is great.
Glad to hear it. Yeah, no, I appreciate everybody. Yeah, same. Yeah, Bruce did a better job than I did. Please give the feedback because it does help me. I would love to try and do this with more teams, help more teams.
Like, I think there's just so many frameworks out there and everybody just tries to apply these off the shelf solutions, but we're all unique, like individually and our teams and organizations that, you know, I want to try and help teams like, you know, feel some like less stress and actually get to deliver work on time because it fits your natural rhythm.
So appreciate everybody doing that. And I'll send all this stuff out and hopefully everybody can take a good breather. Enjoy the rest of your day and week and reconnect.
Awesome. Thanks, guys.
Thanks, Andrew.
Thanks, everybody. Thank you.
Thanks, Andrew.
Bye bye.
Thanks.
Bye bye.
Hello.
I am sorry I came in off of me with this.