I started building Tuki because I needed a better way to keep six teams straight.
Tuki is a Finnish word meaning support. It can mean a brace in construction, or emotional help and solidarity. That was exactly the feeling I wanted: friendly, short, easy to spell, and quietly load-bearing.
One of those teams reports directly to me. The others intersect with my work constantly. Features move across delivery, design, applications, data science, hardware, and leadership priorities. Dependencies are everywhere. Context gets lost easily.
At that scale, a normal roadmap starts to feel like a polite fiction.
The Problem With Planning Theater
Gantt charts have their place. I am not morally opposed to bars on timelines. But they are often a bad default for product planning because they make uncertain work look more certain than it is.
The harder question is not "what date does this bar end?"
The harder questions are:
- Why is this ranked above that?
- What business case supports it?
- What teams does it depend on?
- Is it desirable, feasible, and viable?
- What context does leadership need to understand the priority?
- What happens to everyone else if this slips?
Tuki is built around those questions.
The PRD Context Problem
We moved toward automated product briefs and PRDs to improve tickets and estimates for engineering. That was useful. Better structured requirements lead to better engineering conversations.
But there was a trade-off.
As the artifacts became cleaner, some of the messy strategic context got pushed out of view. The ticket explained what to build. The PRD explained the feature. But the leadership-level reasoning could get thinner:
Why now? Why this customer segment? Why this over the other five good ideas? Is this a wow feature, table stakes, a blocker, or a long-term platform investment?
That context matters because prioritization is not just ordering work. It is explaining trade-offs.
The Tuki Shape
Tuki replaces the Gantt-first mental model with stacked ranking and dependencies.
The live beta focuses on:
- Product stacks across teams.
- Ranked priorities inside each stack.
- Dependency visibility between teams.
- Blocked, scheduled, and shovel-ready states.
- Business case capture.
- Desirability, feasibility, and viability notes.
- Product briefs and PRDs that stay connected to the ranking logic.
I think of it less as a roadmap and more as a product operating map.
Cagan, But Practical
Marty Cagan's desirability, feasibility, and viability framing is useful because it keeps product people honest.
A feature can be desirable and infeasible. It can be feasible and not viable. It can be viable and not desirable. The product manager's job is to hold those tensions without flattening them into a fake score.
Tuki does not try to make that qualitative judgment disappear. It tries to capture it.
That is important to me. I do not want a tool that pretends prioritization is a spreadsheet formula. I want a tool that keeps the reasoning visible enough for leadership, engineering, design, and adjacent teams to understand why the stack looks the way it does.
Why I Built It Now
Tuki has been a nights-and-weekends project over the last three weeks. The beta is live internally, which is exactly where it should be right now.
I am building for a real workflow I live in every day. That makes the product sharper. When a screen is awkward, I feel it immediately. When a concept is too clever, actual work punishes it. When the tool helps me explain priorities better, I know.
That is the joy of building for your own pain. The feedback loop is merciless and useful.
Tuki is still early, but the core idea feels right: preserve the business case, show the dependencies, and rank the work in a way that matches how product leadership actually thinks.