Gachi and Tuki look like separate projects, but in my head they are connected.
The names point in the same direction. Gachi comes from the Korean word for together, which fits a tool built to gather buy-in and enthusiasm from a room. Tuki is Finnish for support, whether as a physical brace or emotional solidarity, which fits a tool built to support prioritization across teams.
Gachi asks the room a fast question:
Did this feature land?
Tuki asks the organization a slower question:
Given everything we know, where should this work sit?
I need both.
Fast Signal Is Not Strategy
The danger of a tool like Gachi is over-believing the reaction.
If the sales team loves a feature, that is meaningful. They know what gets attention in a demo. They know what makes a buyer lean forward. They know what competitors are saying. Their excitement is a real signal.
But it is not strategy by itself.
A feature can wow the sales team and still be too expensive to build. It can be desirable and not viable. It can be useful for one customer segment and distracting for another. It can create support burden, implementation complexity, or roadmap debt.
Fast signal needs a place to go.
That place is Tuki.
Priority Needs Context
Tuki exists because product ranking without context becomes theater.
It is easy to stack-rank features in a spreadsheet. It is much harder to preserve the reasoning:
- What is the business case?
- What customer pain does it solve?
- Did sales react strongly?
- Is the work feasible?
- Is the opportunity viable?
- Which teams are involved?
- What depends on it?
- What does it block?
The ranking is only as good as the judgment behind it.
Gachi helps produce one kind of judgment: desirability signal from a group. Tuki helps put that signal next to feasibility, viability, dependencies, and business case.
The Build-In-Public Pattern
I am trying to build these tools in public because the act of writing about them improves the products.
Writing the Gachi post clarified that it should stay narrow. It is a room instrument, not a roadmap suite.
Writing the Tuki post clarified that Tuki should preserve judgment, not hide it behind fake precision.
Writing about Nimra clarified a similar lesson from another angle: the best AI product is often less about flashy generation and more about preserving organizational knowledge inside a real workflow.
These projects are becoming a little portfolio of my own product instincts:
- Nimra: read the document before drafting the answer.
- Gachi: capture the room reaction before it disappears.
- Tuki: preserve the reasoning behind the ranking.
That is a useful pattern for me.
The Product Management Thread
All three projects are about context.
Nimra protects the context behind RFP answers. Gachi captures the context of a room's reaction. Tuki preserves the context behind priorities and dependencies.
That is probably not an accident. A lot of product management is context preservation. The work is always at risk of being compressed into a ticket, a score, a date, a slide, or a yes/no decision.
Good tools should resist that compression where it matters.
They should make the important context easier to see, easier to discuss, and harder to lose.
That is the thread I want to keep pulling.