Kizna

From AI-first to user-first: restructuring a fragmented admissions CRM.

What it shows: Product · process · engineering
My role: Product Owner · Fullstack Developer
When: 10/2026 – present · assessment & restructuring
Company: Sanan Corporation

Product RoadmapUser StoriesAcceptance CriteriaBacklog Management

01 · The problem

Kizna

Context

Kizna is an AI-first admissions CRM built to help schools manage leads, student profiles, and multi-channel communication. It had grown without a consistent approach to user experience, technical architecture, or the way the team builds and ships.

The challenge wasn't just building new features. It was turning a fragmented, AI-first product into a usable, maintainable system that actually meets customers' needs.

Poor UX/UI
Complex navigation, cluttered screens, and workflows that didn't match how admissions teams actually work.
Unstable product
Frequent bugs, inconsistent behaviour, and disconnected features that created friction for users.
Fragmented codebase
Multiple development branches, duplicated logic, and little shared architecture, which made maintenance and scaling hard.
Unclear development process
Scattered documentation, loosely managed requirements, and no consistent way to track issues, prioritise work, or release.
AI-first, not user-first
The product focused on AI capabilities without fully covering users' basic needs.

02 · What I did

Kizna

01Product discoveryMet customers, collected feedback, and reviewed existing features to find usability issues and gaps between the product and real admissions workflows.
02Business & UX analysisMapped the admissions journey from lead to enrollment, and reviewed navigation, onboarding, student profiles, and multi-channel messaging for improvements.
03Product ownershipDefined requirements, user stories, and acceptance criteria. Organised and prioritised the backlog by customer pain, business value, and technical dependencies.
04Development processIntroduced a structured workflow for issue tracking, development, code review, testing, and releases. Turned scattered information into clearer documentation and actionable tasks.
05Technical architecture & deliveryReviewed the existing codebase and proposed a unified monorepo with reusable modules and shared packages. Contribute to fullstack development, bug fixes, and technical improvements.

03 · Decisions & trade-offs

Kizna

One path from request to release

Proposed a standard flow for managing requirements, development, testing, and release, so business, dev, and QA hand work over the same way every time.

04 · Before / after

Kizna

Drag the divider to compare

Demo image (replace): reworked navigation and core screen — Navigation & core screensBefore: the original navigation and cluttered screens. After: the reworked layout built around the admissions workflow.

Demo image (replace): original navigation and core screen — Navigation & core screensBefore: the original navigation and cluttered screens. After: the reworked layout built around the admissions workflow.

Demo image (replace): structured board for requirements, issues and releases — Development workflowBefore: scattered docs and untracked requests. After: one board for requirements, issues, and releases.

Demo image (replace): scattered requirements and issue tracking — Development workflowBefore: scattered docs and untracked requests. After: one board for requirements, issues, and releases.

05 · What I achieved

Kizna

What changed

Product requirements and issue tracking in one place.
A clearer development and release workflow.
Critical UX and functional issues identified and prioritised.
A technical direction for consolidating the existing codebase.

Proposed / in progress

Restructuring the codebase into a monorepo with shared modules and packages.
A full UX/UI overhaul of navigation and the core admissions workflows.
Rolling out the product roadmap.

More about my time at Sanan

Next case study · Sanan

Leads · Kizna CRM