How our Product & Tech culture influences the way we work
From day one, as a company, we have always been very product- and tech-driven. This probably stems from the fact that the majority of our co-founders are engineers. So it’s no surprise that the processes, tools and methodologies developed and used by our Product & Tech teams have ended up being used across the company. Yes, even by business teams.
In this article we want to share some of the methods that we have developed in-house and that are successfully being used across all of our teams. We hope that it can be helpful for other teams out there.
📚 Backlogs and roadmaps
As a startup company, we face a very common challenge: we have unlimited ambition and limited resources to deliver on that ambition. It means we have a million ideas and projects, but we can only get a handful of these done in a reasonable timeframe. That’s why it’s very important to get prioritization right, to focus on things that matter at any given time without losing speed and agility. It’s also a great way to never feel overwhelmed by everything you have to do.
Tech & Product teams have always faced this challenge more acutely than other teams. Everybody, from users to customers and team members, has ideas of features we could (should) develop. But product development, especially if you want to do it in a scalable way, inevitably takes time. And as outlined by Brooks’ law, adding software engineers to the team does not necessarily solve the equation. That is why Product teams have always pioneered techniques to manage backlogs and roadmaps in an efficient way.
A structured backlog on Notion
At Joko, we apply the following framework. It was initially built by our Product team but is now used across the company by all teams.
The overarching principle is that all projects we work on or may work on in the future are added to a structured table on Notion. For example, here’s how it looks for our Analytics team:
Each item in the table has the following properties:
1- Name → it describes in a synthetic way the actual project
Two important things to keep in mind:
- Name it in a way that’s clear enough and that allows you to know when it’s actually done (and one that you can actually get done!). For example:
→ ✅ Define the location and dates for the next offsite
→ ❌ Next offsite
- Take time to add emojis. It may sound superficial but it makes managing the backlog much nicer 🙂
2- Statuses
Each item in the table has one of the following statuses:
- To do → not started yet and not scheduled to start very soon, this is the actual “backlog”
- Selected → selected to be worked on soon, but not started
- In Progress → currently being worked on
- In Progress — Done → completed very recently
- Done → completed
See the process below for the difference between the last two statuses.
We also use the following fields to make a rough prioritization, which turns out to be very helpful when you have dozens and dozens of projects in your backlog.
3- Complexity: Low / Medium / High
4- Impact: Low / Medium / High
5- Priority: score from 1 to 5 computed automatically based on Complexity and Impact
6- Owner: each project must have an owner (it can be two or three people in some cases, but most of the time, there should be only one), but only when it starts being worked on. It is not necessary to assign an owner to a project before the work actually starts, because things may change.
7- Reviewed: a checkbox field that is checked once the item has been reviewed during the fortnightly review (see process below). It is unchecked for recently added items.
It is important to keep in mind that in Notion, items in a table are also pages. That’s where the method is very powerful: all relevant content and work that is being done on a project can be stored and documented on that very page.
In our table, we always have the following views:
- All: no filters
- New: items with Reviewed not checked
- Backlog: only items with status To do
- In Progress: only items with status Selected, In Progress or In Progress — Done
- Done: only items with status Done
Six-week roadmaps, reviewed every two weeks
Every 2 weeks (usually on Tuesday), we review the backlog together and align on priorities.
- First, we check items that are in progress in the In Progress view: we discuss what got done (In Progress — Done), where we made progress, where we didn’t, and why. If some projects got done, we set them to Done.
- Then, we review new items that have been added in the last two weeks. They have the status To do and appear in the New view. We discuss the suggested Complexity and Impact, as well as the wording used. Once we all agree, we check Reviewed.
- Finally, we select items to be worked on soon. We use the Backlog view, which is ordered by descending Priority. We change the status of the items that we find most important to Selected (it moves it to the In Progress view). We then make sure that items In Progress + Selected can reasonably be done in the next 6 weeks, otherwise we remove some of them (back to To do).
There are three benefits to this approach:
- Alignment: we get to make sure that we are focusing on the right things, and have frequent opportunities to discuss it as a team.
- Anticipation: we all know what’s coming next, and if needed, we can prepare for it in advance (e.g. write specifications for upcoming features before they are handed to software engineers).
- Agility: we don’t plan too far into the future and we can make adjustments every 2 weeks if the context changes.
✍️ Specs
Beyond backlogs and roadmaps, there is another methodology that we have developed for our Product and Tech teams and that has conquered other teams.
It’s a problem-solving methodology. When writing specs for features, Product teams often have to define and design concrete solutions for broad problems. For example, let’s say we want to add a price tracking feature to our mobile app. Where do we start? What’s the scope of the feature exactly? How can we do that? Do we have multiple options? Which one should we keep, and why? How should it fit into the existing UX and UI? What about specific edge cases? Where should the call-to-action be placed? etc. While writing feature specs, our product managers go from a broad topic to very tiny details, and take many decisions on how we will implement the feature.
It is actually a universal need. For example, when we decided to implement an individual budget for team members to get access to learning & development training, we didn’t know where to start. How can we do that? What are the third-party providers we can use for that purpose? What are the key criteria? Should a validation from the manager be required? How often should the budget be allocated? Should it expire? There were so many questions to answer, and many other questions were raised along the way as we were exploring these questions. So we wrote everything, just like we would do for a feature specification. And it led us to the solution that was right for us: we implemented Simbel, and we allocated a budget of €500 per semester per person, that expires after 12 months (because we never stop learning).
There are three very important principles that you need to have in mind to be successful with this approach:
1- Only ask questions
The way we structure our specs is that we only answer questions. It’s like a very long Q&A. It’s a very important principle because it forces to justify any content in your spec. It’s there because it answers a question. Otherwise, it doesn’t belong there.
2- Ask them in the right order
It’s very important to do things in the right order. Indeed, going from problem to solution is like navigating through a giant decision tree like this one. It’s always better to ask yourself “should I go red or dark blue?” before you ask yourself “should I go yellow?”
In practice: first ask yourself if there should be a call-to-action on the screen before you ask yourself if the call-to-action should be green or blue.
3- Don’t wait till the end to get your work reviewed
Let’s say you decided to go red in the decision tree above, and then wrote your full spec until level 3. But what if your reasoning was flawed when you decided to go red? You may have written a very long spec for nothing, and you’ll need to start from scratch again.
That’s why it’s always a good idea to have drafts reviewed and challenged. Since everything is justified in writing, an external eye can easily spot flaws in the logic. It’s all about finding the right balance: you don’t want to have your spec reviewed at every question, but you don’t want to wait till the end.
There are three benefits to this approach:
- Argumented: When you have to write it, you have to justify every single decision you make, and that forces you to make the right decisions.
- Challengeable: Writing everything as questions and answers also makes it easier for colleagues to challenge your reasoning: are some questions missing? Are some arguments too weak?
- Asynchronous: Writing everything allows for asynchronous reviews by other team members, which provides flexibility to everyone.
That’s it! Feel free to reach out to us if you have interesting insights to share on how Product & Tech cultures can make organizations better at solving problems and executing fast with focus!
And if you want to know more about Joko, check out hellojoko.com/join!
