Exploring Product Development process  from project idea  - Page 1
Forum section: electronics / general

author: EVblog1
author_rank: Contributor
timestamp: August 18, 2025, 12:18:04 pm
content: Hi everyone,I am currently working on an imaginary project with the goal of learning the complete product development process from start to finish. I’d like to treat this as a case study to understand how real-world products are designed, developed, and deployed. Later, if things go well, this project might even evolve into a practical one.The project idea is: many small sellers use QR code cards for digital payments. These cards are usually prepared manually (assuming for now) printed and then verified one by one individually. This process is slow, prone to errors (wrong prints, unreadable codes, missed checks), and doesn’t really scale if you need to prepare mote than thousands of cards.What I want to imagine instead is an automated system that could take over this job, something that can print the QR on cards, verify them automatically (e.g., scan and check if the code works), and do it in bulk. For example, I picture the cards moving on a conveyor where they get printed and verified in one go. The aim is to make the process faster, more reliable, and scalable using microcontroller.The main reason I’m doing this is not to build the system right away, but to use it as a case study for myself so I can understand how things usually move from requirement gathering all the way to deployment. If it shapes up well, maybe one day it can even turn into a real project.I’ve broken down the process like this:1. Requirement : (Product Requirement Document – what the product should do)2. Specification : SRD (System Requirement Document – how the system will achieve it)3. Design (architecture, flowcharts, schematics, etc.)4. Development (hardware + software)5. Verification (System level testing)6. Deployment (field trials, production)Right now I want to start with the PRD stage. My question is , if you were writing a PRD for a project like this, what are the key things you’d include? How detailed does it need to be at this stage, and are there any templates that you personally find useful? I am planning to create Excel sheet for PRDI’d really appreciate hearing from experienced people who’ve worked on real projects.Thanks a lot for reading, and looking forward to your thoughts!

author: EVblog1
author_rank: Contributor
timestamp: August 19, 2025, 08:53:25 am
content: I started with the PRD stage and have drafted some initial requirements.Here’s what I have so far in my PRD: Automated system suppose to print QR code on card and verify its quality and must reject Defective/unreadable packages1) Package dimensions: Minimum 80 × 60 × 40 mm2) Package weight: Minimum 50 g3) Package shape: Rectangular box4) Target throughput: 60 packages per minute5) Printing requirement: Each package/card must have a unique QR code printed in a fixed location.6) Verification requirement: Each QR code must be automatically scanned and verified.7) Error handling: Defective/unreadable packages must be rejected automatically.Now, I want to move into the SRD stage (System Requirement Document) where these productrequirements get translated into technical specifications.This, I feel, is the real challenge because it means deciding exactly how the system should achieve each requirement.Do you think the PRD I’ve written is sufficient to start writing a meaningful SRD, or would you expect more detail at the PRD stage before moving on? If more is needed, what kind of requirements usually get missed by beginners at this stage?

author: EVblog1
author_rank: Contributor
timestamp: August 19, 2025, 01:33:37 pm
content: I wasn’t really sure what should go into SRD , so I decided to skip it for now and jump straight into the Design stage.This is my proposed solution for the system.This is not yet a complete solution there are still many things I am thinking about and need to refine.The system begins at the stacking station, where the cards are placed and fed one by one onto the conveyor. As the conveyor moves forward, the first sensor detects the arrival of a card and sends a signal to the printer. The printer then prints a QR code on the card while it continues moving.After the printing step, the card travels further down the conveyor until it reaches the second sensor. This sensor activates the camera, which takes an image of the printed QR code. The image is sent to the controller, where it is checked to confirm whether the code is printed correctly and is readable.If the controller finds the code valid, the card simply keeps moving forward on the conveyor until it reaches the end, where good cards are neatly collected at the colleting station. If the controller detects a problem with the code, it activates the actuator. The actuator pushes the faulty card off the main line into the reject bin, so only the good ones continue forward.The conveyor itself is driven by a motor, and its speed is controlled by a variable frequency drive (VFD). The controller can adjust the conveyor’s speed through the VFDIn this way, the whole system should automatically handles printing, verification, rejection without manual checking.

author: shabaz
author_rank: Frequent Contributor
timestamp: August 19, 2025, 02:03:17 pm
content: I notice so far you've used the word "seller" just once, and the word "customer" zero times.I don't really understand the actual problem this is solving, I've not heard of these cards for payment either, so I can't really comment much. However, you say you're assuming these cards are produced manually, and I don't think an assumption at this stage is a good idea, because you need to know intimately what your (potential) customers do and what the actual customer problem is. Without that, you're off to a bad start if you design something that doesn't really meet customer needs.Also, you might end up creating the absolute technically best system in the world for QR code verification but it's no good if these small sellers actually have no space for a conveyer belt system, or if it costs more than they are willing to spend. You'd end up with an (effectively) useless product despite it being the technically best thing for QR code verification. This again boils down to knowing what your customers are doing and understanding them. If you don't have that information, you need to find a way of obtaining it. Ideally through actual 1:1 contact, for instance, if you were the person supplying the blank QR cards to them, then physically get up and go to them, see what they're doing and talk to them about the problems they have. If you can't do that, then find the people who supply them, and go with them (this is just one example pulled out of the air with me knowing nothing about this, therefore you may have to find your own way).By doing that, you might learn if it's really a pain point, or if they work around it by (say) printing the QR code twice, once on each side of the card, so that if the user cannot scan one side then they scan the other, or, perhaps they may tell you their users use low-quality phones and that may be the issue in which case perhaps the actual solution is a bigger QR code on bigger card, or maybe switch to NFC or whatever. In other words, you may be solving the wrong problem, who knows.

author: EVblog1
author_rank: Contributor
timestamp: August 19, 2025, 02:39:32 pm
content: Quote from: shabaz on August 19, 2025, 02:03:17 pmSince this is more of a learning project, I haven’t really gone deep into the seller/customer side yet. What I had in mind was the factories that produce QR code cards in bulk and then supply them to retailers. You’re right though in a real project I’d definitely need to spend more time understanding the actual customers and their needsTo clarify my thought: when these QR code cards are made manually in bulk, it becomes a very time-consuming and error-prone process. If the same job is handled by machines, it can be done much faster, more consistently, and at a scale that manual work just can’t match. That’s really the angle I’m trying to explore here

author: shabaz
author_rank: Frequent Contributor
timestamp: August 19, 2025, 03:35:49 pm
content: Hi,Even if your customer is the factory, it's still an assumption that they currently make them in bulk manually.I believe even the smallest factory will likely have at a minimum, a desk-sized machine with a stack of cards one end, spitting out the printed result. It won't be manual.In any case, it's clear you're trying to move past customer requirements and skip to the next step. This is a bit like South Park Underpants Plan however, but you can't say you weren't warned : )Where/when and how in your plan will you test out your idea with customers? Or are you going to design and develop the entire thing and then realize you misinterpreted what the customer actually wanted? Is that the stage 6 in your plan (the last step?).

author: EVblog1
author_rank: Contributor
timestamp: August 19, 2025, 04:32:06 pm
content: Quote from: shabaz on August 19, 2025, 03:35:49 pmI’m not actually building and deploying this system at the moment. it’s more of a case study to practice writing a PRD, converting it into an SRD, sketching out a design, etc.My first example with QR cards wasn’t really a validated customer problem. Since this is more of a practice case study, I thought I’d shift to something that sounds a bit closer to reality.Let’s say there’s a soap manufacturing company that needs to print things like manufacturer name, batch code, weight, and expiry date on every package in bulk. In their current process, errors like smudges, missing prints, or wrong data can slip through, which creates compliance issues and wastes product. What they actually want is a system that prints at high speed, checks the print in real time, and rejects faulty packages automatically.For me, this makes the exercise more meaningful I can write the PRD from that requirement, move into an SRD, and then sketch a design. I’m not actually building it, but it feels like a better test case.Does that framing make more sense?

author: shabaz
author_rank: Frequent Contributor
timestamp: August 19, 2025, 06:57:29 pm
content: Worth keeping this in mind; think of the PRD as (approximately) a promise that if an engineer were to follow it, then there's a fighting chance that sales may result.A good scenario to think of, is people that ask on forums for engineers to develop a product for free, in exchange for profit from future sales. You could hypothetically test any PRD by imagining that scenario, and mentally answering the question, would an engineer start developing from that PRD no questions asked, or would it need to be altered to provide more detail and justification?Most engineers will look at a seven-line PRD and reject it, because in seven lines there's zero chance it addresses customer needs. You need to justify the requirements too.One technique to put flesh to it, is to come up with some categories and them write your requirements for each category (e.g. hardware, interfaces, etc).Be ready to answer why there is a 40 mm package requirement, when customers may well want to sell greetings cards, CDs, and so on, which are thinner.Also, engineers may ask things like what if they designed a system that performed at 30 packages per minute, and you sold the customer two of them, instead of having a 60 packages per minute requirement.I know it's a theoretical exercise, but to add meaning to it, some would suggest it's worth working on the detail to an extent, and not overly gloss over steps.

author: EVblog1
author_rank: Contributor
timestamp: August 19, 2025, 07:56:03 pm
content: Quote from: shabaz on August 19, 2025, 06:57:29 pmIn my case I’m not aiming to sell anything right now, but I get that treating the PRD this way forces me to be more detailed and closer to real customer needs, instead of just sketching an idea.Quote from: shabaz on August 19, 2025, 06:57:29 pmThe way I see it, the customer’s job is to explain their problem, and the engineer’s job is to figure out the solution. That’s why in the PRD you’ll mostly see the problem described what needs to be solved. It’s not the customer’s role to tell the engineer how to solve it. The “how” part comes later, when the engineer prepares the SRDQuote from: shabaz on August 19, 2025, 06:57:29 pmWhy, what’s the problem? From my understanding the customer’s role is to explain the problem, and the engineer’s role is to work out the solution. That’s why the PRD focuses on describing the problem, while the SRD is where the engineer defines how to solve it.Quote from: shabaz on August 19, 2025, 06:57:29 pmI’m not fully convinced about breaking things into categories like hardware and interfaces at the PRD stage.Quote from: shabaz on August 19, 2025, 06:57:29 pmThe 40 mm package requirement isn’t something I randomly picked it’s because that’s what the customer specified in PRD. If the customer is asking for 40 mm packages, then my PRD should reflect that requirementQuote from: shabaz on August 19, 2025, 06:57:29 pmI feel like you’re focusing more on the real-world sales and business angle, but my intent here is a bit different I’m mainly trying to explore, if you already have a set of requirements, how would you actually go about developing the product. That’s the perspective I’m working from. I also shared one proposed solution, but the bigger picture for me is to walk through the typical process. I strongly believe that if an engineer is developing a product from start to finish, he would naturally have to go through all the stages requirements, specifications, design, development, verification, and deployment. Does that make sense from your view?

author: shabaz
author_rank: Frequent Contributor
timestamp: August 19, 2025, 08:15:16 pm
content: That's too much for me to want to reply to, but regarding your questionQuoteI'm simply repeating myself, a bit more bluntly this time: Engineers are not dumb. They are not going to just believe you at face value. They would want to see justification (which, unsurprisingly, needs the customer needs part to have been performed). They would look at your PRD for two seconds (since you only have 7 lines in it, two seconds is quite generous!!) and send it back to you, because it's inappropriate for you to ask for engineers to work on it when you've put no effort into defining the product requirements.You can disagree all you want, but I can guarantee you you'll get a rude awakening were you to hand that to someone as a serious stab at a PRD.

author: EVblog1
author_rank: Contributor
timestamp: August 19, 2025, 08:58:43 pm
content: Quote from: shabaz on August 19, 2025, 08:15:16 pmDo you understand what I’m actually trying to do here and what I’ve done so far? I don’t know your exact experience and expertise, so let me put it another way.Imagine I’ve just started a small company that manufactures soap. The soap is ready, but I need labeling done (manufacturer’s name, batch code, weight, expiry date). I can’t rely on my workers to do this manually, because if I did, it would be too costly and waste a lot of time especially since I want to sell hundreds of thousands of soaps per day. So I thought, why not automate this process, so that both costs go down and production speed goes up.Now just assume, for the sake of this exercise, that I’ve called you in as an engineer and explained my problem. These are the requirements I’d share with you as the customer:Package dimensions: Minimum 80 × 60 × 40 mmPackage weight: Minimum 50 gPackage shape: Rectangular boxTarget throughput: 60 packages per minutePrinting requirement: Each package must have unique information printed in a fixed location.Now, if you were the engineer, what more information would you ask me for so that you could start thinking about the solution?

author: shabaz
author_rank: Frequent Contributor
timestamp: August 19, 2025, 09:19:59 pm
content: So now it's a bespoke product? Before it was for "many small sellers".Also, your thread title literally states you wanted to take the process from "project idea". But now it seems a contract role for one client.You seem to want to skip all the hard stuff. Like I mentioned, if you handed me those seven items in your PRD (which you've now reduced to five) I'd not take you seriously, because you would not have done your job. Nothing to do with the customer, it would be purely be your problem to solve.

author: shabaz
author_rank: Frequent Contributor
timestamp: August 19, 2025, 09:27:06 pm
content: Also, this part that you now mention:QuoteYou seem to mix customer requirements, and product requirements. They are not the same thing..

author: EVblog1
author_rank: Contributor
timestamp: August 20, 2025, 08:56:57 am
content: In my design (attached diagram), I need to get the exact position of each card so that the printer can print at the correct spot and the camera can take image to verify the QR code.I understand an encoder can be used for position tracking, but I’m not sure whether I should go with a single encoder or multiple encoders (for example, one for printer, or separate encoders for different for camera and rejection system

author: krish2487
author_rank: Frequent Contributor
timestamp: August 20, 2025, 01:29:54 pm
content: 1. If you want to understand how product development is done in the "real world", get a job in your field of choice. learn, think critically on the job, ask people smarter than you in the job to gain insights and gotchas.2. If you want to develop a product then pay a suitable contractor handsomely to get an acceptable solution ( it might seem expensive upfront, but a experienced contractor often saves you money in the long run)3. If you wan to develop a product based on some whims and fancies without a clear idea of what you want ( i.e no business case, no thorough understanding of where and how the product fits into your workflow, what actual real world problem you are trying to solve, or just scratch an itch) then pay the contractor twice as much as in option 2.4. Same as step 3 but you pay a cheap contractor 3 times as much during the overall project duration. The only thing you will gain is experience.What you have there are vague wishes. and a semi decent business analyst (forget an engineer, they are far more expensive) will blow your wants out of the water.Which is it? a soap manufacturing or a qr code scanner for small sellers ? both are opposite in use cases - one is mass manufacturing and the other is low volume. one is perennial manufacturing , the other not so much.One of them needs to be specced to handle the throughput of several hundreds of thousands daily, the other very infrequently.. you see where I m going with this...secondly, lets take the image you provided.. what happens if there is an error in any stage? how should it be "handled" what do you do with the already printed qr codes that have been rejected ? reworked or discarded? how about the storage of the printed codes ? 1 ? 100? 1 million ? where ?? how do you want a machine to take a printed code and move it on the conveyor belt? what should the system do when there is an error ? stop the line and wait for human intervention or discard and continue?more importantly, why not just invest in a good industrial printer with a high dpi to ensure the qr code is printed correctly? they have very very very low printing errors?You need to have a much much more clearer idea of what you want your system to do than just those bullet points..

author: EVblog1
author_rank: Contributor
timestamp: August 20, 2025, 02:26:00 pm
content: Quote from: krish2487 on August 20, 2025, 01:29:54 pmThanks for sharing your perspective. I’m approaching this as a hobby project, not as a commercial product. My main goal is to learn how engineers go through requirements and make design decisions in a systematic way.I’ve already gone through the basics of embedded systems, Protocol's and develop mini projects and now I want to challenge myself by attempting a more advanced project that I find interesting. That’s why I’m asking these kinds of technical and design questions. For me, this exercise is less about building a finished, production-ready system and more about understanding the thought process behind solving real-world problems.Even if I can’t complete everything exactly as it would be done in industry, I want to follow the same steps requirements, specifications, design, development, and testing because I believe that’s how I’ll really learn.Quote from: krish2487 on August 20, 2025, 01:29:54 pmActually, I wasn’t trying to define an exact business case like soap manufacturing vs. small sellers. What I was really looking for was a use case where information is printed on a card/package and then verified . So I just came up with an example scenario to work with, to make the problem more concrete.Quote from: krish2487 on August 20, 2025, 01:29:54 pmYes,this is exactly the part I want to discuss more deeply,so thank you for raising it. For example, if the system detects a continuous series of 10 defective cards, it should generate an alert message and stop the production line to minimize losses. The reason for stopping at that point is to reduce waste and minimize losses, instead of continuing to produce more defective items.Regarding rejected cards, once a QR code is found to be defective, that card cannot be reused or reprinted. All such cards will be diverted and collected in the reject bin shown at the end of the conveyor in the diagram. Right after the reject bin, I am planning to add another collection bin for the verified (good) cards so that separation is automatic and clear.As for the card movement, you can see in the image that at the start of the conveyor there is a vertical frame that holds the stack of cards. From the bottom, each card is released and moves onto the conveyor belt in sequence, which then carries it through the printing and inspection stages.Of course, I understand that industrial-grade printers with high DPI are designed to minimize printing errors, and yes, they can provide very reliable results. However, in my concept, verification still has the highest priority. Even with a high-quality printer, errors can happen occasionally due to any factors By verifying every printed card, the system ensures that only correct and readable card reach the final collection bin, while any defective ones are automatically rejectedIn short, my main focus here is to design a system that not only prints but also actively verifies and handles errors in a controlled way with alerts, automatic rejection, and proper collection of both good and defective cards. That’s the part I’m most interested in learning

author: krish2487
author_rank: Frequent Contributor
timestamp: August 20, 2025, 08:14:41 pm
content: I get your enthusiasm.. and I appreciate it.But you do really need a much much better test bench project.for one, it sounds like a LOT more than you are prepared to chew. pick a much much simpler project to get started. maybe make a fancy widget or an iot gadget that measures temperature, pressure, humidity in the room.. maybe build lcd dashboard using esp32 that retreives the aforementioned data from a database and displays them on the screen. make a fancy enclosure for it. think of where you would mount it.. what size, shape and weight should it be.. how would you power it... battery powered or not.. how long should it run on a battery.. what other quality of life improvements would like to see on it? backlight?? rtcalarmsmaybe some sort of automation to your thermostat?pick your poison and define what you would like to see in such a gadget.. really think about it.. implement it.. you ll find something missing or incorrect or wrong.. fix your mistakes and do over. rinse and repeat...and second... a good engineer would simply add the scanner stage when they print the cards... not as an afterthought.. thereby making the use case irrelevant. there is no case where such a machine would make economical sense..

author: EVblog1
author_rank: Contributor
timestamp: August 20, 2025, 08:53:24 pm
content: Quote from: krish2487 on August 20, 2025, 08:14:41 pmI’ve come across some videos of machines that do something very similar printing and verifying codes on cards/packages. That’s what gave me the idea to explore this kind of design as a learning exercise.https://youtu.be/QmKO81sk7f4https://youtu.be/diRuuLFvPDghttps://youtu.be/x0FYg2WEJZM

author: rf-fil
author_rank: Regular Contributor
timestamp: August 27, 2025, 05:36:20 am
content: QuoteThere is a whole field of knowledge about this. The INCOSE Guide to Writing Requirements is a formal description of it. And it can't be easily summarised in a quick post. You need about a week's worth of training from one of the systems engineering consulting companies to explain the process to you, and then a bit of real world practice. Many (most) engineers actually don't know how to do this properly. Poorly captured requirements is a common cause of projects failing.More broadly, the two disciplines that cover what you're talking about are project management, and systems engineering. You can get PMBoK certificate to learn how to do project management properly. There are similar things for systems engineering.Btw, your example project is a bit limited because the hardest thing about real world projects is working with stakeholders - clients, management, your own teams, external suppliers, etc.A life-hack: If you are good at your engineering discipline + you know how to capture requirements properly + you know how to project-manage ==> super power.Btw, companies with the core business of product development usually have a role of product managers. Those are the guys that figure out what the product roadmap should look like (+ marketing teams).