Raphaël: Hey folks, and welcome to the
small tech podcast by Ephemere Creative.

I'm your host Raph.

And today we're going to talk a little
bit about how we organize our product

development processes in ClickUp.

So before we start, if you enjoy
what we do, please like and subscribe

on YouTube and give us a review
on your podcast app of choice.

We're a tiny team and
every little bit helps.

Before we get going.

I promise this is not an ad for ClickUp.

It's just, yeah, basically I want to
talk about how we organize things.

I'd love to get feedback
on how we organize things.

So if any of you have
thoughts, that would be great.

If anyone wants to join me and
talk about this sort of stuff

on the podcast, that would also
be super helpful and really fun.

Probably.

So, yeah, let's, let's get right into it.

I'm going to talk a bit
about how we organize things.

And we do that on a per product basis.

Because we work with
multiple, organizations with

whom we develop products.

And we also build our own stuff.

So we use ClickUps feature
called spaces to organize these.

I had previously seen some information
from some ClickUp consultants

who suggested not doing that but
I think they were not talking

specifically about a product
development or software development.

They were talking about other types
of work and I found one thing that

is broken if you do not do this
by space, which is that if you

connect GitLab or GitHub to ClickUp.

You have to assign access.

To those repositories per space.

So that might mean that you have
people working on different projects.

And, if they're all in one space, they'll
just see every single repository, and

the way that things are displayed,
it could get really confusing.

Like if you have an organization in
GitHub that has a repository named web.

And then you have another organization
with a repository named web, and

they're both available in that space.

Now, you've got two things of the
dropdown list called web, and it

just felt messy to have all of
these things in the same space.

So that's why we decided to
move to a per-space , thing for

products, which I think also makes
sense for the way we do things.

The way we think of a product is very
much like we're building a product, we're

building a business with our partners
or for ourselves, so there's a lot of

stuff, you might want to group with your
product development that I think if you're

organizing that just in like a folder...

It doesn't really work.

There's just too much stuff.

So we break things down in each space.

We have a documentation folder.

A product folder, which I
haven't figured out if that's

the right word for this stuff.

And then another folder called dev
sprints and for the scale of project

that we tend to work on the only thing
that really needs a full scale, like two

week fully loaded sprints is development.

All the other stuff.

Is light enough that it doesn't need
a full two weeks sprints, to address.

So inside the documentation folder.

That's where we put everything
that is a standalone document.

Something that doesn't relate to
a specific task or card in other

lists and other parts of the space.

These are things that you just
want to read as you get started

with a project, for example.

So it might be onboarding materials...

explaining to a developer like
this is the context, this is

the type of tech we're using.

This is why we made those
decisions about that tech.

It might be things about, our design
system, that we're using a particular

framework, maybe it's even design assets.

We might organize those things.

In the documentation folder.

So you can just, if you need to have an
SVG of the logo, You can go find it there.

If you need to know what colors we're
using, you can go find them there.

Of course, you'll probably find
them in the designs themselves, but

sometimes it's practical to just
have like a nice list of assets that

you can access when you need them.

We'll also put things like documentation
for larger features in there.

It might be something like search which
might in some cases be a very small and

well-defined thing and other apps that can
be really big and it might mean searching

across different types of data and in
different contexts, but you still might

need like a unifying document to explain
how we're going to do it how we're going

to implement it technically, from a user
perspective, like all of these things.

Yeah, we kind of use that space that way.

And so all of those things
are our documents in ClickUp.

And that's a thing that I find really
practical in their platform is that you

have documents and tasks side-by-side.

And, personally, I find that I
don't like how notion and Coda have

lists of tasks inside documents.

I like the in ClickUp there side by
side, like a list is a list on its

own and they have statuses, like a
list of tasks has statuses can have

sub tasks and all of those things
that are separate from documents.

You can mix and match them.

Like you can do formatting, for your text
in the same way that you might a document

inside a task and you can also attach it.

Document to a task and you
can embed tasks in documents.

But by default, they are these sort of two
separate entities and it feels good to me.

So, yeah, that's basically our
documentation folder in a product space.

Then we have this product folder, which we
have a bunch of lists that I put together.

That we often don't need all of them.

So I'm going to skip some of the ones
that we don't generally make use of.

And talk about the ones that we do.

So the roadmap one is I
think really valuable.

And so this is a sort of
Kanban style board where we're

grouping things by quarter.

And we're saying like, yep, these are
things that we'll do in Q1, Q2, Q3, Q4.

And they are bigger overarching, features,

Then let's talk about our backlog and this
might include, this includes everything.

This is just all of this stuff.

And if you're familiar with scrum,
then this is our scrum backlog.

And so it's bugs, that we need to fix.

It's features that we need to build.

It's just anything that might need
to be developed but also things

that might need to be designed.

It's a mix of all the things and
some of those things will need to

be broken down but this is where
everything gets shoved eventually.

In there we use a process called
rice, which I learned from, I think

the Intercom blog at some point.

Which I quite like.

So it's reach impact
confidence and effort.

And, that's how we prioritize
what we work on next.

So if something needs design work, we will
move that into a design list and, get that

work done and just plop it into that task.

We don't really split things up too much.

So the task moves around.

We're small enough.

And the products that we build are
small enough that it doesn't really make

sense to split things up more than that.

So then you might have a link
to a Figma file or pen pot file

in the task or sometimes just
images depending on the context.

And it'll go through UX and UI design and
then once it's ready to be taken on by a

developer, we'll move that into a sprint.

So that brings us to our third
folder, the sprint folder.

We're small enough that our process
can be, I think, simplified.

But the gist of it is
we do two weeks sprints.

Sometimes it's a little loosey goosey.

With every task a developer takes on, they
will use the lovely ClickUp integration

with either GitLab or GitHub depending
on where we are working, which is

dependent on the client and ClickUp will
generate a nice branch name and it will

automatically link as long as you have
that integration set up for the space.

You can then also create pull requests
or merge requests depending on which

platform you're using directly from
ClickUp or again, you can use the

naming conventions and ClickUp.

We'll figure out how to
bring those things in.

We try to do all of our communication
about a task in ClickUp because so much

of the process happens there anyways.

So it makes sense to have, most of
the discussions in that context.

We will do code reviews in the Git
platform we are using, because of

course it makes sense to comment
on the code where the code is.

Sometimes I think it would be kind
of neat if you could do that as

well in ClickUp, but that seems like
it's it doesn't actually make sense.

So there is a little bit of
like splitting where you work.

Which I guess isn't ideal but I
think it makes sense in our context.

And the final thing that we do,
and this is something that we use

to pay for an external tool to do.

But it's great that we have this built
into ClickUp, which is that for tasks

that are, that, have a visual component.

So if you're building UI stuff,
then, the developers will record

a video of the thing in action.

Of course, depending on the context,
we are still running things, in the

browser or on a device to make sure
that everything is working, but it's

nice to just have a quick overview
of what things look like and how they

are working in an interactive context.

So that if something is kind of off, you
can just quickly say, Hey, that's not

quite, we were what we were looking for.

Maybe we can update this
to change X, Y, or Z.

We also use Vercel a lot more of these
days and so we get those nice preview

deployments, for every pull request or
merge request, which is also very valuable

to just be able to point someone to a
URL and say, here is the functioning

thing in the browser, go check it out.

And yeah, that's basically our process.

I think the key things to take out of
that is if you're building multiple

products, You should probably organize
them in different spaces in ClickUp.

You will want to use the
GitHub or GitLab integrations.

It's nice that you can have documents and
tasks side by side and link between them.

And you've got a nice sprint system
with estimates and sprint points,

and video recording, so you can
see your features in action before

they actually get to a browser.

Alrighty.

Well, thanks for listening folks.

If you enjoy this stuff please like and
subscribe on YouTube and subscribe to

the podcast in your podcast platform
of choice and leave us a review.

It would really help us out.

We'd love to hear what you think.

And we would love to have you on
the podcast if you would like to

talk about this stuff with us.

Also make sure to sign up for
our newsletter, where we will be

sending you tons of great info
about building small tech products.

It's going to be videos, blog posts, any
podcast episodes you might've missed.

And plenty of other stuff.

So head to smalltechpodcast.com and in
that nav bar, you can see a newsletter

link, which you can click to subscribe.

So that's it for this week's episode, we
all want to do some good in the world.

So go out there and build something.

Good folks.

See ya.