How to implement your Product Stack’s Project Management?
This is part 4 of a long-form series of setting up your Product Stack’s Project Management correctly.
You can read Part 3 about the setup of the Project Management structure of your Product Stack here.
If you’ve already implemented your Project Stack’s Product Management, please feel free to skip over to the next part where I discuss the best practices to follow for the Scrum and Kanban methods of Product building.
As discussed, the correct Project Management structure of your Product Stack should be decided by the number of Products or by the types of users of your product stack.
Throughout this series, I’d use a case study of a hypothetical online cab booking platform called ‘EasyRide’ to help us understand the process of building Products and Initiatives across the Product Stack.
Let’s recap quickly what ‘EasyRide’ is and what it aims to achieve -
‘EasyRide’ is an online cab booking platform that enables users of the platform to book a cab on demand to go from their current location or a location of their choice to a chosen destination. To fulfill these cab bookings, ‘EasyRide’ provides its drivers with a ‘Driver’ App where they receive and service these bookings.
To get bookings from local taxi stands, ‘EasyRide’ has an ‘Agent’ App where local taxi stands that EasyRide has tied up can book the same inventory.
All this inventory of ‘EasyRide’ is hosted on an ‘Admin Dashboard’ that users can use to add dynamic pricing and the ability to book the same inventory.
Here’s a high-level diagram of what this Product stack looks like -
Let’s assume that you want to set up your Project Management structure for managing Product-building efforts for all these products. Let’s start structuring your Project space on a Project Management tool -
Projects
In part 3, we discussed the types of Projects that you’d need to exhaustively manage all the Product-building efforts that you have. Let’s try to enlist all the types of Projects that you’d need -
Product Projects
We’ve already discussed a thumb rule that you’d need to create one Project for every Product that you have in your Product stack. Taking from the sample above, here are the Projects that you should create -
- EasyRide Consumer
- EasyRide Agent
- EasyRide Driver
- EasyRide Admin Dashboard
Please note that you may have different developers working on a requirement needing to build the same user flow on the EasyRide Website, EasyRide Android Application, and EasyRide iOS Application. Even then, one project for all these three streams will suffice since they’d be used to build product requirements for the same type of user — A person who’s on the website or on the App to book and take a ride from a source to a destination.
A major takeaway from this is that the platform that your Product is available on such as Android or iOS doesn’t matter. All requirements related to all of this should form part of the same Project.
Initiative Project
The number of ‘Initiative’ Project types would depend upon the division of Product structure in your organization. Usually, the following are the two types of Product structure divisions that exist in multi-product organizations.
Business Unit Structure
If your organization is structured around Business Units, then you should create one Project each on a combination of your ‘Business Unit’ and its ‘Function’ since most of your Initiatives would be mapped around a combination of Business Uni and Function.
Taking the same sample, the following would be the possible Business Units if the organization is structured in that manner -
- Consumer
- Agent
- Driver
Usually, the Business Units division is chosen by organizations that have multiple services to offer to different types of consumers. (For Example — Food Business Unit and Groceries Business Unit for a Food Delivery Platform)
The following would be possible Functions inside the Business Units -
- Demand
- Supply
- Operations
Hence, taking from the above, the following would be your Initiative Project types for a Business Unit type of structure -
- EasyRide Consumer Demand
- EasyRide Consumer Supply
- EasyRide Agent Demand
- EasyRide Agent Supply
- EasyRide Driver Demand
- EasyRide Driver Supply
Function Structure
If your organization is structured around Functions. then you should create one Project each on a ‘Function’ level. Taking the same sample, the following should be your Initiative Project types for a Function type of a structure -
- EasyRide Demand
- EasyRide Supply
- EasyRide Operations
- EasyRide Marketing
Collector Project
For ‘Collector’ type Projects, the number of Projects to create would depend upon the type of development methodology you’re following —
Agile Methodology
If you’re following the Agile Methodology, then you would need to create the following two collector projects —
Engineering Sprint Project
Engineering Sprint Project would reference all other Projects to display all the development-related issues present across the entire organization. This Project should be used for planning your development sprint as well as for grooming your backlog of all issues that need to be picked.
Design Sprint Project
Design Sprint Project would reference all other Projects to display all the design-related issues present across the entire organization. This Project should be used for planning your design sprint.
Kanban Methodology
In case your organization follows the ‘Kanban’ methodology of Product building, then you can have only one board with the collection of all Issues of ‘Development’ and ‘Design’ types which would keep moving in their respective stages.
Please note that you can also choose to create two different Kanban Projects separately for ‘DEsign’ and ‘Development’.
Summarizing this section, you should have the following Projects in total —
- EasyRide Consumer
- EasyRide Agent
- EasyRide Driver
- EasyRide Admin Dashboard
- EasyRide Demand
- EasyRide Supply
- EasyRide Operations
- EasyRide Marketing
- EasyRide Engineering Sprint
- EasyRide Design Sprint
Boards
Each ‘Product-type’ Project would have the following two boards. You wouldn’t need a Board for any ‘Initiative-type’ Project since these are only placeholder Projects for Initiatives. You would need a Board for a ‘Collector-type’ Project for running the ‘Sprint’ or ‘Kanban’ methodology of Product Building.
Hence, you should have the following boards -
- EasyRide Consumer Development Board
- EasyRide Consumer Design Board
- EasyRide Agent Development Board
- EasyRide Agent Design Board
- EasyRide Driver Development Board
- EasyRide Driver Design Board
- EasyRide Engineering Sprint Board
- EasyRide Design Sprint Board
Issues
Issues are the building blocks of Project Management which get assigned to users of Project Management and which give the visibility of ownership of each type of project. Let’s first discuss the Issue Types —
Issue Types
In part 3, we discussed the list of exhaustive ‘Issue Types’ that you’d need to map all types of your Product Building tasks. Let’s recap and list down all the Issue Types that we identified in that part -
- Initiative
- Feature
- Epic
- Development Story
- Design Story
- Copy Writing
- Bug
- Task
- User Research
- Usability Testing
The important thing to note here is that you could create multitudes of Issue Types on your Project Management tool. You’d still need clearly defined stages in each Issue Type that an ‘Issue’ would take to distinctly understand the progress on that Issue Type. Let’s list down all the stages of the Issue Types discussed —
Issue Stages
Issue Stages are the critical success factor for your Project Management implementation. If you get the list of your exhaustive stages right, most of your issue tracking and reporting of your development progress will be sorted. Here’s a link to create your custom stages of each Issue type in Jira.
Initiative
An Initiative should have the following stages —
Please note that for an Initiative, I’ve included stages such as ‘Blocked’ and ‘On Hold’ because, at the level of initiatives which are mostly strategic in nature, your organization may choose to start an Initiative but put the same back on hold pending some decision clarity or changing environment. Additionally, some Initiatives may remain blocked by other Initiatives and may have to wait for them to roll out first.
If your organization doesn’t function at the level of ‘On Hold’ or ‘Blocked’, you may choose to skip those. An Initiative is undertaken to be qualified as ‘Successful’ or ‘Not Successful’ to get the result that was desired. Please note that not being successful doesn’t mean failure of an initiative. It just means that it didn’t get the desired outcome.
Feature
A Feature should have the following stages —
For a Feature, you should have a ‘Picked’ stage which indicates that to fulfill an ‘Initiative’ if you may have ideated on 4 ‘Features’, then you may not choose to pick all four of them. The ‘Ideation’ stage indicates the stage at which a Feature is being broken down into development requirements and deliverables. ‘Epic’ created stage indicates that the Feature will now be given for timeline-bound ‘Design’ and ‘Development’.
You can choose to not include the ‘Await Release’ stage if your organization directly releases the development work it has concluded into production.
Epic
An Epic should have the following stages —
You may not have the ‘Business Scoping’ stage for all your requirements across all your ‘Epics’. In such a case, you may choose to eliminate the stage. Your technical team should use the ‘Technical Scoping’ stage to break down the requirement into all the implementable pieces such as ‘Front-End’, ‘APIs’, ‘Back-End’ logic, and Database Architecture.
Design User Story
A design story should have the following stages —
The ‘Wireframing’ stage should be used by your design to come up with the basic idea of the number of screens, the information to be displayed to the user, and the basic flow for the user. The ‘Design In Progress’ stage should be used to implement the design on top of the wireframe according to your Design Language and come up with the Interaction design for the user. If you go to the design implementation straight away, you can choose to skip wireframing.
The ‘Design Review’ stage should be used to critique the design, come up with edge cases, and correct any function flaws in the design. The ‘Content Review’ stage is needed for design stories that require your copywriter to come up with engaging content for some of your screens.
Copy Writing
A Copy Writing task should have the following stages —
Please note a copywriting task should be created when your designers are working on design stories.
Development User Story
A development story should have the following stages —
You may choose to have the ‘Functional’ and ‘Design’ QA as one stage only if both responsibilities are performed by one person in your team. However, as a best practice, I’d recommend your designer do a ‘Design QA’ of each user story. You could also choose to not have the ‘Code Review’ stage if your organization doesn’t mandate a review of the quality of the code.
Please note that depending on the priority or impetus of design in a development story, you may have scenarios where a ‘Functional QA’ is required, but a ‘Design QA’ isn’t. It may also be a case, that you go live straight away than awaiting release. Therefore, you should have provisions in your stage flow, to skip a stage or two to reach the last ‘Done’ stage.
Bug
A bug story should have the following stages —
Please note that the stages in the ‘Bug’ and ‘Development User Story’ Issue types are the same. The only difference between the flow is that from the ‘To Do’ stage, a bug can be moved to the ‘Done’ stage since a bug may not be reproducible that may have been reported.
Task
Please note that a ‘Task’ is created as a part of the whole implementation of a ‘Development User Story’. There could be multiple tasks created for development contributing to a development story.
User Research
A User Research task is created out of sync with the rest of your ‘Agile’ or ‘Kanban’ process of Product Building but is created for your Product team to Business Team to conduct research with defined objectives.
Usability Testing
Please note that a ‘Usability Test’ should be conducted for user flows that you’re building to either create a new category of Products or to test usability with a specific segment of your users for whom a specific user flow is being built. It should be done before you give your designs for implementation to save on the cost of development. You should try to test as much as possible with a prototype of your product which modern designing tools like Figma and AdobeXD provide.
Summary
We have now discussed the exact number of Projects, Boards, and Issue Types along with the stages that you would need to create, manage, track, and visualize the progress of your Product Stack.
In the next section, we’ll discuss the two famous methodologies for building products and will try to establish a framework for using the right methodology for your specific use case.
Do share your feedback with me at kshitj.saxena@gmail.com or connect with me on LinkedIn
