As a Director of Product Design, I am admittedly biased, but I believe high-visibility initiatives start with Product and Design. While engineering or sales might trigger strategic moves, the product team takes the lion’s share of customer-facing work.
We operate as the critical interface between technology, customer feedback, and executive vision. Because of this, designers cannot just be “screen makers”, we must be feature owners.
Here is my framework for ensuring success on your next big project, from the initial idea to the final release notes.
1. Prep: Define the “North Star” & Operationalize It
Before a kickoff meeting ever hits the calendar, the product team needs to do the heavy lifting. It is our duty to populate the backlog not just with requirements, but with a vision.
- The North Star: I always start by designing the ideal state. Populate the top of the backlog with well-thought-out UI patterns, interactions, and error states. If existing Design System components work, great. If they need an overhaul, detail those updates carefully so engineers can evaluate the lift accurately.
- The Translation: Design files aren’t enough. I create base-level user stories in our task management platform. I detail expectations for Front-End (FE) and Back-End (BE) work, such as layout logic or modeling new interactions.
Why this matters: When you walk into a kickoff with a visual plan and ticketed user stories, the project feels real. Engineers can see requirements immediately, and the conversation shifts from abstract ideas to concrete execution.
2. The Kickoff: Align on the “Why” and “Who”
The goal of a kickoff isn’t to solve every problem; it’s to align on the problem space. I try to keep these focused (30 minutes max) to introduce the topic without overwhelming the team.
- Bring Data: Show customer feedback or usability tests that prove the need for this feature.
- Assign Point-People: Explicitly identify cross-functional partners. Who is the FE Lead? Who is providing BE support? Who from Sales is determining pricing?
- Start the “Low-Hanging Fruit”: You will likely still have unanswered questions about scope during the kickoff. That is okay. Don’t let negotiation stall progress. Identify the “low-hanging fruit”, work like research spikes or foundational infrastructure that developers can start immediately without risking throw-away work.
3. Mastering the Art of the MVP
Once work begins, the difficult questions arise. How much can we actually ship?
Defining the MVP (Minimum Viable Product) is as much art as it is science. As designers, we naturally want to protect the “North Star” scope to favor feature-rich releases. However, roadmap constraints often require us to cut scope.
When deciding what to cut, I ask myself these four questions:
- Is it better than the existing UX?
- Are there reasonable workarounds for the missing features?
- Can users recover from errors in this state?
- Does it still address the primary goal of the customer request?
If the answer is Yes, it is safe to cut scope.
The “V2” Trap: Never cut scope with the promise that “we’ll fix this in V2.” In my experience, V2 rarely happens. New priorities will always appear. If you ship a feature with bad UX or tech debt, assume you will have to live with it as a crystallized part of your product for a long time.
4. Execution: Incremental Testing
Don’t wait for a “Big Reveal” release candidate. I advocate for testing as developers merge PRs into lower environments.
As a designer, I am functionally testing updates alongside the engineers. This allows me to:
- Catch unaddressed edge cases early.
- Create new patterns for requirements we missed during scoping.
- Drastically reduce the time needed for final regression testing, as bugs are squashed the moment they are introduced.
5. The Close: Documentation is Part of Design
Once the feature is released and users are happy, the work isn’t quite done. Real product maturity is demonstrated in how you wrap up a project.
- Update the Single Source of Truth: Ensure your documentation and Design System reflect the new interaction patterns.
- Enable Marketing: Demo and share high-res screenshots with marketing and sales teams.
- Release Notes: Ensure the value proposition is clearly articulated in the public release notes.
Final Thoughts
Leading high-visibility initiatives requires more than good Figma skills. It requires the ability to navigate ambiguity, negotiate scope without compromising quality, and partner deeply with engineering. When Design steps up as a true owner, the whole product wins.