The Making of a Spec-zilla

by Vlad Loktev

So you’ve got an idea for the next kickass software product. You’ve done your homework. You talked to a gazillion people, did three months of market research, got your parents’ advice, and bought a timeshare on the islands of Fiji in anticipation of your soon to be great fortune. You are so excited you also went out and spent 50 bucks on brand new business cards. Well…before you start handing these out to everyone you see, and hiring a 20 person engineering team, you should probably slow down a little and write out your idea on paper.

Most people refer to a detailed idea on paper as a “product spec.” In a nutshell, a spec tells the reader what the product should do. The purpose of a spec is to effectively communicate every nook and cranny of your idea to everybody around you - your friends, co-founders, developers, and most importantly yourself. I found that oftentimes every product detail is very clear in my head, but once I sit down to actually write it all out, I start running into all sorts of issues that I didn’t think of before.

Here are some tips I’ve found useful that I wanted to share in case they save somebody else some time and potential aggravation:

1.     Quick summary. Always start your spec with a few sentence summary about your vision for the product. The goal of this part is to communicate your high-level vision quickly. Don’t get lost in the details. Anybody on your team should be able to get a general sense of the vision after reading these few sentences. Writing a short summary will also help you focus on what’s really important. If you can’t write two sentence about your vision, then you probably haven’t through the idea through yet.

2.     List functionality. In bullet form, write down everything you want the software to do. “Share images with other users; Comment on people’s images; Message other users.” Once again, it helps to be succinct in this stage. This section should give everyone a snapshot of the functionality that will be built.

3.     Explain the value. Write out why each feature listed in #2 should be included in the product. What value does it add? What problem does it solve? What evidence do you have this feature is valuable/correct solution? Answering questions such as these accomplishes two things: a) it forces you to think through each feature carefully and to begin understanding what the most important/necessary features are; b) it helps show your team the value of what they are building.. there is nothing worse than developing without being excited about the impact you can make. Show your team that your vision is worth staying up at night for!

4.     Create user profiles. Time for some role play! List and describe all of the “types” of users who will interact with your product - Logged in user, Logged out user, First-time user, etc. Explain each user’s characteristics.

5.     Create navigation flow. This is where you write out how all of the functionality interacts throughout the product. I found it super useful to create separate navigation flow for each user profile. Explain how a Logged in user can go from page to page, etc.

6.     Exhaust use cases. Here is where the real challenge comes in. You need to clearly explain how each piece of functionality should behave in every scenario of the world you can think of. If done well, this section will probably be the longest part of your spec. Pretend you are an obnoxious user trying to point out every flaw in the product. What happens if you type really long messages? One character comments? Really long comments? Attach really large pictures? Cycle through the UI buttons in random order? Don’t forget to have some fun with this one. Try to break the product.

Congrats! You’ve made it through the first six steps in one piece. That’s a huge accomplishment. In the process, you probably bashed your keyboard a few times, pissed off a few friends, and neglected to exercise… but all is well in the world – you are almost done!

7.     Prioritize. Your team won’t be able to take a stab at everything in your spec all at once. After doing all that work, you probably have a good sense of what the necessary components of your idea are. Tell your team! Prioritize each feature and use case (I typically prioritize everything into three categories – High, Medium, Low… but you should try to be a lot more creative than me).

8.     Use pictures. I can’t stress this enough. Show, don’t tell. Use pictures (mocks) as often as you can. Being able to see what you are talking about will help out your team a ton. Your mocks don’t have to be pretty… just get a basic layout together. It’s very likely that you’ll be changing the look and feel of your product continuously through A/B testing anyway.. so if you are strapped for time, it’s better to devote more attention to flushing out all the use cases rather than trying to perfect something that will change shortly anyway.

9.     Moderate. When everything is said and done, think about the person you’ll be handing off the spec to. Do you really want him or her to read through a 25 page word document? It’s totally demoralizing! Have some pity on your teammates. It’s also likely that he’ll skip through important sections of the spec. At first, hand over the initial 5 sections… these should be enough to get his heart pumping. Then hand over the rest of the spec in pieces. Keep in mind that the structure of your specs may and should change overtime. There is no one style that works for everyone. Experiment and see what works for your team. Bon voyage!