Product Specs — Product Requirement Docs (PRD)

Notion template included

Product Specs (or PRDs) can align your product and the people who work on it to make sure you’re on the right path.

It’s the weapon of choice for a product manager to express the needs of the user, ideate on the solution, and align the teams towards a single objective.

✨ Get the Product Specs (PRD) Notion template here ✨

What is its purpose?

A thinking tool

Never start anything from scratch. A template forces you to think about a problem or feature more clearly and articulate it better. This way, you are sure not to miss out on any important considerations.

For example: If I didn’t have a metrics section for each feature, I would tend to ignore ways to measure the success of a feature.

Another example is, if I don’t have a research or needs section, I wouldn’t be forced to assert whether a feature provides value to the customer.

This is why templates are useful, even before you start collaborating.

Collaboration and alignment

Remember the days in which we used to write specs in Word documents and manually email them? Hard to believe that this was just 4 years ago.

Now we have the luxury of Google Docs, Slite, Notion-to write collaborative specs.

Comments become an important part of the collaboration process. You want to move from disorganized discussions on Slack to maintaining contextually organized notes on a discussion point.

But comments only work when you address and resolve them. Otherwise, they remain orphan comments.

It requires discipline to keep the specs up-to-date with new information, but it pays off in the long run.

By referring to the product specs in discussions, the team is aligned in one direction.

What does it contain?

The nature of specs differs from company to company, even between teams in the same company, and the type of product (B2B or B2C). Choose what suits your style the most.

Here is a template that I use for B2B/B2 Prosumer.

Talk about the goals, needs, and problems

A good story always starts at the beginning.

Set the context well by understanding the underlying user need or problem. Ask yourself-what’s the business goal from this feature or product and how will you measure success.

Now that you’ve highlighted the problem, provide evidence. I use the framework from The Mom’s Test to justify the problem to see if it really is a problem, and how are people solving the problem right now.

It’s only a problem worth solving if it’s causing a lot of pain and they’re actively seeking solutions to solve that problem.

You can include both primary and secondary research. Primary through user interviews, research, and testing. And secondary through benchmarks, surveys, and competitor analysis.

Then move to the solution

Once you’ve justified the problem, you talk about the features. I combine job stories with personas to explain features.

The jobs-to-be-done framework makes it very effective to focus on what needs to be achieved yet keeps implementation loose for the designer and developer to build on.

Personas humanize the user and enable empathy.

Sometimes, if I want to shape the discussion, I add comments.

Embed external links to designs and tech docs

I know that external documents like wireframes, high-fidelity designs, and tech docs will change. So I link to external documents, instead of including screenshots or image exports.

Free-flowing exploration

While thinking through the solution, you might start with whiteboarding, sketches, wireframes, or just random thoughts. I include them all under Exploration which illustrates the thinking process that has gone behind the scenes.

Wrap it up by keeping space for retrospectives

You’re not done when you just launch the feature. You need to see how well did the feature perform, what’s the feedback from users, and how to make it work better in the future.

When working on product specs, a few questions might come up. Particularly if you’re part of a small team with minimal process and documentation.

How much detail to add?

Always err on the side of detail. Having said this, it doesn’t give the liberty to be verbose in the document. The document should be as concise, crisp, and as clear as possible.

Why not move directly to implementation?

Suppose you’re a team of less than 3, you can get away without having any docs. But if you’re a team of more than 3, it’s better to write things down.

Because writing solves for ambiguity.

Also, if you don’t have needs or problems justified and articulated, you might move fast but in the wrong direction. You need to be able to objectively process every piece of feedback that comes your way.

Why not have only designs?

If you just show the hi-fidelity design without context or annotations — there can be ambiguity in interpretation.

Plus, they’re also harder to update for all scenarios.

For example, if you’ve to explain what tooltips are in a UI, it is far easier to write down in a document rather than design the tooltips manually for all tools.

Designs are always used in conjunction with specs and never on their own.

👉🏽 Get my crafted Product Specs template in Notion 👈🏽

That’s it for today, thanks for reading! Have any questions? Leave a comment below, and I’ll be happy to answer them.

Talk to you soon!

P.S. Hit the subscribe button if you liked it! You’ll get insightful posts like this directly in your email inbox every week.

Originally published at https://thediscourse.co.