Project Context
Aside from being a valuable feature to customers, the Course Drafts project ultimately set the tone for how Skilljar approached scoped and built initiatives across product and engineering after it was released. It helped the organization develop a more disciplined product mindset that balanced speed, quality, and risk. The discipline that the team developed and honed was later cited as a positive factor during Skilljar’s acquisition by Gainsight. The processes that were incubated here were taken to the larger Gainsight Customer Hub organization.
At the time, Skilljar invested in large, long-running initiatives that often took months to launch. While the impact was meaningful when they landed well, time to market was slow and the cost of getting things wrong was high. Any miss in customer needs was amplified by the size and duration of the work.
When our new VP of Product joined, she challenged the organization to change course. The goal was shorter, MVP-sized releases that delivered value faster and reduced risk. This shift was not about moving faster at all costs. It was about making clearer bets, learning sooner, and being more disciplined about scope.
Our existing process made that difficult. Briefs were long, often 15 to 20 pages, decision-making was slow, and projects tended to accumulate features in the name of certainty. Engineering risk was minimized, but product risk increased, and teams defaulted to over-solving too early. We needed a new approach that allowed us to quickly decide what was worth building, what should wait, and what should be dropped entirely.
I was asked to lead the first project and define this new way of working because I had previously led ambiguous, cross-functional initiatives that required clarity under constraint. After early discussions with our VP of Product, we chose to explore Drafts. It touched a core workflow, had clear customer pain, and carried meaningful business implications. It was an ideal test case for shorter, higher-confidence releases.
My Role
I led the Drafts project end-to-end, from defining the problem and reshaping the brief process to hands-on interaction design. My role spanned product design, research, facilitation, and cross-functional leadership. I would partner with a PM on the build for ticket creation and testing with the engineering team. In practice, that also meant helping the team navigate the discomfort that comes with ambiguity and reduced certainty.
This project carried real risk. Shorter briefs intentionally leave questions unanswered. Smaller releases can feel less exciting. Fewer requirements increase the chance of uncovering issues later in the process. Success depended on creating clarity where it mattered most while resisting the urge to over-specify too early.
Throughout the project, I acted as a connective layer between disciplines. I translated customer needs into clear design intent, surfaced tradeoffs early, and helped the team make confident decisions under constraint. The goal was not just to ship Drafts, but to demonstrate that strong product outcomes are possible without heavy process, long timelines, or over-designed solutions.
Designing the Brief
The first step was to simplify our brief process, which had grown overly complex and time-consuming.
As we moved toward smaller, faster releases, we needed a different kind of brief. The purpose was no longer to define an entire solution, but to help the team decide whether a problem was worth solving and whether it deserved our attention now.
As we moved toward smaller, faster releases, we needed a different kind of brief. The purpose was no longer to define an entire solution, but to help the team decide whether a problem was worth solving and whether it deserved our attention now.
I realigned the brief around four core questions.
What problem are we solving for real people?
Why should we do it now?
How much is it worth?
How does it align to our company strategy?
Why should we do it now?
How much is it worth?
How does it align to our company strategy?
Everything else was secondary. If information did not help answer one of those questions, it did not belong in the brief.
Each brief allowed for one of three outcomes: proceed, pause for later, or cancel. All were treated as positive results to create psychological safety. The option to “go learn more” and come back soon was eliminated. It was either important or not.
This approach created alignment early without constraining execution. Product, design, and engineering could agree on intent, urgency, and value, while still leaving room for teams to apply judgment later. The brief became a tool for decision-making, not a contract for implementation.
To prepare, I conducted targeted customer interviews with participants who had reported frustrations to our support team. This allowed us to surface the most painful points and estimate the potential ARR impact of solving them. A clear insight emerged: customers were forced to update courses outside working hours. This became our rallying cry:
Samantha should not have to
update courses at 3:00 am!
update courses at 3:00 am!
Shaping and Collaboration
After presenting to the product review team we would choose to move forward with the project. We scoped it for a six-week engineering timeline, balancing ambition with feasibility.
With the project green lit, I led three shaping sessions with a small multidisciplinary group: myself, a PM, and three engineers. I prepared by creating a future state flow that illustrated some key areas for debate and drafting a working document where the team could comment and break down the workflow. This acted as a durable, digital whiteboard and a shared space for discussion.
A sample of the first flows to facilitate discussion. Comments were left open to capture what was discussed in the meeting. They would be used as a heat map to determine the areas that we needed to focus on.
The first meeting had the risk of only focusing on fears around timelines and scope. To mitigate this I did two things.
First, I started the meeting by saying. “There are a lot of reasons this is scary. It’s different than how we’ve worked. But for 90 minutes I want us to think about HOW we could do it. Not if we can do it. We’ll find initial gotchas, note them and move on. Let’s assume this will work and that we can do it.”
The second was to anchor our conversation to our rallying cry. “Samantha shouldn’t have to update courses at 3:00 AM.” This helped limit the scope of our conversation and problem space, and importantly keep it focused on the human beings we were building for.
The team agreed to those principles and we had a healthy discussion.
A sample of the notes that started emerging. These would get deeper as the sessions went on. Note that getting the UI right was not a priority here, getting ideas down was key.
The second session introduced higher-fidelity mockups. We refined priorities, explored technical feasibility, and identified potential risks, like analytics integration. We also made intentional decisions about what to defer, such as Live Events, which not all customers used and would have expanded scope unreasonably.
Examples of areas that we would defer or just not do. These were decided based on how close to the core problem they were and how much engineering effort they would be. We wanted to launch fast.
In the third session, we finalized scope and highlighted known risks, preparing for the build phase. The resulting document was not a PRD or technical spec. Instead, it outlined our intent, constraints, and areas requiring judgment, giving engineers a foundation while trusting them to solve implementation details.
These sessions created alignment on intent and reduced feature creep early. By the end of session three, engineering had clear direction while retaining ownership of implementation decisions.
New Design Patterns and Very Tight Scope
During shaping, a need for a new design pattern emerged: a sticky header for navigation and save functionality. Previously, users had to scroll to the bottom of long course pages to save changes. We needed a clear way to indicate “This is a draft,” and the sticky header solved this while supporting other interactions.
I kept mockups intentionally incomplete, often using bright colors to make them clearly temporary. This encouraged discussion and prevented the team from being “wowed” by a polished design too early.
Early versions of the sticky header can be seen above, as well as part of a debate around if the customer should default into draft mode or have to click a button to enter it. Comments from other contributors on where we had opportunities were tracked. Notes were written in a conversational style to keep collaboration going.
Balancing design ambition with engineering constraints was key. We wanted to meet our six-week deadline without compromising product quality. I proposed that we leave the sticky header on the table during early shaping and sizing. If it proved too large or complex, we would revisit the pattern. In this case, it fit within scope and was included successfully.
Deferring perfect design until clarity and feasibility were established allowed us to make thoughtful tradeoffs. It ensured the final implementation was both practical for engineering and meaningful for users, while avoiding unnecessary delays or over-engineering.
In this case we chose to launch a version of Drafts without the sticky header to a limited number of customers, following up very quickly with the sticky header solution. This would allow us to solve the immediate customer pain quickly, and iterate into the design solution we wanted.
Clarity Leads to Craft
Once shaping and constraints were clear, it was time to focus on pixel-perfect UI work. Something simple that could handle the complexity beneath surface of Drafts was needed.
I was able to keep it on my desk because our design team was small. Being hands-on allowed me to fully control the craft and ensure alignment with the intended user experience.
The sticky header, once approved for development, went through several variations and design critiques to balance button fatigue and clarity of navigation.
Because the problem, technical constraints, and timeline were clearly defined, I could focus on the right interactions without wasting time on ideas that would be abandoned. Early experimentation had allowed the team to work quickly and make mistakes in low-stakes ways, so by this stage we could invest deliberate effort in details that really mattered.
This approach ensured that design decisions were grounded and deliberate. It also allowed me to mentor engineers, PMs, and other team members, showing that strong craft only works when aligned with clear purpose.
As a bonus, with the sticky header no longer a blocker for Drafts (at least the beta), we made a couple of additional improvements. We connected the course directly to its publication settings and analytics, which were historically scattered across the dashboard and required six to ten clicks to access. The sticky header brought these elements closer to the course, saving users real time. Customers LOVED this change.
Details around the hover tips and RBAC controls, which allowed us to expose powerful actions without increasing cognitive load or violating admin permissions.
Outcome and Impact
Drafts launched on time, within the six-week engineering window.
Customer feedback was immediately positive, with several noting they no longer felt constrained by off-hours updates. These responses confirmed that Drafts solved the most meaningful pain point from the research. Follow-up requests for features such as versioning and scheduled publishing were seen as future opportunities rather than failures, reinforcing the value of the new brief-to-shaping-to-build process.
This approach was repeated across other initiatives and eventually became the standard workflow for the entire product and engineering organization. The process was refined as the team learned from each project and adapted it for longer initiatives when necessary, but the principles of it remained the same, even two years later when we'd redesign the Dashboard Homepage.
Drafts became a concrete example that high-quality product outcomes are possible without long timelines, heavy process, or over-designed solutions.