Turn your product roadmap into real daily delivery

Patricia @Kairn
5 min readMay 18, 2022

--

We’re building Kairn — the daily project management app to achieve your goals. We’re super product driven so nailing the process from adding tons of ideas in our roadmap to making them a daily reality is KEY 🗝. Here’s how we currently do it — in constant improvement would love to hear your feedback and how you do it too :).

Keep a simple & efficient product roadmap

We’ve iterated a lot on this, went to super complex roadmaps, with tons of status, connected to loads of documents, and in the end, we’re now back to the simplest Kanban of them all.

The Product manager is in charge of moving cards on this roadmap which lives in Notion.
Backlog => To do — Has been betted during the session (see below) — Needs a Pitch ready with clear problem + potential solutions
To do => In Progress — That’s when we explore solutions in depth and code — Spec documents should be updated all the time to allow async work
In Progress => Done — Test + QA + deployment should be validated

Run betting table to prioritise the next sprint

Pretty inspired by the Shape Up method, we run a Betting Table meeting before each 6 weeks Sprint.

Our PM is in charge of preparing the pitch from user request, our CEO (hi 👋) prepares pitch for strong vision problems we think Kairn should address, and anyone in the team is welcome to add their own pitch on ideas they have.

At this stage our pitch (in Notion) includes:

  • Context > what drove the person to write it
  • Problem > we [try 😅 to] don’t start with a solution, it’s just about the problem for now
  • At least 3 potential solution super high level > drawings no wireframes so people are still very open to challenge 😉
  • Any big roadblocks identified upfront (ie. “this will need a full review of our task component => 🛑 gonna take min 6 weeks”)

At the Betting Table each person presents their Pitch in 3–5min max (document should be ready before hand and read / commented by all).

Outcome?

Our list of must tackle problems for the sprint + a list of explorations that can be taken by anyone during the sprint when they have time => this enables us to stay flexible, get everyone engaged, and keep a shipping pace.

Spec example

Build the solution async with feedback

We’re a small team, we’re product driven so yes our CEO and CTO will be interested in all features that get shipped. They’ll be driving product in some, but not all, and they definitely won’t be in all meetings so people should progress independently . That means documenting is key including:

  • Solution exploration to solution choice > what drove the choices / what were the options / how do they compare
  • Choices in UX flow
  • Choices in UI

Documenting in written formats takes forever > you need to give the full context, and to re-update constantly. So instead we use Claap and record live our thinking, add feedback zones when we want people to join in the discussion, use polls when we have doubts. It helps us structure feedback in the fastest way, full async so anyone can join whenever.

Outcome?

A Claap with the solution exploration + UX + UI flow >> added also to the Notion Spec of course.

Documenting our Spec with Claap

Write tickets, no dev starts without a clear picture

While we think creative developers are absolutely great, tickets matter. We believe developers should take problems pitch and explore them on their own, but once they have their thinking clear, they’ll still put it to tickets so it becomes crystal clear. All the specifications are added to our Notion page so anyone can jump in and the feature’s tech owner can write tickets.

It enables better collaboration as other tech members will see what is getting built. When the feature is built by our Product Manager / Product Design / CEO then tickets make sure the delivery matches with what’s expected.

Outcome?

A ticket roadmap in Linear for the next 2 weeks with the following set up

  • Not ready (when tickets come from Bugs / have been logged by non tech / content needs a review)
  • Ready (once tickets content has been finished)
  • Todo (once tickets have been prioritised for the 2-week)
  • In Progress (guess you can guess)
  • In Q/A (when Q/A is needed — done by PM + product design mostly)
  • Approved (once Q/A has been validated and it’s ready to be deployed)
  • Cancelled (if along the way the ticket got deleted >> need comments to explain why )
Showcase of our Linear board

Prioritise on a daily basis with Kairn

We’ve linked Kairn to all our favorite tools so…

  • when a task is assigned to someone on a Notion Spec, it sync 2-way on Kairn to be prioritised
  • we turn Claap decisions into tasks in Kairn and prioritise them
  • we linked our Linear board with Kairn through Zapier and prio them

Tasks are added to the weekly sprint board, with an owner, a status, a date, (sometimes an impact depending on how each person works). We all have access to the board to see how things progress, and if we can help out 🙏.

Creating a task from Claap so work gets prioritised!

We’re constantly improving our Product process so we’d love to hear yours and your feedback on what we’re doing :)

Hope this helps!
Cheers,

Patricia
Kairn CEO

--

--

Patricia @Kairn

cofounder of Kairn now helping teams build great product