How does the product vision is turned into the product itself? The CEO and company executives have a vision where the company is going and what the goal is for the next 3-5 years. Company has to have goals to get to the vision. Goals are decided by the executives but defined further into metrics – for example, increase new user signups by 30% this year. Then there’re initiatives the whole company would do to achieve each of those goals. For example, revamp user sign up flow.
Underneath initiatives, there are releases. They are a group of features or functionality that is released to the public on one particular date. For instance, we have a release of new user sign up flow in May. This will be our release. The product features and functionality that are in the releases are called epics.
Epics group one or more features and functionality that we’re building to solve a problem. Usually a product team builds 3-5 epics per quarter of the year. It depends on the company and team size how many efforts the epics going to take. An example of epic would be, allow users to work with files offline and sync files when online.
The term epic usually equals feature but not all the work done on the product can be presented as the new features for the user. So epic term reduces confusion, for example migrate API version would be an epic but it’s not a feature. This epic might be done to scale or to allow more uses. Epics are defined as something that needs more than one sprint to build.
Most project management apps (Jira) allow you to create an epic and then add features (user stories) to this epic. In any case epics always have supporting documentation with them explaining what are you building and why. Sometimes it’s called epics spec sheet or requirements document. It can be hosted in Jira, Google docs or any shared resource so the company employees have access to it, can read and understand what are you building. It also works as guide for the team as you build things.
How epics specs usually look like? They usually have 4 major areas – an Introduction, Product requirements, Design requirements, Engineering requirements. Product manager is responsible for creating and maintaining epic spec sheet but especially responsible for the first two items. The introduction contains summary of what features are for and why you’re building it, what metrics you’re trying to improve? It also usually contain links to supporting documentation, marketing plans, legal requirements, what feature and functionality look like, early wireframes and what it looks like ideally vs. what are you going to build for MVP, v2, etc.
The second section is the product requirements. Here we are talking about features or functionality we’re developing in details. We go deeper on what’s required. For instance, the feature should be fast or available in certain language. Or it must generate a certain type of data and store it for later use.
The design requirements section is to be filled by PM and designer together but more from the designer side since they are the experts here. For example, you need high resolution for user picture and this will be stated in this section. It also contains early wireframes and sketches or high fidelity prototypes to help engineers better understand the requirements and what have to be done here.
Engineering requirements spec sheet section is filled out by the engineers after you discussed the product and design requirements with them. Here’s the engineers will write down the database and technology requirements or outline a series of things that must be done on the technology side in order to support new feature. For example developing new API endpoints to support high-resolution picture stated in design requirements. Or they need to know if they need to work with another team in order to access their database in order to build this new feature.
User stories and acceptance criteria are located underneath epics. With their help, you take epics and get them into developers’ hands to work on. After decision has been made of what you’re going to build, you had outlined the phases you’re going to build them in. Now you need to put this work into project management software so that the engineers can start working on it. This is where user stories and acceptance criteria come in.
User story is a way to describe a thing you’re going to build that delivers some type of functionality to the end user. For example, As a user I want to know my Spanish level accurately so I can resume my language study at the right level.
User stories always follow this format – As an x I want to do y so I can z. Why user stories have this format? Product manager usually writes them and puts into project management software. By writing them this way, you can avoid saying how something should be built on the technical level. You’re not telling engineers how to do their job you’re just telling functionally – as a user what I should be able to do.
User stories belong inside your PM tool where there’s a card with your user story and different status: to do, in progress, and done. These cards are commonly called tickets and besides user stories they contain bugs and other issues. The engineers complete the user story and move on to the next one. Before you can say that the user story is complete you need to make sure that the functionality does what you intended it to do.
This is where acceptance criteria come in; it’s a set of conditions user story must satisfy to be considered complete. Typically, acceptance criteria are written with the ticket. “Given I’m a user who has successfully completed my language assessment, I want to get a report with my accurate score and recommended level.”
AC are usually very specific because their purpose is to reflect how the feature should function. It provides a list of things you can test before releasing it to the public. This is very helpful for engineers who like everything to be very specific so that they can think through the process of engineering the stuff correctly. Product Manager is usually responsible for testing completed tickets and stories before approving them to go live.