This post is part of a series where we document our journey of building a new product, 7pace For GitHub in real-time. We share our experience and what we have learned along the way. Here’s how it all started.

Launching a new product isn’t easy. If you’re trying to maintain an existing platform concurrently with the same amount of resources, it can be quite overwhelming.

When whipping out a few more developers from a magician’s hat isn’t an option, you must be strategic about resource allocation.

You need to decide who should remain on the core product and who should focus on the new one. Then, consider whether the plan is feasible in terms of cost and efficiency.

Resource allocation is one of the challenges we face as we develop our new product, 7pace for GitHub.

While we push forward with this new product, we also need to maintain our core application — 7pace Timetracker for Azure DevOps. Here’s how we juggle everything without sacrificing the health and reliability of the existing product.

Finding the Right Balance

The magician’s hat isn’t an option. We have to work with what we’ve got. The question is, how do we decide on how many people to allocate to the new project?

First, the product team will work out the deliverables. Then, the development team does some high-level estimations. Meanwhile, the business team will define the deadline.

We then estimate the time it’ll take to complete the tasks by applying “pace” to our calculation. Simply put, pace tells us how many story points a developer can complete per hour. It’s calculated by dividing time tracked in a previous task with the number of story points of that task.

Since we know the pace of each development team, we can determine if the deadline set by the business folks is realistic.

If there’s a discrepancy between the estimate and the deadline, we’ll decide if we want to add resources to meet the timeline, consider pushing back the deadline, and/or adjust the deliverables.

We also keep an eye on our pace throughout the development process to catch potential problems that’ll prevent us from meeting our deadlines. For instance, if the team’s pace is usually 5 but it’s 9 during a sprint, we know we have a risk of falling behind schedule and need to reevaluate our tieline and investigate the issue.

But how do we know the total number of work hours that needs to go into this product launch?

Thankfully, we have been a huge fan of time tracking.

The way we actively engage with estimated efforts and tracked time has led to solid estimating skills. By understanding our pace, we can confidently translate how much time a specific deliverable will take to complete by comparing features and assets in previous projects.

This approach allows us to move forward with the development process as we find the balance between resources, timeline, and deliverables. We measure our pace, revisit our estimations and scope frequently, and update our projection as we progress. This helps us prevent time crunch when the scope isn’t adjusted to match the adjusted estimation.

After we determine the resources we need for developing the new product, we’ll also know how best to deploy the rest of the team to maintain the existing platform.

Remember, this is no magic. It’s just about developing reliable habits of estimating efforts, constantly tracking real time, actively putting the two in relation, and learning to read the signs.

Don’t Drop the Ball!

While we go full steam ahead with new product development, we must also focus on our existing platform and make sure our customers are happy. Here’s how we keep all the balls in the air to ensure that both old and current products are getting the attention they need.

Keep Engaging With Current Customers

Even though we have slowed down the development of Timetracker, we continue to communicate with our community, capture information from our customers, and make sure bugs are fixed promptly. Once we have reached a major milestone for the new software, we’ll slow down development for the product and return to our normal cadence to work on the existing platform.

Avoid Context Switching

It’s tempting to pile everyone who has a spare second onto a new project. But too many cooks can certainly spoil the broth.

We aim to have each team focus on one specific product at a time because conflicting priorities can cause chaos. If a team has to work on both products, the pressure to get the new software out the door will likely cause them to put the old product on the back burner. This can impact the experience of our current customers.

Not to mention, context switching simply isn’t efficient. We always aim to create an environment where team members can commit to a task and give it their best without being pulled in different directions.

The bright side of this approach is that once we resume work on the current product, our team can focus on it without distraction.

Wonder how our approach will turn out?

We’ll be sharing new posts and teardowns of our product development process, as well as insights and lessons along the way—join us to see what happens.