Hey, I'm Corinn and I'm the founder of Speckled - the tool that helps PMs
build the right thing at the right time.
Today, we're going to be talking more about product requirements
documents, a.k.a PRDs a.k.a Specs.
And we're going to be covering the various sections of a PRD.
Now, if you're not familiar with the PRD, it's a overview of a
feature or a product or something big that you're about to build.
The PRD writing process is usually preceded by customer interviews.
So when I'm talking about PRDs, I'm kind of assuming that you have already done
your customer discovery and research.
Now we're just going to take all of that stuff from customer discovery,
tie it up neatly, write a bit more about it, find the insights and really
summarize them and put them into a written format, put a little bow on top
and then hand it off to engineering.
Now you're probably wondering, okay, I have my customer discovery done.
How do I write a spec?
Well, the first thing that you're going to want to put in a spec
is some quick reference data.
This is stuff that is just most likely in a table at the top of the document, it's
going to list out when this feature or product is going to hopefully be released.
It's going to indicate if it's part of a larger Epic that you're working on.
It's going to give the status of the actual document...
is this still in draft?
Is it ready for review?
Is it out in the wild?
Is it with engineering?
Like where is this in it's life cycle?
We're also going to include things like who is the owner, the product
owner, and key information such as who is the technical lead, design lead,
QA lead and other important people involved in the actual implementation
and construction of the spec.
That's, what's in the quick reference status section, next up is the objectives.
And this is kind of the really big picture stuff.
This is the section where you're going to outline what this is, who it's for,
why you're doing it, how you may plan on doing it and how does this fit into
the organization's larger objectives?
So after you've written your objectives, the next section is success metrics.
And you may choose to include this or not.
I like to choose to include it because it leaves a lot less
ambiguity in the whole process.
This is where you're going to write out what it means to be successful with
this particular feature or product?
Like how do we know we did it and we can give ourselves a pat on the back?
Um, I just like to include it.
You don't have to, but I think that most specs should include some kind of
success metric, no matter how small.
Next up...requirements.
This is where all of your user stories come into play.
This is where they're all going to be located and hang out together.
Now, if you're not familiar with writing user stories, I do
have a different video on that.
I'm not going to cover how to write them right now, but just know that the
requirement section is where they live.
You may also choose to add technical requirements or business
requirements in this section.
Next up is documents.
Usually at a minimum this includes some kind of wire frame or mock-up, but in
many cases it may also include things like icons or design elements, maybe some copy,
maybe some database diagrams, whatever it is that's going to make the implementation
of this spec easier for your engineers.
And finally, we have the section that includes everything that is out of
scope or is future work that we're not going to worry about right now.
So this is just to give engineers a little bit more insight into what may be coming
down the pipeline and may help them design for more flexibility in the future, but
lets them know that, Hey, you know, we don't have to do X, Y, and Z right now,
we just need to worry about a, B and C.
So those are the six sections.
They are once again, some quick reference data objectives, success
metrics, requirements, documents, and things that are out of scope.
If you liked this content, be sure to subscribe to our newsletter
getsspeckled.com/blog, drop your email there and every Sunday we
send out a newsletter with the top three stories of the week for
PMs at small software companies.
And in the meantime, happy spec writing.