Hi, I’m Elisa (rhymes with 🍕)





THE CHALLENGE
The original MVP was difficult to use and not well defined, hindering Sugarwork’s ability to scale.

We had a powerful team of engineers, but no one in product to lead the process.


THE SOLUTION
A tightly scoped, flexibly designed platform that can support knowledge-sharing at enterprise scale.


THE IMPACT
CLOSED FIRST CUSTOMERWithin the first 2 weeks of this version being demoed to customers, we closed our first paying customer.
This platform has supported 10 customers and generated $300K+ in revenue over 12 months.

AUTOMATED ONBOARDING
Reduced user onboarding time by 75% and customer set-up time by 90%.
We never had to deliver another webinar to onboard users.
We supported 500 users on the platform without a dedicated customer success hire.

LAID THE FOUNDATION FOR SUCCESS
Bugs were reduced by 75%, so the engineering team could focus on value-added features
I was promoted to head of product and able to grow the team

MY ROLE
Lead strategy, product, UX/UI design. Scope the work and manage delivery.

Lead team of engineers and visual designer to deliver the right features rapidly

KEY ACTIVITIES
Defining the Problem

  • Aligning on Priorities

  • Scoping and Planning

  • Clarifying the Domain Model

  • Fundamental Design Improvements

  • Moving on!
TOOLS
FIGMA

FIGJAM

ASANA

NOTION

SENDGRID


PROCESS

UNDERSTANDING SUGARWORK’S AMBITIOUS VISION        To capture the critical knowledge inside people’s heads
THE PRODUCT WAS HINDERING SUGARWORK’S GOALS
    Poor product definitions and lack of design required webinars and 80-100 weeks during the first customer deployment.

REFLECTING IN-DEPTH ON LEARNINGS OF 1ST DEPLOYMENT
      I facilitated a workshop in my third week to dive into the pain points from a business and engineering perspective. 
CLARIFYING THE PAIN POINTS
      I facilitated a workshop in my third week to dive into the pain points from a business and engineering perspective. 
FURTHER PRIORITIZING TO DELIVER OPTIMUM VALUE
    This value chain and its priorities continue to drive product decisions
DEFINING THE MVP SCOPE
    It was important to be ruthless on the scope so that we could complete the work quickly
DEFINING THE APPLICATION’S DOMAIN MODEL
    I worked with the senior engineers to precisely define the domain model to inform the data model. 
EVALUATING COST/BENEFIT OF ARCHITECTURE OPTIONS 
    There are few simple decisions when building an application from scratch. This is one example of how I helped the business and engineering speak the same language.
DEFINING FINELY GRAINED PERMISSIONS MODEL
    Some of the most complex work came in moving from role-based permissions to fine-grained permissions.
FORMER PARTICIPANT EXPERIENCE
     Didn’t work well: only 30% of pairs completed the work. There was tons of scrolling, the text was difficult to read, and rigid definitions that hindered users’ progress.
NEW PARTICIPANT EXPERIENCE
     Basic design best practices (visual hierarchy, information architecture, minimal scroll, dynamic elements) made a big difference in prospects’ perception of the product and users’ ability to use it.
CELEBRATING THE COMPLETION
     This high-trust, humble, ambitious team made this incredible feat doable. 
LAYING OUT THE ROAD AHEAD!
     Once we had a stable platform, it was easier to see the target trajectory from manual, white-glove service to self-service.

LESSONS LEARNED


Replatforming sucks but can be worth it
  • Document, Document, Document
  • In Product, tackle what is easiest, clearest first; 
  • hope that eventually the hard thing becomes the easy thing
  • A high trust team is worth its weight in gold
  • Do the thing that intimidates you
  • There are engineers that are too fast for sprints (hi Sasha!)