< back to portfolio

<aside> 💡

Executive Summary

• Context: Companies plan performance in very different ways (OKRs, strategy maps, sales goals, individual targets). The challenge was to design one Plans & Goals module flexible enough for all of them, starting from a vision that lived in stakeholder conversations, not in a spec.
• Approach: I treated discovery as a design problem: frame the right questions, give stakeholders something concrete to react to, and make every decision traceable. Claude Code was my working partner throughout. It synthesized meeting transcripts, kept a living spec consistent, and helped me model the data and build rough wireframes inside a clickable prototype.
• Role: Product Designer & Product Owner (Hybrid — AI-Augmented Product Lead).
• Core Impact: Three validation rounds took an ambiguous domain to a validated data model and wireframes. When a core assumption was overturned, the whole workspace was updated in days, not rebuilt. </aside>

1. Structure Before Screens

The obvious brief was “build OKRs.” The real problem was harder. OKRs, balanced scorecards and sales goal plans look alike but behave differently, and the product had to support all of them without becoming several products glued together.

So before designing screens, I needed answers to structural questions. Is OKR a plan type or something else? Do indicators belong to a plan or to the company? What does it mean for one plan to “cascade” into another? Getting these wrong would mean redesigning everything later.

The project paused at the wireframe stage, so this case is about how I got to the right structure, not about shipped metrics.

Home page for the discovery wiki

2. Research That Ends in Decisions, Not Features

Before reading a single stakeholder transcript, I used Claude Code to benchmark established goal-management and performance platforms. The output wasn’t a feature list. I framed it around the decisions the module would have to make, each one paired with how the market splits on it.

That framing changed every meeting that followed. Instead of asking stakeholders what they wanted, I could ask them to take a position on a specific trade-off.

TD;DR excerpt from the benchmark

I also wrote a short Fundamentals primer that explains each planning concept and how it appears in the software. It became the onboarding doc for anyone joining the project, and it forced me to understand the domain well enough to teach it.

Excerpt from the Fundamentals

3. A Discovery Loop Built for Reaction

When a key stakeholder was unavailable for an open discovery session, I flipped the approach. Instead of diverging in a vacuum, I sketched structure, flows and rough wireframes first, and used the next session to validate and react to something concrete.

Each round followed the same loop. The judgment calls stayed with me; Claude Code handled the parts that usually decay.

This is the kind of change that usually forces a restart. Because every rule was documented and cross-referenced, Claude Code found everything the decision touched (spec, glossary, flows, backlog) and proposed consistent edits. I reviewed them, and the whole workspace moved to a new discovery version in one cycle.

5. Key Design Decisions