Building the product operations that reduced rework by 60–80%.
SKED's product ambitions were outpacing the processes that supported them. I developed bespoke discovery, requirements, design, and review processes that aligned five departments around shared specs — supporting the organization through its acquisition by ChiroHD.
Role
Strategic Product Designer
Industry
Chiropractic Software
Timeline
Ongoing (~3 Years)
Platform
Web App & Mobile
Context: A patient experience and operational efficiency platform serving 1,000+ chiropractic offices, layered on top of EHR systems.
Result
60–80%
Less Rework
The Situation
SKED — scheduling, messaging, and operational tools for 1,000+ chiropractic offices.
SKED had been growing steadily for years, but scaling the team had outpaced the organization's ability to keep everyone aligned on what was being built and why.
I had first worked with SKED years earlier on the initial mobile app designs. When they brought me back, the original challenge was improving design adherence — but within my first couple of months, I identified a deeper issue. It wasn't design quality. It was communication.
The workflow was linear: leadership would declare a vision, engineering would interpret it and build, and then everyone would gather for a demo. These demos had become a point of frustration — not because anyone was doing poor work, but because there was no way to align on intent before code was written.
"Before, we didn't have any standards in the project, in terms of UI and UX."
André Pinheiro, Engineer
Leadership
Leadership had strong product vision, but the rationale behind decisions diluted as it moved through the org.
Engineering
Developers interpreted vision as best they could, but unclear specs meant builds often missed the mark.
Support & Sales
Customer-facing teams had critical insights from the field but were brought into the loop too late.
The Diagnosis
The team had outgrown the informal handoffs that worked at an earlier stage — vision was strong, but the path from strategy to implementation needed a bridge.
The key insight: I proposed that my role shift from pure product design to bridging communication across departments — translating vision into requirements and mockups that made decisions visible and debatable. None of this would have worked through top-down mandate. I didn't have formal authority over other departments, so everything depended on earning relational capital: listening well, understanding each team's constraints and motivations, and facilitating discussions where people felt genuine ownership over the outcome.
The System
The product lifecycle I established spanned from kickoff through design review, feeding into the broader development and release pipeline.
Two principles gave us an edge: first, we sketched and prototyped before writing formal requirements — mockups sparked richer conversations and surfaced hidden challenges sooner. Second, our requirements balanced being lean enough to stay ahead of the dev team with being detailed enough to capture every edge case.
Rapid-capture sessions with leadership, support, and sales to surface unfiltered ideas before any design work begins.
I conducted focused interviews across departments — listening more than debating — and what came back was a wealth of product knowledge that had never been centralized: anticipated concerns, desired workflows, things people explicitly didn't want, and directional insights.
The Broader Lifecycle
These four phases were part of a nine-step product lifecycle that also included feature selection, development, code review, QA, and release. I owned the phases above; the broader team owned the rest.
The Design System
A comprehensive design system in Figma, mirrored in the codebase as a component library developers could build with directly.
This wasn't just a style guide. I built the Figma system and oversaw its replication in the codebase, ensuring developers had a 1:1 reference library. Being able to speak their language, understand architectural constraints, and contribute code directly meant the system was practical — something the team could actually build with, not just reference.
"With standardization, it improved both visually and in terms of how to work with it — the colors and the components."
André Pinheiro, Engineer
UI Components
Buttons, inputs, modals, navigation, and layout primitives — all documented with usage guidelines.
Interaction Patterns
Standardized behaviors for common flows: forms, confirmations, error states, and loading sequences.
Design Tokens
Color, typography, spacing, and elevation values shared between Figma and code — a single source of truth.
Code Library
A developer-facing component library mirroring every Figma component, reducing interpretation gaps to near zero.
Accountability
The team had operated on trust and informal check-ins — which worked at an earlier stage. As the product grew more complex, I saw an opportunity to make that accountability more visible and structured.
I established a tracking system for spec completion, timeline adherence, and deliverable throughput — then reported directly to leadership on a regular cadence.
What was tracked
Deliverable completion rates, timeline adherence per feature, and whether the pipeline was keeping the dev team unblocked.
Delivery rate
Consistent on-time delivery across design specs, requirements docs, and review cycles.
Planted a seed
After the ChiroHD acquisition, the incoming Chief of Product built on this foundation with standardized reporting across all departments.
The Impact
60–80%
Estimated reduction in feature rework
Features shipped cleanly through the lifecycle on the first pass, with most design demos receiving zero change requests by the time the process matured.
4–5
Developers in continuous flow
The lifecycle eliminated the spec bottleneck — the full development team stayed productive without idle time or waiting on requirements.
5
Departments unified into one process
Leadership, engineering, support, sales, and design each had defined roles in the lifecycle — with clear moments to contribute, review, and approve.
Engineer Perspective
Kevin Bloom · Full Stack Engineer
Before
~95% of features needed UI rework
~80% needed data/logic rework
~30% required full rewrites
After
~30% needed UI changes
~15% needed data/logic rework
0% full rewrites
"The process dropped our rework down significantly. Very seldom do we ever have to redo work. The requirements were very thoughtfully written and covered nearly everything."
The trade-off was speed: the pipeline took longer to move features from idea to code, and design review could occasionally feel exhaustive. But the team found the reduction in rework more than justified the upfront investment.
Company-wide design demos became a highlight rather than a pain point — many received zero change requests because decisions had already been resolved.
If sales cared about something working a certain way, they could get it. If engineering had architectural constraints or a future direction to build toward, they could voice it.
Changes that would have previously cost weeks of development time could now be caught and resolved while the cost of change was still low — in mockups and docs, not in code.
Recognition
Impact Through Innovation Award
After the ChiroHD acquisition, I was selected for the Impact Through Innovation award — honoring individuals who push boundaries with conviction and curiosity to spark meaningful breakthroughs.
During the acquisition, the incoming leadership recognized the product lifecycle and requirements process as organizational strengths worth building on.
Looking Ahead
This product lifecycle served SKED well for three years — but as AI reshapes how software gets built, the process itself needs to evolve.
The premise
Feedback loops accelerate every phase.
The shift
Continuous, spec-driven, AI-augmented.
What changes
Requirements become machine-readable
Structured repositories that AI agents can surface broadly — not Google Docs designed for human readers.
Design-to-code cycles tighten
Lower-fidelity specs with rapid experimentation happening directly in the codebase, not in static mockups.
Go-to-market becomes the bottleneck
When requirements and engineering accelerate dramatically, the real constraint shifts to sales, marketing, and support keeping pace.
Quality gates automate
Shared AI coding standards handle routine design review, and testing is built in from the outset rather than bolted on.
In early 2026, I attended the Gauntlet AI Applied AI Engineering program alongside senior PMs and engineers from 60+ companies. The experience helped inform SKED's transition to spec-driven development — built on the foundation of the product lifecycle above.