Home

How I work

What I bring to a product team.

Across Stck’s content formats, pricing and community features, these are the four kinds of work I do most, each with the case study that shows it.

01

Problem Framing and Research

Some of the best problems don’t arrive as feature requests. I look for signals in analytics and in the workarounds people invent, and write them up as a problem the team can argue with before anyone opens a design tool.

What this looks like

  • Reading usage data and creator behavior for signals
  • Scoping creator interviews and turning findings into features
  • Competitor teardowns
  • Problem statements with the trade-offs spelled out
  • Deciding what not to build yet

Seen in: Stories & Chapters, where a creator workaround became the main format on Stck.

Read the Stories & Chapters case study

02

Product and Interaction Design

I design around what people already know. On Stories that meant building on the post editor instead of a new tool. On Comments it meant a separate pattern for phones instead of a squeezed desktop panel.

What this looks like

  • End-to-end flows, from entry point to edge case
  • Several models side by side before committing to one
  • Phone and desktop patterns designed on their own terms
  • Prototypes to test a direction with users and engineers
  • Empty, limit and lapsed states

Seen in: Comments, from a side panel on desktop to markers on individual paragraphs.

Read the Comments case study

03

Monetization and Conversion

I treat pricing as a question of timing first and wording second. Plans, paywalls and upgrade prompts should appear when someone has just shown they want more, and stay fair to the people who never will.

What this looks like

  • Plan limits and feature gating
  • Upgrade prompts placed at moments of intent
  • Pricing modals and plan landing pages
  • Per-chapter and full-story purchase flows
  • Lapse and downgrade states that don’t punish people

Seen in: Pro Subscription, a paid tier for the creators who earn the most.

Read the Pro Subscription case study

04

Foundations That Scale

I look for the decision that makes the next few features easier. Once chapters belonged to a story, bundles, paragraph comments and plan limits became simple decisions. Once comments were tied to paragraphs, discussion became data the team could build on.

What this looks like

  • Content models and information architecture
  • Reusable interaction patterns
  • Role labels and moderation interfaces
  • Checking what’s buildable with engineers as I go
  • Leaving room for what comes next without a rebuild

Seen in: Stories & Chapters and Comments.

See all work

Working with teams

How I bring people along.

  1. 01

    Show a Rough Cut, Not an Argument

    When engineers wanted a separate content type for Stories, I showed them a working rough cut on the post editor. Seeing it settled more than a debate would have.

  2. 02

    Start From Their Side

    Before I make a case, I work through what each direction costs the people who will build it.

  3. 03

    Scope Research Others Can Run

    On Stories I scoped the creator interviews and my teammate ran them, so research and design moved at the same time.

  4. 04

    Take the Critique

    My first idea for Pro was an always-on banner. Our design lead pushed back, rightly, and every prompt after that waited for a creator’s intent.

The process

How a project runs.

  1. 01

    Signal

    I start from something real: a workaround, a repeated complaint, a split in the numbers.

  2. 02

    Frame

    I write down the problem and its trade-offs, and agree on it before designing.

  3. 03

    Explore

    I compare several models with teardowns, rough flows and prototypes, checking what’s buildable.

  4. 04

    Ship

    I stay through build and review, covering the edge cases that slip in handoff.

  5. 05

    Measure

    After launch I check adoption, sales and behavior, and say what the data can’t show.