A well-written spec is about <\/span>clarity<\/b>. The more information you have going into a product spec, the more clarity you give everyone working on the product with you. <\/span>
We generally include some or all of the following, depending on what is needed to clearly communicate what is needed.<\/p>\n\n\n\n
A product spec includes:<\/h3>\n\n\n\n\n- Summary – <\/b>what is the idea being suggested? <\/span><\/li>\n\n\n\n
- A business case – <\/b>what value does this create for the business and\/or customer?<\/span><\/li>\n\n\n\n
- User stories – <\/b>what is the user trying to accomplish? (<\/span>we have a quick template here<\/span><\/a>) <\/span><\/li>\n\n\n\n
- User personas – <\/b>who is the solution for?<\/span><\/li>\n\n\n\n
- Designs – <\/b>what does the solution look like? <\/span><\/li>\n\n\n\n
- Functional specs – <\/b>what are the technical details behind the solution? <\/span> <\/b>(Joel Spolsky<\/a> has written extensively about this.)<\/span><\/li>\n<\/ul>\n\n\n\n
If you\u2019re working in a bigger company or large teams, you should err on the side of over-communication: more context and more deeply detailed specs. As a rule of thumb, the more moving parts that are involved, the less you want to leave up to interpretation. <\/span>
On the other hand, if you\u2019re working closely with a small team, you might be able to get by with simpler, lightweight specs.<\/span><\/p>\n\n\n\n![\"Free](\"https:\/\/www.prodpad.com\/wp-content\/uploads\/2023\/04\/PRD-banner_Blogs-1280x300-v1.1-1024x240.png\")
<\/a><\/figure>\n\n\n\nOur 5-Step Process For Writing Product Specs<\/h2>\n\n\n\n
For much of its life, a product spec is a work in progress. That\u2019s fine! That\u2019s how it should be. You\u2019ll be getting new information and dealing with potential setbacks throughout the process.<\/span>
We follow a process here at ProdPad that mirrors something Einstein once said: \u201cIf I had an hour to solve a problem, I\u2019d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.\u201d<\/i><\/p>\n\n\n\n![\"Einstein](\"https:\/\/www.prodpad.com\/wp-content\/uploads\/2017\/04\/einstein.jpg\")
<\/figure>\n<\/div>\n\n\nThinking through the problem that you intend to solve – and sometimes even going back to the drawing board entirely – is not a waste of time. The problem is usually the hardest thing to nail.
So expect that you\u2019ll probably be making a series of changes to make along the way – but also that you\u2019ll end up with a more solid product spec for it. <\/span>
Writing specs is not a straight shot – but here\u2019s the process that works for us.<\/span><\/p>\n\n\n\nStep 1: Turn to customer feedback and data to find the source of the problems<\/h3>\n\n\n\n
The best place to go looking for problems is in your customer feedback<\/a>.<\/span>
Customer feedback comes in many forms: complaints, questions, product suggestions and feature requests. The most critical thing when evaluating all this is to <\/span>not take it literally<\/span><\/a>. <\/span>
What your customers are asking for is not a mandate. When you\u2019re investigating a problem area, each item of feedback is a data point to help you get down to the root of the problem.<\/span>
Speaking of data, customer feedback won’t always tell you if something critical like the checkout flow isn’t working. You’ll often need to look at the data!<\/span>
What\u2019s behind all this feedback in the first place? What is the underlying issue here? These are the kind of critical questions that help you understand a) the problem and b) the scope. <\/span>
Other questions to ask here: <\/span><\/p>\n\n\n\n\n- Are a lot of customers asking for this? How big is customer desire? <\/span><\/li>\n\n\n\n
- How critical is this problem? Is this going to make it hard for you to win over future customers? <\/span><\/li>\n\n\n\n
- Is it keeping you from acquiring more users or closing deals?<\/span><\/li>\n<\/ul>\n\n\n\n
Step 2: Break the problem down into a bunch of hypotheses<\/b>
So how big is this problem, actually? In this step, you\u2019ll continue to understand the scope of what you\u2019re dealing with. <\/span>
Let\u2019s say for example, your customer feedback tells you that you have a big problem on your hands. There\u2019s no quick fix for this one. You need to completely redo your checkout process. <\/span>
Now you\u2019re probably considering all kinds of ideas<\/a> and that can quickly start to get overwhelming. What we suggest is that you break these ideas out into three categories: <\/span><\/p>\n\n\n\n\n\ud83d\udc49\ud83c\udffd Essentials: <\/b>This is MVP level stuff. If this isn\u2019t there, the whole thing falls apart. What will it take to get this off the ground and functioning?<\/p>\n
\ud83d\udc49\ud83c\udffd Nice-to-haves: <\/b>Non-essential, but would add immediate value. What will add value to the spec but isn\u2019t absolutely necessary?<\/p>\n
\ud83d\udc49\ud83c\udffd Delightful: <\/b>The sprinkles on top; stuff that makes people smile What will make people smile?<\/p>\n<\/div>\n\n\n\n
This way you can still account for the full scope of the problem, but keep your eyes on the ball. Think MVP. The essentials are your top priority. Everything else is going to have to wait its turn.<\/span>
Step 3: Open up product discussions across your team\/company<\/b>
\u201cWriting a spec is a great way to nail down all those irritating design decisions, large and small, that get covered up if you don\u2019t have a spec. Even small decisions can get nailed down with a spec,\u201d says Joel Spolsky of Fog Creek Software<\/a>.
Oof, yes. That sounds familiar. However, those small decisions tend to add up – and it\u2019s in no one\u2019s best interests to start dealing with them when it\u2019s already sitting in your dev backlog. <\/span>
The mistake I\u2019ve seen made over and over is leaving these discussions until the end when a spec is already in production. You must create a space and a forum for your internal stakeholders to contribute while the idea is still taking shape. <\/span><\/p>\n\n\n\n![\"Great](\"https:\/\/www.prodpad.com\/wp-content\/uploads\/slack-imgs-1.png\")
<\/figure>\n<\/div>\n\n\n
Start inviting colleagues around the company now to help you start getting your idea ready. They know things you don\u2019t and they can tell you from their corner:<\/p>\n\n\n\n
\n- What works<\/li>\n\n\n\n
- What doesn\u2019t work<\/li>\n\n\n\n
- Argue for a bigger\/smaller scope<\/li>\n<\/ol>\n\n\n\n
The opportunity to open up product discussions around what gets done and how is a key trait of effective product teams<\/a>.
We keep all our product discussions in ProdPad. Each product idea has a discussion section, so we\u2019re able to focus on really specific objections and concerns.<\/p>\n\n\n\nStep 4: Do user testing with your closest customers<\/h3>\n\n\n\n
Everything you\u2019ve done so far makes sense on paper, but reality bites. Things change when you<\/span> put a prototype in front of humans<\/span><\/a>! It\u2019s time to see whether your assumptions hold and your customers react the way you\u2019ve imagined they will.<\/span>
At ProdPad, our designer preps a series of simple designs – really simple, like wireframes and clickable prototypes – for user testing. <\/span>
We do our user testing in two ways usually: <\/span><\/p>\n\n\n\n\n- Slack customer community <\/b>–<\/span> We throw<\/span> designs into our <\/span>customer community<\/span><\/a> and invite feedback. It\u2019s a public channel, but it\u2019s also where our closest and most engaged customers hang out. We get a lot of insights from the discussions that follow. <\/span><\/li>\n\n\n\n
- One-on-one user tests<\/b> – We set up a dedicated session where we ask our user tester to perform a series of tasks to see how\/where they trip up<\/span><\/li>\n<\/ol>\n\n\n\n
Can users complete the tasks you ask them to? Are they easily able to find buttons? Do they feel confident about where to look for stuff? <\/span>
What usually follows is that some of your assumptions were wrong. It\u2019s not as easy to find the buttons, or the flow isn\u2019t as obvious to the user as you thought it was. <\/span>
There\u2019s a couple other surprises you may find out here:<\/p>\n\n\n\n\n- edge cases<\/span><\/li>\n\n\n\n
- surprise requirements<\/span><\/li>\n\n\n\n
- misunderstood functionality<\/span><\/li>\n\n\n\n
- widened or changed scope<\/span><\/li>\n<\/ul>\n\n\n\n
At this point, we\u2019re also looking at the bigger picture. We also look at how the new solution fits in with the way our users already use the product. What\u2019s the difference between changing nothing and putting something new in place?
But it\u2019s just a prototype and all you have to do is adjust it. Repeat until you\u2019re confident you\u2019ve gotten it right. <\/span>
So think of it this way: User testing is all about minimizing risks. It\u2019s cheaper to repeat this step than go live with a new feature that could blow up in everyone\u2019s faces.<\/span><\/p>\n\n\n\nStep 5: If it\u2019s ready, send to development<\/h3>\n\n\n\n
Remember how I mentioned earlier that product specs are always a work in progress? That\u2019s the case even now, here in this final step. <\/span>
The, even if development goes flawlessly, QA is a diff story. Once you start clicking around, you might start to discover little things that you may have missed. It\u2019s okay not to be harsh on yourself – it happens even to us. <\/span>
We think everything is great and pat ourselves on the back for being so meticulous. But when we\u2019re testing, we think, \u201cHmm, maybe this button should be on the right because it doesn\u2019t actually make sense in the context of the rest of the app.\u201d<\/span>
It happens to the best of us. Perfection takes time. <\/span>
When you feel confident you\u2019ve got something going, add the final touches: final prototypes, technical information, key context, etc.<\/span>
If you\u2019ve been developing your product spec in ProdPad, now you can simply push to Trello, JIRA or your development tool of choice.<\/a><\/span>
All done! Now take a well-deserved break and when you\u2019re back, go right back to where you started from: <\/span>customer feedback<\/span><\/a>. The life of a product manager, eh? <\/span><\/p>\n\n\n\n<\/a><\/figure>\n","protected":false},"excerpt":{"rendered":"What is a product spec? A product spec is a blueprint that describes what you\u2019re building, who you\u2019re building it for and what the final outcome should be. A well-written…<\/p>\n","protected":false},"author":4,"featured_media":4607,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[5230,9],"tags":[78,130,186,201,234],"pp_uni_tag":[],"class_list":["post-1674","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-most-popular","category-product-management-best-practice","tag-featured","tag-new-feature","tag-product-specs","tag-redactor","tag-text-editor"],"acf":[],"yoast_head":"\n
How to Write Great Product Specs - ProdPad<\/title>\n<meta name=\"description\" content=\"Plan and write great product specs that you can send directly to your development team with this simple five-step process from ProdPad\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"How To Write Great Product Specs\" \/>\n<meta property=\"og:description\" content=\"Einstein once said, \u201cIf I had an hour to solve a problem, I\u2019d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.\u201d\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/\" \/>\n<meta property=\"og:site_name\" content=\"ProdPad\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/ProdPad\/\" \/>\n<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/bastow\" \/>\n<meta property=\"article:published_time\" content=\"2016-06-11T19:10:54+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2024-02-08T15:58:40+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.prodpad.com\/wp-content\/uploads\/2016\/06\/Blog-post-specs-facebook.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1200\" \/>\n\t<meta property=\"og:image:height\" content=\"630\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Janna Bastow\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:title\" content=\"How To Write Great Product Specs\" \/>\n<meta name=\"twitter:description\" content=\"You've heard them say "Move fast, break things" right? Do the exact opposite.\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/www.prodpad.com\/wp-content\/uploads\/2016\/06\/blog-post-spec-twitter.jpg\" \/>\n<meta name=\"twitter:creator\" content=\"@simplybastow\" \/>\n<meta name=\"twitter:site\" content=\"@prodpad\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Janna Bastow\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"8 minutes\" \/>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"How to Write Great Product Specs - ProdPad","description":"Plan and write great product specs that you can send directly to your development team with this simple five-step process from ProdPad","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/","og_locale":"en_US","og_type":"article","og_title":"How To Write Great Product Specs","og_description":"Einstein once said, \u201cIf I had an hour to solve a problem, I\u2019d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.\u201d","og_url":"https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/","og_site_name":"ProdPad","article_publisher":"https:\/\/www.facebook.com\/ProdPad\/","article_author":"https:\/\/www.facebook.com\/bastow","article_published_time":"2016-06-11T19:10:54+00:00","article_modified_time":"2024-02-08T15:58:40+00:00","og_image":[{"width":1200,"height":630,"url":"https:\/\/www.prodpad.com\/wp-content\/uploads\/2016\/06\/Blog-post-specs-facebook.jpg","type":"image\/jpeg"}],"author":"Janna Bastow","twitter_card":"summary_large_image","twitter_title":"How To Write Great Product Specs","twitter_description":"You've heard them say \"Move fast, break things\" right? Do the exact opposite.","twitter_image":"https:\/\/www.prodpad.com\/wp-content\/uploads\/2016\/06\/blog-post-spec-twitter.jpg","twitter_creator":"@simplybastow","twitter_site":"@prodpad","twitter_misc":{"Written by":"Janna Bastow","Est. reading time":"8 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/#article","isPartOf":{"@id":"https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/"},"author":{"name":"Janna Bastow","@id":"https:\/\/www.prodpad.com\/#\/schema\/person\/ceec8b615b0ad09e9199ba2fa8545e8c"},"headline":"How to Write Great Product Specs","datePublished":"2016-06-11T19:10:54+00:00","dateModified":"2024-02-08T15:58:40+00:00","mainEntityOfPage":{"@id":"https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/"},"wordCount":1581,"publisher":{"@id":"https:\/\/www.prodpad.com\/#organization"},"image":{"@id":"https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/#primaryimage"},"thumbnailUrl":"https:\/\/www.prodpad.com\/wp-content\/uploads\/2017\/04\/product-specs.jpeg","keywords":["featured","new feature","product specs","Redactor","text editor"],"articleSection":["Most Popular","Product Management Best Practice"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/","url":"https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/","name":"How to Write Great Product Specs - ProdPad","isPartOf":{"@id":"https:\/\/www.prodpad.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/#primaryimage"},"image":{"@id":"https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/#primaryimage"},"thumbnailUrl":"https:\/\/www.prodpad.com\/wp-content\/uploads\/2017\/04\/product-specs.jpeg","datePublished":"2016-06-11T19:10:54+00:00","dateModified":"2024-02-08T15:58:40+00:00","description":"Plan and write great product specs that you can send directly to your development team with this simple five-step process from ProdPad","breadcrumb":{"@id":"https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/#primaryimage","url":"https:\/\/www.prodpad.com\/wp-content\/uploads\/2017\/04\/product-specs.jpeg","contentUrl":"https:\/\/www.prodpad.com\/wp-content\/uploads\/2017\/04\/product-specs.jpeg","width":940,"height":627},{"@type":"BreadcrumbList","@id":"https:\/\/www.prodpad.com\/blog\/how-to-write-great-product-specs\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Latest Blogs","item":"https:\/\/www.prodpad.com\/blog\/category\/latest-blogs\/"},{"@type":"ListItem","position":2,"name":"Product Management Best Practice","item":"https:\/\/www.prodpad.com\/blog\/category\/latest-blogs\/product-management-best-practice\/"},{"@type":"ListItem","position":3,"name":"How to Write Great Product Specs"}]},{"@type":"WebSite","@id":"https:\/\/www.prodpad.com\/#website","url":"https:\/\/www.prodpad.com\/","name":"ProdPad","description":"Product Management Software","publisher":{"@id":"https:\/\/www.prodpad.com\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.prodpad.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.prodpad.com\/#organization","name":"ProdPad","url":"https:\/\/www.prodpad.com\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.prodpad.com\/#\/schema\/logo\/image\/","url":"https:\/\/www.prodpad.com\/wp-content\/uploads\/2018\/12\/blue-full.png","contentUrl":"https:\/\/www.prodpad.com\/wp-content\/uploads\/2018\/12\/blue-full.png","width":2050,"height":400,"caption":"ProdPad"},"image":{"@id":"https:\/\/www.prodpad.com\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/ProdPad\/","https:\/\/x.com\/prodpad","https:\/\/instagram.com\/prodpad","https:\/\/www.linkedin.com\/company\/prodpad\/","https:\/\/www.youtube.com\/channel\/UCXHOx5Ed-6sHPujypIlhdMA"]},{"@type":"Person","@id":"https:\/\/www.prodpad.com\/#\/schema\/person\/ceec8b615b0ad09e9199ba2fa8545e8c","name":"Janna Bastow","description":"Janna Bastow is co-founder of ProdPad, software that helps product managers plan and deliver better products. Janna also organizes ProductTank events around the world, including Mind The Product, a global community of product managers. She likes to inspire great product conversations by asking: \u201cWhat problem are you trying to solve?\u201d","sameAs":["https:\/\/www.facebook.com\/bastow","https:\/\/x.com\/simplybastow"],"url":"https:\/\/www.prodpad.com\/blog\/author\/janna-bastow\/"}]}},"_links":{"self":[{"href":"https:\/\/www.prodpad.com\/wp-json\/wp\/v2\/posts\/1674","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.prodpad.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.prodpad.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.prodpad.com\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.prodpad.com\/wp-json\/wp\/v2\/comments?post=1674"}],"version-history":[{"count":0,"href":"https:\/\/www.prodpad.com\/wp-json\/wp\/v2\/posts\/1674\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.prodpad.com\/wp-json\/wp\/v2\/media\/4607"}],"wp:attachment":[{"href":"https:\/\/www.prodpad.com\/wp-json\/wp\/v2\/media?parent=1674"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.prodpad.com\/wp-json\/wp\/v2\/categories?post=1674"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.prodpad.com\/wp-json\/wp\/v2\/tags?post=1674"},{"taxonomy":"pp_uni_tag","embeddable":true,"href":"https:\/\/www.prodpad.com\/wp-json\/wp\/v2\/pp_uni_tag?post=1674"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
If you\u2019re working in a bigger company or large teams, you should err on the side of over-communication: more context and more deeply detailed specs. As a rule of thumb, the more moving parts that are involved, the less you want to leave up to interpretation. <\/span> For much of its life, a product spec is a work in progress. That\u2019s fine! That\u2019s how it should be. You\u2019ll be getting new information and dealing with potential setbacks throughout the process.<\/span> Thinking through the problem that you intend to solve – and sometimes even going back to the drawing board entirely – is not a waste of time. The problem is usually the hardest thing to nail. The best place to go looking for problems is in your customer feedback<\/a>.<\/span> Step 2: Break the problem down into a bunch of hypotheses<\/b> \ud83d\udc49\ud83c\udffd Essentials: <\/b>This is MVP level stuff. If this isn\u2019t there, the whole thing falls apart. What will it take to get this off the ground and functioning?<\/p>\n \ud83d\udc49\ud83c\udffd Nice-to-haves: <\/b>Non-essential, but would add immediate value. What will add value to the spec but isn\u2019t absolutely necessary?<\/p>\n \ud83d\udc49\ud83c\udffd Delightful: <\/b>The sprinkles on top; stuff that makes people smile What will make people smile?<\/p>\n<\/div>\n\n\n\n This way you can still account for the full scope of the problem, but keep your eyes on the ball. Think MVP. The essentials are your top priority. Everything else is going to have to wait its turn.<\/span> The opportunity to open up product discussions around what gets done and how is a key trait of effective product teams<\/a>. Everything you\u2019ve done so far makes sense on paper, but reality bites. Things change when you<\/span> put a prototype in front of humans<\/span><\/a>! It\u2019s time to see whether your assumptions hold and your customers react the way you\u2019ve imagined they will.<\/span> Can users complete the tasks you ask them to? Are they easily able to find buttons? Do they feel confident about where to look for stuff? <\/span> At this point, we\u2019re also looking at the bigger picture. We also look at how the new solution fits in with the way our users already use the product. What\u2019s the difference between changing nothing and putting something new in place? Remember how I mentioned earlier that product specs are always a work in progress? That\u2019s the case even now, here in this final step. <\/span> What is a product spec? A product spec is a blueprint that describes what you\u2019re building, who you\u2019re building it for and what the final outcome should be. A well-written…<\/p>\n","protected":false},"author":4,"featured_media":4607,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[5230,9],"tags":[78,130,186,201,234],"pp_uni_tag":[],"class_list":["post-1674","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-most-popular","category-product-management-best-practice","tag-featured","tag-new-feature","tag-product-specs","tag-redactor","tag-text-editor"],"acf":[],"yoast_head":"\n
On the other hand, if you\u2019re working closely with a small team, you might be able to get by with simpler, lightweight specs.<\/span><\/p>\n\n\n\n<\/a><\/figure>\n\n\n\nOur 5-Step Process For Writing Product Specs<\/h2>\n\n\n\n
We follow a process here at ProdPad that mirrors something Einstein once said: \u201cIf I had an hour to solve a problem, I\u2019d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.\u201d<\/i><\/p>\n\n\n<\/figure>\n<\/div>\n\n\n
So expect that you\u2019ll probably be making a series of changes to make along the way – but also that you\u2019ll end up with a more solid product spec for it. <\/span>
Writing specs is not a straight shot – but here\u2019s the process that works for us.<\/span><\/p>\n\n\n\nStep 1: Turn to customer feedback and data to find the source of the problems<\/h3>\n\n\n\n
Customer feedback comes in many forms: complaints, questions, product suggestions and feature requests. The most critical thing when evaluating all this is to <\/span>not take it literally<\/span><\/a>. <\/span>
What your customers are asking for is not a mandate. When you\u2019re investigating a problem area, each item of feedback is a data point to help you get down to the root of the problem.<\/span>
Speaking of data, customer feedback won’t always tell you if something critical like the checkout flow isn’t working. You’ll often need to look at the data!<\/span>
What\u2019s behind all this feedback in the first place? What is the underlying issue here? These are the kind of critical questions that help you understand a) the problem and b) the scope. <\/span>
Other questions to ask here: <\/span><\/p>\n\n\n\n\n
So how big is this problem, actually? In this step, you\u2019ll continue to understand the scope of what you\u2019re dealing with. <\/span>
Let\u2019s say for example, your customer feedback tells you that you have a big problem on your hands. There\u2019s no quick fix for this one. You need to completely redo your checkout process. <\/span>
Now you\u2019re probably considering all kinds of ideas<\/a> and that can quickly start to get overwhelming. What we suggest is that you break these ideas out into three categories: <\/span><\/p>\n\n\n\n
Step 3: Open up product discussions across your team\/company<\/b>
\u201cWriting a spec is a great way to nail down all those irritating design decisions, large and small, that get covered up if you don\u2019t have a spec. Even small decisions can get nailed down with a spec,\u201d says Joel Spolsky of Fog Creek Software<\/a>.
Oof, yes. That sounds familiar. However, those small decisions tend to add up – and it\u2019s in no one\u2019s best interests to start dealing with them when it\u2019s already sitting in your dev backlog. <\/span>
The mistake I\u2019ve seen made over and over is leaving these discussions until the end when a spec is already in production. You must create a space and a forum for your internal stakeholders to contribute while the idea is still taking shape. <\/span><\/p>\n\n\n<\/figure>\n<\/div>\n\n\n
Start inviting colleagues around the company now to help you start getting your idea ready. They know things you don\u2019t and they can tell you from their corner:<\/p>\n\n\n\n\n
We keep all our product discussions in ProdPad. Each product idea has a discussion section, so we\u2019re able to focus on really specific objections and concerns.<\/p>\n\n\n\nStep 4: Do user testing with your closest customers<\/h3>\n\n\n\n
At ProdPad, our designer preps a series of simple designs – really simple, like wireframes and clickable prototypes – for user testing. <\/span>
We do our user testing in two ways usually: <\/span><\/p>\n\n\n\n\n
What usually follows is that some of your assumptions were wrong. It\u2019s not as easy to find the buttons, or the flow isn\u2019t as obvious to the user as you thought it was. <\/span>
There\u2019s a couple other surprises you may find out here:<\/p>\n\n\n\n\n
But it\u2019s just a prototype and all you have to do is adjust it. Repeat until you\u2019re confident you\u2019ve gotten it right. <\/span>
So think of it this way: User testing is all about minimizing risks. It\u2019s cheaper to repeat this step than go live with a new feature that could blow up in everyone\u2019s faces.<\/span><\/p>\n\n\n\nStep 5: If it\u2019s ready, send to development<\/h3>\n\n\n\n
The, even if development goes flawlessly, QA is a diff story. Once you start clicking around, you might start to discover little things that you may have missed. It\u2019s okay not to be harsh on yourself – it happens even to us. <\/span>
We think everything is great and pat ourselves on the back for being so meticulous. But when we\u2019re testing, we think, \u201cHmm, maybe this button should be on the right because it doesn\u2019t actually make sense in the context of the rest of the app.\u201d<\/span>
It happens to the best of us. Perfection takes time. <\/span>
When you feel confident you\u2019ve got something going, add the final touches: final prototypes, technical information, key context, etc.<\/span>
If you\u2019ve been developing your product spec in ProdPad, now you can simply push to Trello, JIRA or your development tool of choice.<\/a><\/span>
All done! Now take a well-deserved break and when you\u2019re back, go right back to where you started from: <\/span>customer feedback<\/span><\/a>. The life of a product manager, eh? <\/span><\/p>\n\n\n\n<\/a><\/figure>\n","protected":false},"excerpt":{"rendered":"