Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Doing a lot with a little at Pitchfork

Doing a lot with a little at Pitchfork

Matt Dennewitz

May 27, 2014

Other Decks in Business


  1. Hello • I’m Matt Dennewitz <@mattdennewitz> • VP Technology @

    Pitchfork <@pitchforkmedia> • First full-time developer, now heading up product and engineering efforts
  2. Pitchfork • Most influential music publication on the ‘net. •

    Founded in 1995, run from Chicago since ’99.
  3. Pitchfork • Two music festivals (Chicago, Paris) • Pitchfork.tv, Nothing

    Major, The Dissolve • Weekly mobile app • The Pitchfork Review
  4. • In the beginning, there was 1 developer • No

    time for non-essential work. New features had to be essential. • From great constraint came great agility. • Had to grow the team(s) to survive, had to rethink what an online publication could be.
  5. • Now 4 developers, 4 designers. • Hire weirdos. Don’t

    silo. • Invest in people, not products. Let people define 
 your products. • Continue to embrace constraint. • Constantly rethinking what an online publication can mean.
  6. • Embrace that reading is a feeling. • Goal: understand

    and satisfy the reader’s
 need to feel.
  7. • Embrace browsing as a medium. • Goal: build the

    tools necessary to remove the browser from the browser.
  8. • The emotions we want to evoke are a by-product

    of combining of substantive writing, beautiful design, and solid engineering. • regardless of platform
  9. • Do not build what you cannot maintain. • Build

    only what enables you to continue building. • Ex: Django’s admin is fine for basic work. We build tools for our staff to improve their workflow.
  10. zineutil • Set of reusable Javascript interaction and design components,

    broken into units of work • Each unit serves a single purpose (image fitting, video control, parallaxing). • Used in almost everything we do.
  11. Problems: • Trying to do even basic custom design work

    within a CMS text editor can be a cruel joke. • Design and dev concerns need to be removed from editorial workflow.
  12. Solutions: • We built a platform where writers build stories

    from pre-designed atomic elements. • Dev and design can quickly build reusable components to suit editorial needs. • Editorial focuses exclusively on writing and arrangement.
  13. Problems: • Wanted to offer pre-release streams to artists •

    Most pre-release streams do the music no favors • How can we put albums in front of our readers before stamping a number on it?
  14. Solutions: • Give bands and labels a full-screen blank canvas,

    to be filled with video and artwork they make. • Give listeners a real chance with the music: 
 stream the album for one week prior to its release, and our scoring.
  15. Outcome: • Totally immersive, distraction-free experience for listening to music.

    • Listeners engage with the music and artwork as they would a real album.
  16. Problems: • Craftsmanship put into our best writing wasn’t reciprocated

    by dev and design. • Not capitalizing on the potential a story has to be more than its words. • Need to sharpen the distinction between good and disposable content.
  17. Goals: • Focus on new and innovative ways to showcase

    our content. • Amplify content with context: photography, video, and music. • Exploit powerful modern tech to push browsers as a medium for beautiful storytelling.
  18. Solutions: • Seamless integration between media into content–words flow into

    video and artwork. • Use the whole team to create totally custom experiences tailored to each story’s subject
 and flow.
  19. • We do what’s best for our readers and ourselves.

    • We do it with what we have or can build. • Every process is tuned for optimal
 resource usage, just like a web app • Our benchmark: we look back and see that everyone’s trying to interrupt a conversation we’ve already moved on from.