Genesis of the Payload Planner: a Product Owner's Journey

The Strategic Challenge: Revolutionizing GHG Space Observation

Imagine having to orchestrate a symphony of 12 satellites in orbit, each capable of capturing dozens of observations per day, covering 12 km by 12 km zones across the globe. For GHGSat, the world leader in detecting greenhouse gas emissions from space, this challenge represented much more than a simple technical problem: it was the key to their commercial expansion.

The company found itself at a critical turning point. Its satellite constellation was about to evolve from a single prototype to a fleet of next-generation satellites. This multiplication of their observation capacity required a complete revolution of their planning system. The old tool, designed for a single experimental satellite, could never manage the operational complexity of a commercial constellation.

The stakes were colossal: develop a fully automated system capable of optimizing each satellite's observations, while respecting orbital constraints, client needs, contractual obligations, and technical constraints. Failure would mean the impossibility of commercially exploiting this revolutionary constellation.

It was in this context that in summer 2021, GHGSat entrusted me with the mandate to develop this "brain" of their constellation: the Payload Planner.

The Challenge Begins

The project starts with a merciless constraint: the system must be ready before the SpaceX launch scheduled for May 2022. No margin for error, no possibility of postponement. The GHGSat-C3, C4, and C5 satellites will be put into orbit, with or without their automated planning system.

As the Product Owner, my first mission is to transform an ambitious vision into a tangible plan and roadmap. The operations team presents me with high-level requirements that hide a dizzying complexity: automatically optimize observations from dozens of satellites operating at 530 km altitude, taking into account dozens of simultaneous variables and constraints.

The Strategy: Marrying Vision, Tech, and Users

Collaborating with the Operations team (the internal customer), and supported by three expert developers, I start planning on three axes conducted simultaneously:

• the Vision: Communicate the vision then build a roadmap through progressive elaboration, establish a realistic timeline and reassure all stakeholders about our ability to deliver a functional product before the SpaceX launch.
• the Technical risks: Collaborate closely with the development team to identify major technical challenges and launch explorations (spikes) as early as possible. These investigations would guide our crucial technological choices.
• the hidden needs: Meet with GHGSat's satellite operators to grasp their real problems, their daily frustrations with the existing planning tool. To identify and anticipate these, and ensure that the new product improves the user experience and doesn't reproduce past problems.

Connect business needs, engineers, and users together to build great products!

Laying the Foundations

My role as Engineering Manager becomes crucial: I take on the recruiter hat and build a hybrid team mixing internal developers and expert consultants. I engage a talented scientist to lead the optimization part. I seal a strategic partnership with a company in Quebec City to cover our Frontend needs. This partnership quickly becomes viral and other teams request their services. Two talented developers join the adventure. As a team, we establish a working method: Agile Scrum with two-week sprints and quarterly releases. Fixed duration and budget, variable scope - an essential approach for such an innovative project. In parallel, I set up rigorous monthly budget tracking with the PMO and accounting departments.

The first explorations reveal the magnitude of the technical challenge. The application must be cloud native to allow future scaling of the constellation. The final data model is not expected to be known in the first place, thus schema evolutions should be made easy. A fast and reliable data ingestion pipeline is required to fetch targets and contracts. Finally external data like weather forecast is required to make sure the payload camera does not capture fluffy cumulus.

The Architecture of the Spatial Brain

The heart of the system reveals its complexity: the optimization framework. This critical component becomes the centerpiece of my prioritization work because it's the one that will make crucial decisions at each orbit: which geographical zone to observe? Respecting which priorities? The algorithm must juggle with:

• Business needs,
• Contractual obligations with clients,
• Physical satellite constraints (battery, storage),
• Orbital constraints (target visibility, connectivity with ground stations)

Each satellite can perform dozens of observations per day - the system must optimize these choices daily.

The most fascinating part of the project unfolds: a component is required to find an optimal solution in the very large multidimensional research space. It gets called the Optimizer. It shall converge to a usable solution and generate a schedule for the satellite in less than 10 minutes. A typical problem of Operational Research. After few weeks of experimentation, the computational optimization framework is selected. It uses a genetic algorithm, stochastic by nature. The optimizer is the backend's centerpiece, allowing operators to define planning priorities: contractual obligations, surface coverage, revisits to sites that have recently emitted greenhouse gases (GHG), clear weather. The operator can weight these parameters differently according to current priorities, and also force the capture of one observation in the satellite schedule if required.

Many industries today use Operational Research to optimize their processes. This is a classic use case with relatively few parameters. For the novices, consider that Operational Research is a lightweight AI.

First Negotiations

Faced with growing complexity, I realize that supporting GHGSat-D, the first technology demonstrator satellite launched in 2016, will be expensive. I evaluate with the operations team alternative solutions to continue planning its operations, and the impact on activities. The decision is made, GHGSat-D will not be supported by the Payload Planner, the old tool will continue to be used to operate it. This allows the team to focus on the essential: the new satellites whose operations are infinitely more complex. A decision that would prove decisive in meeting deadlines.

Development Accelerates

The "Low-Tech High-Touch" agile approach pays off: with users in the same office, feedback is constant and valuable. The team progresses remarkably well, integrating the system's main components. Bi-weekly demos show tangible progress. Developers and operators meet regularly to make the tactical decisions that are needed, from the weight of a variable in the optimizer, to the placement of a button to facilitate UX.

Tension Rises

Spring is here. The tool works for standard use cases, but few bugs on the orbital calculations still prevent from using the Payload Planner in production for the two commercial satellites: GHGSat-C1 and C2.

Pressure intensifies. Less than two months before GHGSat-C3, C4 and C5 launch with Transporter-5 from SpaceX. Each sprint counts double. My role as Product Owner becomes a constant balancing act between urgent demands, maintenance of the current tool that's showing fatigue, technical constraints, and the race against time. The roadmap is adjusted at each Sprint review, with stakeholders, revising the order of essential features and the relevance of secondary functions.

When all the sudden, in early April, space-time twists... SpaceX announces that the launch is moved up by two weeks! 😶

How will we deliver a working product with one less Sprint? Subscribe to get notified.