If client wants to make board like raspberry and your company is shortlisted for the project. How do you discuss a project when you meet with a client?

If I were in the meeting, I would ask the following questions:

1) What should be the speed of your board?
2) How much memory do you need for storage
3) Do you want to connect the monitor, keyboard with your board
4) Do you want to connect the camera with your board
5) Do you want to connect the Mike and speaker with your board
6) Do you want wi-fi bluetooth Features in your board
7) How many GPIO do you want in your board
8) Do you want gps in your board.


I am well aware that making this type of board requires a lot of experience and skill. The focus of this question is to ask only the requirement. I know experience person asks customers about product requirements in meetings. I know that there are many experienced people here who do this work or done this work many times, so I want to ask them a question here.

What questions would you ask the customer ?

 

If you were already a prospect for this project you'd have responded to some sort of RFP (Request For Proposal) or other solicitation. If you hadn't been provided with this information that phase, it would be very surprising and it would mean that you would have to tell them what they needed.

In such a meeting you would be negotiating price and production schedules, not doing basic discovery.

You are better off thinking about projects of the sort you are more likely to encounter where you need to do discovery, that is, you need to find out what functionality the client needs in the final deliverable.

Remember, the client is the expert in the problem to be solved not in how to solve it. The information you need is about what needs to be done and how they want it to look from the user's perspective.

 

Remember, the client is the expert in the problem to be solved not in how to solve it. The information you need is about what needs to be done and how they want it to look from the user's perspective.

The client has told you problem that he needs a universal board like Raspberry Pi. Will this information be enough for you to make a universal board? I don't think it's enough.

 

The client has told you problem that he needs a universal board like Raspberry Pi. Will this information be enough for you to make a universal board? I don't think it's enough.

That's not a thing. The process doesn't work that way.

Your example is far too artificial. In real life, any client who wanted a design to compete with the RPi would have a lot of information already at hand and your list of questions would be silly, or, if not I wouldn't touch that job with a 10 foot pole.

There is so much value engineering required for a complex device like this that the real questions would be around sourcing parts to save pennies and production methods, not which peripherals should be on the board.

 

In real life, any client who wanted a design to compete with the RPi would have a lot of information already at hand.

What kind of information can they have?

Will the client tell you what speed they need, how much memory space they need, what keyboard or monitor is connected, they need bluetooth wi-fi gps etc. This is all the information client gives you you don't ask them this information

 

What kind of information can they have?

Will the client tell you what speed they need, how much memory space they need, what keyboard or monitor is connected, they need bluetooth wi-fi gps etc. This is all the information client gives you you don't ask them this information

Any client that would provide an outside contractor with such basic information at the beginning of an investigation only after being asked wouldn't be creating such a project, they would buy the RPi. The complexity of something like the RPi means it is a multidisciplinary team project and so there would never be a meeting that went the way you propose.

There would already be a specification at least as detailed as your questions. The meetings would be about cost and schedule.

 

Yours is rather a contrived example - the sort of company that designs Raspberry Pi‘s is likely to be company that already designs that sort of thing. You are much more likely to be dealing with someone with a little (and probably a dangerous amount) electronics knowledge, who would be more interested in the shape and colour of the box than what goes on inside it. The interaction with the client will vary with the type of industry and the national culture.
I did a lot of design work for special needs education, my most successful strategy was to take along a nice A4 size notebook and a fountain pen, and draw what I thought the customer wanted. Then discuss it and amend it, then draw it again. Drawing it in front of the customer seems to work better than a 3D CAD drawing done ahead of time. You score even more points if you can draw the client’s logo on the drawing of the proposed product.
Then write up a technical spec, because the written spec is what forms the legal part of the contract.
Some drawing skill is required, but it’s not the Sistine Chapel!

 

There would already be a specification at least as detailed as your questions. The meetings would be about cost and schedule.

Thanks, I came to the conclusion that the client gives us the specification list which tells what kind of board the client needs.

e.g. list of specifications

• Speed : 1.2 GHz
• Processor: ARM
• Memory : 1 GB
• GPS features
• Number of USB 2.0 ports: 4
• Port extension: 40-pin GPIO
• Video outputs: HDMI
• Audio outputs: 3.5 mm stereo jack or HDMI
• Data storage: MicroSD card
• Network connection: 10/100 Ethernet, 802.11n WiFi and Bluetooth 4.1 (BLE - Low Energy)
• Peripherals: UART, I2C, Timer ADC interrupt
• Supply: 5V 2.5A via micro USB
• Dimensions: 85.60 mm × 53.98 mm × 17 mm

Will the technical team start designing the product after having such specifications?

 

Much more important than those things is the reason for making the new board.

There has to be a business case for it. The cost of development has to be recovered, so there must be a competitive advantage to the design. Cost, reliability, functionality in some peripherals, something that would differentiate the board from what is available.

Whatever that is, it will drive the design as it is optimized for that goal. None of the items are your list are design goals, and every one of them should be subject to change as the actual design goals are worked towards. After all, the RPi is open source, so if I wanted to manufacture an RPi-like board, why wouldn’t I just build one? It also has a very large software base and tool chain. So something has to be compelling about the new design to begin the project. What is that thing? That is the question the client must answer and the design team ,use work to create.

As an example, I might expect something like: “we need an ultrahigh reliability RPi compatible board with on board BLE and WiFi, as well as solar power controller. It must have a very low consumption sleep mode as well”.

That would make some sense to me. Not a specification list.

 

Much more important than those things is the reason for making the new board.

That would make some sense to me. Not a specification list.

Just for curiosity I am trying to find out how microcomputers are designed by big company. How would you design a microcomputer for your hobby? Being an electronics student this question came in my mind so I asked it on the forum.

So in the discussion so far it has come out that if we want to design a product, first of all we should know the specification of the products. My next step should be that I should have a list of specifications of the microcomputer I want to build.

 

No. The first thing you need to know is the design goal(s). Those drive the specifications.

actually designing an MCU board or one that uses a CPU is not something I do or have done so I will leave it to others to help you with that. But, always remember, design goals should drive every decision including specifications, and design goals are not specifications themselves.

 

No. The first thing you need to know is the design goal(s). Those drive the specifications.

The goal is clear to design a microcomputer that can be used for a hobby IoT project. Apart from this, I have no other reason

Obviously there are many boards available in the market, but I don't want to use them. because i also want to learn to design boards. And the benefit of all this will be that my thinking ability will increase, many real problems will come in front of me, which I will try to solve.

 

Hello,

Discussing the details of a design can make a huge difference.

This makes me think of this old joke:

Bertus

 

The goal is clear to design a microcomputer that can be used for a hobby IoT project. Apart from this, I have no other reason

Obviously there are many boards available in the market, but I don't want to use them. because i also want to learn to design boards. And the benefit of all this will be that my thinking ability will increase, many real problems will come in front of me, which I will try to solve.

If you were my client, your “goal“ would make me fire you. It’s not something that can be designed to. It doesn’t have enough specificity to succeed at the project. How would you know that to do, or if you’d done it when you are finished?

How many different boards fit that “goal”? In this case, you are the client. The goal you stated isn’t your goal, it’s actually part of the very high level specifications. The second point is actually a real goal. You want to design a board to learn how.

Given this, you need to add to it. Are you planning to write all the software for it? Seems unikely, so one goal for you might be something like “It should be Arduino library compatible”. If this is a goal, then you now know that you must use hardware such as processor and peripherals that are easily compatible with Arduino libraries.

You mentioned IoT. This probably means you need low power consumption, a real goal. It also means you probably don’t need something like an HDMI interface, so you wouldn’t see that in the specifications list. But maybe you don’t really mean IoT but instead you want something that can run a general purpose operating system after you think for a while.

This iterative process in design is expected. It can even include making prototypes that are abandoned because after trying them the shortcomings inform the next iteration.

What you are asking for is to create something in a near vacuum of information. Since you are the client in this case, do what you would do for a client and tell yourself to write some “user stories”. That is, come up with a few real world scenarios of how you will expect the application of this board to look from the user perspective.

This is just a narrative about normal activities using it. Not any sort of specifications. For example:

“The user will develop code and program the using the Arduino IDE without interaction with the hardware (e.g.: disconnecting or pressing a button”

”The user will develop an automatic plant watering system using moisture sensors and Internet-based weather reports, as well and some machine learning using only on-board peripherals using solar power”

This general idea of how your device will behave when it is a real thing instead of just an idea will drive the specifications. Once you have an idea about the specifications, you will need to research which processor and peripheral hardware might be good. Then you will need the datasheets and application notes with their reference designs and also competing products which you can inspect and reverse engineer to see how this was successfully done in the past.

You are very resistant to my advice because you don’t want to go in order, but skipping steps is the road to failure. A system I developed with a colleague which is valid in various ways for all projects is called “4D”. It refers to the 4 phases of the process:

• Discovery
• Design
• Development
• Deployment

Discovery is that first step where you do the goal setting based on researching what the system must do to be successful.
Design usually includes the specification list, as well as the physical and logical description of the system.
Development is where code, boards, and other physical parts are assembled into the system.
Deployment is actually putting the system into use.

This process is not necessarily linear. Each step feeds the next and the following step can require backing up to the previous one before completing it. It is a circular, iterative process. Deployment moves right into Discovery again. This time it is focused on seeing how the system operates relative to the design goals and where it needs improvement, then on to each step in turn and back around again.

Additionally, in each step, the 4D process Is used in a smaller way. For each subsystem, 4D is applied, so inside Development, for example, each of the other steps exists.

This is not a rigid ruleset. Sometime phases can be combined like Discovery-Design depending on the nature and scale of the project, but in some way all of the phases must be present for success.

Good luck, I’ve given you all the help I have to offer.

 

”The user will develop an automatic plant watering system using moisture sensors and Internet-based weather reports, as well and some machine learning using only on-board peripherals using solar power”

@Yaakov Thank you, I liked your project idea "automatic plant watering system based on the weather". it will be a good project for learning. I will do more research on this project.

 

If I were in the meeting, I would ask the following questions:

Hi P,
Amongst the top of my list in the first meeting with a potential client, regarding a product design they are proposing, is what is their budget target price for the product design, and their required timescale for completion of a design/prototype and possibly a preproduction batch.

In the real-world, build cost/price and selling price are controlling factors for any product.
If you design and manufacture your own products, sales quantity is also important for amortizing the design costs over a given sales quantity.

The designer company has to make a profit on any design work done for the client, a required short design timescale will cost the client more.

As a principle, never give the client a price or delivery date without first agreeing a written specification.

E

 

The goal is clear to design a microcomputer that can be used for a hobby IoT project.

Then my first question would be:

“I am a hobbyist. Why should I buy your board instead of an ESP32 or Pi Zero?”

Bob

 

Remember, the client is the expert in the problem to be solved not in how to solve it. The information you need is about what needs to be done and how they want it to look from the user's perspective.

Perfect summary of the first rules of contract engineering.

 

Then my first question would be:

“I am a hobbyist. Why should I buy your board instead of an ESP32 or Pi Zero?”

Bob

I really didn't want to make a microcomputer, I had to do research work on it, how can it be designed. I have already clarified that this thread is only focus to understand how the products are designed. To understand it.I took an example microcomputer. I believed that I could learn a lot if I thought about designing a microcomputer.

i split it in three parts

1) Products specifications
2) Hardware description
3) software description

I can go into more detail but now it is not right to go into detail because my idea has already been rejected

 

Remember, the client is the expert in the problem to be solved.

Yes. NEVER disagree with the client about this!