How we use Kitemaker (to build Kitemaker)
Here is a quick dive into our development process and how we use our tool, Kitemaker. Every team using Kitemaker uses it a bit differently. However, they all use work items as central places for collaboration allowing for a better way to work through Kitemaker.
We’re a small team right now so we don’t have a very defined process. However, we have some principles we believe in:
- We try to talk to as many of our users as possible.
- We don’t build anything unless we have specific users we are quite sure will use it.
- When we get feedback from users, we discuss:
- Does it make sense? Is it in our core?
- If yes, do we start fixing it in the next few days, or do we do it later?
- An item isn’t done until we have gotten feedback from our users, or we can see the effect in the data.
Perhaps not surprisingly, Kitemaker is great for supporting this kind of a process.
Above, you see an example of one of our work items where my co-founder and I collaborate. It started out with a discussion with one of our users on Slack where the theme screen’s functionality was creating some confusion. I copy/pasted the screenshot into the description. We also had a discussion in Intercom with another user in the same company who also had similar problems.
After I created the work item, I pinged my cofounder. We then had a short discussion thread about:
- Is this something we should do?
- Will we do it within the next few days?
- What are possible solutions?
This time around the discussion was short, but sometimes it can be a long thread.
In this case, the solution was simple enough, and we started working on the item right away. So my cofounder moved it to “In progress” and started coding (you can see the first commit message there as well).
As my cofounder continued to work on this, we kept the conversation in the work item (see images below).
Notice that the work item isn’t done yet. This is for the simple fact that we’re still waiting for more feedback from the users. Since this is a fix for a “I randomly do things I don’t intend to do”-type of issue, we let them use it for a few days to determine if the problem is really solved.
Our boards are pretty simple. We have a Backlog with an “Inbox”, “Icebox”, and “Todo”.
Items enter in “Inbox”. If we decide to wait to work on the item, we place it in “Icebox”, if we do it immediately, it’s either moved to “Todo” or “In Progress”
You will also notice that on top of the board, we have two current themes. These are the overall goals we’re working on. We work in weekly cycles where we each Monday review our goals, and we put the goals as themes, clearly visible right on top of the board. As a small team, we only focus on a few overarching themes at at time.
How about other teams?
Every team has its own process and way of using Kitemaker. Some write detailed specs and like to do that collaboratively in work items. Others use themes A LOT and do their planning in the Roadmap. Some have wide boards with many steps. Some do discovery work in the work item backlog and have their pre-development process there. Others use the backlog for ideation and have a very unstructured setup. Some use the backlog for sprint planning and will have columns for each sprint.
But there are a few commonalities between our users:
- Their work items are typically a bit higher level than issues and todos for similar tools.
- They write more, and keep more content in Kitemaker, and have fewer documents and discussions spread across multiple tools.
- Kitemaker becomes a central tool to collaborate across engineering, design, and product. Even marketing and management sometimes!
I hope this provided a bit of an overview of how Kitemaker can be used effectively, and I hope the example of how we use it ourselves serves to make things more concrete. If you are a user and uses it very differently from what we have outlined here, ping us, and maybe we can make an article about your use-case.
If you want to check out Kitemaker, head over here and create your free account today.