Foundations audit

Eight questions about your product development process

Things that cost very little while the system is young and a great deal to retrofit once devices are in the field. None of them are the product, which is why they lose every scheduling argument they are ever in.

Eight questions, about five seconds each. Answer them the way the system works today, not the way the plan says it will work next quarter.

Nothing leaves your browser. No email box at the end, no score sent to me, no follow-up sequence. Your answers persist between visits, and the link at the bottom carries them, so you can compare notes with someone else on the team.

01 / Know what you shipped

Identity is the cheapest thing to add and the most expensive to reconstruct.

Does every board, assembly, cable, and purchased component have an easy to read identifier that carries meaning and stays stable as the design changes?

Without one, the same part gets ordered twice under two names, and a year from now nobody can say what went into build three.

Can you quickly identify what sits on a given customer's floor, what went into it, and which units share a suspect batch, without sending someone to look?

The day a supplier tells you a batch was bad, this is the difference between recalling three units and recalling all of them.

02 / Change what you shipped

A machine you cannot reach is a machine you cannot fix.

Does every machine report what it is doing, with configuration flowing back the other way, so problems can be diagnosed and settings changes without a site visit?

It turns a support call into a diagnosis, shows a worn part before it fails, and tells your engineers which numbers to design against next.

Was the update path built and exercised on the first boards, before any unit shipped?

Deployed units require it eventually. Building it early speeds up development immediately, which is the part teams do not expect.

03 / Rebuild what you shipped

A year from now, someone has to reproduce exactly what a customer is running.

Is every firmware image, board revision, and configuration set versioned, tagged, and tied to the machines running it?

A regulated customer will eventually ask you to produce this record. So will you, the first time a unit misbehaves and nobody can say what is on it.

Can automation rebuild the whole system from source: firmware, PCBs with their BOMs and fabrication outputs, Linux images, backend services, and test tooling?

Any step that lives in someone's head is the step that breaks a release, usually during the week that person is out.

04 / How the team decides

Two habits decide whether what the team learns stays with the company.

Do design discussions, questions, and decisions happen where the whole team sees them, in issues and pull requests next to the code, rather than in one-to-one threads?

Knowledge in a private thread leaves when the person does. Visible discussion is what makes outside review worth anything at all.

Does a change start with documentation and a spec, before design and code?

AI now writes code faster than anyone can review it. Starting from the document lets a reviewer see the whole system instead of one file at a time.

These are simple, obvious things, but sometimes the hardest things to find the discipline to do and get right.

In the rush to get the features shipped and the hard things done, we skip the basics that let us do it again and again, with ease and confidence.

The verdict

What your answers add up to

Answer all 8 questions and the summary appears here. Reading it on paper works too: print the page and take it to the next planning meeting.

Thoughts, questions?

Is something missing, tell me about it. If the answers pointed at something you want to fix, the first conversation is free and there is nothing to prepare.