Killing the Requirements Document

Scrapping heavy product process & solving for soul

Amanda K Gordon
Apr 15, 2015 · 5 min read

Moving desks to sit between our designers, producers, and developers gave me a front row seat to our product development process. Our design-thinking product sprints uncovered product opportunity, but once we went into build, it was painfully obvious we were missing something: a visible articulation of the product’s soul. This is an attempt to build it back into how we work.

I’ve become fascinated with the common thread that determines the success — or failure — of a product. When it fails, it’s ugly. Teams — both internal and external — are hamstrung by process and hefty requirements documents, design-by-dictatorship, or opinions masquerading as facts.

Designing process and culture where product teams can become autonomous must involve vision. However, you can’t write a requirement for vision. Or can you?

Problem solving, when undertaken by a unit of diverse specialists who share a common goal, yields better results than a homogenous group of team members. But. Getting diverse team members rowing in the same direction is easier said than done. My mission is to help diverse teams articulate that common goal, so that:

  1. Product teams are ‘singing from the same hymnal’ (to quote my mother). Note: sharing a vision doesn’t mean there’s no debate — on the contrary, it should act as a lens through which debate is framed: deciding the best way to execute vision.

I believe there is a correlation between how a team communicates a product’s vision — which frames our day to day decisions, behaviours and attitudes towards a product — and the success of the product. What follows is an attempt to create a framework of (scalable) guiding principles to nurture the product design process.

What is a Product’s Soul?

In my role, I hear a lot about technical requirements. Responsive. Integrated. Scrolling. Bounce rate. Churn. But when it comes right down to it: soul is the details. Bug release notes captured with humour. Lovingly crafted ‘404’ pages. I think it’s more. It’s not about process, but it is about a shared understanding of how the product should make the user feel. A few examples of products with ‘soul’:

Slack

Slack is the product person’s product. It’s simple, it’s elegant, and it knows what it stands for. My favourite nod to the user — and Slack’s mission (to make your working life simpler, more pleasant, and more productive) — was their bug fix notes: a charming amuse-bouche from the product team to the user.

Image for post
Image for post
Slack’s bug fix notes: worth the read.

Spotify

Spotify is often held up as a brilliant example for product teams everywhere for many reasons (among them, their product squads). I recently stumbled upon a lovingly crafted, ‘404’ page, proof that Spotify lives up to the hype.

Image for post
Image for post
Spotify 404 page.

MailChimp

A product in a category that’s not known for much of anything (email), Mailchimp’s mission is simple: send better email. One of my all time favourite features on Mailchimp is the screen that pops up just before sending an eDM.

Image for post
Image for post
Mailchimp’s ‘pre-launch’ screen.

“There is a perpetuated myth within the design community, that a single visionary is required to build great products. Rubbish. Great teams build great products; moreover, in my experience, the greatest teams prioritise and nurture a design process itself.”

-Rhys Newman

How do You Solve for Soul?

As Rhys Newman states, there’s a design myth that it takes a visionary to build great products. Visionaries don’t scale, but vision can.

Good product managers solve for success of a product, but great product managers help their teams solve for product soul. Fewer requirement documents. More ‘most important user story’ discussions. In an attempt to solve for soul, I created a tool for myself and my teams, that I’d like to share. I’ve used this to identify internal and external product opportunities. It’s not meant to be a requirements document, or a brief, but rather a guiding compass, a north star for the product team.

The Product Charter

Image for post
Image for post
The Product Charter.

The product charter may not be right for every project, but it made me think differently about how we articulate, measure, and share our product purpose and knowledge. For our team, it’s been helpful in 1) capturing design workshop results, 2) communicating product purpose to new team members and 3) checking product decisions against.

Download it, use it, debate it, ask questions, improve upon it.

Image for post
Image for post

I want to build teams, and products, that sing with purpose. This document is a tool that has helped me ‘listen’ for that purpose throughout our design process. It takes inspiration from the Lean Business Canvas, draws on frameworks including Clayton Christensen’s ‘Jobs to Be Done’, Kerry Rhoden’s ‘HEART’ metrics framework, and challenges not only product owners — but product teams to identify problem, purpose, and vision statements.

How do you, and your teams champion product purpose internally?


Thanks to Kirsten Dunlaevy and Chris Sheriff for reading drafts of this.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store