My new series of articles is called Music Product Academy. We will learn how to think like a Product Manager and System Engineer.
How a Music Product Really Gets Built
When musicians, engineers, or entrepreneurs talk about building a new product, the conversation often starts with technology: “Let’s build a new audio interface.” “We need a better wireless microphone.” “What if we build a pedal that does this?” “We can make a much better DSP algorithm.”
But this is not where product development really starts. Technology is only one part of the story. A successful product begins with understanding who needs it, what problem it solves, why someone would pay for it, and what the complete system must do to deliver that value.
This is where Product Management and System Engineering meet. For Music Product Academy, I want to follow the entire journey — from the first idea to a product sitting on a musician’s or sound engineer’s desk, in a studio, on a stage, or inside a professional audio system rack.
The Product Journey
A simplified product journey looks something like this:
Market → Problem → Product Concept → Business Case → Requirements → Architecture → Prototype → Verification → Production → Quality → Support → Operations → Next Generation
These stages are not strictly linear. In reality, product development is iterative.
- You may discover during prototype development that the original requirement was wrong.
- You may discover during testing that the architecture cannot achieve the required latency.
- You may discover during manufacturing that your beautiful prototype is too expensive to build.
- Or customers may tell you that the feature you considered most important is not actually what they need.
The System Engineer’s job is therefore not simply to “design the system.” It is to help maintain the connection between:
Customer → Business → Requirements → Technology → Product
1. Start with the market
Before designing anything, we need to understand the environment in which the product will exist. Who are the customers? What are they using today? What frustrates them? What alternatives already exist? What are they willing to pay? Who are the competitors? And perhaps most importantly: Is there a real problem worth solving?
For a music product, the customer might be:
- Musician
- Producer
- Recording engineer
- Live sound engineer
- Mastering engineer
- Broadcaster
- Studio
- Installation company
- Rental company
- Music technology company
Each customer may have completely different priorities. A guitarist may care about latency and feel. A studio may care about audio quality and reliability. A touring engineer may care about robustness, weight, serviceability, and compatibility. A manufacturer may care about cost and production yield.
The first lesson is therefore simple: The customer does not buy your technology. The customer buys the solution to a problem.
Wojtek wrote a bit about the market research in the article: Where to take good product ideas from
2. Define the problem
Once the market has been investigated, we need to turn observations into a clearly defined problem. For example: Live musicians need a wireless monitoring solution with extremely low latency and predictable performance in crowded RF environments.
That statement is already much more useful than: Let’s build a new wireless audio system. The first describes a problem. The second describes a technology. This distinction becomes extremely important later when requirements and architecture are created.
3. Build the product concept
Now we can start asking: What should the product actually be? This is where Product Management plays a major role. We define the product vision and begin creating the product concept.
For example:
Product: Professional wireless in-ear monitoring system.
Potential product goals:
- Very low audio latency
- High audio quality
- Reliable RF performance
- Simple setup
- Multi-channel operation
- Professional monitoring
- Robust stage operation
- Compatibility with existing equipment
But we still haven’t designed the electronics. We are defining what the product needs to achieve.
4. Is there a business?
A technically brilliant product can still fail. Why? Because economics doesn’t work.
We need to ask:
- How large is the market?
- Who are the competitors?
- What will customers pay?
- What will the product cost?
- What will development cost?
- How much engineering is required?
- What will manufacturing cost?
- What is the expected production volume?
- What is the expected margin?
- How will the product be sold?
- Who will support it?
This is where investors may become part of the story. A startup may need funding before engineering can begin. An established company may need to justify an internal development budget. Either way, the product concept eventually needs to become a business case.
Wojtek wrote a bit about it in the article: PnL – essential tool of a Product Manager
4. Requirements: Turning Ideas Into Engineering
Now comes one of the most important transitions in the entire process. We move from “We want a great product.” to “What exactly must the system do?” This is the world of requirements engineering. For example:
Audio
- Frequency response
- Dynamic range
- THD+N
- Signal-to-noise ratio
- Maximum input level
Latency
- End-to-end latency
- Processing latency
- Network latency
- Buffering latency
RF
- Operating frequencies
- Channel spacing
- Range
- Interference tolerance
Interfaces
- Analog
- AES
- USB
- Ethernet
- Dante
- MIDI
- Bluetooth
Mechanical
- Dimensions
- Weight
- Mounting
- Connectors
- Environmental requirements
Reliability
- Operating temperature
- Expected lifetime
- MTBF
- Protection requirements
Business
- Target manufacturing cost
- Target selling price
- Production volume
The requirements are where the product idea becomes something engineers can actually build and test.
6. System architecture
Now the System Engineer starts putting the pieces together. We need to answer: What is the system made of? For example:
Audio Input → ADC → DSP → Network → DSP → DAC → Audio Output
But real systems quickly become more complicated. We may need:
- Processors
- FPGA
- DSP
- Memory
- Power supplies
- Clocks
- ADC/DAC
- RF components
- Networking
- Embedded software
- Firmware
- Mechanical assemblies
- Thermal management
- User interface
- Cloud services
- Mobile applications
The architecture defines how these pieces interact. This is one of the places where System Engineering provides enormous value. The System Engineer needs to understand enough of every discipline to make sure the complete system works.
6. Project Management: When Agile Meets Hardware
Once the architecture is defined, the team has to actually build it. This is where project management methodologies often crash into engineering reality.
Today, the software world is almost entirely Agile. Development is broken into two-week sprints, features are iterative, and if an embedded DSP algorithm or a user interface needs tweaking, a new build can be pushed by Friday.
But you cannot “sprint” a physical printed circuit board. You cannot iterate a metal chassis overnight, and you certainly cannot ignore the 20-week lead time for a critical FPGA or AD/DA converter. Hardware development is inherently governed by Waterfall-style milestones and stage-gates. Once a PCB design is sent to fabrication, it is locked. If a mistake is found a week later, you lose time, money, and momentum. This creates the ultimate project management challenge for a System Engineer and Product Manager: synchronizing two different clocks.
To successfully deliver a unified hardware and software product, the project management strategy must be a hybrid. The Hardware Track: Driven by strict gates—EVT (Engineering Verification Test), DVT (Design Verification Test), and PVT (Production Verification Test).
The Software Track: Operating in Agile sprints, but rigidly tied to the hardware delivery dates.
The firmware and software teams need early evaluation boards to write their code, while the hardware team needs the software to properly stress-test the prototype boards. Managing this dependency loop requires extreme discipline. Daily stand-ups and Kanban boards are excellent for tracking task progress, but the overarching master schedule must always respect the unbending laws of physical manufacturing lead times.
8. Make the First Prototype
At some point, we have to stop talking and build something. The first prototype does not need to be beautiful. It needs to answer the most important technical questions:
- Can we achieve the latency?
- Can the DSP provide the required processing?
- Can the hardware handle the data rate?
- Can the RF system achieve the required range?
- Can the thermal design work? Can the system communicate reliably?
This is where engineering reality begins to challenge the original concept. And that is a good thing. Finding a problem in a prototype is much cheaper than finding it after mass production.
9. Verification and Validation
One of the biggest misunderstandings in product development is thinking: “It works, therefore we are finished.” We are not. We need to prove that the system meets its requirements. This is the world of: Verification and Validation — V&V
Verification asks: Did we build the product according to the requirements?
Validation asks: Did we build the right product for the customer?
These are not necessarily the same question. A product can pass every engineering test and still fail in the market. That is why System Engineering must maintain the connection between requirements, tests, and the customer’s actual needs.
10. From prototype to production
A prototype is not necessarily a product. A prototype might be assembled by one engineer in a laboratory. Mass production is a completely different challenge.
- Design for Manufacturing
- Design for Assembly
- Component availability
- Suppliers
- Production testing
- Manufacturing fixtures
- Calibration
- Tolerances
- Production yield
- Cost
- Logistics
- Regulatory requirements
- Packaging
The question changes from “Can we build one?” to “Can we build thousands of them consistently?”
11. Quality Is Part of the Product
Quality should not be something added at the end. It begins with the product requirements and architecture. We need to define:
- Incoming inspection
- Manufacturing tests
- Automated tests
- Functional tests
- Environmental tests
- Stress testing
- Regression testing
- System integration testing
- Final acceptance testing
For a professional audio product, this might include automated measurement of:
- Frequency response
- THD
- Noise
- Latency
- Channel separation
- Digital interfaces
- Synchronization
- RF performance
The objective is not simply to find defective products. The objective is to create a repeatable process that produces reliable products.
12. The Product Meets the Customer
Eventually the product leaves the factory. But engineering does not end there. Now we enter another important part of the product lifecycle: Operations and Support.
Customers will report:
- Bugs
- Unexpected behavior
- Compatibility problems
- Installation problems
- Performance problems
- Usability problems
Support becomes an important source of engineering information. A good organisation does not treat support tickets as isolated problems. It looks for patterns. Maybe 2% of customers are experiencing the same network configuration problem. Maybe a particular firmware version creates instability. Maybe a connector is failing under touring conditions. Maybe customers are using the product in a way the original designers never anticipated. That information should return to Product Management and Engineering.
13. The Product Becomes a Cycle
And this brings us back to the beginning. The product generates real-world information. That information becomes input to the next version.
Customer → Support → Data → Requirements → Engineering → New Product
This is why product development is not a straight line. It is a cycle. The first product teaches us how to build the second product. The second product teaches us how to build the third. And over time, the organization develops something even more valuable than a product: a product development capability.
The Role of the System Engineer
So where does the System Engineer fit into all of this? The System Engineer is often the person connecting the different worlds.
Product Management asks: What does the customer need?
Engineering asks: How do we build it?
Manufacturing asks: How do we build it efficiently?
QA asks: How do we prove it works?
Support asks: What happens when customers use it?
Operations asks: How do we keep the product running?
The System Engineer needs to see the whole picture. The role is not to replace the specialists. It is to make sure that the specialists are building one coherent system.
The Music Product Academy Series
This article is only the beginning. In the coming articles, we can take each stage of this journey and go much deeper. For example:
Market & Product
- How do you know if a music product is worth building?
- How do you interview musicians and turn conversations into product requirements?
- How do you analyze competitors without simply copying them?
Requirements
- How do you write a good requirement?
- What makes a requirement testable?
- What is the difference between a product requirement, system requirement and subsystem requirement?
Architecture
- How does a System Engineer create a system architecture?
- How do you decide what should be hardware, software, FPGA or DSP?
- How do you make architectural trade-offs between performance, cost, power and complexity?
Prototyping
- What should the first prototype prove?
- How do you decide what to prototype first?
- When should you use an evaluation board, development kit or custom hardware?
Verification
- How do you build a V&V strategy?
- How do requirements become test cases?
- How do you automate testing of an audio product?
Production
- What changes when you move from one prototype to 10,000 units?
- How do you design for manufacturing and production testing?
Quality
- How do you build a quality strategy for a professional audio product?
- What should be tested in the laboratory and what should be tested in production?
Support & Operations
- What can customer support teach the engineering organization?
- How do field failures become engineering improvements?
The Business
- When should you look for investors?
- How do engineering decisions affect the business case?
- Why can a technically superior product still lose money?
The Bigger Story
Ultimately, this series is not about teaching people how to build one particular audio product. It is about learning how to think like a Product Manager and System Engineer.
A successful product is the result of many connected decisions:
Market → Customer → Problem → Product → Requirements → Architecture → Engineering → Prototype → Verification → Manufacturing → Quality → Support → Operations → Next Generation
Every arrow matters. If one of them is broken, the product can fail. If they work together, an idea can become a real product. That is the journey we will explore in Music Product Academy.
