Where do products come from? All products ultimately stem from a CEO or founder’s overarching vision for the company.

But how does vision get translated into the products we see and use every day?

First, the vision is written out as metric-based goals that the company wants to see. For example, a 5% increase in in-app purchases.

Next, managers create initiatives, or specific actions that will help their team to meet the goals.

An example of an initiative is “Redesign the purchase screen of the app.”

Initiatives are further broken down into releases, which are points in time when new features are released to users.

For example, “We’ll have a release in September of the new purchase screen.”

Finally, releases are broken down into groups of specific features and functionality called epics.

What’s an Epic?

An epic is a statement, defined by the Product Manager, of what you’re building and what features are necessary to implement it. Epics take longer than one sprint to build.

An average company produces three to five epics per quarter.

An example of an epic is: “Add a purchase button to the home screen,” or “Translate the app to Japanese.”

And epics may not be concrete features that go to the user.

For example, “Migrate the data to a new database.” This isn’t a feature, but may be necessary for the future of your product.

Defining Epic specs

After you’ve defined the purpose of the epic, you’ll need to establish its requirements before you can outline the product schedule.

To do this, you’ll make an Epic Spec Sheet (also called a Requirements Sheet), which defines exactly what you’re building and why.

This spec sheet makes sure all stakeholders have a clear understanding of the project. It should be easy to understand for any employee.

Epic Spec Sheets are divided into four parts:

Introduction

A brief summary of the purpose of and reason behind the features. You can include other helpful documentation or related metrics here.

You can also include what it will look like by adding wireframes, plans for MVPs, and the future vision for the feature.

Product requirements

A detailed list of what’s required for each feature.

Design requirements

You’ll write this together with the designer. Outline the design requirements in detail. Include sketches, wireframes, mockups, etc.

Engineering requirements

This is mostly written by the engineers. It outlines the engineering work, technology, databases, and other resources that are necessary to finish the feature.

PMs are responsible to see that this entire document is completed.

User stories

In order to collaborate effectively with designers and developers, you’ll need to harness the power of user stories and acceptance criteria.

These will come in handy when putting the work into project management software to send off to engineers. (A common software used by big companies is called JIRA.)

Instead of writing a vague statement like “Revamp the purchase page,” you’ll divide the work into each specific need and write them from the perspective of the target user.

These are called user stories, and they follow this format:

“As a __, I want to __ so that I can ____.”

Instead of writing the specific solution, you’re outlining the users’ problems and needs.

That’s because a PM’s job is not to decide how something should be built, but to communicate what should be built and why.

Focusing on the users’ needs and desires will allow you to build a much better product.

Each user story gets its own card called a ticket inside of your project management software.

Once you’ve created the tickets, you can change each one’s status (to do, in progress, done).

Once finished, engineers will work through the tasks one ticket at a time.

Acceptance criteria

Checking the engineers’ work and finalizing the tickets is also the job of the PM.

But how will you know that the feature has been implemented correctly?

That’s where acceptance criteria comes in.

Acceptance criteria is a set of requirements that the software must meet in order to be considered finished.

These are written into the ticket and look like this:

“Given that I am a (user) and I (complete some action), (this happens).”

Like user stories, this is written from the user’s perspective.

Be very specific with acceptance criteria so that nothing falls through the cracks.

PMs have to test the features according to the acceptance criteria before sending them off to be released.