How to Get Your Product and Engineering Teams Running Like Clockwork

18 min readAug 16, 2018

If you are a software startup leader, Product Manager (PM), Engineering Manger (EM) or anyone who wants to get their product and engineering team executing more predictably, more efficiently and with less stress, this post is for you. While there are countless tools and software out there for managing your team process, what is missing is a comprehensive approach to software development. Below is an opinionated framework based on over 10 years of product and engineering management experience on what has worked for me to get my product, design and engineering organizations executing with the lowest friction, highest throughput and greatest overall team happiness.

Common Challenges in Development

Process can be a four letter word for many companies, especially on high growth teams and at the early stages of startups. However, without some agreed upon process, there are a number of problems that come up at various stages of software development. Release delays, requirements churn or working crazy hours to meet a deadline can all be common. Each of which can cause commitment delays, misalignment across teams and unhappy customers and employees. There’s nothing worse than having a workforce of highly capable professionals feeling like they don’t have the suitable structure to utilize their full potential. Regardless of the company stage, the teams that perform the best and have the least thrashing tend to have a solid framework in place. Illustrated below are some of the common challenges at the various stages of development.

Existing Approaches and Tools

Popular approaches like Agile/Scrum, Waterfall or Kanban are a great start for engineering teams, but they only solve part of the problem. For example, how do you set and track quarterly goals using agile? How do you handle unexpected bugs and customer requests in pure Waterfall? How does your Kanban board tell you when a big project has met all requirements and is ready to ship to customers?

You’ve probably used some set of tools out there such as Jira, Asana, Trello, Git tasks, sticky notes or a good old spreadsheet. All of these tools can and will work. The key is in how you use these tools and that to get your cross-functional team bought in and committed to using the process. Let’s dig in.

Principals for a Software Development Team Process

First, let’s start with some principals for a comprehensive process. Considering the common issues that come up, a good process framework should have the following principals. Our process should have:

Planning accuracy and predictability of releases
Accountability without unhealthy pressure
Flexibility to handle ad-hoc and emergency requests
Avoidance of re-work once engineering work starts
Keeping engineers, designers, PMs and leadership in-sync on expectations
Keeping the team happy, calm and feeling like things are under control

Achieving these goals consists of two large areas: planning and execution. Let’s now get into the specifics.

The Planning Process

The first step before any execution begins is to have a good planning process in place. The planning process needs to account for longer term, big picture initiatives as well as ongoing requests that come up during the year. An overview of the process is illustrated below.

Backlog Inputs

A primary source of backlog items should be ideas that come from user research, support tickets, customer feedback, leadership input and the PM’s vision for the product. Additionally, across the organization, team members should feel that they have a way to give input and ideas to the product engineering backlog after formal planning. It is the job of the PM and EM to synthesize this into the backlog and own the priority of what is worked on and when. Having a formal input system for requests, especially with the sales, ops and customer service teams is a great way to create a shield for the product engineering team from being randomized. A simple Google form that populates a spreadsheet that is reviewed regularly to get new items on the backlog has worked well for me in the past. At least twice a year, typically aligning with the planning cycles (more on that later), a brainstorming session with the whole team is a must. Then the output of that sessions should be synthesized and turned into actionable backlog items by the PM.

Finally, the engineering team will have technical debt, refactoring projects or framework migrations for which they will need to carve out roadmap time for. These should be included on the backlog and prioritized alongside other projects to promote transparency and to ensure the team is tackling the most important projects in order. The EM or tech lead will need to be the champion of these projects and be able to articulate the importance of them relative to the customer-focused product efforts.

Backlog Prioritization

An organized, prioritized product backlog is one of the most important aspects of a good planning process and a high-functioning team. The backlog not only serves as the on-deck list of what the team is going to work on next, but also as the source of projects that go into the larger goal commitments, roadmap and resource plan. Of all the tools out there, I still find an online spreadsheet to be the best for building the product backlog as it offers the most flexibility for formatting, editing and sharing and allows you to add custom columns that make the most sense for your company and team.

On the product backlog, the key elements to include for each item are:

Project Description: this can be in the form of a user story or just a simple description that is universally understood.
Impact score: this is the meaningful, objective estimate a given backlog item will have — this can be users, revenue, ticket reduction etc. If you use different metics for different backlog items (which is likely), you’ll need to do a mapping of each metric to a relative score (i.e. 1–5) so that you can compare apples to apples between items that are driving different success metrics. For example, a 3 might mean 10M in monthly revenue, a 20% reduction in tickets or 1M monthly active users and a 2 might mean 5M in monthly revenue, 10% reduction in tickets or 500k monthly active users, but a 3 should always have a bigger overall impact than 2.
Technical costing: values should be a t-shirt size or other SWAG; it is helpful to have a lookup to translate any non-time-based estimates like t-shirt sizes to an actual range of weeks; you’ll need that to set your OKRs/half-yearly goals with confidence.

Another feature of your backlog should be a cut line. Items above the cutline indicate that they are ready to be kicked off. Items below the cutline should be prioritized, but can still have a lot of unknowns (legal, scope, feasibility etc). You can also create a 2nd cutline to serve as an ‘icebox’ to park ideas and distant future projects.

Resource Plan and Roadmap

The engineering resource plan is owned and updated by the EM while the product roadmap is updated by the PM. These two docs are admittedly somewhat redundant, but have different purposes. It is possible to utilize a roadmap doc for both purposes, but you have to be careful not to overbook engineers and ensure that tech debt projects are captured. I’ve found that both of these tools are also best in a spreadsheet which creates the most flexibility to customize for your team and company.

The resource plan is a matrix of each engineering team member on the Y axis and the week on the X axis. Each color-coded cell is simply filled in with the project title. Projects will span 1 to N number of weeks. Vacation and other out of the office should be captured here as well.

The roadmap is similar to the resource plan, but the Y axis on the roadmap is each project. The product roadmap includes not only the engineering time, but also the design and spec time prior to engineering work kicking off along with launch and A/B testing time. These milestones are represented by checkpoints, which are described later in the execution part of this article. At a high level, Checkpoint 1 is requirement definition complete, Checkpoint 2 is engineering costing complete, Checkpoint 3 is beta ready and Checkpoint 4 is the full launch after beta and A/B testing (when applicable). The roadmap will typically only capture medium to larger projects. The roadmap is typically consumed by cross-functional folks across the company while the engineering resource plan is typically consumed only by the engineering team.

For both documents, the goal is to have at least 2–3 months planned with rough estimates to give an overall sense of who is going to work on what, and when. This will help set the goals for individual engineers and designers and give the product and business teams a sense of what resourcing and project timelines looks like. These tools will also ease discussions about any unplanned requests since it is much clearer which other projects will have to move in order to slot in the ad-hoc request.

Planning Cycles for Goal Setting

I’ve found that the larger planning cycles and goal setting is best to organize in half year increments. A six month period gives a nice balance to steadily achieving commitments and allowing for enough time to execute in between so the team isn’t constantly doing planning activities. These larger planning cycles are where the team commits to their goals or OKRs (Objectives and Key Results) that are formally reviewed with org or company leadership. These goals are what the team will be held accountable for and should be reviewed monthly with the leadership team to update on progress. There is lots of written information out there around setting goals/OKRs, for example here is a good OKR overview from Google.

Setting Goals

In most software product companies, there should be 2 types of goals: project and business. Project goals are the specific projects that you plan to ship, including new products, end user features and technical migrations or platform work. Business goals on the other hand are the numerical targets that the team is shooting for. Many (but not necessarily all) of your project goals should support a business goal.

If you’ve done a good job with prioritizing your backlog and building your roadmap, your project goals should be relatively easy to create. It should essentially be taking a look at your product roadmap and resource plan and officially committing to the bigger projects your tools tell you that you can get done in the time period you are planning for. Many of your project goals should support hitting your business goals.

Business goals will be focused on metrics like sales and revenue targets, customer service improvements and measurable numerical success factors. How to set these is a topic for another post, but this is where your sales/BD team, marketing team, customer service and leadership team should be heavily involved. Depending on the size and complexity of your company, you may set goals/OKRs per division (i.e. marketing, customer service, sales) or combine them all into one set with clear ownership for each.

The way to organize your goals is around themes that group together a set of project and business goals. In OKR speak, these would be your objectives. These themes/objectives are typically created by the PM and the EM along with leadership and should be agreed upon first before goals/key results are set. Think of them as categories for your goals that serve a business or engineering purpose. For example, growing revenue, reducing churn or improving quality are all good themes/objectives. The sweet spot for a typical 10–15 person R&D team over a 6 month period is 3 to 6 goals per theme/objective and 3 to 6 themes/objectives overall. For all your goals, you want to set targets that are a stretch, but achievable. 80% achievement of your goals should be considered success. Once goals/OKRs are set, they should remain locked for the 6 month period. Goals should be reviewed monthly with the cross functional leadership team where status and numerical targets are updated and reported on by the respective owners.

The Execution Process

Okay, now you have your plan and goals set, what is the process to get stuff actually done? For each project’s overall execution, we borrow a bit of the spirit of waterfall approach to software development. Yep, I said it. Waterfall. While all the hype has all been about agile development in the last decade, my experience has been that teams that are too focused on agile run into trouble in a number of areas. Specifically, if they don’t add some level of explicit handoff between PM/design and engineering and if the engineering team doesn’t commit to milestones and dates, a lot of the common challenges mentioned earlier start to surface such as unclear requirements and miscommunication of release expectations. Agile techniques are still used as a big part of how the engineering team executes, but that is only one piece of the puzzle in a highly functioning product engineering team. In some ways, managing the agile sprints is the easy part. It’s the rest of the process that most teams don’t have a good approach around.

Project Checkpoints

For an overall project framework, I’d like to introduce the concept of project checkpoints. These are typically tracked in the roadmap as well as the project tracker that we will talk about in a bit.

Checkpoint 1: User research, use cases and UX design are all flushed out. The Product Requirements Doc (PRD) is written and reviewed. Any legal or leadership buy off has happened and open questions are closed. This is the phase where some amount of thrashing and churn is welcomed as the project is being fleshed out. Exit criteria is creating a PRD and UX design that are ready for Engineering to execute on. PM is primarily responsible for the committed date to complete Checkpoint 1.
Checkpoint 2: This is where the Eng team asks any clarifying questions with PM and design and then creates the tech design doc for the project. During this phase it is common for requirements to need further clarity from PM. The Eng team works to get sign-off from all technical stakeholders on the design and approach. The eng squad or individual breaks down the project into tasks in the task tracking system like Jira or Asana using agile techniques such as epics and story points (although I’m a bigger fan of just using hours for task estimation). The exit criteria for this phase is a fully costed project in the task tracking tool and committed plan with dates for each milestone on the project tracker (more on project tracking below) that is reviewed bi-weekly with leadership.
Checkpoint 3: Between Checkpoint 2 and 3, the team works in an agile fashion with weekly sprints. I could write an entire separate blog post on how to organize sprints and day-to-day work (and cover some of it later in this article), but in general, this is the biggest phase of the checkpoint process where the Eng team does their core coding work. In addition to the task tracking tool, a key component of the process is that the Eng team keeps the project tracker up to date with milestones and launch dates. The project tracker should be reviewed and updated each week during sprint planning. PMs, marketers and leadership shouldn’t have to dig through Jira workboards or ping each manager for project updates. The project tracker is the single outward communication from the team on project status (explained in detail in the next section). User acceptance testing is also done by the team in this phase. Exit criteria for Checkpoint 3 is the beta launch to users or the full launch to end customers if no beta period is deemed necessary.
Checkpoint 4: Once the project is in beta and being tested by real users (or launched live for smaller features that don’t require A/B testing), data will be collected. There could be some small feature tweaks required during this phase. Once the team feels confident in the results, the feature or project should be launched to 100% of users and the experiment code should be removed. Once live for some time, the PM and data science team should update metrics to account for the new features. Exit criteria for this phase is that results have been reviewed, there are no near term tweaks to be made and the project is fully launched to users. For smaller features, Checkpoint 4 can come soon after Checkpoint 3.

Project Tracking

The committed milestones and dates created in Checkpoint 2 and kept updated throughout the development process leading up to Checkpoint 3 is the heart of communication between engineering/PM and sales, design, marketing and leadership. There are several ways to build a project tracker, but what I’ve found most effective is an online slide deck, with each project having a set of slides (or single slide with sections for smaller projects) with all milestone and status information for a given project. Only larger multi-month projects are typically included in the deck.

The project tracker deck and meeting serve the following purposes:

Creates a single source of truth for timelines and status updates for product engineering projects and a single place for leadership to track projects across teams
Creates accountability for individual PMs, tech leads and managers for their projects
The bi-weekly meeting gives a forum for cross-functional discussion of project status, launch timing and any clarifications on project decisions

The project tracker deck is the source of truth for milestones and launch dates related to active projects across the org. Milestones break the project into logical chunks that are typically 1–3 weeks apart. The dates in the project tracker include 3 slides (or 3 sections on the same slide) for each project, each with a single owner. The team should pick a fun icon for each project!

The first slide (or section) are the milestones for PM/design (Checkpoint 1) such as user research, UX design ready and requirements/use cases complete.
The second slide (or section) contains all the engineering milestones including the technical design doc, key development milestones, beta testing, bug fixing and beta launch (Checkpoints 2 and 3).
The third slide (or section) contains the launch milestones that include A/B test dates, marketing release dates, help center updates, communications to customers, press release dates etc. (Checkpoint 4).

Other then the checkpoints, each project can have different milestones that are relative to the given project. The level of granularity for the milestones should generally be kept high, keeping in mind that the project tracker is consumed by leadership, other teams and non-technical people.

Slides should be added to the deck as soon as research and requirements definition work begins on them. Early in the project lifecycle, namely before Checkpoint 2, many milestones will be listed as TBD. Eng and launch milestones are committed to only after the project has finalized use cases / requirements and has gone through the tech design and scoping checkpoint. Launch dates are filled in as the project gets closer to launch.

Once every 2 weeks the deck is reviewed with cross-functional stakeholders and senior leadership to keep everyone aligned on progress and answer any questions around product engineering project status. Each slide owner presents their respective slides and give a brief overview of the status followed by 2–3 minutes of open discussions if needed.

Engineering Execution Process

The engineering execution is the beating heart of a good functioning product team. With a good engineering process, the team should feel like they have the space to work toward longer term goals while still having ample time for tech debt and the ability to handle breaking issues when they arise.

Sprints

The team has 2 types of sprints that are managed in the task tracking tool like Jira: Weekly sprints and projects sprints.

Project sprints (and respective workboards) are created per project with all known tasks and bugs for a given project. The columns on the project workboard in your task tracking tool are determined by team members per project, but typically include backend tasks, frontend tasks, operational tasks, bugs, etc. Project sprints are created as part of the Checkpoint 2 planning deliverable when the project is broken down to the task level. In many ways, project sprints aren’t sprints at all in the traditional sense, but more of a container for all tasks for a given project. Depending on the task tracking software you are using, you could (preferably) create a project for these.

For weekly sprints, each week a new sprint and workboard are created with the dates for that work week. On Monday morning before the team planning meeting, individual team members pull in the project tasks, bugs and misc tasks that they intend to complete in a given week with respect to their committed milestones. Each team member should only allocate roughly 70% of their available work hours to task work as the remaining 30% will be taken up by meetings, trainings and personal time. Each engineering team member’s tasks are reviewed along with the project tracker slides for their respective projects during the Monday planning session. The goal is for each engineer to complete all of the tasks that he/she committed to for that weekly sprint. Once a quarter, the team will take a sprint off from project work to fully focus on tech debt and lower priority bugs.

Bug Backlog

In the task tracking tool, there should be a bug backlog for each product area. The areas can include areas like signup, user dashboard, billing, communications etc. depending on your product. Essentially the bug backlogs should represent logical sections of your application and codebase and serve as a container to prioritize bugs against one another. Bugs are generated from a variety of sources such as end user reported issues, left over bugs from a project launch and issues discovered during beta testing. I also recommend capturing tech debt in the bug backlog as often times tech debt or refactoring work will reduce future bugs in your application.

It is important to have a clear, written process on how to file a bug. This bug process and expectations for fixing should be widely communicated to sales, customer service, marketing and others. Having this process agreed upon across the org can save a lot of headaches when issues pop up. Creating a bug template for submitters to fill out in your task tracking tool is also a good best practice. Some key elements for a good bug are: summary, expected behavior, actual behavior, reproduction steps, account info and device/browser info.

Each bug backlog will have a respective owner (or two) who is responsible for triaging the bugs and ensuring issues are getting worked on and closed. When new issues are filed, the respective bug backlog owner should be notified (via email or other notification from your task tracking tool) to initially triage the bug, ask for more information and/or assign it out to an individual to be worked on if it is ready. Each bug should be assigned Low, Medium or High priority by bug backlog owner. Anything that is in High priority should be actively worked on by the assignee as the top priority to be resolved ASAP. High priority issues can obviously be disruptive to sprint plans and is one of the reasons to only allocate 70% of available time for planned work each week. The expectations for engagement and closing of Medium and Low priority bugs can be debated by your team, but some guidelines would be to take no more then 2 weeks for the resolution of a Medium priority issue and no more than 4 weeks resolution for a Low priority issue. Medium and Low priority bugs along with minor tech debt are included as part of the aforementioned weekly sprint process. The bug backlogs and status should be reviewed during a weekly (or bi-weekly) bug prioritization meeting. This meeting is where open issues are reviewed with the team leads, including ops, sales and other bug submitters. Once you have your bug process working smoothly, you can start to track metrics around filed/closed rates, time to close and average age of bugs that can be reviewed during this meeting. I find an export of the bug data into a spreadsheet to be the easiest tool to use here.

If there is a question on priority around project commitments from the project tracker vs. a bug or tech debt, this is where the EM and PM apply their judgement to determine what should take precedence for a given week. If committed dates in the project tracker are disrupted due to a bug or other issue, the project tracker should be updated with the details and new dates as soon as this is known. If you find you are disrupting dates frequently, it may behoove you to create a project to address the core of the issues being reported and/or consider investing in expanding your testing framework.

Summary

Alright, if you’ve made it this far, hopefully you weren’t too overwhelmed by it all! It’s worth noting that a lot of what is listed here can be applied in piecemeal fashion to still render some benefit for your team. Hopefully some of these techniques and approaches will help you get your product engineering team running like clockwork.

Questions? Comments? Feel free to drop me a line below.

More where this came from

This story is published in Noteworthy, where thousands come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.