For 7+ years, I've been part of the entire process β planning Produtct, working with engineering, design, and operations, and taking features from a rough idea all the way to launch. I know how software gets built, where things go wrong, and why users get stuck.
I've worked across hardware, software, and B2B SaaS β from Wi-Fi routers and mobile apps to complex admin platforms. And because I started in UI/UX, I don't just know what a product does β I know how people actually use it, where they struggle, and how to fix it.
I started my career in design and later transitioned into Product Management. Because of this background, I have developed a strong ability to clarify ambiguous requirements, understand different stakeholders' perspectives, and turn abstract ideas into concrete product features. I enjoy analyzing problems, organizing complex information, and translating unclear needs into practical design solutions.
As I gained more experience in software development, I also developed an understanding of what the work actually involves. Beyond requirement analysis, a large part of Product Management is about roadmap planning, feature prioritization, development scheduling, resource coordination, and balancing the needs of different stakeholders. These responsibilities are important, and I believe I have performed them well. However, over time, I realized that they are not the parts of the role that motivate me the most.
The work that gives me the strongest sense of achievement is work that brings me closer to customers.
This became even clearer through my part-time experience as a Pilates instructor. Students come to me with different problems, goals, and limitations. My role is to first understand their situation, analyze the cause, and then use my professional knowledge to provide suitable guidance and help them improve. When I do not have the best answer immediately, I am willing to spend extra time researching, reading, and learning from other instructors, so that the next time I work with the student, I can provide a more complete and effective recommendation. Seeing someone improve or reach their goal because of my support has consistently given me a strong sense of accomplishment.
Over time, I realized that what attracts me is not teaching itself, but the process behind it: understanding a problem, applying expertise, giving thoughtful recommendations, and helping someone solve a real issue.
I want to bring this way of working into a business environment.
This is why I have started to think more seriously about my long-term career direction. I want to move toward a customer-facing role where I can work more directly with clients, understand their real business challenges, and use my product knowledge and business understanding to recommend suitable solutions. Compared with spending most of my time on internal requirement coordination, prioritization, and development management, I find myself more motivated by work that involves direct customer interaction and practical problem-solving.
I am also drawn to commercial roles because they are results-oriented. In Product Management, the value of one's work can take a long time to become visible. In Sales, the goals and outcomes are clearer. I enjoy challenges, and I want my effort to be reflected more directly in business results. What I want to do is not simply sell a product. I want to build trust with customers through my expertise, understand what they truly need, help them find the right solution, and create value for both the customer and the company.
For me, transitioning roles is about building on the foundation I have already developed and better fits my strengths, interests, and long-term motivation. My background in design and product management has trained me to understand users, structure complex problems, and connect needs with solutions. I now want to apply those strengths in a role where I can be closer to customers, contribute more directly to business outcomes, and continue growing in a customer-facing commercial career.
π Based in Taiwan. Also open to relocate or remote.
My approach to product work is iterative, honest, and structure-loving.
βοΈ Email: chiangyichieh@gmail.com
It's a platform monitor data center clusters. Over the years, the platform was expanded without a clear structure. Features were added one after another, which led to confusing user flows and inconsistent visuals across modules. This made it harder for new users to understand the system, and also slowed down internal collaboration.
I joined the team as both a designer and interim Product Manager to define a coherent experience and resolve gaps in developer collaboration.
My role involved translating ambiguous requirements into scoped wireframes, design UI layout, driving cross-functional alignment, and codifying interaction logic into a reusable system across modules.
This project focused on redesigning an platform used by our support team to monitor data center clusters and troubleshoot system issues. Over time, as more third-party services were added, the platform started to feel messy. Also, the inefficiencies in daily workflows like check status or identify errors need refinement.
The project has these primary goals:
While not a commercial product, internal adoption and productivity were the key success markers.
Our primary users were support engineers and platform ops teams responsible for managing hundreds of active clusters. They needed fast, reliable visibility into system logs, health checks, and configuration states to triage incidents and minimize downtime.
| Work stream | My Actions | Direct Impact |
|---|---|---|
| Project framing οΌProposed Solution | - Defined project goals based on stakeholder inputs and product gaps. - Designed modular solutions (Modules see below) | Created a structured and scalable solution focused on user and business value. |
| Design-spec clarity | β’ Created mockups and UI-logic breakdowns in Figma. | Developers had clear references and could start immediately; Reduced follow-up questions and rework. |
| Team collaboration | β’ Produced end-to-end scenarios and UI copy for engineers. | Reduced ambiguity across designβdev handoff and improved implementation speed. |
| DevβQA schedule realignment | Detected a two-week development slip; rapidly re-sequenced engineering and QA tasks, locking critical paths. | Recovered a 2-week delay and still met the planned release date. |
| Issue-board visualization | Reworked the GitHub Project boardβadded explicit status columns and auto-labels so QA could pull tickets directly. | QA tracked progress without extra sync meetings. |
| Next-milestone prep | During the QA window, groomed the Milestone 2 backlog and pre-split tickets with dependencies noted. | Helped the team distinguish priorities for upcoming work. |
This initiative aimed to transform the platform into a branded and user-friendly product.
| Goals | MVP prioritized |
|---|---|
| Unified brand identity | - Create new UI library, storybook for reuse - Masking other open-source projects fragments - Restructuring dashboard layout for visibility and clarity |
| Improved usability | β’ Improve Troubleshooting flow (file upload/download) β’ Redesign Health check display dashboard and logic β’ Advancing Notification flexibility β’ Check detailed node status |
| New features | β’ Tunings modules β’ License management |
Modules
π₯ Youtube demo (27 min) in Mandarin
I presented our latest product updates, including a comparison of new vs. legacy features. (Note: the feature order differs from the list below.)
The platform originally linked several third-party tools on sidebar, each with its own styling and logic. This created a fragmented user experience that felt more like a collection of disconnected tools than a cohesive product.
I replaced iframe-based views with unified layoutsβstandardizing headers, sidebars, and page structure to reduce fragmentation and context switching. I also partnered with the designer to rebuild our UI library from scratch, documented in Storybook for consistent reuse. I also replaced iframe-based views with unified layoutsβstandardizing headers, sidebars, and page structure to reduce fragmentation and context switching.
The redesigned UI delivered a cohesive, branded interface that felt internally owned. It established a structured design foundation for future modules and enabled teams to build with greater consistency.
Information was spread across tabs with no visual hierarchy, making it hard for users to find critical data.
I conducted UI audits and mapped user flows to identify overlapping data and redundancies. I then proposed hi-fi mockups to initiate discussion and move the team from vague ideas to tangible feedback.
We implemented a new dashboard with collapsible sections and clear visual prioritization.
Users could only download logs one at a time, and inconsistent file names complicated support and escalation.
I collaborated with ops engineers to analyze usage patterns and pinpoint common naming issues.
We added batch download support.
The original health check interface displayed real time status but not stored history, leading to delays in identifying system issues.
I created health status and it history bar to monitor the logs
More detailed and history status could trace back.
Tuning configurations were CLI-only, inaccessible to non-technical teams..
This UI module reduced reliance on CLI and empowered support teams to make adjustments independently.
This UI module reduced reliance on CLI and empowered support teams to make adjustments independently.
| Stage | Timeframe | Feature / Deliverable | Rationale | Success Metric |
|---|---|---|---|---|
| Now | Public release by end of May | Platform Rebrand (brand & UI unification) | Cohesive brand experience required before going public | β₯ 80% of interviewed partner teams report that the new modules improved visibility. |
| Existing-feature improvementsβ Support file batch actionβ‘ Health status & history viewβ’ Event-ID dashboard | Addresses current pain points and boosts efficiency | Reduce operation time at least 20%(TBD) | ||
| Tunings module (new feature) | Satisfies power-user tuning needs | -Reduce tuning editing time 10% -Adoption Rate to 50% (TBD) | ||
| Notifications β Triggers Phase 1 β user-configurable notification methods | Increases alert flexibility | Reduce emergency fixing time at least 20%(TBD) | ||
| Next | 0β3 months after release | Notifications β Triggers Phase 2 β personalized conditions & automated responses | Moves from reactive alerts to proactive automation | -Adoption Rate to 50% (TBD) |
| Integrations β user-addable third-party services | High-demand request; scheduled after Rebrand stabilizes | -Adoption Rate to 50% (TBD) | ||
| Later | 3β6 months after release | Node Advanced Controls β deeper hardware-level operations | Requires backend refactor & new permission model; follows Integrations | -Adoption Rate to 50% (TBD) |
π All content has been anonymized. It's an open source project.
This spreadsheet documents the planning process for a product rebuild initiative.
It covers:
This document provides module-level UI copy text and annotation such as:
The document was written to assist engineering and QA during implementation.
This project deepened my role β from a designer primarily executing tasks, to someone who actively scopes work, makes decisions, and delegates responsibilities.
Instead of waiting for clarity, I started shaping it together with the team β asking questions, identifying gaps, and helping turn vague goals into concrete tasks. Aligning with engineers, understanding each person's workload, and breaking down unclear requirements into structured, testable tasks.
When working with unclear requirements, I've found that putting forward a proposal β rather than waiting for clarity β helps the team move forward faster. In this project, I initiated product discussions by presenting hi-fi wireframes based on my own interpretation of needs, using them as starting points to frame decisions.
This approach speeded up our conversations. Instead of debating abstract possibilities, we could evaluate actual workflows, uncover missing logic, and focus on what needed to change. Even when a proposal wasn't feasible, it anchored the discussion and reduced time spent circling around the same questions.
By breaking down features visually and resolving one topic at a time, we created shared understanding more efficiently. Before this, we often spent hours debating small assumptions; now, by breaking down features one by one through visuals and structured sessions, we were able to reach consensus more efficiently β and turn uncertainty into actionable steps.
I also started taking more responsibility for how work moved through the team. I helped coordinate QA schedules, triaged issues, and kept our GitHub board organized so that QA could track progress directly β even though we didn't have an SOP for that, and it was my first time using GitHub for issue management.
These were small things β updating statuses, checking who's blocked, labeling tickets β but they made a noticeable difference. We spent less time syncing. I began to see that a good implementation isn't just about product decisions β it's also built through everyday maintenance.