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.