“Discipline is doing what you really don’t want to do so that you can do what you really want to do.”
– Jeff Fisher
Thomas Edison famously remarked that genius is 1% inspiration and 99% perspiration. In the world of product development, I often frame it this way: Success is 10% inspiration. and 90% perspiration.
The specific percentages don’t matter as much as the relationship between them. Inspiration is the spark—the “Eureka” moment—but it is transitory. Without a disciplined approach, the “perspiration” (the routine, the documentation, the testing) becomes chaotic. It overwhelms the team, draining the time, energy, and mental clarity required for that vital 10% of creative thinking.
Discipline is a “mindset”
Discipline is often misunderstood as rigid hierarchy or “doing drills.” In product development, discipline is a mindset. It is the belief that systems should not be bypassed and rules should not be broken just to save a few hours today.
True professionals understand that following a systematic approach—even the “boring” parts like scheduling and reviews—is what keeps the mind free for innovation. To achieve this, we must focus on two pillars: The Process Approach and Adequate Documentation.
The Process Approach (Macro vs Micro)
Process discipline exists at two levels: the organization and the individual.
Organization processes (The Macro)
Most companies follow standards like ISO 9001, which treat design as a “black box” where inputs are transformed into outputs. While top-level Quality Management Systems (QMS) are necessary, they are rarely enough to guarantee a great product. They ensure the organization is compliant, but they don’t always ensure the engineer is effective.
Personal Processes (The Micro)
This is where the real work happens. A Personal Process is the set of habits an individual uses to achieve results. Inspired by the Personal Software Process (PSP) from Carnegie Mellon University, I believe these principles should be second nature to every developer not restricted to Software Development:
- Understand: Grasp the task and expectations fully.
- Estimate: Gauge the work and time required before you start.
- Check: Ensure all resources and information are ready.
- Design: Cover all requirements and hidden expectations.
- Implement: Execute with meticulous attention to detail.
- Verify: Check if the implementation matches the design.
- Refine: If it fails, redo it immediately—do not pass the error forward.
The product developers need to make their personal processes a second nature. Skipping these steps under time pressure is a trap. A skipped step today is a technical debt that will cost ten times more to fix tomorrow, and resources to fix the problems later.
Orgazional and Personal Processes Compared:
| Feature | Organizational Processes (Macro) | Personal Processes (Micro) |
| Participants | Cross-functional (“Actors”) | Single individual |
| Time Span | Weeks or Months | Hours or Days |
| Documentation | Elaborate/Standardized | Minimal (Checklists, Notebooks) |
| Goal | Compliance and Predictability | Self-improvement and Quality |
Documentation: Know What, How and Why
In Product Development, output is not just prototype; it is essentially “Prescription for Manufacturing”. If your documentation is weak, your prescription is unreadable. I classify vital documentation into three categories:
Know-What: The blueprints (Drawings, layouts, schematics, BOMs, specifications…)
Know-How: The methods (Standard Operating Procedures (SOPs), Work Instructions, calibration steps…)
Know-Why: The rationale (Architecture, Technical Decision Logs…)
Know-Why is the most neglected area of development.
When a part becomes obsolete five years from now, the “Know-Why” documentation allows future engineers to make informed changes without breaking the system.
I never created Know-Why related documents during my period as a design engineer and Development Manager, though I included some notes about critical components and architecture in my Lab Notebook. I realized importance of this during my consulting assignments later.
Case Study: The Danger of Missing “Know-Why”
During a consulting project to redesign an electronic product due to component obsolescence, and different packaging requirements, we discovered there was zero “Know-Why” documentation. None of the original designers were available to explain the rationale behind specific component choices.
The Solution: We applied a Risk-Based Approach. We identified that only about 20% of the components were critical to specifications, safety and compliance. By focusing our engineering judgment and environmental testing on those “critical few,” we successfully finalized a new design that was an astounding success.
The Lesson: If that 20% had been documented originally, the redesign would have taken a fraction of the time and reduced risk.
This has strengthened my belief that the company, the teams and individuals must finalize a Risk-based process for preparing No-Why documents.
Best Practices for the Disciplined Developer
To keep your discipline from becoming “red tape,” follow these five rules:
- Be Lean: Documentation should be the minimum required to be effective.
- Be Clear: Aim for concise, correct, and complete and understandable information. Consider using diagrams, pictures, videos instead of, or together with, verbose documents
- Stay Synchronized: Update documents as the project evolves, not as an afterthought.
- Stay Realistic: Documents must reflect the “as-is” reality of the product, not an idealized version.
- Risk-Based approach: Follow a risk-based approach to decide what and how much to document. Focus your documentation on aspects that affect safety, regulatory compliance, or core performance
Summary and Key Take Aways
- Discipline protects inspiration: It clears the mental clutter so you can innovate.
- Personal Processes matter: Organizational rules provide the framework, but personal habits provide the quality.
- Capture the “Why”: Documentation is a gift to your future self and your successors.
In the next blog, we will tackle Commandment 2: Embrace Uncertainty. We’ll discuss why “frozen specifications” are a myth and how to stay agile when the ground shifts beneath your feet, customer changes the specifications, market changes.
What is the one “boring” part of your process that has saved you from a major failure? I’d love to hear your stories in the comments.
Precise and to the point.