How you write Product Specs is how you build products

In my 5 years of working as a Developer and then as a Product Manager I have come to understand the importance of a well written spec.

When I started out in Product, I used to write long-winded emails which I passed off as a product spec. Then I stopped the practice of writing a spec altogether when I realised most people don’t even read the doc and I had to explain all features in person.

How wrong was I!

With the lack of a proper spec the process of product development was chaotic at best.

There was scope creep. Feature requests would come from everywhere even after you you are far into the dev process.

Worse, I forgot that you don’t write the spec for the designer or the developer. You write it so that you have much more clarity on what you are building and even more: Why you are building. This is PM 101.

The other common pattern I have seen is to have detailed specs but which keep changing every other day. Scope is never frozen. There is no set goal or measurable metrics. The spec is just a collection of features and nothing more.

This leads to creation of wedding cakes in case of cupcakes.

I remember how things went so bad at one of my past companies that the Engineering Head forced us to give specs in PDF format so that PMs could not change the requirements on the fly after dev starts.

There are different ways to write a Product Spec. If you have never written one before here is a good example and an accompanying blog post.

In some companies the specs are quite detailed. While at some it just focusses on the WHY and WHAT part without worrying about the How. I have been at places too where the specs written are quite technical.

So how do you know you are on the right path? See if you are doing the things mentioned below.

Is your spec doc clear, understandable without you having to explain them again and again to your designers and developers?

There should always a kick off meeting where you discuss the spec but you should still be able to communicate to your team the user goal as well as the scope of the feature/product.

Don’t worry about writing the spec in one go and getting it perfect the first time. Write a quick draft. Loop in your team. Discuss the core ideas. Think more. Rewrite if needed.

Have you mentioned what/how you are going to track to measure the success of your feature?

All data driven companies will have a ‘Yes’ as an answer to the question above. If your answer is ‘No’ then think again. If you can’t measure then don’t build.

Are your specs frozen before your developers start working on the feature? Do you change your specs whenever a fresh idea comes?

If your answer to the above is Yes then it means either:

• You lack clarity on what you are building. Next time focus more on understanding why you are building the feature in the first place. What unique problem you are solving and how are you planning to measure the success of it. If you have identified both you would not need to change the scope midway through dev.
• You lack understanding of your platform. Spend more time understanding the tech behind your product.
• There are better optimised ways to solve the problem. The HOW part is not something which should come just from you. Involve your tech counterpart early in the process and do a proper tech feasibility analysis.

Stay up to date with my latest posts/tweets here: @manas_saloi