PERSONAL - 2025 > 2026
Designing and building an AI-native product operating system — and learning firsthand how AI changes the role of Product.
Context
AI coding tools were making software dramatically faster to build, but I kept seeing the same problem: building faster did not mean teams were making better product decisions.
Product context remained fragmented across Jira, Notion, Miro, research repositories, analytics tools and people's heads. Teams could rarely trace a feature back through the customer problem, evidence, KPI and decision that justified it — and AI coding tools had even less access to that context.
I started Bonzaii as an independent experiment to explore a question:
What would Product Management software look like if it were designed for both humans and AI from the start?
Over roughly a year, I took the idea from early problem validation and landing-page experiments through product discovery, design and a functioning platform — using AI-assisted, prompt-driven development rather than a traditional engineering team.
What is it?
Bonzaii is an AI-native Product Operating System designed to preserve the reasoning behind product decisions.
Instead of storing research, strategy, features, KPIs and delivery work as disconnected documents and tickets, Bonzaii models them as a connected product graph.
A team can trace:
Signal → Problem → Opportunity → Solution → Feature → Release → KPI
This creates a shared source of product context for both people and AI.
Product teams can use Bonzaii to:
-
capture research, signals, problems and opportunities
-
connect product decisions directly to user needs and KPIs
-
prioritize solutions and plan roadmaps
-
manage features, releases and delivery context
-
preserve the reasoning behind decisions as the product evolves
-
use contextual AI to investigate, synthesize, review and draft work
-
expose structured product context to external AI development tools
~12 months
Independent product experiment
10+
PM discovery interviews
20+
Interconnected product modules
8
Core entity types in one product graph
2.5%
LinkedIn validation CTR
The problem I wanted to solve
Product knowledge was everywhere — but never connected
Across the teams I'd worked with, product knowledge lived across Jira, Slack, Notion, Figma, Miro, dashboards, strategy decks and individual people's heads.
Each tool stored part of the story, but very little preserved the relationships between them.
A feature might exist in Jira, but six months later it was difficult to answer:
-
What customer evidence triggered it?
-
Which problem was it meant to solve?
-
Which KPI justified the investment?
-
What changed during delivery?
-
Did it actually improve the intended outcome?
AI made this problem more important. Coding assistants could build rapidly, but they still lacked the structured product context needed to understand why something should exist in the first place.
My hypothesis
If product knowledge could be represented as a structured, connected system rather than a collection of documents, the same context could support:
-
better human decision-making
-
stronger organizational memory
-
more useful product AI
-
better context for AI-assisted software development
Validating the problem before committing to the platform
I did not start by building the full product.
I used lightweight prototypes, ChatGPT experiments and Wix landing pages to test the underlying problem and different ways of positioning it with Product Managers.
I then tested positioning through targeted LinkedIn campaigns and spoke directly with Product Managers, founders and operators.
One of the strongest lessons was that problem-first messaging resonated much more strongly than feature-first messaging.
Problem-first messaging such as “Your product data lives everywhere” resonated more strongly than positioning Bonzaii as another roadmap, discovery or AI tool.
The research also challenged my first product direction. My initial MVP focused heavily on creating a structured product knowledge base. Interviews suggested that storing information was not enough — the harder problem was helping teams decide what to do with it.
That insight shifted Bonzaii from a passive repository toward an active product reasoning and decision-support system.
What I built
Bet 1 — Preserve the “why” behind every product decision
I built Bonzaii around a connected product graph rather than isolated tickets and documents.
Research, signals, user needs, problems, opportunities, solutions, features, releases and KPIs can be linked directly to one another.
That means a team can open a feature and reconstruct why it exists, rather than relying on stale documentation or institutional memory.
What I built
-
connected Hub model across core product entities
-
typed, bidirectional relationships
-
product and feature trees
-
discovery funnels
-
journey and strategy mapping
-
live links between research, decisions and delivery
Bet 2 — Turn product data into decisions, not another repository
My first direction was too focused on organizing information.
Research pushed me toward a more active system that helps PMs decide what deserves attention and what should happen next.
I introduced:
-
structured prioritization and an evolved RICE model
-
product-health and lifecycle signals
-
quarterly planning
-
AI-supported investigation
-
proactive Discovery, Planning and Delivery advisors
-
AI review of incomplete or weak product thinking
The goal wasn't to automate Product Management. It was to surface evidence, gaps and trade-offs while leaving judgment with the PM.
Bet 3 — Keep strategy and delivery connected
One of the recurring problems I wanted to solve was the loss of strategic context once work entered delivery.
Bonzaii therefore carries the product reasoning with the work:
problem → evidence → KPI → solution → feature → release
Delivery can update the underlying product model rather than creating another disconnected layer of tickets.
I also built structured PRD and Jira/Linear/GitHub export so engineering context can include the user problem, KPI, acceptance criteria, dependencies and research rather than just a feature description.
Bet 4 — Give AI the same product context as the team
I didn't want AI to exist as a generic chatbot bolted onto a PM database.
Instead, I experimented with AI at different points in the workflow:
-
contextual actions inside Discovery, Planning and Delivery
-
automated synthesis of research and signals
-
evidence-grounded investigation of individual product entities
-
product-quality review
-
drafting specs and product narratives
-
natural-language access to the product database
-
structured context for external AI coding tools through MCP
The underlying principle was simple:
AI becomes more useful when it understands the product model, rather than receiving the same context again in every prompt.
How I built it
Building without a traditional engineering team
I designed the product, workflows, interaction model and underlying product logic, then used AI-assisted tools to turn that thinking into working software.
My process evolved into:
-
Define the problem and behavior
Work through the user need, UX, data model, business rules and edge cases. -
Break the work into atomic specifications
Use Claude as a technical/product critic to challenge assumptions and convert the design into small, sequential implementation tasks. -
Execute through AI-assisted development
Use Lovable and other AI development tooling to implement each task. -
Test and inspect
Use automated Playwright testing alongside manual product and visual validation. -
Iterate
Feed failures, edge cases and user feedback back into the next specification.
This let me build a very broad, interconnected product without a conventional engineering team — while also exposing the limitations of AI-native development firsthand.
What didn't work
AI made building easier — and prioritization harder
When implementing another feature can take hours rather than weeks, the cost of saying “yes” collapses.
That sounds entirely positive, but I found the opposite Product problem emerging: it became easier to build something than to prove it deserved to exist.
I caught myself expanding the platform because I could, rather than because each capability had earned its place.
That forced me to reintroduce stronger scope discipline and use Bonzaii's own traceability and prioritization principles against its roadmap.
The question changed from:
“Can I build this?”
to:
“Should I build this?”
The bottleneck moved from development to learning
AI dramatically shortened implementation time.
It did not make customer research, user recruitment, testing, positioning or evidence gathering dramatically faster.
That created an unusual imbalance: I could create product surface area faster than I could responsibly validate it.
The most important constraint therefore became the feedback loop — not engineering throughput.
That changed how I allocated my time: fewer capabilities simply because they were possible, and more focus on interviews, positioning tests and validation.
Key learnings
-
AI changes where the bottleneck sits
When implementation becomes dramatically cheaper, product judgment, prioritization and validation become more — not less — important. -
Structured context makes AI substantially more useful
Generic prompts repeatedly recreate context. A connected product model gives AI a persistent understanding of users, problems, features and metrics. -
The difficult problem isn't storing product information
Teams already have plenty of places to write things down. The harder problem is preserving relationships between evidence and decisions, and helping people act on that context. -
AI-native building still needs engineering discipline
Small changes can propagate quickly through an interconnected product. Atomic specifications, explicit rules, testing and controlled iteration became increasingly important as the platform grew.
Current status
Bonzaii remains an independent product experiment and free beta, built to explore how AI is changing product development and what Product Management infrastructure might look like for AI-native teams.
It is a functioning platform, but I do not present it as having achieved product-market fit or commercial scale.
The project has primarily become a practical laboratory for AI-assisted development, product information architecture, AI UX, prioritization under dramatically lower build costs, and preserving product context for both humans and AI.
