Creating Shared Language: Good, Better, Best Framework

Teaching Teams to Ship Value Progressively Instead of All-or-Nothing

Role: Director of Product Design
Partners: Product Management and Engineering Leadership
Impact: Adopted across the entire organization; developed further into a company-wide planning framework after the acquisition

The Problem

Design work was being treated as 'all or nothing,' which was breaking our delivery process and limiting what Paycor actually delivered.

Here’s what kept happening: Designers would create comprehensive visions showing what a great solution could be. Product and Engineering would look at the scope and say “we can't build all that in one quarter.” So teams would scramble to cut features to fit the timeline — but those cuts weren't strategic, they were reactive. No one asked “what's the minimum that delivers value?” They just asked “what can we finish by end of the month?

What shipped was often one of two bad outcomes — either it was technically feasible but didn’t deliver real user value, or it was so stripped down it didn’t actually solve the user's problem.

Worse, once something shipped, product leadership saw it as “done.” No one went back to build a better version because no one had documented what that even looked like. Teams just moved on to the next priority, leaving behind half-finished solutions that disappointed users and frustrated designers.

What Made This Hard

Shipping “Good” felt like lowering the bar. The hardest part was cultural, designers equated shipping less with compromising quality. We had to make “Good” feel like a strategic choice, not a concession.

Planning for Better and Best took discipline. Teams wanted to design one solution and move on. Asking them to think through all three tiers upfront was more work in the moment, even though it saved rework later.

It had to survive planning, not just design. A framework that lived only inside design wouldn’t change what shipped. It needed Product and Engineering to plan around it, which meant earning their buy-in, not just the design team’s.

How I Approached It

I created the Good, Better, Best (GBB) Framework — a structured approach for scoping design solutions in three intentional tiers.

Good Solves the core user problem with minimal complexity Delivers measurable value Can ship quickly (2-4 weeks) Creates foundation for iteration Clear limitations are acceptable tradeoffs

Better Adds capability and polish that improves the experience Addresses common use cases beyond core Removes friction points from Good Typically 5-8 weeks to build Still has some known limitations

Best The comprehensive vision that fully realizes the opportunity Solves edge cases and complex scenarios Includes personalization and advanced features Creates competitive differentiation Typically 3+ months

Wireframe example of a good, better, and best version of an employee analytics dashboard

The Decisions That Mattered

1. We Made “Good” Acceptable

The biggest cultural shift was making teams comfortable shipping the Good tier. By explicitly defining Good as “solves the core problem and creates foundation for iteration,” we gave teams permission to ship value fast instead of waiting for perfection.

2. We Required All Three Tiers Upfront

Teams had to think through Better and Best during planning, not just design Good. This prevented the “we'll figure out v2 later” mentality that led to solutions never getting improved.

3. We Focused on User Outcomes, Not Features

Each tier had to articulate what user problem it solved and what limitations were acceptable. This prevented teams from just cutting features arbitrarily — they had to think about value at each stage.

4. We Built It Into Planning Process

After the acquisition, its value carried forward. It was developed further into a company-wide planning framework, used well beyond design.

What Changed

GBB started with three portfolios, and their feedback showed what shifted:

Tradeoff conversations became easier. Instead of arguing about which features to cut, teams discussed whether Good solved enough of the problem to ship. The framework gave everyone shared language for scope decisions.

Teams could argue for continued investment. Before GBB, once something shipped, it was hard to justify improvements. With Better and Best documented upfront, teams could show stakeholders the value path: “We shipped Good, here's the usage data, and here's what Better would unlock.” Some teams successfully secured funding for future quarters this way.

Solutions actually got iterated. Because teams documented Better and Best during planning, there was a roadmap for improvement. Work didn't just stop at Good — teams knew what to build next when the opportunity came.

The biggest validation came after the acquisition, when GBB was developed further into a company-wide planning framework — used not just for design work, but for product planning across the organization.

What I Learned

Shared language changes culture. The simple act of naming the tiers — Good, Better, Best — gave teams a way to talk about scope that didn't feel like compromise or failure.

Documentation prevents amnesia. Writing down Better and Best during planning meant that knowledge didn't disappear when the team moved to the next project. Teams had a roadmap for iteration instead of starting from scratch each time.

Good frameworks scale beyond their creators. That GBB spread well beyond design, and beyond the team that built it, showed it solved a real problem." Simple systems spread because anyone can use them.

Project Details

My Contributions Created the three-tier framework and guiding principles Developed real-world examples and application guidelines Rolled out to design teams and trained on usage Partnered with product leadership to embed in planning process Documented common pitfalls and how to avoid them

Team Credits Product Design Team: Pilot testing and feedback refinement Product Management Leadership: Adoption and advocacy