Our educational CubeSat project started much closer to the second category: create a hands-on platform that could combine programming, AI literacy, and space-themed STEM education.
That's enough to explain the product. It isn't enough to build one.
Moving from concept to implementation required translating that vision into decisions across hardware, software, electronics, power, physical design, educational content, production cost, support, and future development. Managing those dependencies has been as important as solving any individual technical problem.
The process has reinforced a project-management principle we see repeatedly in technical work: the job isn't simply to create a plan. It's to progressively remove ambiguity until a team can build from it.
Start With the Problem, Not the Parts List
It would have been easy to begin the CubeSat project by choosing interesting sensors.
Instead, the broader product requirements provide the context for those decisions.
The project is intended to combine three areas: AI literacy, C/C++ programming, and space-themed hands-on learning. Students should be able to interact with AI while developing the critical-thinking skills necessary to evaluate its responses. Programming provides a more foundational understanding of how technology works, while the CubeSat provides a physical environment in which that code can do something observable.
Those goals affect the product architecture.
If the purpose were simply to demonstrate a temperature sensor, the hardware could be dramatically simpler.
But a platform intended to support lessons ranging from beginner to advanced needs room to grow. That led to requirements for multiple environmental sensors, acceleration sensing, air-quality measurement, camera capabilities, audio interaction, local storage, a display, and Wi-Fi communication.
The important project-management step was connecting those technical requirements back to the reason the product exists.
A feature isn't valuable merely because it can be added. It needs to support what the product is supposed to accomplish.
Break the Vision Into Workstreams
Once a project crosses multiple disciplines, a single task list stops being a particularly useful representation of the work.
The CubeSat concept naturally separates into several connected workstreams.
There is the physical product: the CubeSat structure and the placement of the components inside it.
There is the electronics platform: microcontroller, sensors, expansion hardware, storage, display, camera, audio, connectors, and interfaces.
There is the power system: USB-C power, supplementary solar generation, charging, battery storage, and the power requirements of the complete electronics package.
There is the software platform: the web portal, code-execution environment, and AI assistant.
There is the educational product: the lesson library and progression from beginner to more advanced AI and coding material.
And there are commercial and operational requirements: unit cost, licensing, production considerations, and the planned support lifecycle.
These workstreams can move independently to an extent, but they cannot be managed independently.
A change in one can create constraints somewhere else.
Make Constraints Explicit Early
One of the most useful things a project manager can do for a technical team is turn assumptions into documented constraints.
The CubeSat hardware provides a straightforward example.
"Everything needs to fit inside the CubeSat" is an idea.
The actual requirement is much more useful.
The CubeSat is 10 cm × 10 cm × 10 cm. The current battery and charge-controller design consumes the lower 3.575 cm. The frame further constrains the available width and length.
The resulting working space for the Arduino and sensor electronics is approximately:
8.9 cm × 8.9 cm × 6.425 cm.
Now the team has something it can design against.
The same process applies elsewhere.
"Keep it modular" became a requirement that the Arduino remain easily removable so it can be used independently with a breadboard and additional sensors.
"Make the storage accessible" became a requirement that the microSD card be externally reachable from a non-solar side of the enclosure.
"Keep it serviceable" contributed to requirements for labeled sensors and connectors.
"Make the display usable" means the OLED needs to remain clearly visible from either the top or side.
Specific requirements turn subjective expectations into engineering inputs.
Track Dependencies, Not Just Tasks
A project plan might contain separate tasks for the battery, camera, display, PCB, sensors, and enclosure.
The more important information is how those tasks affect one another.
Consider the solar system.
Solar panels require exterior surface area. So can a camera. External access to the microSD card also needs to be preserved on a non-solar side. The OLED needs an appropriate viewing position.
Meanwhile, adding electronics affects power consumption, internal packaging, connectors, and cable management.
The current system power estimate is approximately 350–400 mA at 5V. With the estimated battery configuration and conversion losses, the design estimate is approximately 3 to 3.5 hours of continuous battery operation.
Those figures may change as the product develops, but documenting them gives the team a baseline.
A decision to add or change a component can now be evaluated against several questions:
Does it fit?
How is it connected?
How much power does it consume?
Does it block another component?
Can it still be serviced?
What does it do to cost?
That is dependency management in a much more useful form than simply marking a task complete.
Preserve Flexibility Where the Design Is Still Evolving
Early-stage product projects have an unavoidable tension.
Engineers need enough specificity to move forward, but defining everything too early can lock the product into decisions made before enough was known.
We have deliberately preserved modularity in the CubeSat architecture.
The Arduino UNO R4 WiFi serves as the current microcontroller foundation, with expansion hardware intended to stack above it. The Arduino itself should remain removable for use with breadboards and additional sensors.
The design also needs to remain compact enough to support other form factors in the future.
That last requirement is important from a project-management perspective.
The team isn't being asked to solve every possible future use case now. Instead, the current architecture is being asked not to unnecessarily prevent them.
Good project planning isn't about predicting every future requirement.
Sometimes it is about recognizing where not to close a door.
Cost Is an Engineering Requirement
Cost can easily become something that gets evaluated after a prototype works.
For a product intended to scale, that's too late.
The CubeSat project includes a target of keeping production cost below $250 per unit. Component sourcing is also part of the specification, with sensors and PCB components from North American or European sources preferred where practical.
Those requirements belong alongside the electrical and physical specifications because they influence the same decisions.
A component might be technically ideal but economically impractical. Another may be inexpensive but create assembly, sourcing, packaging, or support problems.
The product concept also includes a broader commercial structure covering student licensing, teacher access, and a defined hardware support lifecycle.
That means engineering decisions have consequences beyond the initial build.
The project has to consider not only "Can we build this?" but also "Can we reasonably produce and support this?"
Define What Comes Later
One of the easiest ways for a project to lose focus is to treat every good idea as a current requirement.
The CubeSat planning documents explicitly separate launch requirements from longer-term ideas.
Current work includes areas such as:
- CubeSat structural and electronic design
- assembled hardware
- the web portal
- code execution
- educational lesson guides
- cost structure
- support structure
A grading and submission portal is identified as a longer-term direction.
That separation matters.
The grading system may ultimately be valuable, but the CubeSat does not need every potential feature completed simultaneously for the core product to move forward.
Separating what we are building from what we may build next protects the current project from uncontrolled expansion while still preserving the longer-term vision.
Documentation Is Part of the Product
The project's documentation has also become more specific as the design has matured.
A high-level concept document establishes the market need, target audience, technology, product components, commercial concept, and major development areas.
The hardware specification goes much deeper. It defines the microcontroller, sensor requirements, interfaces, power architecture, physical dimensions, mounting requirements, communication, data logging, modularity, production constraints, and component preferences.
That progression is intentional.
Different stages of a project require different levels of documentation.
An early concept document should help everyone understand what is being built and why.
An engineering specification should remove enough ambiguity that technical decisions can be evaluated consistently.
Neither document replaces the other.
Together, they create traceability between product intent and technical implementation.
What We Learned
Multidisciplinary technical projects rarely fail because nobody created a task list.
The harder challenge is maintaining alignment as one concept turns into dozens of interconnected decisions.
Our CubeSat work has reinforced several principles we use when managing product development.
Requirements should become more specific as the project progresses. Technical constraints should be documented rather than assumed. Dependencies need to be visible across workstreams. Cost and support should be considered engineering inputs, not problems reserved for the end. Future ideas should be captured without automatically becoming current scope.
Most importantly, technical teams need to understand the reasoning behind the requirements.
"Put this sensor here" is an instruction.
"The storage needs to remain externally accessible because the device will be repeatedly used in an educational environment" provides context that can guide many subsequent decisions.
That context becomes increasingly valuable as more people and disciplines become involved.
Next Steps
The CubeSat project still has work ahead across structural design, electronics, assembly, software, and educational content.
That doesn't make the planning incomplete.
Product development is inherently progressive. Early decisions establish direction. Engineering work exposes new constraints. Those constraints improve the specification, which makes the next round of decisions better informed.
The objective of project management in that environment isn't to pretend every question can be answered on day one.
It is to make sure the right questions are answered before the next decision depends on them.