The Product Development Lifecycle: Roles & Responsibilities
In an organization with engineers, engineering managers, technical project managers, product managers, UI/UX designers, what is the responsibility and working relationship between the different roles? How does a team find new opportunities and deliver business value? What does working together look like?
Let’s walk through the product-development lifecycle of a team both from a high-level strategy perspective as well as the per-project day-to-day development standpoint.
Team or Org Level Strategy
To start out, everyone on the team must understand the team mission & direction. The mission of the team answers the following questions: Why does the team exist? What products do we own and what business value do we provide either to the end users or internal customers? The direction and vision of the team answers: Where are we going? What pain points will we be solving in X years?
- For healthy team collaboration, it’s crucial for everyone involved to be aligned on the long-term vision of the team. It is the responsibility of the team lead to form the vision & strategy with input from the team. It is also the lead’s responsibility to make sure everything the team builds takes the team one step closer to that vision. If there are multiple teams, then an org level vision is required and every team’s vision rolls up to the org vision. →The EM/PM (engineering manager/product manager) pair share the responsibility of maintaining the vision and coming up with the strategy of how to turn the vision into reality.
→ An important part of setting team vision is setting KPIs (key performance indicators) or a method of measuring success. How do you know the direction the team is going in is actually bringing business value? How much business value? Is it the best fastest path (or at least a fast and sustainable path) to achieving that vision?
→ It’s also important to learn how to properly communicate this team vision to other parts of the company so everyone understands what value your team brings, how it fits into the larger company mission, and how to collaborate with your team. I’ll save more details on this in a future post. - User research is the first step to understanding the customers and the problem space the team is trying to solving. This step can be performed by the product manager or the user researcher. This research will help the team identify opportunities for new products and/or feature ideas. At Square, many teams use the JTBD framework to gather and identify customer needs. What are the opportunities that bring the team closer to accomplishing the vision?
- With a prioritization strategy, normally designed by the product manager by using KPIs and metrics, it is the responsibility of the engineering manager & product manager to use the prioritization strategy and create a roadmap. The engineering manager forms a list of engineering improvements, scalability, and maintainability requirements. The product manager forms a list of new product/feature ideas generated from the user research (2). The team roadmap is a single prioritized list formed by merging the two engineering priorities with the product priorities.
- To properly communicate the team’s progress, the team vision should be broken down into annual goals, which splits further into quarterly goals, and organized even more granularly into sprint goals. Sprints can range from 1–3 weeks long each. Even if a project spans multiple sprints, it’s important to set smaller milestones on a per-sprint basis to easily share and keep track of the progress.
On one particular project
For a specific initiative, once the pain-point has been identified, the product manager plays the glue of the team. As a group, the team needs to figure out the answer to this question: What is the problem & how do we solve it sustainability in the shortest* amount of time? and successfully build and ship that solution.
*a key thing to keep in mind here when thinking about product strategy & coming up with a solution is knowing how to balance short term wins against long term wins
Many different frameworks or approaches can be used to accomplish this, here is one suggestion.
Even though the sections below have suggested owners, any team member should be welcome to contribute to any part of the process. This helps individuals empathize with one another’s struggles across the different roles.
IMPORTANT: My personal philosophy around product development is that even though there are many frameworks that suggest different ideal working patterns, the key to a successful cross-functional partnership is collaboration & flexibility. Product requirements may change mid-development because of an unpredictable blocker, or designs might have to change because of new incoming customer feedback. While using a framework can help define some of the responsibilities and relationship boundaries, approach this process with an open mindset and be comfortable with change. It’s okay to move plans around or push back the deadline as long as these changes are reasonable and communicated properly & early.
[3–4 sprints before implementation]*
- User Stories | UX Research/Product Manager — Perform user research by talking to customers through interviews, product tests, surveys, or other methods to better understand the customer perspective and identify the opportunities. What pain point is this initiative attempting to solve?
[output] User Stories doc that encompasses current user flows and pain points. It can also include ideal user flows. These ideal flows should not be copied verbatim into the PRD; instead, they can be used to understand what the customer is asking for. The reason is a customer’s suggested solution is often one sided, it’s frequently not a good idea to build feature requests without a full 360 perspective. - Product Requirement Document (PRD)| Product Manager** — based on the user stories and constant communication with the customers, the product manager designs a new product or feature by putting together requirements in the PRD. If an engineer is playing this role, it’s especially important not to conflate WHAT the product is with HOW to build it.
[output] PRD draft — WHAT is the product and WHY are we building it. What are the requirements of this new development. How do we measure success & What is the rollout plan?
→ The PRD is reviewed by the stakeholders, designer, & engineering project lead.
→ Tradeoffs regarding functionality vs maintainability, complex designs, as well as missing features should be discussed at this stage
→[important] Don’t forget to add KPIs and how we measure success of this new feature or product
→ It’s also important to design a rollout plan for the new initiative because that will also have an impact on engineering decisions.
→ a fully complete PRD should be thorough and inform an engineering team exactly what the requirements of a product is.
[2–3 sprints before implementation]*
- Mocks & Wireframes | UI/UX Designer — Once the stakeholders sign off on the PRD, design should build wireframes and mockups for the new product/feature.
[output] wireframes — add more clarity to WHAT is the product and how all the different features/user flows work
→ [important] Don’t forget to design user experience flows and describe in detail how a customer will interact with the different components. This piece is often overlooked, but it is very important and will inform engineering architecture
→ Depending on the product, it can be helpful to run these mocks & wireframes by the stakeholders to get their feedback on the new designs.
→ These new designs need to be reviewed by both the PM & engineering lead. Once all parties agree, they should be added to the PRD
— — PRD is finalized at this stage — —
[1–2 sprints before implementation]*
- Engineering Design Document| Engineering Manager/Engineering project lead — the eng design should describe in detail all implementation architecture of the product or feature. This design is both a project plan as well as a method of communication for the development team or external teams who will be using/integrating with this new development.
[output] Eng Design Doc — HOW is the product built? What are all the tradeoffs considered, optimal & alternative implementation methods, timeline & engineering resources required.
→The eng design needs to be reviewed and signed off by the development team, any tech leads, all technical stakeholders (owners of systems that will integrate with or be integrated with), and the engineering manager.
→The engineering manager is responsible for ensuring that the architectural designs are sound and all perspectives have been considered. Ideally, technical disagreements are resolved at this stage. The EM is also responsible for allocating the right people to the project and that the timeline matches up with the overall team long-term execution plans.
→This design can also be reviewed by the product manager & designer if they feel they have an strong-enough technical expertise to provide input.
→The eng design doc is written by the Engineering project lead, but must be signed off by the engineering manager. It is the manager’s job to find the appropriate project lead for each project
— — Eng design is finalized at this stage — —
- Implementation | Engineering Manager/Engineering dev team — The eng design is broken down into tickets and added to the sprints based on initial estimations.
→ Managing execution pace & output | Project Managers/Engineering Project Lead/ or Engineering Managers are responsible for making sure the estimates are reasonable and that the project stays on track as it’s being developed on by the team of engineers allocated to the project.
→ Reviewing user-facing components | UI/UX Designer/Product Manager — If there are user-facing screens involved, it is the Project Lead’s responsibility to pull in the designer & product manager to review completed user flows and any UI components before they’re “completed”.
→The dev team does the work, but the Engineering Manager is responsible for the overall team output & execution. - New Product Rollout | Product Manager/Project Manager — This portion is different depending on the product you are working on. For many consumer products, this phase is continuous throughout implementation. For an enterprise product, a more-detailed rollout plan is required. That is because we can’t change the user experience of all our enterprise customers every day. This would break their user experience and end up costing our customer companies/teams a lot of money in lost time.
→ Ideally, the product manager designed a well thought-out rollout process with an alpha tester team and then releases the initiative to the rest of the teams in waves. The product manager & project manager can collaborate with customer teams to help them train agents & slowly migrate their workflows to the new system.
Suggested Timelines & Notes
* These timelines are all suggestions and can vary based on complexity and scope of the new project. They are there to give you an idea of how to allocate sufficient time for the different parts of the life cycle. This is why people say “the PM & Designer are frequently 1–2 months before the engineering team” If a team is working on multiple projects at the same time, it’s important to stagger them and plan them out during annual/quarterly planning so there are always different projects in different stages of the product development lifecycle.
** In lieu of a product manager, the engineering manager or a project lead can step in to fill the roll. However, it’s important to not wear both engineering & product hats at the same time as the product perspective answers the WHY & WHAT while the engineering perspective answers the HOW. The two optimize for different perspectives. Product optimizes for customer experience while engineering optimizes for engineering maintainability and scalability. Conflating the two will end up with a mediocre solution for all parties.
