Killing the Requirements Document
Scrapping heavy product process & solving for soul
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:
- 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.
- Clients are empowered to input at the right time, in the right way. Too often we ask for client feedback once we’re finished solving their problem. Problem is, we solved the wrong problem — or worse, invented a problem that no one had. Quit working in a black box and bring clients into the product discussion up front.
- The soul of the product is not only tangible — but is visible: quite literally, written on the walls of the studio. Out of sight = out of mind. People put important things where they’ll see them. Truck drivers tape photos of their family to their dashboard. Keeping knowledge in your head is great for trivia night, but it tends to turn the design process into a game of Chinese whispers: and the results aren’t pretty.
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.
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.
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.
“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
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.
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.
