Founder, Product Manager, Developer | 2026
Tuki is a prioritization and dependency-management tool I built because my actual working life outgrew my planning tools.
Tuki is a Finnish word meaning support: a brace in construction, or emotional help and solidarity. I liked that it was friendly, short, and easy to spell, but mostly I liked that the word carried the product's purpose. This is a tool for supporting decisions, supporting teams, and showing the load-bearing structure behind a roadmap.
I manage four product teams, one directly, and have deep dependencies with my hardware and software leaders. So I need to keep track of what matters, why it matters, what depends on what, and which work should rise to the top. Traditional roadmap tools often pull planning toward Gantt charts and timeline theater. I needed something closer to how product prioritization really feels: stacked ranking, dependencies, business case, and trade-offs. The EV industry is a rollercoaster and the traditional roadmap just does not cut it when we have to pivot and shift attention frequently.
The Problem
We moved toward automated product briefs and PRDs to create better tickets and better engineering estimates. That was the right move in many ways. Engineering needs clarity. Estimation improves when the ask is structured. The quality of tickets matters.
But in that shuffle, some leadership context started to disappear.
Why this feature? Why now? What business case supports it? Is it desirable, feasible, and viable? What team does it depend on? What happens if the dependency slips? Is this work a customer-visible differentiator, a demo moment, a compliance necessity, or operational plumbing?
A PRD we didn't actually write means those memories created when you make something are never in your head. We became more reliant on artifacts and notes as we automated away more of the artifact creation, perhaps ironically.
That is the gap Tuki is meant to fill.
The Product Thesis
Tuki does away with Gantt charts as the default planning mental model.
Instead, the product focuses on:
- Stacked ranking by team or product stack.
- Dependencies between teams.
- Status such as blocked, scheduled, and shovel-ready.
- Business case and leadership context.
- Desirability, feasibility, and viability in the Marty Cagan sense.
- Product briefs and PRDs as structured artifacts, but not the whole story.
The goal is not to replace judgment with a formula. The goal is to preserve judgment so the organization can see why the work is ranked the way it is.
Why This Needed to Exist
At six-team scale, product management becomes less about a single perfect roadmap and more about managing load paths.
If one team is blocked, another team's plan may become fiction. If a high-priority feature depends on design, data science, firmware, and application work, it needs to be visible as a connected system. A list of tickets does not show that clearly. A Gantt chart may show dates, but often misses why the work matters.
Tuki is trying to show the product organization as a set of priority stacks with dependencies between them.
That framing matches the real work better.
Beta Status
The beta version is live internally. This has been a nights-and-weekends project over the last three weeks, and it is intentionally focused on the workflows I need now:
- Keep priorities straight across multiple teams.
- Capture the business case.
- Preserve leadership-readable context.
- Show interdependencies.
- Support better conversations around ranking.
- Connect product briefs and PRDs back to the strategy that made them necessary.
There is a lot still to refine, but the shape feels right.
Product Lesson
Tuki grew out of the same lesson as Gachi, but at a different altitude.
Gachi captures fast desirability signal from a room. Tuki takes that kind of signal and places it into a broader prioritization system: desirability, feasibility, viability, business case, dependencies, and team capacity.
One tool asks, "Did this turn heads?"
The other asks, "Given everything else we know, where should this sit?"
I need both questions in my product work, and the beauty of working in 2026 is I can build bespoke solutions to match my work style without breaking a sweat.