How to set up your Product Stack’s Project Management structure?

Kshitij Saxena
Agile Insider
Published in
6 min readAug 23, 2023

This is part 3 of a long-form series of setting up your Product Stack’s Project Management correctly.

You can read Part 2 about the working and structure of Project Management tools here.

If you already understand the best practices for your Product Stack’s Project Management structure, please feel free to skip over to the next part where I discuss how to implement your Product Stack’s Project Management.

In the last two parts, we have understood the building blocks of a Project Management tool as well as the process of building a Product and its constituent building blocks as well.

Let’s first start by discussing another fundamental issue of Project Management by detailing the Requirements discussed in the last section.

Requirements are crafted from a user’s lens of using a product and devolve into various ‘Issues’.

Issue

An Issue is the smallest functional unit of Project Management which is the actual work item assigned to personnel on your team for meeting their deliverables.

The customizability of Project Management tools like ‘Jira’ and ‘Asana’ is mostly enabled by ‘Issues’ since there can be as many Issue types that you can create as you need.

Issue Types

You can create as many Issue Types as you desire on Jira by following this guide for creating your own issue type. You can also create a hierarchy between your Issue Types on Jira that would help you map a parent-to-child relation between Issues that exist between a higher to lower level (For Example — An Initiative which is at a higher hierarchy level may be broken down into one or more Features)

A typical Issue hierarchy map along with the Issue Types and the Projects that each Issue Type may belong to would look like this -

ProductStackProjectManagementIssueType

Initiative

As discussed in Part 1, an Initiative is a strategic decision that is undertaken to fulfill a business objective involving one or more Products. Please note that an Initiative should also belong to a Project since each Issue on Project Management must belong to a Project. Hence, as mentioned above, there must be Projects that should be created for mapping Initiatives.

An Initiative should be assigned to a Group Product Manager or a Lead Product Manager in the organizational hierarchy. Initiatives should be created only if your organization has multiple Products to build upon and planning needs to be done beforehand. I’d recommend not having Initiatives and Plans for organizations where the count of Products in your stack is less than or equal to 2 since this wouldn’t warrant larger planning and strategic management.

Feature

As discussed in Part 1, a Feature is a set of user flows to be built for one or more Products to achieve an Initiative. From Feature onwards, all Issues created may be mapped to Projects created for each Product or Product Type having the same intended objectives.

A Feature should be assigned to a Senior Product Manager or a Lead Product Manager in the organizational hierarchy. Features should be created only if your organization has multiple Products to build upon and planning needs to be done beforehand. I’d recommend not having Features for organizations where the count of Products is less than or equal to 2 since this wouldn’t warrant larger planning and strategic management.

Epic

An Epic is a collection of units of implementable work that’s going to be delivered in a decided period of time. An Epic is a smaller deliverable unit of a feature that can be used to track delivery milestones.

A feature may only be broken down into one Epic if the amount of work to be delivered is worth only one period of time decided upon by an organization. However, for more complex work, a Feature is usually broken down into more than one Epic with each Epic representing one deliverable unit of collection of work. All Issue Types below Epics in hierarchies should be created with their parent as Epics.

We’d later discuss how Epics and all Issues below this hierarchy can be mapped in the case of the Agile vs. Kanban approach of Project Management.

An Epic should be assigned to a Product Manager or an Associate Product Manager in the organizational hierarchy. Please note that Epics must be a part of your organizational Issue hierarchy no matter how many Products exist in your stack.

Development Story

A development story is a type of ‘User Story’ used for development to craft a written narrative from the perspective of a user using a Product rather than multiple functional development tasks.

A Development Story should be assigned to an Engineer (Developer and QA) in the Development team.

Design Story

A Design story is a type of ‘User Story’ used for designing to craft a written narrative from the perspective of a user using a Product rather than multiple functional design tasks.

A Design Story should be assigned to a Designer in the Design team.

Copy Writing

A copywriting task is a type of ‘Task’ assigned to a copywriter to complete the content on your designs.

A Copy Writing task should be assigned to a Writer in either the Design team or a specialized Content Team.

Bug

Any exception to the expected functionality in your Product is defined and filed as a ‘Bug’. Bugs help bring visibility to issues for which the intended functionality is breaking or the user interface doesn’t appear as it was expected to be.

A Bug should be assigned to an Engineer (Developer and QA) in the Development team

Task

A smaller unit of workstream than the development or design story is a task that an individual can create for oneself for keeping track of code commits or for fulfilling a smaller portion of the larger user story in one go.

A Task should be assigned to an Engineer (Developer) in the Development team

User Research

User Research tasks are created for specific times when organizations conduct research with objectives like the launch of a new business unit, the launch of a new product, or for understanding the unfulfilled needs of existing customers.

A User Research Task should be assigned to a Product Manager/Designer in their respective teams.

Usability Testing

Usability Testing tasks are created specifically for designs generated for user types where your Product and Design teams may not be sure of which specific version of the design to select and may go to the field with your target customer segment to test which ones are preferred.

A Usability Testing Task should be assigned to a Designer in their Design team.

ProductStackProjectManagementIssueTypeHierarchy

Summary

Here’s a brief summary of what has been discussed so far of all the types of building blocks, Issue Types, and the association of Issue Types with each other and which building block they’re a part of.

Additionally, we’ve also discussed which team member or resource type, each Issue Type gets assigned to in the usual case of an organization.

ProductStackManagementStructure
ProductStackManagementStructure

In the next part, we’ll discuss how to implement your own Product Stack’s Project Management by taking a real-life example.

Do share your feedback with me at kshitj.saxena@gmail.com or connect with me on LinkedIn

--

--

Kshitij Saxena
Agile Insider

Product Management experience in startups. Here to share the common, reusable, and powerful frameworks for building Products