Product Specs That Work

Past Mistakes

One of the early mistakes I made when I started to take on product work was to write really detailed specs, trying to make sure I'd considered every possibility and angle so the team would have all the information they needed. I suspect this mindset came from the pain of (as a developer) dealing with product owners that were hard to get hold of and expected the team to work from a two line description with no input.

However giving too much detail is no better than too little. By trying to specify every last detail, I removed any scope for creativity. Whether you're a designer, a tester or a developer, creativity matters, it's what makes the work fun and I'd inadvertently removed that from the process. Also, the docs get so long, that no-one actually reads them and just works from what was said in meetings anyway!

What I do now

The process I use now, came about in my last company due to multiple slip-us with product launches where key information was missed or key people were not notified. We tried several things to prevent future recurrences, including Trello boards with tasks and launch meetings. What really seemed to make a difference though, was the concept of a two-page product spec. I tried to distill what was in my head into a two pages or less so that everyone would read it before we started the work.

Despite it being intended as an outward communication tool, it also worked well within the delivery team, to get everyone aligned on what we were delivering with just enough information. Whilst I'm sure this is not a radically new concept, I thought I'd share what I include in these docs as a reference for others.

1. Context

2. Scope

3. Workflow

4. Questions & Answers

Context

I like to set out who the users are and what their challenge is that we're trying to address. A lot of this information came from or was refined by the user and market research we did, so linking out directly to that research so the team can explore the details themselves would be a neat addition.

The main aim with this section is to make it clear to everyone why we are doing this work and the impact we expect it to have. That kind of information is useful well beyond the development team. The marketing and social media folks found it particularly useful for planning campaigns ahead of time for instance.

Scope

A common problem I've found related to scope, is the assumptions people make about what is and isn't included. This section was designed to set out clearly and simply what was being changed and what wasn't. I found bullet points rather than lengthy descriptions worked a lot better. I had an explicit "what is not included" section as well as a coming soon/next section so people could see that this was part of a larger piece of work.

For instance you might have something like:

Included

• Allowing all users to upload new content in video and image format

• Review workflow for approving/rejecting user content

• Notifications for new content to review

• Sharing content to other platforms

Coming Soon

• Threaded comments

Out of Scope

• Direct upload of videos e.g. mp4 files

Workflow

Workflows can be quite hard to describe, so pictures are your friend here. I tended to use a brief description and then link out to some basic wire-frames. The idea isn't to specify every last user interaction, instead to give an overview of how it might work with plenty of scope for creativity.

Using the same example as above, here's what I would write and draw:

The contributors will be guided through the upload, step by step to ensure that all the required information to make the content is captured

Example workflow mockup

This is a basic drawing, designed to give ideas for how it might look, rather than to dictate the design. I like to keep the mock-ups linked rather than in the actual doc, so we can update the designs as they evolve.

Questions and Answers

Finally, this section of the doc came about more organically. Once I'd shared the first spec, people started to add comments and questions to the doc, so I added a FAQ's section to the end. People would add their question and then someone from the delivery team would answer, following up with them for more information if needed.

This was a great way to uncover 'hidden' requirements early on, giving us plenty of time to figure out how to address them. It also had the side effect that product decisions become more visible to the wider team as they were written down in a place everyone had access to.

Product strategy and leadership for start-ups and small businesses is what I do. If you're a start-up or small business owner and would like to find out more about how I can support you, I have slots every week for a free initial chat.