How do you build a PM system that a company actually uses?

Overview

• Built a project management system from the ground up as the first UX hire at a growing company

• Aligned Research, Design, and Engineering around shared workflows and visibility

• Iterated on the system collaboratively, earning adoption across all three functions

Background

When I joined as the first UX hire at a B2B software company, there was no shared system for managing work across Research, Design, and Engineering — and it showed. Priorities were siloed, handoffs were unclear, and it was difficult to predict timelines or capacity. I partnered with C-Suite leadership to design and implement a project management system that could support a growing team and a maturing product process.

I had never been at a product company that didn’t have some form of project tracking, so the absence of one was the first thing I flagged when I came on board. Without a shared system, it was hard to manage expectations — with leadership, with my team, and across functions. We needed something that could support long and short roadmap planning, be understood by all, and scale as we grew.

The Problem

While the company was about 150 strong, the engineering department was less than 30 engineers, product managers, UX designers, and UX researchers. The rest of the company couldn’t understand why we couldn’t build them something new for this or that client within a couple of weeks. We needed a way to make the work of the department clearer and more transparent - so I started by estimating the time of various projects using a “T Shirt” sizing metaphor - XS projects take less than 10 hours, S projects take 10-15 hours, and so on. My attempt to visualize project size for my team captured the attention of the VP of Engineering, who asked me - can you help me set up a new project management system?

The challenge wasn’t just picking a tool. It was designing a process that three different the three different functions with different working styles and different definitions of “done” would commit to, while increasing transparency and trust with our non-engineering stakeholders.

Approach

Our project management system was customized to our department, with three major influences: the Shape Up system of product management, a custom idea tracking tool, and my concept of project “t shirt” sizes.

Shape Up

Two of the biggest stressors the company faced were stakeholders expecting the engineering team to do high-touch, custom work with little notice and too short of a time frame. Shape Up appealed to our leadership because it required work to be “shaped:” clearly defined work to be completed over a specific time period. We used this system as our base, but we adapted it to our unique needs for 8 week work cycles:

• Cool Down: We spent two weeks in a “cool down,” planning, shaping, and gathering requirements for work. A committee of a UX Lead, the Product Manager, and the Technical Lead reviewed pitches to evaluate if the work was feasible, aligned with product vision, and could be executed in the next sprint. We kept work that wasn’t scheduled in a back log to be revisited next cycle.

• Work Sprint: The next six weeks, individual contributors executed work on the road map.

Pitch Tracking System

Our team knew that expecting our colleagues to change their behavior by adopting our system was trigger opposition, so we wanted to help them feel like they had a voice in the product development process. Our team built a tool where anyone in the organization could submit a “pitch” or a feature idea for one of our three products. They could also vote on ideas based on feedback they were receiving from clients to inform our Product Managers’ roadmaps. I watched my engineering colleagues bring this attempt at democratizing the future state of software within a day. As they coded, I gave heuristic analysis style feedback during the creation of this tracking system to help make it as user friendly as possible in an expedited time frame.

After working with our internal tool for a few months, we observed low rates of adoption, and decided to prioritize systems that helped up build and visualize roadmaps. We sunset our internal tool and tested project management software, starting with Monday.com then evenatually finding Notion fit our needs better. We found that regular touch points with key stakeholders served our organization better, and adjusted accordingly. What lasted was our approach to scheduling projects.

Project “T Shirt Sizes”

My concept of “t shirt” project sizes helped make the abstract nature of roadmap planning concrete for stakeholders. This framework was built into the pitch tracking tool, which allowed the system to automatically predict and visualize timelines for the person creating the pitch, simultaneously educating people in the process. If pitches were too big, we could have conversations with stakeholders how to break the work down into feasible chunks & check in regularly. Breaking work into small bites was intentional — it made progress visible and kept teams from going dark between milestones.

Iteration & Adoption

I didn’t build this once and hand it off. I checked in regularly with each function, adjusted the structure based on feedback, and facilitated conversations when the system revealed misalignment rather than hiding it. When we received feedback that the roadmaps still felt opaque, I began hosting “Work Cycle Recap” presentations, where my team and the product managers gave roadmap updates, giving the organization the information they need to manage client expectations and have meaningful conversations about the future of our products and our company.

Results & Impact

The PM system gave the UX department a shared language for prioritization and made our work legible to the rest of the organization. It reduced friction at handoff, supported roadmap conversations with executive stakeholders, and created a foundation for the team to scale. One of the things I’m most proud of is that two VP level stakeholders referred to my team as the most organized they’d worked with at the company under my leadership — not because I imposed structure, but because I built something that worked for all of us.