How We Meet Engineering Goals With No Product Roadmap

Earlier this year, I hopped on a call with Dharik, a software engineering candidate who had recently applied to Magoosh. After reading many of our blog posts, he shared his excitement about our culture and values, but he still had a big question that I always struggle to answer concisely: “What types of big projects will I get to work on?”

I get asked this question by nearly every software engineering candidate. In response, I provide examples of current projects, but those aren’t the projects the new engineer will necessarily take on. Over time, I’ve realized there’s more to the question — candidates care not only about the specific projects but also the process by which we determine those projects. In this article, I’ll break down the process we use to find impactful work without a long-term product roadmap.

It all starts with our annual plan

Our annual plan serves as our north star. It outlines the metrics we’ll hit if we’re successful, but it doesn’t necessarily prescribe exactly how we’ll get there.

For example, we might have a goal to achieve a Net Promoter Score (NPS) of 50+ for our ACT test prep product. However, the annual plan doesn’t specify which projects we’re going to take on to achieve that goal.

Our annual plan contains quite a few goals, and we try to make them metrics-based. Here are examples of goals that relate to product and engineering.

• Achieve NPS of 50+ for ACT
• Maintain 99.9% uptime
• Increase engineering redundancy

Now onto quarterly planning

At the end of every quarter, the entire company goes through a reflection and planning period. During this time, we write reflections on the projects we tackled in the previous quarter and we begin planning for the next quarter. The team uses the annual plan, usually set by the department leads and me (the CEO), to guide how we approach quarterly planning.

We use an approach of freedom within limits. Anyone can share/brainstorm ideas, but we will only move forward with ideas related to the company priorities. For example, if we are already achieving our target uptime, then we’re not going to prioritize new approaches to further improve that uptime.

Out of the quarterly planning process, we determine a clear set of goals that we’ll focus on for the next 10 to 11 weeks. During the planning process, we also identify who will work on what, looking at a combination of a person’s skills and interests. Each employee has some voice in this process.

Any employee, engineers included, may be slotted on several themes for the quarter. We try to estimate when the work for different themes will take place so there aren’t too many peaks and valleys. We also take conferences, vacations, buffer time, and other events into consideration. After the planning period, every employee should have a rough sense of what they need to accomplish each week in the quarter.

Examples of quarterly goals

Below I’ve shared two examples of quarterly goals: one led by an engineer and another led by a product manager, with support from a designer and engineer.

Q3 2016: Outsource DevOps

Our usage peaks from August to October. Historically, these months have been a point of stress for our engineering team since there’s uncertainty about whether our servers can handle the load — no one enjoys waking up to major site issues.

Last fall, Zack (one of our engineers) identified that this was a recurring problem each peak season, so we set a goal of outsourcing our DevOps. This goal would help us build engineering redundancy and better maintain uptime, both of which were part of our annual plan.

Zack led this theme, and I supported him. We looked at several agencies and organizations, did reference checks, and settled on one. Then the hard work began. Zack worked with the agency to determine what specific changes we needed to make to our Rails app and infrastructure and to discuss the details of how we’d handle the migration. This was Zack’s main project for August and September.

We’ve now been working with our DevOps agency for over a year and have been quite happy with the results. We have better deployment and roll-back systems, auto-scaling, multiple availability zones, and more. As a bonus, our engineers are no longer on pager duty!

Q2 2017: Build in-app study schedules for the ACT web product

As I outlined above, one of our annual goals is to improve our ACT NPS score. As part of that goal, Lucas (a product manager at Magoosh) looked into which features could be helpful in providing students with a better experience. He ultimately settled on building an in-app study schedule — that feature became a goal for Q2 2017. We allocated some of his time, along with some time for design (Alice) and engineering (Albert).

Alice, Albert, and Lucas worked together to design, test, and roll out the new ACT in-app study schedule, releasing it in the last weeks of Q2. Since then the team has been monitoring its usage and impact, and will continue to refine the feature to make sure that it satisfies the issue our students had brought to our attention — and that the work put in pushes us toward that greater annual goal of NPS improvement.

So where’s the product roadmap?

Unlike many companies, we don’t have a long-term product roadmap with specific projects and features.

Instead, we know where we are headed (based on our annual plan), and then figure out the best path to get there, quarter by quarter (and week by week). This approach makes it hard to share exactly what projects a new engineer will be working on. However, we know whatever those projects may be, they’ll be relevant to Magoosh’s long-term goals. Overall, we want employees to do work that they are both proud of and that is impactful for the company.

I shared this approach with Dharik during that call earlier this year. He chose to continue on with our hiring process. Fast forward a bit, and he’s now been working at Magoosh for about six months, having owned a few quarterly goals of his own. You can read more about his experience here.

Interested in working at Magoosh? Check out our open positions.

If you don’t see an open position that’s perfect for you, please submit your resume via the general application.

Learn more about our philosophy and culture here.