American Pool and Spa

Flagship Case Study · Working Product

Overview

I started with a provisional idea for an app, then refined it by listening closely. A discovery interview brought the actual center of gravity into focus: a simple way to see where each build stood, without turning the product into a broad business platform.

That shift shaped everything that followed. American Pool and Spa is a Working Product, but this story starts before the interface—with the whiteboard-and-memory workflow it needed to clarify. The strongest proof is not that I arrived with a perfect plan. It is that listening closely changed the direction of the product.

Context & Problem

The starting point was straightforward and easy to overlook: status lived on a whiteboard and in memory. That worked until the work became harder to hold in one place. The product did not need to become every system around the job. It needed to make the next meaningful state of a build visible.

I focused the experience on a fixed sequence rather than a catalog of loosely related tools. That made room for the decisions that actually affect movement through the work: whether a selection is still outstanding, whether the right items are ready before a trip, and whether a phase has reached its required gate.

Katey’s Role

I led the translation from discovery into product direction. I came in with a starting concept, listened for the concrete moments that caused friction, and used those moments to narrow the scope. From there, I modeled the workflow, made blockers visible, and gave each important transition a clear place in the product.

Where this story uses interface evidence, it uses recreated, representative views with fictional data rather than production screenshots. That keeps the focus on the product decisions—the status view, selection tracking, and bring-list behavior—without exposing private records or turning the work into a data dump. A little restraint goes a long way here.

Process & Key Decisions

What I heard	What changed
They needed the app to do what the whiteboard did: show where every build stood.	I focused the product on one fixed, 14-phase workflow—not a broad business platform.
Customer selections could hold up work without making the delay visible.	I added selection-status tracking so the team could see what was still needed before work moved forward.
Forgotten tools or materials cost the team significant time driving between job sites and the shop.	I added a per-job bring list so they could capture what they needed before leaving.

Designing for the Field

The workflow is deliberately sequential:

Estimate & Design
→ Engineering & Permits
→ Dig
→ Plumbing
→ Rebar
→ Pre-gunite inspection
→ Gunite
→ Tile
→ Concrete / decking
→ Equipment set
→ Safety / barrier inspection
→ Plaster
→ Startup
→ Handover.

Seeing the full path in one place turns an abstract schedule into a readable system of progress, dependency, and wait.

Two inspection moments are hard gates. Pre-gunite inspection comes only after dig, plumbing, and rebar; safety/barrier inspection follows equipment set and must clear before plaster.

In this project’s configured workflow,

gunite waits three days in summer or until the next day in winter before tile,
and concrete waits until the next day before equipment set.

The interface makes those dependencies visible instead of treating every phase change as equally available.

Field constraints shaped the interaction model, too. Updates happen in short, one-handed, low-attention moments—sometimes with gloved hands—so the product favors a clear current phase and small, purposeful actions over a dense control surface. The goal is not to digitize every detail of the work. It is to make the next decision easier to see and act on.

Solution or Current State

The current-state story is a focused field product organized around a fictional status board and representative examples of selection tracking and per-job bring lists. The interface evidence is explicitly recreated and fictional, but the product direction is real: show the build’s place in the workflow, surface what is still needed, and support a quick update when the work moves.

The product remains accurately described as a Working Product. The evidence stays focused on the product behavior and decisions visible in this case study.

Evidence & Outcomes

The interview-to-decision map and the 14-phase workflow connect the original discovery to concrete product choices. The latest verified feature milestone covers the pool-burial Done flow and Costs/Profit behavior. That establishes a specific checkpoint in the product’s development, not a claim about time saved, revenue, or broader business results.

A closer look

Representative product details. The status view, selection tracking, and bring list are three expressions of the same idea: make the next dependency visible before it becomes a surprise.

Feature milestone. The pool-burial Done flow and Costs/Profit behavior show how the product can hold a clear, bounded state without losing the focused structure that shaped the original workflow.

Reflection & Next Steps

This project reinforced a habit I want to keep: arrive with a point of view, but hold it provisionally. Listening helped me give the real shape of the work a clear system. A whiteboard can be deceptively wise; the job was to preserve its clarity while making the workflow easier to follow.

The lasting lesson is to keep the story as precise as the product direction that earned it. This case study is strongest when it shows the reasoning plainly and lets the evidence do its quiet, persuasive work.