Why we’re building Kitemaker

Sigurd Seteklev
May 25, 2020

Scratching an itch

A couple of years ago, Kevin, my co-founder, and I walked out of a small cramped meeting room, having just finished a meeting with one of our teams. The team was very much like many other teams we have been part of and led:

  1. It was cross-functional, meaning that it consisted of designers, product managers, coders, user researches, data analysts, operations, and security experts. They all worked together daily building excellent consumer products or intricate pieces of technology, living by the mantra of starting together, executing together, and finishing together.
  2. It was autonomous. The team decided their priorities, what they worked on, the tools they used, their processes, and more or less anything pertaining to their day-to-day work.

In this meeting, the team could not manage to agree on a particular topic - a topic Kevin and I had seen teams fail to align on many times before. They were struggling with tools. They discussed when to use e-mail and when to use Slack, they discussed Jira vs. Trello vs. Github Issues. They discussed Zeplin, ProdPad, and Google Drive. They understood that coders, designers, and product managers have all different needs and different products optimized for their role, but it was apparent that the tooling didn’t reflect that.

What they were missing was' the one tool' where they could collaborate as a team. The closest was probably Slack. It patched up the silos between the other tools, but it's not really meant for focused work, persisting important information or filtering irrelevant information. Stepping out of that meeting, Kevin said: "There has to be a better way to solve this." And so started the journey that became Kitemaker.

Cross functional teams

If you have ever worked in an environment like I describe above, then you will probably feel that it's the most natural way of working. We have ourselves been directors, leading organizations with many teams, and we were never the best ones to tell the teams what to do or how to do it. What we tried to do was to coach teams to do what is best for the company, to collaborate with other teams, customers and users, and to relentlessly focus on optimizing value creation.

We know that all not teams work this way and that's not necessarily a bad thing. One of my core values as a product developer and manager is that your process should depend on the product you're building, your team, your company, and your customers. Sometimes a waterfall process is the best way to maximize value creation, or maybe following the directions of a visionary; even that perhaps is hard to believe for some.

However, very often autonomous cross-functional teams are better than the alternatives; especially if your company is bigger than a two-pizza size team. The teams will know the needs of their customers and users, the code base, the current state of the product, and all the details that management will not have the time or capacity to know in detail. And autonomous teams are common across many industries, because top down decision making doesn’t scale as good as decentralized decision making (see references below).

How Kitemaker helps

The core problem we want to solve with Kitemaker is how to make cross-functional teams collaborate better. It means building something where people with any skillset feel at home - where you, no matter what your role, can effortlessly collaborate with your team. A place that you can help you find what you need to do to do your job.

Our first attempt was building a platform that connected all the other tools teams were already using. That way if you updated design, or merged a pull-request, or changed the roadmap, everyone that needed to know would get the information. However, the product had perhaps a bit of a steep learning curve and our users wasn’t ready for ‘yet another tool’ for the team. When our first users onboarded, they didn't even use the fancy integrations or the smart documents that connected everything. What they did was to love how easy it was to create tasks, how flexible the tool seemed, how great the UI felt (we're fans of Superhuman, so we built on similar philosophies). They said, 'if you only add X, I won't need Trello or Jira anymore, and it could use all these other great things you’ve built' That is why we ended up building another collaboration tool.

Fibery.io anxiety campaign illustrates pretty well the feeling of building a productivity tool before you have any traction.

However, Kitemaker is not just 'yet another collaboration tool.' It is saving people time and frustrations since it is The fastest, most efficient, product development tool ever built. It is a canvas for product development. It allows you to figure out your process and roadmap because it doesn't get in the way when you execute. It is a home for your team because it is where you can keep up to date on what is going on. It is where you go to get an overview, and it becomes your favorite meeting killer because you will need fewer status meetings. It is enabling team members to focus better because it will be less distracting than your chat client.

Perhaps we can not fulfill all of those promises today. But, this is our mission, to make the effort of product development to be about you figuring out how to bring the best value to your users and customers, and then to build the tool that allows you to do this with the least amount of effort.

If you want to sign up for our early access program, you can visit www.kitemaker.co.

You can follow us on Twitter or LinkedIn, or ping us at contact@kitemaker.co.

Interesting articles:

https://hbr.org/1990/11/how-i-learned-to-let-my-workers-lead

https://www.mindtheproduct.com/team-smarter-autonomous-product-teams-work-better/

http://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/