Dooly — Building the Organization That Ships the Work

Overview

Dooly was an AI-driven sales enablement platform helping revenue teams capture, organize, and act on deal intelligence. The company had product-market fit and engineering momentum, but design was struggling to keep pace. There was no design organization — just individual designers attached to product teams with no shared standards, no critique process, no unified design vision, and no representation at the leadership level.

The company needed design to scale from reactive execution to a structured practice that could support multiple product teams, contribute to strategy, and maintain quality as the product grew more complex.

The goal: Build a design organization from scratch — the team, the systems, the standards, and the leadership seat — that could support rapid product growth without sacrificing quality or coherence. And do it while staying hands-on with the product work that the organization existed to ship.

Role

Head of Design, Senior Leadership Team

I joined as the design leader with a seat on the Senior Leadership Team (SLT), responsible for the full design function across product and marketing. The role required operating at two altitudes simultaneously: building the organization and its systems while staying close enough to the product to lead design direction on critical initiatives.

• Built and led a team of seven designers spanning Product Design and Marketing Design
• Defined the high-level user journey that drove storytelling across multiple product streams
• Partnered with PM and Engineering leadership to align design vision with the product roadmap
• Introduced design principles, critique systems, and growth frameworks for the team
• Established Dooly's "Quality Bar" — the standards, tools, and rituals that defined what good looked like
• Led hands-on product design on key initiatives including Deal Vitals — a pipeline health system that addressed one of the product's highest-impact user problems
• Built user models and work-back planning methods for prioritization and release planning
• Represented design at the SLT, influencing company-level product and GTM decisions

Approach

Assessing what existed

When I arrived, design was happening — but it wasn't organized. Designers were embedded in product teams and shipping work, but without shared principles, consistent quality standards, or a unified vision for how the product should feel across experiences. Each designer was effectively operating as an independent contributor solving their team's immediate problems.

The first step wasn't to redesign anything — it was to understand the current state: what was working, what was inconsistent, and where the gaps were creating downstream problems.

Building the team

I scaled the design team from a small group to seven designers covering both Product and Marketing. Hiring was deliberate — I looked for designers who could operate with autonomy but who would benefit from (and contribute to) shared standards and critique. The goal was a team where people could do the best work of their careers, not just fill seats on product squads.

Establishing the Quality Bar

Dooly's "Quality Bar" became the organizing concept for design standards. It wasn't a style guide or a component library — it was a shared definition of what "done" meant for design work at Dooly. It included:

Design principles. A set of guiding beliefs about how the product should work and feel. These weren't aspirational posters — they were decision-making tools the team used in critique and review.

Critique systems. Regular, structured critique sessions where designers presented work to peers. The format was intentional: here's the problem, here's the approach, here's where I need input. Not a free-for-all, not a stakeholder review — a craft conversation.

Growth frameworks. Clear expectations for what "good" looks like at each level. Designers could see where they were, where they were going, and what they needed to develop to get there.

Connecting design to the product story

I defined a high-level user journey that spanned Dooly's multiple product streams. This wasn't a detailed flow — it was a narrative map that showed how different parts of the product connected from the user's perspective. It became the storytelling backbone for roadmap alignment conversations with PM and Engineering. Instead of each product team optimizing their slice in isolation, the journey gave everyone a shared picture of the whole.

Operational design leadership

Design was often brought into projects too late — after scoping and prioritization decisions had already been made. I introduced user models and work-back planning methods that gave design a structured voice in prioritization. Instead of reacting to what product and engineering had already decided, design could now contribute to what to build and in what order, not just how it should look.

At the SLT level, I made sure design had a seat in company-level product and go-to-market decisions. Design leadership at Dooly wasn't about approving mockups — it was about shaping what the company built and how it told that story to the market.

Staying hands-on: Deal Vitals

While building the organization, I stayed close to the product on critical initiatives. The clearest example is Deal Vitals — a pipeline health system I led the design for that addressed one of the most persistent user problems in the product.

Sales reps and managers lacked a clear, real-time understanding of deal health. They were manually inferring whether a deal was on track or at risk. Critical gaps — missing next steps, stale close dates, absent activity — went unnoticed until pipeline reviews, when it was often too late. The pipeline review itself relied on subjective judgment instead of observable signals.

I framed the design around a core job: when I'm managing a deal, I want to quickly understand its health and what's missing, so I can take the right action to move it forward. Deal Vitals gave reps and managers a lightweight, shared system to surface what was incomplete and what mattered — reducing anxiety before pipeline reviews, improving deal hygiene, and giving leaders confidence that their pipeline was real.

This is the kind of work the organization existed to ship well. Building the team, the Quality Bar, the critique systems — all of it was in service of enabling product design at this level of clarity and impact.

Outcomes

• Scaled design from ad-hoc delivery to a structured organization supporting 3 product teams and multiple GTM initiatives
• Increased design velocity and quality by 30% through introduced design principles, critique systems, and growth frameworks
• Built and led a team of seven designers across Product and Marketing design
• Established the Quality Bar as the company's shared standard for design work
• Created the high-level user journey that unified storytelling across product streams
• Led hands-on design on Deal Vitals — a pipeline health system that gave sales teams real-time visibility into deal gaps
• Gave design a seat at the SLT, ensuring design perspective influenced company-level decisions

What this reveals about how I work

Dooly is a story about systems over heroics — and about not choosing between building the organization and doing the work. The Quality Bar, the critique rituals, the growth frameworks — none of those depend on one person having a great week. They're infrastructure that makes quality repeatable. But the organization only earns credibility if the work it ships is good. Staying hands-on with initiatives like Deal Vitals kept me connected to the problems the team was solving and gave the organizational systems a feedback loop grounded in real product outcomes.

It's also a story about starting with the room: the user journey map became the single most useful alignment artifact because it gave product, engineering, and design a shared picture before anyone started building in isolation.

What I'd do differently

• Would have introduced the user journey mapping earlier. The journey became the single most useful alignment artifact — the team needed it sooner than I delivered it.
• The Quality Bar took time to earn buy-in across the company. I'd invest more upfront in showing non-design stakeholders why the bar mattered for their outcomes, not just for design quality.
• Would have formalized the operational rhythms (planning cadences, stakeholder review formats, design-engineering handoff checkpoints) earlier. The informal versions worked but didn't scale as fast as the team grew.