My Wife Was My Product Owner: Building Software Through Real Agile Feedback

Most side projects start with a developer scratching their own itch. This one started at our dinner table. My wife, an HR professional managing dozens of ongoing responsibilities, was describing a frustrating meeting where she couldn't recall why a specific task had been stalled for weeks. Her tracking system was a patchwork of Excel sheets and email threads. I recognized the symptoms immediately: she had a tooling problem, not a productivity problem.

As a developer who builds deployment systems and maintenance tools for a living, I knew I could help. But building for someone else, especially someone who isn't a developer, requires a fundamentally different approach than building for yourself. This post documents the process: from discovery to delivery, through four agile feedback rounds, to a tool she now uses daily.

My first instinct was to jump into code. Instead, I forced myself to sit down and actually listen. I asked her to walk me through a typical week: what she tracks, what falls through the cracks, and what frustrates her most.

Three core pain points surfaced quickly:

1. Blocked Visibility: When a task was stalled, she had no structured way to record who was blocking it and why. Weeks later, sitting in a status meeting, she'd struggle to recall the context. Excel rows don't carry that kind of narrative.
2. Accomplishment Tracking: At the end of a quarter, summarizing what was actually completed across dozens of projects meant digging through months of spreadsheets and sent emails. There was no single source of truth.
3. Time Awareness: She had no quick way to see how long a task had been open, when it was last touched, or whether a deadline was approaching. Everything required manual mental math against dates scattered across cells.

But the most important insight came from a subtler observation.

In software engineering, a project has a start and an end. You ship the feature, close the sprint, and move on. My wife's world doesn't work that way. Her 'projects' are areas of ongoing responsibility: employee development programs, compliance processes, recurring recruitment pipelines. They don't finish; they cycle continuously.

This distinction shaped the entire data model. I needed a hierarchy where Projects represent permanent areas of ownership, User Stories capture ongoing initiatives within them, and Tasks are the concrete action items that flow through statuses. The system had to support work that lives indefinitely, not just work that ships.

With requirements in hand, I built the first working prototype. React 19 with TypeScript on the frontend, Electron for the desktop shell, and Dexie.js over IndexedDB for fully offline, local-first persistence. No backend, no cloud, no login screens.

I loaded it with dummy data and handed it over. Her first reaction was positive but immediate feedback followed: the hierarchy made sense, but navigating between projects felt clunky. She wanted to see her tasks grouped by urgency, not just by parent story. The dashboard needed to surface what matters today, not just what exists.

Based on her feedback, I built computed view models that derive real-time attributes from raw task data: daysOpen, daysBlocked, isOverdue, isDueSoon, and isStale. These feed into a dashboard that automatically segments tasks into sections: New, Blocked, Active, Due Soon, and Stale.

This was the first moment she leaned forward and said, 'Now I can see what I need.' The blocked section, showing exactly who's blocking what and for how long, was the feature that clicked. No more digging through emails to reconstruct context before a meeting.

Round three focused on the narrative layer. She needed a way to attach timestamped notes to tasks, creating a running log of updates, decisions, and context. I added an activity log per task with dated entries.

Then came the quarterly report feature: select a quarter, and the system generates a summary of completed tasks grouped by project, currently blocked items, and aggregate statistics like average days to completion. What used to take her half a day of spreadsheet archaeology now takes one click.

The final round was about friction removal. Drag-and-drop reordering on the Kanban board using @dnd-kit. Resizable sidebars. Keyboard shortcuts. JSON export and import for backup. And critically, the portable build strategy: using electron-builder, I configured the app to compile into a single .exe with a data/ folder alongside it. No installation, no admin rights. She can run it from anywhere.

The real validation wasn't a thumbs-up on a feature demo. It was when she started opening TaskDashboard every morning without being asked. She uses it to prepare for meetings, reviewing blocked items and recent activity logs so she walks in with full context. At the end of each quarter, she generates her summary report in seconds.

She went from losing track of blocked tasks in a sea of Excel rows to having a structured, searchable, always-available system that reflects how she actually works: ongoing, hierarchical, and context-rich.

This project reinforced principles I apply in my professional work, but with sharper clarity because the feedback was immediate and unfiltered:

• Listen before you architect. The ongoing-responsibility insight would never have surfaced from a requirements document. It came from a conversation.
• Ship early, iterate fast. Four focused rounds beat one massive delivery. Each round built trust and surfaced the next priority.
• Derived data beats raw data. Users don't want to calculate how many days a task has been blocked. Compute it for them and surface it visually.
• Portability is a feature. For a non-technical user, 'double-click the exe' is the entire onboarding process. Zero friction means immediate adoption.

If you're interested in the implementation details or want to build your own portable version, the full source code is available on GitHub: https://github.com/LiorSherbaty/HRTaskDashbaord.