How ClickUp Product Managers Use ClickUp

Erica Chappell

Managing Editor

January 3, 2021

Max 10min read

ClickUp was born out of necessity. Our founders wanted a tool where all of their work could be in one place.

This place didn’t exist yet, so we created it!

ClickUp was first created as an internal tool that we were planning to use for a completely different project. But after just a couple of months building it, we realized the problem we were solving was applicable for nearly every team and company – everyone wanted a less opinionated way to work.

We knew how hard it would be to break into the most competitive market in the world, and we knew it was a tale of David vs. Goliath.

To win, we would not only have to play catchup but also leapfrog our competitors in a way they were least expecting.

To execute on this, we decided to release a new version of ClickUp every single week – as if our lives depended on it.

Within just two years, we’ve reached feature parity with the project management software incumbents (and even won over some of their biggest customers)!

We continue to release weekly and use the same features you do to manage our release process. We’re confident you can do the same! 🚀

Here is a never before seen peek into how we ship value so quickly while maintaining a positive and sustainable culture.

It Starts with Core Values

This goes in line with 4 of our favorite core values:

Quick Wins (Progress over perfection)
Urgency
Best customer experience our customers have ever had
Grow 1% every day

Our process developed out of nailing these core values is simple:

Listen to customers’ problems
Create solutions for problems customers have
Develop and release those solutions
Repeat the process

Progress over perfection

Normally, product and design for a feature can take months of data analysis, aligning of internal stakeholders, securing resources, and UX research.

At ClickUp, we do things a little bit differently. We are 100% alright with shipping things we know aren’t perfect. In fact, we would much rather ship something that we think isn’t quite good enough to get initial feedback, and then make changes rapidly so we can course correct. More often than not, features aren’t going to be perfect anyway—and because you never really know until you ship, we want to get to the customer’s reaction and feedback as quickly as possible.

So ultimately, we do believe that perfect does exist, but only in the future. We don’t need to be perfect now because we want to ship value as quickly as possible.

Working in Sprints in ClickUp

Like many startups who are scaling quickly, we operate with our own flavor of Agile that works for the size of our team and how quickly we need to move.

If you aren’t familiar with the concept, a Sprint is a time-boxed scope of work that your team commits to. This mechanism not only motivates the team to get that work done but also is a useful tool when working with stakeholders.

We work in one-week sprints at ClickUp. Needless to say, fast and nimble feedback loops for stakeholders are essential when you only have 5 business days to solidify what is going to be released. Much of the team is able to use our Sprints and Roadmap as a way to better estimate what will be released on any given week.

We’ll get more into how Product funnels information to Product Marketing and Customer Support a bit later in this article.

Sprints in ClickUp work best when you have the Sprints ClickApp turned on alongside the Tasks in Multiple Lists ClickApp, but you can also manage your sprints without it. (We’ve been doing so up until now 😅) Both options are available on our Free Forever Plan, too! 🎊

Recommended: Sprints ClickApp

Get a detailed overview of the Sprints ClickApp by watching this video. Here are some of the highlights:

Sprints can have statuses of Not Started, In Progress, or Done, allowing you to quickly understand what the team is working on.
Add tasks to Sprints so that you can keep the tasks in their original context, like a List representing the project or a product backlog
Sprint Automations allow you to skip the admin work of maintaining Sprints by letting ClickUp create Sprints and handle spillover tasks for you
Automatically update Burnup, Burndown, and Velocity Charts based on current sprint dates

Our team uses the Sprints ClickApp with all the Automations, making it easy for us to plan ahead and manage the unfinished tasks at the end of a Sprint.

Sprints without the Sprints ClickApp

Even without the bells and whistles of the Sprints ClickApp, you can still manage Sprints effectively. Sprints are still better with the Tasks In Multiple Lists ClickApp enabled, so we still highly encourage you to do that.

Here is a glimpse of what our Hierarchy looks like without the Sprints ClickApp:

In addition to the Features Folder, we have Folders for each individual Product Manager to keep track of their day-to-day tasks. Tasks in Multiple Lists allow us to add tasks from these Feature Lists (e.g. Epics) into a Sprint. We create a task that represents the Release and relate it to other tasks for design and engineering to complete.

This Release task contains the Product Brief, which includes all the requirements and designs. The Release task is a central place to find the information they need. We relate these tasks to the Release using the task linking feature.

You could make the Release dependent on these other tasks getting done if you wanted to as well, but we just opt for linking. This allows you to add estimates to the individual tasks which can then be added to sprints independently.

At ClickUp, developers manage bugs. So the Bug Lists (Internal bugs and User reported bugs) live in the Development Space in the QA folder. Developers add pull tasks in when we do our bug sprints and Hotfix Mondays.

Coming Soon

Soon we’ll be releasing a Task Relationships ClickApp, which will again change how we manage ClickUp Sprints. When released, the tasks that represent projects (i.e. epics) will have a more visual way to display the related tasks, giving you even more information about what needs to be completed before the release.

Teams who prefer Epics to be List based will still be able to pursue that model if they choose.

Truth be told, our backlog is a little messy right now, spanning multiple Lists and organization methods (not pictured), so it’s something we’re hoping to organize more in the immediate future. To quote our core values, we’re striving to improve 1% every day.

Agile Ceremonies and Processes in ClickUp

Our sprint ceremonies are evolving as our team grows, including a bit more meetings than most teams are probably used to. Again, because we’re on such a tight release cycle, we need a ton of communication to coordinate and correct course where necessary.

Here is a glimpse of our meeting schedule:

Using ClickUp for Daily Standups

Like most teams, we have a quick morning standup. We keep standups as short as possible, addressing any urgent bugs first, then moving into a round-robin with the team for typical standup updates.

We use a Dashboard and a prioritized List view of tasks to help guide discussion for our Standups. Each Product Manager reviews the List and the Dashboard prior to the meeting to get an understanding of which tasks need follow-up.

After each developer has given a basic status update and flagged any blockers, Product asks more pointed questions during “Parking Lot” or smaller project teams have short breakout sessions.

Here is a peek at our Dashboard structure:

The key fields to our planning are:

Target Release Group: This indicates when we expect a feature to be released. This framed as a target and is also a commitment the product team is making. If we don’t hit the target, it can get pushed out, but at least we have a record in the task activity.
Backend Target Release: This indicates when BE needs to be complete to hit our intended release date.
Risk: This indicates our confidence in an on-time release. Possible values include Very Likely, Likely, At Risk, and High Risk.

This Dashboard serves double duty for our daily afternoon sync with QA as well. It’s our source of truth, where we continuously update the Risk dropdown so all teams can stay on the same page. Once we know something is at risk, we flag all stakeholders so they can correct course as necessary.

Using ClickUp To Collaborate With Engineers

When you get into the nitty-gritty of a task, you need a way to keep track of decisions made and a way to follow up on specific pieces of conversation that might otherwise have gotten lost in the shuffle.

To quickly include something discussed in a comment as part of the main task, you can open the context menu via the ellipses and click Add to description.

After we get a branch with a working version we can start testing, our QA team jumps in and starts combing through our acceptance criteria and leaving Assigned Comments with banners to help distinguish critical blocking issues from issues that are nice to have.

Here are some examples:

Red banners identify the critical blocking issues.

Yellow banners to identify issues that can be addressed in a follow on release.

All Assigned Comments are shown underneath subtasks as individual items that must be resolved to be crossed off. This makes it very easy to see which items are outstanding for a feature.

If you have the Threaded Comments turned on, it makes it really easy to have discussions about specific topics within the single task. We often have full conversations in threaded comments where we debate different approaches. Then we either add the decision to the description or we make an Assigned Comment as an action item for someone to finish. That way nothing ever falls through the cracks.

QA puts these assigned comments into the text block at the top right of our Dashboard so everyone is on the same page.

Using ClickUp for Sprint Planning & Release Management

Implementing the right Custom Fields was a game-changer for Release Management. Now, it’s easier than ever to filter down a List and see exactly what is going out. These filters are also extremely easy to update to keep our Development Dashboard updated.

Target Release Group: We use this dropdown field in conjunction with the due date to help us better understand when we expect this feature to be released.
BE Release: This dropdown field helps us manage any foundational backend work that needs to be completed for us to hit our deadline.
Planned Build Feature: Because there are stories and tasks that are not features, we use the Planned Build Feature tag to help us identify the features in the release, which helps the Marketing department identify items that need to go in our release notes.

Our Sprint Planning happens on Fridays because even with the tight feedback loops and these fields, we typically don’t know what is going to go into the release until Thursday evening and sometimes Friday morning.

We maintain an extensive backlog of simple usability improvements. So if there isn’t a big feature being released, we typically have a bunch of these in the Non-Build Blocking Sprint List that engineers can pull in when they have capacity. This allows us to balance shipping large complex features alongside low hanging fruit.

You might say, “Yikes! Releasing on a Friday is risky.”

The thing about our team is that they’re dedicated. If something goes wrong, QA and someone from the dev team is ready to jump on it. Without that, we would agree that releasing on a Friday is really risky.

Product Team Collaboration

Because we’re still a fairly small, tight-knit product team, we discuss most big features together as a group. As the team has grown, we’ve implemented some processes to help with standardizing our approach to product and helping with time savings.

Clips: Clips record complex feedback to avoid misunderstandings that can come with written feedback. This also facilitates remote work, allowing teammates to revisit a kickoff if they weren’t able to attend one live.
Product Feature Template: Using the product feature template ensures all product managers are being thoughtful about the tasks they create and are providing the design team, development team, and QA clear acceptance criteria. This template includes a checklist to help product managers stick to the established process.
Async Peer Review: To reduce time spent in meetings, we started doing peer reviews, leveraging the comments feature on the task to leave feedback. After a round of peer review where obvious things are caught, the task goes into a more in-depth product review with the broader team, including Zeb, ClickUp’s co-founder and CEO.

While these time-saving tactics help, we still spend a considerable time per week in the Product Team meeting, which covers a lot of ground.

We typically cover:

Product Brief Review
Design Review
Demos
Process improvement discussions
Prioritizing feedback from Clients
Addressing blockers and general questions

Action items are covered live during the meeting, and then we create follow-up tasks in ClickUp so we don’t lose track of what was discussed. Doing this on a daily basis allows us to constantly react to client feedback and improve our process.

Stay in touch!

Check this page often to continue following our product journey to see how we tackle these challenges with a combination of platform features and process improvements.

If there are questions that weren’t addressed with this article, feel free to reach out to our support team anytime at help@clickup.com.

And if you haven’t already created an account, go to ClickUp and sign up for free!

Related readings:

Questions? Comments? Visit our Help Center for support.