We recently mentioned that we are changing the way we work and think about work at Kanka. Today we’ll go into detail about why the change, how it’s changing, and what we’re committing to ship in Q1 2026. Our goal is to announce these at the beginning of every quarter, along with a video where we go into more detail.

Why I needed a change

TL;DR: I was having a yearly burnout.

As a tiny team, we have the chance but also burden of wearing many hats, and also extinguishing many fires.

I am constantly thinking about Kanka and how to make it better, and have tons of both reasonable and unreasonable ideas on what that looks like. The problem is that every idea ended up having the same weight and mental load. It all lived in one backlog, so every few days when I checked on what to work on, I had to re-parse the whole list of ideas, including things from 2017 that still might be a good idea eventually. I tried frequently pruning the backlog, but that never really worked.

Introducing the roadmap was a big help, but I still had to pay a mental price of now checking in two places.

Another compounding issue is that I constantly had to find issues for Itza to work on, which made sense when he was a junior developer learning the ropes. However, he is no longer a junior developer. He can tackle just about any ticket save for a few rare exceptions.

On top of all of this, Jon and I would define our “yearly wishlist” every december, which we followed for a month or two, and then checked again towards the end of the year if we were lucky, or just wouldn’t.

So we had wishy-washy goals, that we never really committed to, and I was constantly thinking about work. And when I had the chance to focus on actually work on code, I got frequent interruptions to go find work for Itza. Figuring out what to work on next was always draining, and I dreaded it, leading to a yearly burnout.

How we’re changing things

I’ve worked in software engineering for over 20 years and had the chance (and pain) of working with many methodologies. There are many out there that promise to make you more productive, make you faster, make you whatever adjective is hipped up in that decade. But I don’t need to be more productive, I need to stay sane. I need to have fun thinking and working on Kanka.

Agile is one such methodology for software engineering that I have a lot of experience with, but I always had experience with it as a software engineer, not as a product owner. So I did a bunch lot of reading. I found atlassian’s article on quarterly objectives and it resonated a lot (minus using their software Jira, never again). After some more reading and thinking, I introduced the following to Jon and Itza.

Quarterly objectives (outcomes), bets, and issues

Every quarter, we as a team commit on 2 or 3 outcomes. There aren’t features, these are areas that we decide are important and will require our focus for the quarter.

For each outcome, we define multiple bets. These can be features, but not only. Each bet should clearly outline how it helps with it’s attached outcome.

Each bet is then split into multiple issues, which are basically our tickets to work on. These are the units of work.

Splitting the work

Whenever a team member needs to figure out what to work on next, they assign themselves to a bet and work on it’s issues. Each member is fully autonomous to work on whatever they feel like working on, but they commit to delivering each bet to its conclusion.

If all the quarterly bets are done, then we go in the roadmap and autonomously decide what to work on, prioritising requests with high upvotes. If a request isn’t clear, we ask in the Discord for clarification from the community.

The Icebox

You might be wondering where the old backlog went. It’s now a simple shared document with bullet points for each idea. When defining quarterly objectives and bets, we can take items from the icebox. If a team member has a random idea, they can add it to the icebox, and we’ll discuss it when defining the next quarterly objectives. Random ideas still exist but they no longer require frequently mental load. If an item exists in the icebox for so long that we forget why it was added in the first place, we chuck it out.

Outcomes

With these changes, we spend a week or two thinking really hard about the quarter and its objectives and bets, and then just focus on work for a few months. We can still be reactive to landscape changes, disruptions, or new tech on a quarterly basis, rather than say “maybe next year”.

By having each member fully autonomous, I am no longer needed in the taxing loop of “what does Itza work on next”.

Q1 2026

Now that we’ve explored why and how, let’s dive into exactly what we’re talking about.

Outcome 1: Wyvern and Elemental value

Towards the end of 2025, we surveyed our Wyverns and Elementals on how to add value to their subscription. We delivered part of those changes last year, but wanted to finish what we started.

Bet 1 – Collaborative whiteboards

We believe that whiteboards would only be really cool if they had a collaborative aspect, where each user viewing a whiteboard would get instant updates.

Bet 2 – CSV imports

A highly requested feature of the survey was importers and a faster way to import data into Kanka. We want to allow these members to upload CSV files into their worlds.

Bet 3 – Elemental highlight

We want to allow our elementals to “prioritise” one of their open campaigns to bring at the top of the new “looking for game” section we want to build (detailed in outcome 2 – bet 3)

Bet 4 – Roadmap sponsoring

We want to allow our elementals to “sponsor” one feature request at a time from the roadmap to bump it up the list, giving it more chances of being voted on.

Outcome 2: Community as a catalyst

Community has always been a big part of our DNA, but we feel like we’ve lost our way in recent years. We started some changes last year already with our new Developer logs, but can do much more.

Bet 1 – Referrals

We want users to be able to refer their friends to Kanka and have some badge to showcase their efforts into spreading the word.

Bet 2 – Monthly Spotlight

Every month, we want to spotlight 2-3 worlds that users submit to us, including a small survey about what inspired them, what they are proud of, etc.

Bet 3 – Campaign application

We want to re-build the campaign application system to be way more useful for gms looking for players and vice-versa. This includes a proper survey that includes timezones, timeslots, remote/online, playstyle, player count target, language. Then we can build a proper “lfg” section and bring players together.

Bet 4 – One-click sharing

We want to make it stupidly easy for people to share a link to their dashboard or specific entity without having to explain to them how the permission system works. By just offering a simple yes/no on two options, we can set sane defaults that remove any of the guesswork.

Bet 5 – Monthly challenges

We want to bring back our monthly worldbuilding challenges, but in a sustainable manner. We stopped them back in 2023 because they required a lot of time and effort despite low participation rates. We have a new format we want to try that we believe will scale way better.

Bets that didn’t make it

We had a few more ideas that didn’t make it for a variety of reasons, usually from lack of clear scope, or not thinking it would help with the stated outcome.

Rejected bet 1 – Forking campaigns

The same way projects can be “forked” on github (essentially copied), we thought about allowing forking of public campaigns to speed up the sensation of “playing in a world”.

Rejected bet 2 – Weekly stats

We thought about publishing a weekly digest of stats/highlights/leaderboard of what people created that week in Kanka.

Rejected bet 3 – Embeddable snippets

We nearly committed to making maps, timelines, and characters easily embeddable in other websites (like you can embed spotify or youtube in Kanka).

Closing words

We hope you enjoyed this deep dive into how we work and what we’re working on for this quarter. As we get mileage on this new policy, we might end up tweaking some aspects of it and will communicate should things change drastically. I personally hope that this will help with my issues outlined in the why section.

Happy worldbuilding!