You would never know it to look at the toddler detritus strewn about my house, but I’m a minimalist. Having superfluous stuff around really bugs me, and doing superfluous work bugs me even more.
One of the indulgences of starting a company is the ability to shape a company to your personality a bit. If there’s one place I’ve taken advantage of that, it’s been with our product requirements documentation.
After launching UserMuse, I soon realized that I had far less time to focus on the product than ever before. After raising money, business development, marketing, managing customers, and administrativia there was often little time left to focus on the nitty gritty of feature development. As a product person, that bummed me out a little at first. I felt like a chef who opens up a restaurant only to find that running a small business leaves no time to cook.
More importantly though, I needed to be more productive to set strategy and deliver good requirements to the designers and engineers in a timely fashion to keep things moving forward. Here’s what I’ve learned as a founder-slash-head of product on a small team that I believe apply to almost any organization.
Going Lean with Product Requirements
Paraphrasing Dan Radigan at Atlassian, if the product owner and development team share an understanding of why they’re building something, you don’t need ultra-detailed requirements. For UserMuse, “lean requirements” is about over-investing in making sure we all get the “why” and choosing choosing over documentation whenever possible.
Business Cases Matter (Even If You’re the Boss)
There’s something vaguely silly about writing a business case to pitch to myself, but the exercise is more important than ever now that I can make decisions by fiat if I want to. It saves me from myself and guards against lazy thinking. And while I’m not writing a business case to get my team’s approval per se, it’s important that they understand and feel bought in to the vision. Done right, the Opportunity, Market Requirements and Product Requirements sections of the business case accomplish this.
Diagrams Are Critical
I think of requirements at three levels:
- The 10,000 foot view
- Detailed workflow and designs
- User stories
On a small team with a high level of shared context, the developers can usually take over once you’ve provided the detailed workflow and designs. That’s good for time-strapped people, because detailed workflows are relatively easy to create and update when things change. Here’s what one of ours looked like for a feature:
The individual actions each have their own set of moderately detailed requirements in a separate document: User can do this. User can’t do that. If user does this, system does that. The requirements don’t go down to the individual acceptance criteria of user stories because the team didn’t need them. They got the picture and could iterate faster than I could document anyway. Speed, speed, speed.
Conversations > User Stories
I was suprised to find out from one of our first developers who had worked for one of the major walled gardens that none of the teams he’d worked on there used JIRA or any other requirements management tool. They just wrote what they needed to in Google docs and talked constantly. It seemed to work amazingly well despite the seeming absence of top-down control.
I was shocked at how “doc-lite” such a huge organization could be and still function so well. Having come from multiple companies where I spent huge amounts of time in tools like JIRA and Confluence, it opened my eyes to how we could streamline by talking more and writing less.
Our ratio of documentation-to-conversation has shifted back and forth over time primarily due to schedules. When I’ve been swamped with too many things to spend the time I wanted alongside the team, I’ve written more detailed documentation. When we can, I prefer to design out loud, make decisions in real-time, let the team implement then do it again when they have something to review. It takes a lot of trust and cohesion to work this way, and mistakes still happen, but on the whole it’s worked well.
My last big takeaway isn’t a novel one: even product-oriented founders eventually need someone to focus on product strategy full-time. Keeping the developers busy isn’t the same thing as constantly identifying market needs and translating them into tactical product decisions. It’s a full-time job – I look forward to hiring someone for it.